Event Delivery Response Chain (event delivery:the Responder Chain) "Go"

When you design your app, you may need to respond to events dynamically. For example, a touch event may occur on a different object on the screen, and you need to decide which object responds to the given event and how the object receives the event.

When an event triggered by a user occurs, Uikit creates an event object that contains the event information to be processed. Then she puts the event object into the active app's (Application object, each program corresponds to the only one) event queue. For touch events, the event object is a series of touch collections encapsulated by the Uievent object. For action events, this event object relies on the framework used and what kind of action events you care about.

An event is passed through a special path until it is passed to an object that can handle the event. First, the singleton UIApplication object gets the event from the top-level queue and then distributes it. Typically, it sends an event to the app's key window object, and the window sends it to the initialization object (initial objects) in order to handle the event, which initializes the dependency event type.

• Touch Events. For touch events, the Window object first attempts to pass an event to the view that the event occurred. This view is the so-called Hit-test view. The way to find Hit-test view is called Hit-testing, which describes the "hit-testing Returns the View Where a Touch occurred."
• action events and Remote control events (motion and remotes). In these events, the Window object sends an event to the first responder. The first responder is described in "the Responder Chain is made up of Responder Objects."

The ultimate purpose of the event delivery path is to find the object that can handle and respond to the event. Therefore, Uikit sends an event to the object that is appropriate to handle the event. For touch events, this object is the Hit-test view, and for other events, this object is the first responder of the responder. The following sections explain how the Hit-test view and first responder objects are determined.

Hit-testing returns the view that the touch occurred

iOS uses hit-testing to find the touch of a view. Hit-testing checks all child view of the view by checking whether the touch point is within the associated view boundary and, if so, recursively (recursively). A view that is lowest at the level (which I understand is the closest view from the user) and the boundary range contains the touch points becomes hit-test view. After determining the Hit-test view, it passes the touch event to the view.

For example, suppose the user touches view E in the diagram. iOS finds Hit-test view in the following order.

1. The touch points are in view a, so check the sub view B and C.
2. The touch point is not in view B, but in C, so check the child view D and E of C.
3. The touch point is not in D, but in E.

View E is the boundary range of the lowest view at this level that contains the touch points, so it becomes hit-test view.

Hittest:withevent: The method returns hit test view by passing in Cgpoint and Uievent. The method calls the Pointinside:withevent: method, and if the point of the incoming hittest:withevent: is within the bounds of the view, then pointinside:withevent: returns YES. This method will then recursively call hittest:withevent in all of the view's child view:.

If the point of the incoming hittest:withevent: is within the bounds of the view, Pointinside:withevent: Returns No. This point is ignored, hittest:withevent: returns nil. If a child view returns no, the sub-view of the branch at the level of the view it is in is ignored.

Hit-test View is the first choice for handling touch events, and if Hit-test view cannot handle the event, the event will look for the responder from the event response chain until the system finds an object that handles the event. See specifically "The Responder Chain is made up of Responder Objects".

The responder chain consists of a responder object (the Responder Chain is made up of Responder Objects)

The delivery of some types of events depends on the responder chain. The responder chain (responder chain) is a series of related responder objects. It begins with the first responder terminating at the Application object (Application object). If the first responder does not handle events, the event is passed to the next responder based on the responder chain.

Responder object, which can respond to and handle events. The Uiresponder class is the base class for all responder objects, and it defines a dynamic interface that handles not only the event but also the response behavior. Both Uiapplication,uiviewcontroller, and UIView classes are responder, which means that all view and most key controller objects are responder. Enough core Animation layers not responders.

First Responder is designed to receive the event at the top. Typically, first responder is a view object. The reason for being the first responder is due to two reasons:

1. Overwrite the Canbecomefirstresponder method and return yes.
2. Receives the Becomefirstresponder message. If necessary, an object can send itself this message.

。。。

The responder chain follows a special delivery path (the Responder Chain follows a specific Delivery path)

If the initialization object (initial objects)-that is, hit-test view or first responder---does not handle the event, Uikit passes the event to responder chain's next responder. Each responder determines whether it is a passing event or the next responder passed to it through the Nextresponder method. This operation continues until a responder handles the event or no responder.

The Responder chain sequence starts when iOS determines an event and passes it to initial object (usually view). So initial view has the first opportunity to handle events. Describes two different event delivery paths (because of different app settings). An app's event delivery path is determined by the app's special composition, but the event delivery path follows the same rules.

Key methods

- (UIView *)hitTest:(CGPoint)point withEvent:(UIEvent *)eventReturns the view that is farthest from the current view at the level (closest to the user) and contains the specified point.

On the explanation of HitTest method See Hittest:withevent: Method Flow

- (BOOL)pointInside:(CGPoint)point withEvent:(UIEvent *)eventReturns a Boolean value indicating whether receiver contains the specified point.

Call this: Manually specify that the current view does not respond to an event

1234567

-(BOOL)pointInside:(CGPoint)point withEvent:(UIEvent *)event { for (UIView *view in self.subviews) { if (!view.hidden && view.userInteractionEnabled && [view pointInside:[self convertPoint:point toView:view] withEvent:event]) return YES; } return NO;}

Summarize:

The delivery and response of an event is divided into two chains:

• Delivery chain: The system is passed to the view closest to the user. Uikit–> Active App ' s event queue–> window–> root view–>......–>lowest view
• Response chain: Passed from the view closest to the user to the system. Initial view–> Super view–> .....–> view controller–> window–> Application

http://nsdifficult.com/blog/20140314/event/

Event Delivery Response Chain (event delivery:the Responder Chain) "Go"