Event delivery:the Responder Chain

When we design the app, we probably want to respond to events dynamically. For example, to touch a screen that has many different objects, you decide which object to give a response to, and how the object receives the event.

When a user generates an event (such as a click), Uikit produces an object that contains information about the object to be processed. The event object is then placed in the active app's (a Application object, which initializes the user event route, from the global management of a running application) event queue. For touch events, this object is a set of touches, packaged and placed on a Uievent object. For motion events, event objects vary depending on the frame you use and the type of motion event you are interested in.

An event object is passed along an explicit path until an object can handle it. First, the Singleton UIApplication object takes an event from the top of the queue and distributes the processing. In general, the UIApplication object sends events to the application's key window object, and the key window object is passed to a initial object for processing. This initial object depends on the type of event.

• Touch events. For touch events, the Window object first attempts to send an event to the view (Hit-test view) where the event occurred. The process of finding hit-test view is called hit-testing (we'll talk about it in the back).
• Motioin and remote control enents. Such events, window shrimp ing send shaking-motion or remote control event to the first responder processing.

The ultimate goal of event paths is to find an object to handle the response to an event. Therefore, Uikit first sends this event to the object that is most appropriate to handle this time. For touch events, this object is Hit-test view; for other events, this object is the first responder. The following sections describe more details about determining the hit-test view and the first responder.

Hit-testing Returns The View Where A touch occurred (Hit-test return touch occurs View). Some places translation feel very awkward, in order to avoid misleading (really people see it?) ), pasted on the original.

IOS use hit-testing fo find the view this is under a touch. Hit-testing involves checking whether a touch is within the bounds fo any relevant (more emphasis directly related) view objects. If It is, it recursively checks all of the that view ' s subviews. The lowest view in the view hierarchy that contains, the touch point becomes the hit-test view. After IOS determines the hit-test view, it passes the "touch event to the" View for handling.

For example, assuming that the user is touching in view E, iOS looks for hit-test view by checking subviews in the following order:

1. Touch the bounds within view a, so check subview B and C;
2. Touch is not within view B's bounds, but within view C's bounds, so check subview D and E;
3. Touch is not within the bounds of view D, but within the bounds of view E.
   View E is the lowest view of the view hierarchy that contains the touch, so it becomes the hit-test view.
   

hittest:withevent: method returns a Hit-test view of Cgpoint and uievent. hittest:withevent: The method begins execution by calling Pointinside:withevent through the view itself : method. If the incoming pointinside:withevent: point is within the bounds of the view,pointinside:withevent: returns YES. Then, on each subview of this view, the hittest:witheventis raised:.

Incoming hittest:withevent: The point is not in the view of the bounds is not the case.

Note: A touch event is associated with its hit-test view throughout its life cycle, even though a touch moves out of the view later.

Hit-test view was given the opportunity to handle touch events for the first time. If Hit-test view cannot handle this event, the event will go down the responder chain of the view until it finds an object that can handle the event.

The Responder Chain is made up of Responder Objects (the responder chain consists of responders-. -）

Many types of events have responded to chain-passing events since. The responder chain is a series of connected responder objects. Starting with the first responder, the closing Application object. If the first responder cannot handle an event, it is forwarded to the next responder in the responder chain.

A Responder Object is an object which can respond to and handle events. The Uiresponder class is the base class for all responder objects, and it defines the programmatic interface no T only for the event handling but also for common responder behavior. Instances of the, UIView , and classes are responders, which means UIViewController UIApplication Most key controller objects is responders. Note that Core Animation layers is not responders.

The first responder is specified to accept the event first. Typically, the first responder is a view object. An object can become the first responder by doing the following two things:

1. Override the Canbecomefirstresponder method and return yes;
2. Accept a becomefirstresponder message. If necessary, an object can send itself this message.

The object that relies on the responder chain is more than the event object. The responder chain can be used in the following places:

1. Touch events.
2. Motion events.
3. Remote control events.
4. Action messages.
5. Editing-menu messages.
6. Text editing.

Uikit automatically sets the text field or text view that the user clicked to become the first responder; apps must explicitly set all the other first responders, using the becomefirstresponder method.

Event delivery:the Responder Chain