NSNotification protocol vs delegate protocols?

Question

I have an iPhone app that basically receives information from an API (in XML, but possibly JSON). Result objects are usually displayed as controllers (mostly tables).

Here is the architecture right now.

I have NSOperation classes that retrieve different objects from a remote server. Each of these NSOperation classes will use a custom delegate method that will shoot the resulting objects as they are parsed, and then finally a method when there are no more results. Thus, the protocol for delegates will look something like this:

(void) ObjectTypeResult:(ObjectType *)result; (void) ObjectTypeNoMoreResults; 

I think the solution works well, but I get a lot of delegate protocols, and then my view controllers should implement all these delegation methods. I do not think this is so bad, but I am always looking for the best design.

So, I'm thinking of using NSNotifications to remove delegate usage. I could include the object in the user part of the notification and just send the objects in the form in which they were received, and then the final event when there is no more. Then I could have only one method in each view controller to retrieve all the data, even when using multiple objects in one controller. †

So, can someone share with me some of the pros / cons of each approach. Should I consider refactoring my code to use events, not delegates? Is it better then in certain situations? In my scenario, I really don't want to receive notifications in several places, so maybe protocol-based delegates are the way to go.

Thanks!

Answer 1

In fact, your design sounds. Cocoa uses a clear approach with delegates, and it is much preferable to throw objects around. Also, defining your protocols this way makes your code very clear and straightforward. Overall: keep up the good work