When to use NSNotificationCenter

Question

I want to have multiple observers on multiple events of a single object (1-to-N relationship).

A mechanism to achieve this task is provided by the NSNotificationCenter. The mechanism looks pretty overkill when used for my problem.

How I would do it manually without the use of NSNotificationCenter:

- (void)addDelegate:(id<DelegateProtocol>)delegate;
- (void)removeDelegate:(id<DelegateProtocol>)delegate;

to add and remove observers from my object.

- (void)someEventFired:(NSObject<NSCopying> *)eventData
{
    for (id delegate in delegates) {
        NSObject *data = [eventData copy];
        [delegate someEventFired:data];
    }
}

This mechanism is straight-forward and simple to implement without the objects having to share additional strings.

Is there an official pattern for 1-to-N delegates (like C# events) in an iOS framework besides the NSNotificationCenter?
When should the NSNotificationCenter be used and when not?
When should an implementation like the one I am suggesting here be used and when not?

I rarely, or ever, made use of NSNotificationCenter but went with the same method you describe. I've used this in numerous iOS apps (I'd say above 50 apps) for many years, I haven't seen any problem with that so far. A possible gotcha could be that you need to be certain to remove observers at times, or they might not get released when expected because they are retained by the keeper of the delegates. — Jonny, Dec 05 '14 at 08:37
I think that even though NSNotificationCenter is not the approach that we know from C#, we should still focus on using the design patterns for the specific platform we are working for. That said, I went with NSNotificationCenter in several apps now (not as many as you, though), and I don't think that the code became worse through it. — Etan, Dec 05 '14 at 12:20

Sebastian Celis · Accepted Answer · 2012-05-31T15:33:24.100

By convention, delegates should probably only be used for 1:1 relationships. If you really need 1:N relationships for this type of functionality, you have two options:

As you mentioned, NSNotificationCenter.
Key-Value Observing (also known as KVO).

KVO is appropriate if you only care about when a particular property of an object changes. Otherwise, you should really just consider using NSNotificationCenter. You can even be notified only when a specific object posts that notification by passing that object into the addObserver:selector:name:object: method.

Apple uses NSNotification in similar scenarios (like the notifications defined for UITextField, including UITextFieldTextDidBeginEditingNotification, UITextFieldTextDidChangeNotification, and UITextFieldTextDidEndEditingNotification).

Can you tell me if I'm using it right? http://stackoverflow.com/questions/42111829/share-object-state-between-view-controllers-in-ios-development/42113389#42113389 — Leandro De Mello Fagundes, Feb 10 '17 at 13:20

score 2 · Answer 2 · answered May 31 '12 at 15:32

using notifications is broadcasting: 1 sender just sends an information and who ever tuned in, receives it. Petty much like a radio station, there is no channel back (lets for the moment forget about telephones)

delegation is something different. Th object, that asks a deleagte to do something, usually needs a result of that request, there fore delegation is a 1-to-1 communication, that is always initiated by the object, not the delegate (while the object can have methods that can be called to inform the object to initiate the communication, ie [tableView reloadData]).

So if the sender needs to get data back, it is delegation. If the sender doesn't care about anything after broadcasting, go with notifications.

If you run into the situation, that you need delegation, but several objects should implement the protocol. you should have 1 delegate, that hold references to the other objects and calls the methods on the senders behalf — or you could go with blocks.

Today I would just have one object that all VCs share and that informs them. — vikingosegundo, May 13 '16 at 10:26

score 1 · Answer 3 · answered May 31 '12 at 15:27

NSNotificationCenter is not overkill for what you are suggesting, it is exactly the right solution. It prevents the observed object having to know or care about its observers, making your code more loosely coupled and cleaner.

Sharing strings for notification names is trivial and they can be defined in either a shared constants file or in the header of the observed object, if your observers need to import this header to do their jobs.

score 1 · Answer 4 · answered May 31 '12 at 15:46

Your proposed solution is neither simpler than using NSNotificationCenter nor is it thread safe.

To make your solution thread safe, you would need to provide a mechanism to prevent the delegates array from changing while the event dispatch for loop is running.

Your solution also requires that you maintain the delegates array in your class. With the NotificationCenter you can simply use the default center and you don't need to implement the add/remove methods in your class. Instead, instances can register themselves to receive notifications as they see best fit (selector/block, queue, source). Your source class doesn't have to worry about those details. It only needs to register itself as a source of notifications of a specified type. Using blocks to handle notifications is really convenient.

An alternative to the notification center is to use Key-Value-Observing if that meets the needs of your use case.

Ultimately, the mechanism you decide to use depends on how best it applies to your specific use case.

score 0 · Answer 5 · answered May 31 '12 at 15:30

A 1-to-N delegate relationship doesn't make sense. Have a look at

- (NSView *)tableView:(NSTableView *)tableView viewForTableColumn:(NSTableColumn *)tableColumn row:(NSInteger)row

for example. What if this object really had n delegates? How should it decide which of the n views it gets back from all its delegates should be used? Delegates are exactly this 1-to-1 principle.

The NSNotificationCenter is the right approach. Simply use

addObserver:selector:name:object:

respectively

postNotification:

This is definitely not too much code. And it's very easy for you as the center handles all calls.

score 0 · Answer 6 · answered Nov 24 '17 at 08:20

You don't want to use NSNotificationCenter for anything other than system-wide events (e.g. the appearance of the keyboard or some similar event). The reason is that it is completely not type-safe, can make everything dependent on everything and that you get no compile time checks or usage search results anymore.

KVO in my opinion should not be used to observe changes outside of the object you're listening to since it has similar down sides (no compile time checks, crashes if you don't remove listeners properly or register them twice).

The addDelegate/removeDelegate pattern that you pose is completely the right path in my opinion since that has the advantage of maintaining type-safety and compiler checks and makes dependencies explicit. The only problem is that Apple doesn't supply an out-of-the-box solution for this pattern, since you need a collection type that weakly retains its elements to avoid retain cycles.

However, see code from my BMCommons framework which solves this problem neatly using BMNullableArray and macros. See the BMCore.h header for a definition of those macros:

BM_LISTENER_METHOD_DECLARATION(protocol)
BM_LISTENER_METHOD_IMPLEMENTATION(protocol)

The implementation ensures that the same listener will never be added twice and also that listeners are weakly retained, not causing any crash even if they forget to deregister themselves upon deallocation (although I prefer to catch this condition with an assert since it is a programming mistake).

score -4 · Answer 7 · answered May 31 '12 at 15:27

I say NSNotificationCenter should ALWAYS be used, over the delegate model, except in situations where you query a delegate on information (e.g. -webView:shouldLoadRequest:). It is more stable, easier to implement, and results in cleaner code then trying to use a delegate. The other alternative is blocks, which can be good, but they can be a pain when it comes to memory-managment.

In the end, it's up to you, but I think that NSNotificationCenter is the best way to go in almost any situation, if only for the multiple observer functionality.

When to use NSNotificationCenter

7 Answers7