Event handling Guide (Events handling guides for IOS) read notes (ii) Response chain

Event delivery:the Responder Chain

We want to be able to dynamically respond to touch events in our app. For example, a touch may occur on the screen in different locations and on different components, we need to determine which component responds to this touch and how this component accepts touch events.

When a user touches an event, Uikit creates an object that contains the event information that needs to be handled. The object is then placed in the current event loop queue, and for touch events, this object is created as a Uievent object, which is dependent on the object you use for moving events. The framework and the moving events that you care about.

We assume that this event object is Eventa

The Eventa is passed through a special path until it can be processed. First the singleton UIApplication object gets the Eventa from the event queue and distributes the event object. Typically, UIApplication assigns Eventa to the Application key Window object that created the Eventa. Eventa is dependent on the type of event that occurred, there are two types:

• Touch events for touch events, the Window object attempts to pass events to the view that the touch occurred. This view is called hit-test view. So, the process of finding this view is called hit-testing. The process of finding the view is described below.

• Shaking and remote control events (Motion and remotes) handle this event, the Window object emits a shaking event or remote control event to the first responder, and how to find the first responder is described below.

The ultimate goal of these event delivery paths, then, is to find an object that can handle it. Therefore, UIKit will send these events to the most appropriate object to handle them. For touch events, this object is Hit-test view, and for other events, this object is the first responder Sponder.

Hit-testing returns a touch event that occurs when the view

iOS uses hit-testing to find the view that is being touched. The hit-testing operation includes checking that the touch is within the size of the associated View (bounds), and, if it is, iterating through all the child views of the view and the child views of the view, at the lowest level in all view levels, and the view that contains the touch event is Hit-test View When iOS finds this view, it tells the event object to hand it over to the view.
Here's a diagram that shows how to find hit-testing view

Let's say we click on a view e, the system calls first hitTest:withEvent: , the view A and click coordinates are passed in, and the search for sub-view is traversed, then the touch point is found on view C, and the view C's child view is searched, then the touch point is found on view E, and the view E has no child view, all methods return view E As Hit-test view, becoming the first responder.

hitTest:withEvent:Is the method of UIView, which is called by a given click Coordinate and thing Cgpoint and Uievent, the method internal call pointInside:withEvent: to check whether the touch point is on a view, if yes is returned, the description is on the view, and then the hitTest:withEvent: loop is called pointInside:withEvent: Returns the view for Yes.
If the touch point is not hitTest:withEvent: on the call view, the internal call pointInside:withEvent: returns no, and hitTest:withEvent: nil is returned. If a child view hitTest:withEvent: returns no, then all the view levels below it are ignored, because the touch point is not on any of its child views,

* Note: A touch event is bound to this hit-test view during his life cycle, even though the touch point then moves out of the view's bounds *

This hit-test view is the first to have an opportunity to handle the touch event, and if the view cannot handle the event, the event will look up the view's hierarchical chain to find the first one that can handle it, and then stop passing it when it is found and processed.

Response chains are made up of response objects

Many events need to rely on the response chain to deliver the message. The responder chain is a sequence of connected responders. It starts with the first responder to the end of the Application object. If the first responder cannot handle the event, the event is passed to the next responder on the responder chain.
A responder is an object that can respond to and handle events. The Uiresponder class is the base class for all responders, and it defines interfaces for event handling and responder operations. Objects like UIApplication, Uiviewcontroller, and UIView are responders. Note that the Core Animation layers is not a responder.

The first responder is designated as the first responder to receive the event, usually the first responder is a UIView object. For an object to be the first responder, two things must be done:

1. Set Property canBecomeFirstResponder to Yes
2. Receive becomeFirstResponder a message from a sender

* Note: Before an object is specified as the first responder, an object or view has been established. For example: You usually call in the becomeFirstResponder viewDidAppear: method, if you try to specify the first responder in the viewWillAppear: method, but your response object is not established, it causes the becomeFirstResponder return no*

The responder chain is also used for the following events:

• Touch Event Touch events. If Hit-test view cannot handle the event, the event is passed along the Hit-test view to find the processor and discarded if no one is processed.
• Remote control event remotely controlled events. In order to handle the event, the first responder must implement the Uiresponder methodremoteControlReceivedWithEvent:
• Click event Action messages. When a user uses a control view, such as UIButton or Uiswitch, the target responds with nil, and the event is passed along the response chain.
• Edit Menu Event Editing-menu messages. When the user uses the Edit menu, iOS looks for the responder in the responder chain, such as a method, for the necessary method cut: copy: paste: .
• Text edit text editing. When the user uses text field or text view, the view automatically becomes the first responder. The default virtual keyboard pops up and the view becomes the editing focus. You can also play a custom input box instead of the system keyboard.

UIKit will automatically set the clicked Text field or text view to the first responder, we must display the call becomeFirstResponder to set the other object as the first responder.

The responder chain follows a specific delivery path

If the initialized object-not hit-test view, is the first responder, does not handle the event, UIKit will pass the event along the ring chain. Each responder decides whether to handle the event or to continue passing it to the next responder by calling the nextResponder method. This process continues until one responder has handled the event or no next responder.

The responder chain begins to discover an event in iOS and passes it to the initialized object, usually a view. This initialized object is the first to have an opportunity to handle the event. Passing paths for two events depends on the different view constructs.

For the app on the left, the event is delivered as follows:

1. Initial view attempts to process an event or message. If it cannot handle it, it passes the event to its parent view, Super view, because inital view is not the top view in its Viewcontroller view level (the closest views to Viewcontroller, the stack bottom element in the stack).
2. Super view attempts to process an event or message. If it cannot handle it, it passes the event to its parent view, because Super view is still not the top view in the Viewcontroller view hierarchy.
3. Viewcontroller View topmost view attempts to process an event or message. If it cannot handle it, it passes the event to Viewcontroller
4. Viewcontroller tries to process the time, and if it can't handle it, pass the event to a window.
5. If the window object cannot handle the event, it passes the time to application
6. If application cannot handle the event, then the event is discarded.

The app delivery path on the right is a bit different, but the delivery rules follow the following algorithm:

1. A view passes events along its viewcontroller level until it is passed to the top view.
2. The top-most view passes events to its viewcontroller.
3. Viewcontroller passes the event to the parent view of the top view, looping through step 1-3 until the event reaches root Viewcontroller.
4. Root Viewcontroller passing events to the Window object
5. Window passes the event to the UIApplication object.

Important: If your custom view is handling Remotecontrolevents,actionmessages,shake-motion events, or editing-menu messages these messages or events, Do not forward events or messages directly nextResponder to the response chain. Instead of calling the parent class to implement the current event handling, let Uikit handle the event's forwarding in the response chain

Event handling Guide (Events handling guides for IOS) read notes (ii) Response chain