Event delivery and responder chain in iOS

This article transferred from: http://www.linuxidc.com/Linux/2015-08/121270.htm

First of all, let's take a look at the generation and delivery of events in iOS 1. After a touch event occurs, the system adds events to a queue event managed by UIApplication to 2.UIApplication to remove the first event from the event queue and distribute the event for processing, typically sending events to the application Main Window 3. The main window will find the most appropriate view in the view hierarchy to handle touch event 4. Once the appropriate view control is found, the touches method of the view control is invoked as the result of the event: toucheesbegin...touchesmoved ... touchesended, etc. 5. These are the methods by default the event is passed up the responder chain, and the event is handled by a corresponding person, for example, a general event is passed from the parent control to the child control, for example: Click the Green View, The transfer process is as follows:uiapplication->windows-> white view-> Green View Click on the blue view, the transfer process is as follows:uiapplication->windows-> White view- > Orange view-> Blue View If the parent control receives no touch events, then the child control cannot receive the touch event UIView cannot receive three cases of touch events 1. User interaction is not accepted: userinteractionenabled=no;2. Hidden: hidden=yes;3. Transparent: alpha=0.0-0.1; How do I find the most appropriate control to handle an event? There's a guideline 1. Whether you can accept touch Events 2. Whether the touch point is on its own 3. Iterate through the child controls, repeating the preceding two steps 4. If there are no child controls that meet the criteria, then you are best suited to handle, for example, the order in which the controls are added: White 1-> green 2-> Orange 2-> Blue 3-> Red 3-> yellow 4-> here click on the Orange area, the event passing judgment process is as follows: 1. UIApplication out events from the event queue and sends Uiwindows2.uiwondows to determine if they can accept touch events. Can be 3. Uiwindows to determine if the touch points are on their own. 4.UIWindows traverse its own subspace from behind, remove white 1

6. Orange 2 Meet the top two conditions, traverse the child control, first remove the Red 3

7. Red 3 does not meet the condition 2, remove the Blue 3

8. Blue 3 also does not meet the condition 2, the last most suitable control is the Orange 2

After finding the right controls to respond, here's a look at the responder chain: The responder chain is actually a lot of responder objects (objects that inherit from Uiresponder) are grouped together as chains called responder chains

The general default is that the control passes the event up the responder chain, handing the event over to the previous responder for processing. So how do you judge the last responder of the current responder? The following two rules are available:

1. Determine whether the controller is currently a view, if the controller's view, the previous responder is the controller

2. If not the controller's view, the previous responder is the parent control

The response process is as follows:

If the controller does not respond to the response touches method, it is given to UIWindow. If the UIWindow also does not respond, to uiapplication, if all do not respond to the event is void.

In conclusion, a complete touch event delivery response process is:

Uiapplication-->uiwindow--> recursively finds the most appropriate control--the control calls the touches method--to determine if the touches method is implemented-- No implementation by default passes an event to the previous responder--finds the previous responder--Cannot find the method obsolete

PS: Using the responder chain we can have multiple responders respond to the event at the same time by calling touches's Super method.

Event delivery and responder chain in iOS