Skip to content

On Objective-C delegates and NSNotification objects.

Delegates are everywhere in the Cocoa Touch framework for the iPhone and they’re a great idea. They allow you to customise the behaviour and handle the events of the delegating class using a well defined protocol which the compiler will enforce. Delegation also provides design flexibility, sub-classing is no longer your only option for behaviour customisation and you can decide which of your classes would make the most convenient delegate. That class might be the delegate for more than one class or you may even determine the delegate at runtime. It has productivity advantages too, I’ve been surprised by how little effort it can be to switch out one delegate for another and things just work. Flexible. Reusable. Nice.

I’m a relative newcomer to Objective-C and once I’d learned how to create my own delegate protocols I started implementing them in my own classes and this worked very well, mostly. Eventually however, I ran into a problem that felt like a fit for delegates but as I began to work on it, it became clear it was nothing of the sort. The problem was this: I had many instances of a class ‘A’ that were busy asynchronously loading images off the network while another class ‘B’ was presenting a UITableView subclass that included the aforementioned images to the user. I wanted the images to appear in the UITableView as soon as an instance of class A had it loaded. But wiring up class A to class B via a delegate was clearly wrong, class A didn’t exist to serve only class B alone nor did it feel write to have multiple instances pointing at the same delegate.

The answer was, of course, NSNotification. NSNotification and it’s counterpart NSNotificationCenter provide a very loose way of broadcasting events to any class that registers interest. It couldn’t be simpler to use either; firstly you automatically get an instance of NSNotificationCenter in your app:


[NSNotificationCenter defaultCenter]

next creating a notification is simplicity itself:


NSNotification* notification = [NSNotification notificationWithName:@"MyNotification" object:self];
[[NSNotificationCenter defaultCenter] postNotification:notification];

That’s it – it’s dispatched. An identifier and an associated object, in this case the object that created the notification.

Any class that wants to know about “MyNotification” only needs to register interest with the same NSNotificationCenter instance:


[[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(aNotificationHandler:) name:@"MyNotification" object:nil];

So self will now receive the “MyNotification” signal on it’s aNotification: method. The final parameter ‘object’ to which we passed nil allows us to receive the signal from any object. If we passed a pointer in that parameter we’d only get notifications from the particular object referenced by that pointer.

Finally the handler:

- (void)aNotificationHandler:(NSNotification*)notification
{
	MyNotifyingClass* ob = [notification object];
	... app specific stuff

}

So at this point we have an object and we know why we have it, the rest is application specific.

I love this: it’s so simple, powerful and flexible! So while delegates are great for when one class needs to message another or ask how it should handle a particular event, notifications are brilliant for more general broadcast situations where you have a class that would like to tell someone or many someones about a particular event in it’s lifecycle: ‘hey I finished this asyncronous load everyone!’. Observers will hook themselves into the notifications as they need. Brilliant!

About us: Isotoma is a bespoke software development company based in York and London specialising in web apps, mobile apps and product design. If you’d like to know more you can review our work or get in touch.