Responder Objects and the Responder Chain

A responder object is an object that can respond to events and handle them. UIResponder is the base class for all responder objects, also known as, simply, responders. It defines the programmatic interface not only for event handling but for common responder behavior. UIApplication, UIView, and all UIKit classes that descend from UIView (including UIWindow) inherit directly or indirectly from UIResponder, and thus their instances are responder objects.

The first responder is the responder object in an application (usually a UIView object) that is designated to be the first recipient of events other than touch events. A UIWindow object sends the first responder these events in messages, giving it the first shot at handling them. To receive these messages, the responder object must implement canBecomeFirstResponder to return YES; it must also receive a becomeFirstResponder message (which it can invoke on itself). The first responder is the first view in a window to receive the following type of events and messages:

• Motion events—via calls to the UIResponder motion-handling methods described in “Shaking-Motion Events”

• Remote-control events—via calls to the UIResponder method remoteControlReceivedWithEvent:

• Action messages—sent when the user manipulates a control (such as a button or slider) and no target is specified for the action message

• Editing-menu messages—sent when users tap the commands of the editing menu (described in “Displaying and Managing the Edit Menu”)

The first responder also plays a role in text editing. A text view or text field that is the focus of editing is made the first responder, which causes the virtual keyboard to appear.

Note: Applications must explicitly set a first responder to handle motion events, action messages, and editing-menu messages; UIKit automatically sets the text field or text view a user taps to be the first responder.

If the first responder or the hit-test view doesn’t handle an event, UIKit may pass the event (via message) to the next responder in the responder chain to see if it can handle it.

The responder chain is a linked series of responder objects along which an event, action message, or editing-menu message is passed. It allows responder objects to transfer responsibility for handling an event to other, higher-level objects. An event proceeds up the responder chain as the application looks for an object capable of handling the event. Because the hit-test view is also a responder object, an application may also take advantage of the responder chain when handing touch events. The responder chain consists of a series of next responders (each returned by the nextResponder method) in the sequence depicted in Figure 1-1.

When the system delivers a touch event, it first sends it to a specific view. For touch events, that view is the one returned by hitTest:withEvent:; for “shaking”-motion events, remote-control events, action messages, and editing-menu messages, that view is the first responder. If the initial view doesn’t handle the event, it travels up the responder chain along a particular path:

1. The hit-test view or first responder passes the event or message to its view controller if it has one; if the view doesn’t have a view controller, it passes the event or message to its superview.

2. If a view or its view controller cannot handle the event or message, it passes it to the superview of the view.

3. Each subsequent superview in the hierarchy follows the pattern described in the first two steps if it cannot handle the event or message.

4. The topmost view in the view hierarchy, if it doesn’t handle the event or message, passes it to the window object for handling.

5. The UIWindow object, if it doesn’t handle the event or message, passes it to the singleton application object.

If the application object cannot handle the event or message, it discards it.

If you implement a custom view to handle “shaking”-motion events, remote-control events, action messages, or editing-menu messages, you should not forward the event or message to nextResponder directly to send it up the responder chain. Instead invoke the superclass implementation of the current event-handling method—let UIKit handle the traversal of the responder chain.

原文：

https://developer.apple.com/library/ios/#documentation/EventHandling/Conceptual/EventHandlingiPhoneOS/EventsiPhoneOS/EventsiPhoneOS.html#//apple_ref/doc/uid/TP40009541-CH2-SW1