Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Are blocks a better alternative to a NSNotificationCenter?

share|improve this question
    
Sharing your research helps everyone. Tell us what you've tried and why it didn’t meet your needs. This demonstrates that you’ve taken the time to try to help yourself, it saves us from reiterating obvious answers, and most of all it helps you get a more specific and relevant answer. Also see How to Ask –  gnat Apr 18 '13 at 16:49
    
For Block Objects refer powerofobjective-c.blogspot.in –  rainbow1202 Apr 20 '13 at 6:35
add comment

closed as not a real question by gnat, MichaelT, Kilian Foth, GlenH7, Karl Bielefeldt Apr 18 '13 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, visit the help center.If this question can be reworded to fit the rules in the help center, please edit the question.

2 Answers

Blocks are an alternative to NSNotificationCenter in the same way that the space shuttle is an alternative to kittens. They do completely different things.

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 NSNotificationCenter class can be a method on an object or a block.

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 () operator.

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:

typedef void(^CompletionBlockType)(id result);
- (void)doSomethingExpensiveWithCompletion: (CompletionBlockType)result;

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.

share|improve this answer
add comment
(Block)Just like Ajax...

<...>
[self.client postPath:@"/getMeSomething" paramenters:params
    success:^(Response *response) {
            <success work>
    }
    failure:(^Response *response) {
            <fail work>
    }
];
<....>

NSNotification (more controversial if you ask me)

TableController.m
<...>
[NSNotification addObserver:self selector:(refreshDisplay) name:@"Model Refreshed"]
<...>
-(void)refreshDisplay { work }
<...>

MyDataModel.m
<...>
   <many model updates>
   [NSNotification .. postNotificationName:@"Model Refreshed"]
<...>
share|improve this answer
1  
Can you explain in what way notifications are "controversial" please? –  user4051 Aug 23 '12 at 7:13
add comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.