iOS responder Chain

First, when an event response occurs, you must know who is responding to the event. In iOS, the responder chain responds to events, all event responses are subclasses of Uiresponder, and the responder chain is a hierarchy of different objects in which each object is given an opportunity to respond to event messages in turn. When an event occurs, the event is first sent to the first responder, and the first responder is often the view where the event occurs, where the user touches the screen. The event is passed down the responder chain until it is accepted and processed. In general, the first responder is a view object or its child class object, when it is touched by the event is left to handle, if it does not process, the event will be passed to its View controller object Viewcontroller (if present), Then it is the parent view (Superview) object (if present), and so on, until the top-level view. Next, the top view is followed by the window (UIWindow object) to the program (UIApplication object). If the entire process does not respond to this event, the event is discarded. In general, events stop passing in the responder chain as long as the event is handled by the object.

A typical corresponding roadmap such as:

First Responser--> The Window-->the application--> App Delegate

The normal responder chain process is often interrupted by a delegate (delegation), and an object (usually a view) may delegate the response work to another object (typically the view controller Viewcontroller). This is why it is necessary to implement the corresponding protocol to implement the event delegate in Viewcontroller when the event response is done. In iOS, there is a Uiresponder class that defines all the methods of the responder object. UIApplication, UIView and other classes inherit the Uiresponder class, and the controls in UIWindow and Uikit inherit UIView, so they inherit uiresponder classes indirectly, and instances of these classes can be used as responders.

I. Classification of events

For iOS device users, there are three main ways to manipulate devices: Touch the screen, shake the device, and control the device through a remote controlled facility. The following three types of events are available:

1. Touchscreen events (Touch event)

2, motion events (motion event)

3. Remote Control Events (Remote-control event)

Today, as an example of touch event, the process of handling events in the Cocoa Touch framework is illustrated. First we have to introduce the concept of the responder chain:

Second, the responder chain (Responder Chain)

First, the responder object (Responder object), The responder chain is a series of responder objects

uiresponder is the base class for all response objects. Interfaces for handling the various events described above are defined in the Uiresponder class. We are familiar with the uiapplication, Uiviewcontroller, UIWindow

Figure A

As can be seen from figure I, the responder chain has the following characteristics:

1, the responder chain is usually composed of a view (UIView);

2. The next responder of a view is its view controller (uiviewcontroller), if any, and then to its parent view (Super view);

3. The View controller (if any) the next responder is the parent view of the view it manages;

4. The content view of the Singleton window (UIWindow) will point to the window itself as its next responder

It should be noted that the Cocoa touch app is not like the Cocoa application, it has only one UIWindow object, so the entire responder chain is a little simpler;

5. The singleton application (uiapplication) is the end point of a responder chain, and its next responder points to nil to end the entire loop.

Iii. Distribution of events (event Delivery)

First responder refers to the current responder object (usually a UIView object)that accepts the touch, meaning that the object is currently interacting with the user, which is the beginning of the responder chain. The mission of the entire responder chain and event distribution is to find the first responder.

The UIWindow object sends the event as a message to the first responder, giving it an opportunity to handle the event first. If the first responder does not process, the system passes the event (through the message) to the next responder in the responder chain to see if it can be processed.

ios system detects finger touches (touch) The action is packaged as a Uievent object and placed into the event queue of the currently active application, and the singleton UIApplication takes the touch event out of the event queue and passes it to the uiwindow of the singleton for processing. The UIWindow object first uses the Hittest:withevent: method to find the view of the initial point of the touch operation, the view that needs to pass the touch event to its processing, a process called Hit-test view.

uiwindow instance objects first call HitTest on its content view: Withevent: This method calls Pointinside:withevent on each view in its view hierarchy: (This method is used to determine whether the location of the click event is in the current view, to see if the user clicked the current view), If pointinside:withevent: Return yes, continue the cascade call until you find the location where the touch operation occurred, which is the hit-test view you are looking for.
hittest:withevent: The process of the method is as follows:

Figure II

Join the user click on the view E, the following together with the Diagram II Hit-test view of the process:

1, A is the root view of UIWindow, therefore, the Uiwindwo object will be the prime minister of a hit-test;

2, obviously the user clicks the scope is within the range of a, therefore,pointinside:withevent: Returns the Yes, then will continue to check A's child view;

3. At this time there will be two branches, B and C:

The clicked range is no longer within B, so the pointinside:withevent of the B branch : Return no, corresponding to the hittest:withevent: return nil;

Click on the range in C, that is, C pointinside:withevent: return yes;

4. There are two branches of D and E:

Click the range no longer within D, so D pointinside:withevent: Returns no, corresponding to hittest:withevent: nil returned;

The range of clicks is within E, i.e. E's pointinside: Withevent: Returns YES because E does not have a child view (it can also be understood that nil is returned when you hit-test the child view of E), so the hitTest : withevent: will return E and backtrack back, that is, C's hittest: Withevent: Return e--->>a hittest:withevent: Return E.

At this point, the first responder of this click event is successfully found through the event distribution logic of the responder chain.

It is not difficult to see that this process is a bit like the idea of binary search, so that the fastest speed, the most accurate positioning can respond to touch events UIView.

Third, the description

1, if final hit-test did not find the first responder, or if the first responder did not handle the event, the event would go up backwards along the responder chain, if neither the UIWindow instance nor the UIApplication instance could handle the event. The event is discarded;

2, Hittest:withevent: The method ignores the hidden ( Hidden=yes) View, a view that prohibits user action (Userinteractionenabled=yes), and a view that has an alpha level of less than 0.01 (alpha<0.01). If the area of a child view exceeds the bound area of the parent view (the Clipstobounds property of the parent view is no, so that the child view content of the parent view's bound area is also displayed), the touch operations of the child view outside the parent view will normally not be recognized. Because the parent view's Pointinside:withevent: Method returns no, it does not continue to traverse the child view down. Of course, you can also override the Pointinside:withevent: method to handle this situation.

3, we can rewrite hittest:withevent: To achieve certain purposes, the following link is an interesting application example, of course, in practical applications rarely used.

http://blog.csdn.net/error/404.html?from=http%3a%2f%2fblog.csdn.net%2fzhaoguodongios%2farticle%2fdetails%2f44082821

Reference Documentation:

https://developer.apple.com/library/ios/#documentation/eventhandling/conceptual/eventhandlingiphoneos/event_ Delivery_responder_chain/event_delivery_responder_chain.html#//apple_ref/doc/uid/tp40009541-ch4-sw1

iOS responder Chain