Response chain and Uikit framework

Event delivery:the Responder Chain

When you design your app, it's likely that's want to respond to events dynamically. For example, a-touch can occur in many different objects onscreen, and you had to decide which object you want to respond To a given event and understand how that object receives the event.

When a user-generated event occurs, UIKit creates an event object containing the information needed to process the even T. Then it places the event object in The active app" S event queue. For touch events, the object is a set of touches packaged in a  uievent  object. For motion events, the event object varies depending on the which framework of your use and what type of motion event is you inte Rested in.

An event travels along a specific path until it's delivered to an object that can handle it. First, The singleton  uiapplication  object takes an event from the top of the queue and dispatches it for HA Ndling. Typically, it sends the event to the app ' s Key window object, which passes the event to a initial object for handling. The initial object depends on the type of event.

• Touch Events. for touch events, the Window object first tries to deliver the event To the view where the touch occurred. That view is known as the Hit-test view. The process of finding the hit-test view is called  hit-testing , which is described In hit-testing Returns the View Where a Touch occurred.

• Motion and remote control Events. with These events, the Window object sends the Shaking-motion or Remote control event to the first responder for handling. The first responder is described In the responder Chain are made up of responder objects.

The ultimate goal of these event paths is to find a object that can handle and respond to an event. Therefore, UIKit first sends the event to the object that's best suited to handle the event. For touch events, this object is the Hit-test view, and for other events, this object is the first responder. The following sections explain in more detail how the Hit-test view and first responder objects is determined.

Hit-testing Returns the View Where a Touch occurred

IOS uses hit-testing to find the view is under a touch. Hit-testing involves checking whether a touch is within the bounds of any relevant view objects. If It is, it recursively checks all of the that view ' s subviews. The lowest view in the view hierarchy that contains, the touch point becomes the hit-test view. After IOS determines the hit-test view, it passes the "touch event to the" View for handling.

To illustrate, suppose this user touches view E in Figure 2-1. IOS finds the Hit-test view by checking the Subview s in this order:

1. The touch is within the bounds of view A, so it checks subviews B and C.

2. The touch isn't within the bounds of view B, but it's within the bounds of view C, so it checks subviews D and E.

3. The touch isn't within the bounds of view D, but it's within the bounds of view E.

   View E is the lowest view of the view hierarchy that contains the touch, so it becomes the hit-test view.

Figure 2-1 Hit-testing Returns the Subview it was touched

the  hittest:withevent:  method Returns the hit test view for a given  cgpoint  and  uievent . the  hittest:withevent:  method begins by calling the  pointinside:withevent:  method on itself. If the point passed into  hittest:withevent:  is inside the bounds of the view,  Pointinside:withevent:  returns  YES . Then, the method recursively calls  hittest:withevent:  on every subview, returns  YES .

If the point passed into hitTest:withEvent: was not inside the bounds of the view, the first call to the pointInside:withEvent: method returns NO , the Point is ignored, and hitTest:withEvent: returns nil . If a subview returns NO , that whole branch of the view hierarchy are ignored, because if the touch did not occur in that Subview, it also did not occur in any of the that Subview ' s subviews. This means, any point in a subview so is outside of it Superview can ' t receive touch events because the touch point Have to is within the bounds of the Superview and the Subview. This can occur if the Subview's property was clipsToBounds set to NO .

Note:a Touch object is associated with its hit-test view for its lifetime, even if the touch later moves outside the view .

The Hit-test view is given the first opportunity to handle a touch event. If The Hit-test view cannot handle an event, the event travels up that view's chain of responders as described in the Responder Chain is made up of Responder Objects until the system finds a object that can handle it.

The Responder Chain is made up of Responder Objects

Many types of events rely on a responder chain for event delivery. The responder chain is a series of linked responder objects. It starts with the first responder and ends with the Application object. If The first responder cannot handle an event, it forwards the event to the next responder in the responder chain.

A Responder Object is an object which can respond to and handle events. UIResponderThe class is the base class for all responder objects, and it defines the programmatic interface isn't only for event Handling but also for common responder behavior. Instances of UIApplication The, UIViewController , and UIView classes is responders, which means, all views and most key controller objects is responders. Note that Core Animation layers is not responders.

The first responder is designated to receive events first. Typically, the first responder is a view object. An object becomes the first responder by doing and things:

1. Overriding the canBecomeFirstResponder method to return YES .

2. Receiving a becomeFirstResponder message. If necessary, an object can send itself the this message.

Note:make sure that your app have established its object graph before assigning a object to be the first responder. For example, your typically call the becomeFirstResponder method in an override of the viewDidAppear: method. If you try to assign the first responder viewWillAppear: in, your object graph isn't yet established, so the becomeFirstResponder method returns c8/>.

Events is not the only objects this rely on the responder chain. The responder chain is used in all of the following:

• Touch events. If The Hit-test view cannot handle a touch event, the event is passed up a chain of responders that starts with the Hit-te St View.

• Motion events.  To handle shake-motion events with UIKit, the first responder must implement either the motionBegan:withEvent: or motionEnded:withEvent: method UIResponder of the Class, as described in detecting shake-motion Events with uievent.

• Remote control events. To handle remote control events, the first responder must implement the remoteControlReceivedWithEvent: method of the UIResponder class.

• Action messages. When the user manipulates a control, such as a button or switch, and the target for the action method is nil , the MESSAG E is sent through a chain of responders starting with the control view.

• Editing-menu messages. When a user taps the commands of the editing menu, IOS uses a responder chain to find an object that implements the Necess ary methods (such as cut: , copy: , and paste: ). For more information, see Displaying and managing the Edit Menu and the sample Code project, copypastetile.

• Text editing. When a user taps a text field or a text view, that view automatically becomes the first responder. By default, the virtual keyboard appears and the text field or text view becomes the focus of editing. You can display a custom input view instead of the keyboard if it's appropriate for your app. You can also add a custom input view to any responder object. For more information, see Custom views for Data Input.

UIKit automatically sets the text field or text view a user taps to be the first responder; Apps must explicitly set all other first responder objects with the becomeFirstResponder method.

The Responder Chain follows a specific Delivery Path

If the initial object-either the Hit-test view or the first RESPONDER-DOESN ' t handle an event, UIKit passes the event to T He next responder in the chain. Each responder decides whether it wants to handle the event or pass it along to its own next responder by calling the method. This process continues until a responder object either handles the event or there is no more responders.

The responder chain sequence begins when IOS detects an event and passes it to an initial object, which is typically a vie W. The initial view has the first opportunity to handle an event. Figure 2-2 shows the different event delivery paths for the app configurations. An app's event delivery path depends on it specific construction, but all event delivery paths adhere to the same heurist ICS.

Figure 2-2 the responder chain on IOS

For the app on the left, the event follows this path:

2. The initial view attempts to handle the event or message. If it can ' t handle the event, it passes the event to its Superview, because the initial view isn't the top most view In its view controller ' s view hierarchy.

4. The Superview attempts to handle the event. If the Superview can ' t handle the event, it passes the event to its superview, because it's still not the top most view I n the view hierarchy.

6. The topmost view in the View controller's view hierarchy attempts to handle the event. If the topmost view can ' t handle the event, it passes the event to its view controller.

8. The view controller attempts to handle the event, and if it is can ' t, passes the event to the window.

10. If the Window object can ' t handle the event, it passes the event to the Singleton app object.

12. If the App object can ' t handle the event, it discards the event.

The app on the right follows a slightly different path, but all event delivery paths follow these heuristics:

1. A View passes an event up its view controller ' s view hierarchy until it reaches the topmost view.

2. The topmost view passes the event to its view controller.

3. The view controller passes the event to its topmost view ' s superview.

   Steps 1-3 Repeat until the event reaches the root view controller.

4. The root view controller passes the event to the Window object.

5. The window passes the event to the App object.

1. The process of finding a response message view can be illustrated with a picture.

The processing principle is as follows:

• When the user taps the screen, a touch event is generated that will be added to an event queue managed by UIApplication

UIApplication will take the first event out of the event queue for distribution for processing, typically sending an event to the application's main window (UIWindow)

• The main window calls Hittest:withevent: Method finds the most appropriate UIView in the view (UIView) hierarchy to handle touch events

(hittest:withevent: Actually is a method of UIView, UIWindow inherit from UIView, so the main window UIWindow also belongs to the view of one)

Hittest:withevent: Method The approximate processing process is this:

First call the current view's Pointinside:withevent: method to determine whether the touch point is within the current view:

? If Pointinside:withevent: Method returns no, indicating that the touch point is not in the current view, the current view of the Hittest:withevent: return nil

? If the Pointinside:withevent: method returns Yes, indicating that the touch point is within the current view, traverse all the child views of the current view (subviews) and call the hittest:withevent of the Child View: Method repeats the previous steps, The traversal order of a child view is from top to bottom, that is, traversing forward from the end of the subviews array, until there is a hittest:withevent of the child View: The method returns a non-empty object, or all the child views are traversed:

? If the hittest:withevent of the child view is returned for the first time: The method returns a non-empty object, the current view's Hittest:withevent: method returns this object, processing ends

? If all child views are hittest:withevent: The method returns nil, the current view's Hittest:withevent: method returns the current view itself (self)

Class inheritance diagram for the uikit/framework:

I. Responder Object

In an iOS system, an object capable of responding to and handling events is called Responder object, and Uiresponder is the base class for all responder objects, defined in the Uiresponder class to handle various events, including touch events , motion event, and the programming interface for remote control events (Remote-control events), where the programming interface for handling touch events is as follows:
–touchesbegan:withevent:
–touchesmoved:withevent:
–touchesended:withevent:
–touchescancelled:withevent:
These four methods handle touch start events, touch move events, touch termination events, and touch trace cancellation events.

UIApplication, Uiviewcontroller,uiview and all Uikit classes that inherit from UIView (including UIWindow, inherited from UIView) are inherited directly or indirectly from Uiresponder, So their examples are responder object objects, all of which implement the above 4 methods. The default implementation in Uiresponder is nothing, but the direct subclass of Uiresponder in Uikit (Uiview,uiviewcontroller ...) The default implementation is to continue the event along the responder chain to the next responder, which is nextresponder. So when customizing the above event handling method of the UIView subclass, if you need to pass the event to next responder, you can call the super's corresponding event-handling method directly, and super's corresponding method will pass the event to next responder, that is, using

[super touchesBegan:touches withEvent:event];

It is not recommended to send a message directly to Nextresponder, which may miss other processing of the event by the parent class.

[self.nextResponder  touchesBegan:touches withEvent:event];

In addition, when customizing the event-handling method of the UIView subclass, if one of the methods does not call the super counterpart, the other methods also need to be rewritten without using super, otherwise the event-handling process can be confusing.

Response chain and Uikit framework