3

Let me explain. I have a data class that is little more than an instance of NSMutableArray. I've added a property of currentItem. When my app launches, an instance of this class is made and then shared with several view controllers.

When any of those view controllers sets the current item ([myClass setCurrentItem:(MyItem*)item] I want to notify all of the view controllers so that they can update their UI etc...

I am conflicted about the best way to implement a solution. I could either:

1.) Use a custom protocol, have my class keep track of a collection of delegates by adding a method addDelegate:(id)instance, keep the collection of delegates in a NSMutableArray ivar, then iterate and communicate when currentItem is set.

OR

2.) Use NSNotification center to do this communicating when iVar is set.

Calling order doesn't matter to me as far as the delegates go.

Which approach is better suited for this situation? It seems to me that option #1 would be the cleaner way to do it, but my search results for "multiple delegates" suggests that I should use NSNotification center when there are multiple delegates, but not much reasoning behind it.

What is your opinion and why?

VaporwareWolf
  • 10,143
  • 10
  • 54
  • 80
  • 1
    I'm not sure what you mean by multiple delegates. Delegates of what? Personally, I think the notification method is cleaner -- you send out one notification, and any object that registers to see it can. Seems pretty straight forward to me. – rdelmar Jul 24 '12 at 05:56
  • I agree with rdelmar. Using notifications is a much more cleaner and elegant way than using an array of delegates. I guess delegates and notifications are the same thing, but delegates are specifically for one object (or a number of them you specify, I guess...) and notifications will be received by any class in your app that specifies it. – TheAmateurProgrammer Jul 24 '12 at 06:06
  • Thanks everyone. Why do you consider it to be elegant to use NSNotifications? I understand that it's cleaner in that I'd be using some canned goods instead of having to write the functionality. I would think that you'd want to limit the number of notifications to send out. I'm sure it's very little overhead though. – VaporwareWolf Jul 24 '12 at 06:55
  • the elegant using of the `NSNotificationCenter` is [here](http://stackoverflow.com/questions/11229830/delegate-how-to-use/11230990#11230990). – holex Jul 24 '12 at 10:44

1 Answers1

1

I think the comments above sum up some of the thinking, but I just wanted to add a couple of thoughts:

When any of those view controllers sets the current item ([myClass setCurrentItem:(MyItem*)item] I want to notify all of the view controllers so that they can update their UI etc...

This implies you're updating all your UIViewControllers even if they are not visible. You don't state which platform you're developing for, but in general I'd aim to only have controllers update when they absolutely need to (ie. when they are visible to the user). In which case you have the option of putting logic in viewWillAppear: and/or viewDidAppear: to check your model (ie. the NSMutableArray) and update the views appropriately.

Now, the question of whether to use NSNotifications or protocol methods and delegates is a tricky one. I guess there are a few things to consider:

  1. Do you have a single object that owns or manages your class? Generally, this would be appropriate for a delegate - think UITableView, for example.
  2. Do you want to ensure a single object must implement methods on events - again, a protocol can ensure methods are implemented and makes documentation clear.

Otherwise notifications are pretty handy. Look at the standard frameworks and take guidance from them, but realise a lot of it is just a judgement call. Look at UITextField, for example - it uses a UITextFieldDelegate protocol, but also creates notifications. I'm sure there's a great reason, but would probably need to spend some time thinking about it...

Edit: For completeness, as you mention:

2.) Use NSNotification center to do this communicating when iVar is set.

Key-Value Observing (KVO) allows you to register for notifications directly with object instance variables.

From the iOS 5.1 documentation:

Key-value observing is a mechanism that enables an object to be notified directly when a property of another object changes. Key-value observing (or KVO) can be an important factor in the cohesiveness of an application. It is a mode of communication between objects in applications designed in conformance with the Model-View-Controller design pattern. For example, you can use it to synchronize the state of model objects with objects in the view and controller layers. Typically, controller objects observe model objects, and views observe controller objects or model objects.

I'd add a link to the docs but don't have my bookmarks with me at the moment.

ChrisH
  • 904
  • 6
  • 13
  • That is a good point about KVO. I hadn't considered that, and it may just be a handy solution to my problem. Also, you bring up good points about updating non-visible views. I actually was starting to second guess my technique just before I read your post. This should be easy to fix by using the correct methods as you mentioned, or some sort of flag in my model class. Thank you for your response. – VaporwareWolf Jul 26 '12 at 22:19