IOS4 note 12 (5)
Deferring Responsibility
The responder chain can be used to let a responder defer responsibility for handling a touch event. If a responder receives a touch event and can’t handle it, the event can be passed up ?the ?responder chain ?to ?look ?for a ?responder ?that ?can handle ?it. This can happen in two main ways:
(1) the responder doesn’t implement the relevant method;
(2) the responder implements the relevant method to call super.
For example, a plain vanilla UIView has no native implementation of the touch event methods. Thus, by default, even if a UIView is the hit-test view, the touch event effectively falls through the UIView and travels up the responder chain, looking for someone to respond to it. If this UIView is an instance of your own subclass, you might implement the touch event methods ?in that subclass to catch touch events ?in the UIView itself; but ?if the UIView ?is controlled by a UIViewController, you have already subclassed UIViewController, and that subclass is probably where the interface behavior logic for this UIView is already situated,so you might well prefer to implement the touch event methods there ?instead. You are thus taking advantage of the responder chain to defer responsibility for handling touch events from the UIView to its UIViewController, in a natural and completely automatic way.
?
Nil-Targeted Actions
A nil-targeted action is a target–action pair in which the target is nil. There is no designated target object, so the following rule is used: starting with the hit-test view (the view with which the user is interacting), Cocoa looks up the responder chain for an object that can respond to the action message.
Suppose, for example, we have a UIButton inside a UIView. And suppose we run this code early in the button’s lifetime, where b is the button:
? ?[b addTarget:nil action:@selector(doButton:) forControlEvents:UIControlEventTouchUpInside];
That’s a nil-targeted action. So what happens when ?the user ?taps ?the button? First,Cocoa looks in the UIButton itself to see whether it responds to doButton:. If not, then
it looks in the UIView that is its superview. And so on, up the responder chain. If a responder is found that handles doButton:, the action message is sent to that object; otherwise,the message goes unhandled.
Thus, suppose the UIView containing the UIButton is an instance of your own UIView
subclass. Let’s call it MyView. If MyView implements doButton:, then when the user taps the button, it is MyView’s doButton: that will be called.
?
The Term “First Responder”
Apple uses the term first responder in a confusing way. An arbitrary responder object
can be assigned formal first responder status (by sending it becomeFirstResponder, provided that this responder returns YES ?from canBecomeFirstResponder). But this does not make the object first responder for purposes of handling nil-targeted actions! Cocoa’s hunt ?for a ?responder that can handle a nil-targeted action still starts with the control that the user is interacting with (the hit-test view) and goes up the responder chain from there.
Typical legitimate uses of becomeFirstResponder are:
1.To put a UITextField into editing mode, as if the user had tapped in it.
2.To specify the object that should initially be sent remote events.
3.To designate an object that is to present a menu.
