Whenever I have used NSNotificationCenter in iOS it feels fragile and bug prone. It basically lets any object send a message to anywhere. Any object can receive any message. In the end the code feels like object oriented spaghetti code. Whenever I come across a message being posted I have know idea what is receiving the message. I cannot step into it in a debugger. Bugs can easily be introduced by forgetting to stop listening to events. Parameter passing always has to happen through storing a bunch of key/value pairs in a dictionary and overall I feel it is bad design to use NSNotificationCenter.
Yet, as I google trying to find an article that shares the same viewpoint I cannot find one. Any thoughts on NSNotificationCenter or on the observer pattern in general?
Is NSNotificationCenter evil?
I don't terribly like the fact that it is centralised either, but when used for its intended purpose (broadcast of large-scale events), it gets the job done pretty well.
I made a post recently that discussed a similar system to NSNotificationCenter. You should read it:
http://www.gamedev.net/topic/638088-global-event-manager-system/
Overall, I agree with the comments posted there, which is that you will like your code better if you use delegates instead of NSNotificationCenter.
I'm not familiar with it first-hand, but I've seen many systems like it.
This is the classic evil of building a general-purpose communications framework: the more general a system gets, the easier it is to abuse. Coming up with a mechanism to allow arbitrary cross-object messaging that isn't full of the problems you describe is more or less impossible without creating really byzantine architectures.
FWIW, the only "solution" to this that I've seen in production is a full dynamic contract specification system, where every component has to describe in a manifest what messages it transmits and what clients should do with them. Making that general and flexible is a nightmare. Such systems are occasionally used in simulation or hardcore defense research projects, where work is spread across any number of contractors over the span of years - and, potentially, many different hardware/software platforms.
Unless you're in one of those extremes, the cure is worse than the disease.
Yes, general messaging frameworks are open to abuse. It's your responsibility to not abuse them.
This is the classic evil of building a general-purpose communications framework: the more general a system gets, the easier it is to abuse. Coming up with a mechanism to allow arbitrary cross-object messaging that isn't full of the problems you describe is more or less impossible without creating really byzantine architectures.
FWIW, the only "solution" to this that I've seen in production is a full dynamic contract specification system, where every component has to describe in a manifest what messages it transmits and what clients should do with them. Making that general and flexible is a nightmare. Such systems are occasionally used in simulation or hardcore defense research projects, where work is spread across any number of contractors over the span of years - and, potentially, many different hardware/software platforms.
Unless you're in one of those extremes, the cure is worse than the disease.
Yes, general messaging frameworks are open to abuse. It's your responsibility to not abuse them.
A couple of your assumptions about NSNotification Center are wrong:
Any object can receive any message.
This is wrong. Only objects that have registered with the notification center for that particular message can receive them.
Bugs can easily be introduced by forgetting to stop listening to events.
This is not a design fault of NSNotificationCenter it is just bad programming from the user for failing to unregister. Similar to saying when I forget to delete a pointer that I have new'ed it leaks memory bad design C language.
A good rule of thumb is that if you have registered for any notifications within a class then remove the class from the notificationcenter in the dealloc method before releasing any other resources. If the class is a viewcontroller then stop listening for any messages that you have subscribed to in the viewWillHide method. DO NOT remove the class from the notification center in viewWillHide as superclasses may still be subscribed to other messages.
Where the NSNotificationCenter does break down is when people abuse it by passing all their messages through it when they should either be KVO or delagates.
A good practice is to follow the rules of comunication.
http://www.mcubedsw.com/blog/index.php/site/comments/the_rules_of_communication/
Author
I guess I worded that wrong. What I meant was any object can register to listen for any message. What I don't like about this is whenever I broadcast a notification I don't know what is going to receive it.A couple of your assumptions about NSNotification Center are wrong:
This is wrong. Only objects that have registered with the notification center for that particular message can receive them.Any object can receive any message.
I also recognize that if you use it right you can make it work and not have issues, but I still feel that using notifications feels messy and fragile. One of my biggest gripes with it is that you must past parameters through an NSDictionary. If used right I feel it can be useful but I try to avoid using it as much as possible.
What I don't like about this is whenever I broadcast a notification I don't know what is going to receive it.
It should only be the objects that you have deliberatly subscribed to that message. You are using unique names for your messages arn't you?
Or are you broadcasting existing apple messages?
I don't see the issue with passing data as a dictionary. It is a perfectly valid data structure. Also it is not the only way of passing parameters. You can send the calling object (or any other object) so that the receiing selector can access the object through the notifications .object property. Also if you want to pass data some other way then just write a category to extend NSNotification and then broadcast it using:
postNotification:(NSNotification *)notification;
that broadcast the notification.If used right I feel it can be useful but I try to avoid using it as much as possible.
If you are finding ways not to use Notification Center then you a re probably doing it correctly as it is not a one solution for everything.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
