Delegation vs. target/action vs. callbacks


Hi. First of all, I would like to say that you’ve written one hell of a book. I’m a beginner in iOS programming with quite some experience with other technology stacks (mainly Java SE/EE and Python, but I’ve used a few other languages as well), and have read many programming books, and this one is just really nicely written.

What I’m struggling with is the delegate vs. taget/action vs. callbacks question. I don’t really get when you would use which. I managed to get formal / informal protocols out of the equation as informal ones seem not to be used any more - modern Objective-C uses @optional @protocol methods - correct?

At one point in the book you say that delegates are object-oriented version of callbacks. Why is that? For example, in Java, one would create an interface with a few methods and register it somehow (it would be multicast most of the time, though) - this is pretty much what the delegate is, right? So the Java implementations of the given interface are also objects, and the methods are callbacks, so I see no difference. Or by callbacks do you mean simple functions, like in functional programming? But then again, there are languages where functions are also objects and one can store arbitrary data in.

What I also fail to grasp is why and when I would use the target/action pattern, and when the delegate. As far as I can tell, UIButton events (touchUpInside and others) could be implemented using protocols - after all, this could be a protocol with a whole bunch of @optional methods, the view controller would conform to the protocol, and implement only the ones it needs. Then, it would set itself as the UIButton delegate, possibly for multiple buttons, no matter, because the methods could get the (id)sender. (As a side question, why is it id and not UIButton?) Why is it implemented with a bunch of type-unsafe selector to event mappings? Is it the way it always had been and stayed even after Objective-C 2.0 introduced @optional methods just for backwards-compatibility’s sake / not doing too much work updating all the classes?

The biggest question: when and why would I want to use target/action? I have written a few classes myself so far and I seriously always think of delegates, but maybe I need to change my approach?


Don’t be confused. Deep down they are the same, but in terms of logical functionality one can argue that they are different.

However, there are some superficial differences. For example, a target/action pair requires an object that can respond to a single-argument method whereas a delegate requires an object (usually conforming to a protocol) with any number of methods, where each method can take any number of arguments.


Why do you say target/action requires the action to be a single-argument method? I can image that the selector passed can be of any signature (but calling it with sth other than objects, and more than 2 would require messing around with NSInvocation).


Oops! I shouldn’t have said that.

Better to consult Apple’s documentation on this:
- Target-Action in the AppKit Framework;
- Target-Action in UIKit.

[quote]In contrast to the AppKit framework, where an action method may have only one or perhaps two valid signatures, the UIKit framework allows three different forms of action selector:

  • (void)action
  • (void)action:(id)sender
  • (void)action:(id)sender forEvent:(UIEvent *)event
    To learn more about the target-action mechanism in UIKit, read UIControl Class Reference.

Better to consult Apple’s documentation on this:
- Target-Action in the AppKit Framework;
- Target-Action in UIKit.