Are blocks a better alternative to a NSNotificationCenter?
|
closed as not a real question by gnat, MichaelT, Kilian Foth, GlenH7, Karl Bielefeldt Apr 18 at 21:48
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, see the FAQ.
|
|||||
|
|
Blocks are an alternative to Notification Centers offer a central place to publish and subscribe to notifications, decoupling the posters from the listeners. The code that is executed in response to receiving a notification from the Blocks are—unfortunately, as far as clarity goes—blocks in the old-fashioned sense of C code that capture their surrounding state. Like function pointers, block pointers can be captured as variables and the code in the block executed later by using the One way in which you could conceivably use blocks instead of notifications is to implement a callback API in the form of completion handlers. You could have a method declared like this:
This is a good idea when exactly one object needs to know when the task has completed, and has exactly one thing to do in response. If you need more objects to be informed about the event, you should probably post a notification. If there are multiple code paths to execute (for example, different success or failure cases) you should consider a delegate object, with different methods for each of the cases. |
|||
|
|