Delegates vs. events in Cocoa Touch

Question

I\'m writing my first iPhone app, and I\'ve been exploring the design patterns in Cocoa Touch and Objective-C. I come from a background of client-side web development, so I

Answer 1

EDIT: Another good post: NSNotificationCenter vs delegation( using protocols )?

A delegate is a callback so there is a 1:1 relationship. The delegate is a single instance of an object that implements a formal protocol.

Notifications (events) are basically broadcasts to many objects that are interested in when something happens.

Delegates are good for being able to interject code into the pipeline of some other objects processing such as before and after callbacks, providing data sources for a control and communicating between views:

What exactly does delegate do in xcode ios project?

Therefore delegates have a much tighter relationship with the object since they are the single provided object to interject and alter processing of the object or provide data. You're deferring decisions and external operations like loading data to some other object - which is why it's a very common pattern for generic UIKit classes. Notifications to other objects is a much looser relationship - it just that a notifies others that something happened.

It's also not a "vs" question necessarily. For example you could have an app that does background processing and it fired a something changed notification causing a view to call its data source delegate to refresh its view. They are two different mechanisms.

Answer 2

Events and delegates have two different purposes, so you'll see both used.

If you just want your button press to fire off a message, an event is fine. If you want your Done button press to validate the context of the text field before it is allowed to lose focus, you can use the textFieldShouldReturn delegate method to handle any validation and return NO if it doesn't validate.

Delegates really allow you to change behaviour without subclassing. They're filled with should and did methods for this purpose. You implement these methods instead of overriding action methods when you want to validate, notify, or process before and/or after the action.

If you find yourself thinking that you need to subclass a UIKit object, check its delegate methods first. Chances are there's already a place to put your custom behaviour.

Answer 3

One clear distinction is that delegate methods can have return values since there is a one-to-one relationship. On the other hand events are loosely coupled to the sending class, which usually doesn't care if anything responds or not.

Other delegate methods are simply there for convenience and can have corresponding events that are also triggered.