In iOS development, there are three types of common events, namely:
(1) Touch events: normal finger swipe on the screen, resulting in events are touch events
(2) Accelerometer event: A shake is a typical accelerometer event
(3) Remote control event: The headset controls the song on the first, the next song, pause is the remote control event application.
In touch events, typically, which control is clicked, which control reacts. For example, click the OK button to make sure the button responds to the event, click the Cancel button, and the Cancel button will respond to the event. So, how does the system decide which view (control) to respond to the event?
When a touch event occurs, the system adds the event to a queue managed by UIApplication, uiapplication the first event from the event queue and distributes the event for processing, typically sending an event to the application's main window. The main window will find the most appropriate view in the entire view hierarchy to handle the touch event. Once the appropriate view control is found, the control responds with a method to handle the touch event, often in the following ways:
Touchesbegan ...
Touchesmoved ...
Touchesended ...
Touchescancelled ...
In app development, there is usually more than one control under a controller, so which control is most appropriate for handling the event after a touch event?
In the process of determining the most appropriate control, follow these guidelines:
(1) Determine whether you can receive touch events, if not, direct return, if possible, to step (2)
(2) Determine whether the touch point is on its own, if not, direct return; if at, go to step (3)
(3) Iterate through the child controls, repeating the first two steps
(4) If there are no child controls that meet the criteria, then you are the most appropriate control for handling the touch event.
Examples are as follows:
The green view and the Orange view are the child controls of the white view (assuming that the green view was added, followed by an orange view), the Blue View and the Red view are the child controls of the orange view, and the yellow view is the child of the Blue view.
When a green view is clicked, the event is passed to the white view first. White view satisfies the condition (1), to step 2, touch the point on yourself, go to step 3, do steps on Orange view (1) and step (2), do not meet step (2), fallback, do steps (1) and Steps (2) for Green View, all meet, to step (3), No child controls, to step (4), You are the most appropriate control (green view). The entire process is as follows:
White View---> Orange view (Orange view does not meet step 2, so traverse Green view)
----> Green View (for steps 1 and 2), No child controls, so green view is the most appropriate control for handling the touch event.
When you click on the yellow view, the process is as follows:
White View---> Orange view---> Red view (Red view is covered in blue view, Red view is added later.) Red view does not meet condition 2, so to Blue view)
---> Blue view---> Yellow view (Yellow view has no child controls, so yellow view is the most appropriate control for handling the touch event).
That is, when looking for the most appropriate child view, you start from the parent view control and look down one layer at a time.
After the most appropriate view control is found, the Touchesbegan of the control is called ... and other methods. The default practice for these touches is to pass the event up the responder chain and hand it over to the previous responder.
Assuming that the yellow control is clicked, if the yellow control does not handle the touch event, the event is given to the blue control, and if the control is not processed by the blue control, the control is passed to the orange control, and if the orange control does not handle the event, the event is passed to the white control, and if the white control does not handle the event The white control is handed over to the controller, and if the controller does not handle the event, the Controller gives the main window to handle the event, and if the main window does not handle the event, the main window is given to UIApplication to handle the event, and if UIApplication does not handle the event, the event is discarded , do not do the processing. Thus, the process of dealing with events is routed upward along the responder chain.
As follows:
The left side is a single controller and the right side is a multi controller.
The event delivery process for the responder chain is summarized as follows:
1. If the view controller is present, it is passed to the controller for processing, and if the controller does not exist, it is passed to its parent view
2. At the Dingcheng of the view hierarchy, if the received event cannot be processed, the event is passed to the Window object for processing
3. If the Window object is not processed, the event is passed to the UIApplication object
4. If uiapplication cannot handle the event, the event is discarded.
Upload a code that validates the responder chain (MJ writes) Http://files.cnblogs.com/files/acBool/06-%E5%93%8D%E5%BA%94%E8%80%85%E9%93%BE%E6%9D%A1.zip
The delivery and responder chain of events in iOS
