iOS Development-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: When the iOS system detects a finger touch operation, it packs it into a Uievent object and puts it into the event queue of the currently active application. The uiapplication of a singleton takes a touch event from the event queue and passes it to the uiwindow of the Singleton, UIWindow object first uses the Hittest:withevent: method to find the view that contains the initial point of the touch operation, That is, you need to pass the touch event to its processed view, which is 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.

Go into more detail:

iOS events are broadly divided into three types: touch events, accelerometer events, remote control events

Here are a few concepts to understand first:

First, the Responder object:

　　　　 not all objects in IOS can handle events, only objects that inherit Uiresponder can receive and handle events. We call it " Responder object ."

　　　　UIApplication,uiviewcontroller, andUIView inherit from Uiresponder, so they are all responder objects. are able to receive and process events.

Second, the main method of Uiresponder handling events

Touch events　　　　

-(void) Touchesbegan: (Nsset *) touches withevent: (Uievent *) event;-(void) touchesmoved: (Nsset *) touches withevent: ( Uievent *) event;-(void) touchesended: (Nsset *) touches withevent: (Uievent *) event;-(void) touchescancelled: (NSSet *) Touches withevent: (Uievent *) event;

Accelerometer Events

-(void) Motionbegan: (uieventsubtype) Motion withevent: (Uievent *) event;-(void) motionended: (Uieventsubtype) motion Withevent: (Uievent *) event;-(void) motioncancelled: (uieventsubtype) Motion withevent: (uievent *) event;

Remote control Events

-(void) Remotecontrolreceivedwithevent: (Uievent *) event;

Third, Uitouch

The user touches the finger at the same time, each one represents a Uitouch object, it holds the information related to the finger, such as touch position, time, stage.

When the finger moves (move), the same Uitouch object is updated to keep the finger at the touch position.

　　　　When the finger leaves the (end) screen, the system destroys the corresponding Uitouch object.

Iv.uievent

When a touch event occurs, a Uievent object, called the event object, must be produced, recording the moment and type of the event .

V. The responder who first handles the event

After a touch event occurs, the event is added to an event queue that is managed by UIApplication .

　　　　UIApplication takes the first event from the event queue and distributes the event for processing, typically sending an event to the application's main window (keywindow)

The main window will find the most appropriate view in the view hierarchy to handle touch events , which is the first step in the entire event processing process.

Once the appropriate view control is found, the touches method of the view control is called to do the specific event handling

　　　　Touchesbegan ...

Touchesmoved ...

Touchedended ...

　　　　

Here is the PPT example, which is very clear.

　　

UIView three cases of not receiving touch events

1.alpha= 0.0 ~ 0.01

2.hidden attribute =yes

3.userinteractionenabled=yes

Note:Uiimageview 's userinteractionenabled default is NO, so uiimageview And its child controls are not allowed to receive touch events by default

Six, the responder chain

When the appropriate control invokes the touches method, the event is passed up by default along the responder chain, handing the event to the previous responder for processing.

The process of finding the previous responder appears to be the inverse of the search for the first and most appropriate control.

If [super touches] is called in the touches method of the current responder, the touches method is used for the previous responder, and the Uitouch object and the Uievent object can be passed up.

This enables you to pass information about the event object and the touch object of a touch event to multiple responders.

Question: Who was the previous responder (Nextresponder)?

Judgment steps:
1> If the current view is a view of the controller, the controller is the last responder
2> If the current view is not a view of the controller, then the parent control is the previous responder
3> If the current responder is a controller, then the previous responder is UIWindow, and if UIWindow is not processed, it is then forwarded to UIApplication
4> If uiapplication is not processed, the message will be discarded.

　　

Seven, touch event processing process

1. After the user touches, the system first passes the event object (the parent control to the child control) and finds the most appropriate control to handle the event (recursively finds the most appropriate child control for the current control)

2. Touches related methods for invoking appropriate controls

3. If the touches-related method of super is called, the event is passed up the responder chain to the previous responder

4. The previous responder's touches method is then invoked

5. As long as the touches method of super is called in the touches method of the current responder, it will continue to call up recursively until the super's touches method is no longer called

iOS Development-responder chain