Is this a valid use of NSNotificationCenter

Question

I come from a .NET web application background and have just started iOS development. The initial design of my app focuses around the NSNotificationCenter. I was reasonably happy with this until I saw various posts explaining how reaching for the NSNotificationCentre was a common newbie mistake.

Here is a simplified version of the problem I am trying to address:

My application is trying to show a list of messages that are populated using web service calls, think Facebook messaging.

When the app is first loaded it pulls a collection of messages from the server and displays them in a table to the user. The user can add new messages (which get sent back over the API) and the app can receive Push Notifications about new messages which are added to the feed.

The messages are never persisted to disk so I'm just using POCOs for the model to keep things simple.

I have a MessageFeedController which is responsible for populating the message feed view (in a storyboard). I also have a message feed model, which stores the currently retrieved values and has various methods:

• (void) loadFromServer;
• (void) createMessage: (DCMMessage*) message;
• (void) addMessage: (DCMMessage*) message;
• (NSArray*) messages;
• (int) unreadMessages;

The current implementation I have is this:

Use case 1 : Initial Load

1. When the view first appears the "loadFromServer" method is called. This populates the messages collection and raises an NSNotificationCenter event.
2. The controller observes this event, and when received it populates the tableview

Use Case 2: New Message

1. When a user clicks the "add" button a new view appears, they enter their message, hit send and then the view is dismissed.
2. This calls the createMessage method on the model, which calls the API
3. Once we have a response the model raises the NSNotificationCenter event
4. Once again the MessageFeedController listens for this event and re-populates the table

Use Case 3: Push Message

1. A push notification is received while the app is open, with the new message details
2. The AppDelegate (or some other class) will call the addMessage method on the model, to add it to the collection
3. Once again, assuming the MessageFeed view is open, it re-populates

In all three cases the MessageFeed view is updated. In addition to this a BadgeManager also listens to these events which has the responsibility of setting the app icon badge and the tabbar badge, in both cases the badge number relates to the number of unread messages.

It's also possible that another view is open and is listening to these events, this view holds a summary of messages so needs to know when the collection changes.

Right, thanks for sticking with me, my question is: Does this seem like a valid use of NSNotificationCentre, or have I misused it?

One concern I have is that I'm not 100% sure what will happen if the messages collection changes half-way through re-populating the message table. The only time I could see this happening is if a push notification was received about a new message. In this case would the population of the table have to finish before acting upon the NSNotification anyway?

Thanks for your help

Dan.

Answer 1

NSNotifications run the receivers code synchronously as soon as they are posted, so a new message during repopulation would join the back of that execution queue. On the whole it seems valid to me, and it keeps a reasonable degree of separation between The view controllers and the model.

Depending on the number of classes that are likely to want to listen for the same information arriving, you may want to use a delegate pattern, maybe keeping an dictionary of delegate objects, but I personally don't feel as though this scales so well, and you also have to take care of nil-ing out delegates if a page is dealloced to avoid crashes. To sum up, your approach seems good to me.

Answer 2

In my opinion using a delegate protocol pattern would be a much better fit for this scenario. Consider the scenario where your "api layer" needs used across many view controllers in an application. If another developer were to be introduced to your code, they would have to hunt around for notificationcenter subscriptions instead of just following a clean 'interface' like protocol.

That being said, your code will work just fine and this is a valid use of notification center. It is just my personal preference for 'cleaner' code to use a protocol based approach. Take a look around in the iOS SDK itself and you will see scenarios where Apple themselves use protocols and use notifications. I feel it is much more easy to comprehend and use the protocols than having to dig around and determine what I must listen to for a notification.

Answer 3

In other words, you're posting a notification whenever the message list is updated. That's a perfectly valid use of NSNotificationCenter.

Another option is to use Key-Value Observing.

Your controller (and anyone else) can register as an observer to the "messages" property, and will be notified whenever that property changes. On the model side, you get KVO for free; simply calling a method named setMessages: will trigger the KVO change notification. You can also trigger the notification manually, and, if so desired, the KVO notification can include which indexes of the array have been added, removed, or changed.

KVO is a standardized way to do these kinds of change notifications. It's particularly important when implementing an OS X app using Cocoa Data Binding.

NSNotificationCenter is more flexible in that you can bundle any additional info with each notification.

It's important to ensure that your messages list is only updated on the main thread, and that the messages list is never modified without also posting a corresponding change notification. Your controller should also take care to ignore these notifications whenever it is not the top-most view controller or not on screen. It's not uncommon to register for change notifications in viewWillAppear: and unregister in viewWillDisappear:.