I just researched the two, and they both seem to be great means of communication, but nsnotification seems a ton easier to deal with. What are situations where you would want to use delegation rather than nsnotification, and nsnotification rather than delegation?
Just a side note: both are great concepts. Notifications are easier to handle - especially it is quite easy to write unmaintainable code when used without thought.
A good architecture should be able to make it possible to live without them in most of the cases.
I ve seen a larger iPad project where notifications were used to make up for flaws in the architectural design: was horrible. Code completely unmaintainable after 2 months.
My experience: they are a very handy tool - use them if the other tools failed
I typically use delegation between classes within a subsystem, but use notifications across subsystem boundaries that don't need to be directly linked together and where strict order of notification isn't important. I also use Delegation when a class needs something done on its behalf directly (like UITableView does) and Notifications for when actions must occur not directly on behalf of the notifier, but for their own purpose.
Notifications are good for loosely coupled systems, like for instance when you finish logging in to a server and a bunch of other subsystems need to know its ok to proceed with whatever their tasks should be doing. These systems may not all need to have a direct relationship with your login subsystem, but they all need to do 'something' as a result. Notifications also do not dictate the form of the implementation as Delegates do, because the notifier shouldn't care.
Delegates are good in a more tighter coupled system where the implementation can be dictated (like saying 'now do this, and this, and then that'), typically by implementation of a protocol to which the delegate must adhere. Delegation is also easier to follow if you are trying understand how various pieces of code work together because the relationship are more clearly identified.
Here's a good post on this subject as well.
Yes, I agree that NSNotifications are easier to implement than your own delegate protocols and methods. I don't really know what the relative "cost" (in time or memory use) of the two methods are, but my criteria for using one over the other are as follows.
If more than one class needs to know something that you're doing in a third class, then I use a notification, since it's "broadcast", and any object that registers for the notification can get the info.
The other time I use notifications is if I have two objects, say view controllers, that are far apart in a chain of controllers or on different branches of a chain so that it's hard to get a reference to the controller that you want to set yourself as the delegate of.
Otherwise, when two controllers are "close together", like when one controller creates the next one in preparation for a push or segue, then I use delegation to get info from the pushed view controller back to the one doing the pushing.
Also, if a controller needs to do multiple things based on what's happening in another object, then again, delegation is better, because you can have a delegate protocol that has numerous methods (like the UITableViewDelegate for instance).
Delegation is important in many of the iOS views, for example, UITableView. UITableView has a UITableViewDelegate and a UITableViewDataSource. Both are necessary to supply information about the contents of the table. You couldn't do this with notifications.
Some other places where delegation is used:
- There is an application delegate for avery app: UIApplicationDelegate
- UIEditView has delegate to tell it how to behave.
- UIAlertView has a delegate to communicate the user's actions back to the application.
Delegation is typically useful when number of recievers of the event are limited may be 1 or 2 and also if you want to control how events are delivered. For example in case lets say UIApplicationDelegate example, you cannot call applicationDidForeground until applicationDidFinishLaunch is completed so in a way you are making sure the reciever has acknowledged each event before delivering next one. If you have to deliver events which hasto follow a lifecyle like begin, end, beginning , complete etc.. delegates are better.
Notifications in my mind are mostly like boolean events even though you can pass data along with it, They are useful if you have to broadcast a certain event irrespective of who the recievers are. Typically this is useful when you have to communicate information change
First, I have to say that delegates are much faster than notification. If in your project you have 100 delegations it is fine, but when you come to 100 notification it can easy become killing slow on device. However, delegates have limitation: you can have only one delegate of certain type for your objects. And in case of notification, the number of observers is not generally limited. In addition, delegate methods are likely to be performed on the same thread, unless you use specific methods to perform them on different threads.
Just a side note: both are great concepts. Notifications are easier to handle - especially it is quite easy to write unmaintainable code when used without thought.
A good architecture should be able to make it possible to live without them in most of the cases.
I ve seen a larger iPad project where notifications were used to make up for flaws in the architectural design: was horrible. Code completely unmaintainable after 2 months.
My experience: they are a very handy tool - use them if the other tools failed
© 2022 - 2024 — McMap. All rights reserved.