IOS-Responder Chain

Simply put: a first-level view of the found response, if not passed to UIWindow instances and uiapplication instances, if they can not handle, discard this event ...

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)

Responder Chain concept:The iOS system packs a Uievent object (Uikit encapsulated into a Uievent object) when it detects a finger touch (touch) Action, and put into the event queue of the currently active application (the current application's event queue), the singleton uiapplication takes the touch event from the event queue and passes it to the uiwindow of the Singleton, UIWindow object first uses hittest: Withevent: Method to find the view of the initial point of the touch operation, that is, to pass the touch event to its processed view, a process called Hit-test view.

Responder Objects (Responder object) refer to objects that have the ability to respond and handle events. A responder chain is a hierarchical structure of a series of responder objects.

Uiresponder is the base class for all response objects, and the interfaces that handle each of these events are defined in the Uiresponder class. The familiar uiapplication, Uiviewcontroller, UIWindow, and all Uikit classes that inherit from UIView are inherited directly or indirectly from Uiresponder, so their instances are the responder objects that can form the responder chain.

The UIWindow instance object first calls Hittest:withevent on its content view: This method calls Pointinside:withevent on each view in its view hierarchy: (This method is used to determine if the location of the click event is in the current view, to see if the user clicked the current view), and if pointinside:withevent: return yes, continue to cascade until you find where the touch operation occurred, This is the Hit-test view you are looking for.

Hittest:withevent: The process of the method is as follows:
First call the current view's Pointinside:withevent: method to determine whether the touch point is within the current view;
If no is returned, hittest:withevent: returns nil;
If yes, the Hittest:withevent: message is sent to all the child views of the current view (Subviews), and all child views are traversed in the order from the topmost view to the bottom view, which is the forward traversal from the end of the subviews array. Until a child view returns a non-empty object or all the child views are traversed;
If the child view returns a non-empty object for the first time, the Hittest:withevent: method returns this object, processing ends;
If all child views return non, the Hittest:withevent: method returns itself (self).

If the user clicked on view E, the following diagram describes the Hit-test view 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:

The clicked Range is no longer in D, so the pointinside:withevent of D: Return no, corresponding to the hittest:withevent: return nil;

The clicked Range is within E, that is, E's pointinside:withevent: Returns Yes, since E has no child view (which can also be understood as hit-test when the sub-view of E is returned to nil), therefore, E's hittest:withevent: will return E, Back again, that is the hittest:withevent of C: 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.

The first responder of the event is found above, and the next step is to handle the event in the reverse order of the search for the first responder, which is discarded if neither the UIWindow singleton nor the uiapplication can handle the event. ***

Description

1. If the final hit-test does not find the first responder, or if the first responder does not handle the event, the event will go up backwards along the responder chain, and the event will be discarded if neither the UIWindow instance nor the UIApplication instance can handle the event;

2. Hittest:withevent: The method ignores the view that hides (Hidden=yes), disables user action (Userinteractionenabled=yes), and the alpha level is less than 0.01 (alpha< 0.01) of the view. 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.

IOS-Responder Chain