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'm trying to wrap my head around delegates.
Specifically, I don't see why delegate objects are needed instead of event handlers. For instance, when the user presses a button, it is handled with an event (UITouchUpInside
), but when the user finishes inputting to a text box and closes it with the 'Done' button, the action is handled by calling a method on the text box's delegate (textFieldShouldReturn
).
Why use a delegate method instead of an event? I also notice this in the view controller with the viewDidLoad
method. Why not just use events?
Protocol is a set of methods (either optional or required) that would be implemented by the class which conforms to that protocol. While, delegate is the reference to that class which conforms to that protocol and will adhere to implement methods defined in protocol.
A delegate is an object which refers to a method or you can say it is a reference type variable that can hold a reference to the methods. Delegates in C# are similar to the function pointer in C/C++. It provides a way which tells which method is to be called when an event is triggered.
Delegates are a use of the language feature of protocols. The delegation design pattern is a way of designing your code to use protocols where necessary. In the Cocoa frameworks, the delegate design pattern is used to specify an instance of a class which conforms to a particular protocol.
What is delegate methods in iOS? It is an easy and influential pattern in which one object in a program works on behalf of or in coordination with, another object. The delegating object keeps a reference to the other object and at the suitable time sends a message to it.
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.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With