iOS Learning 9_ Event Distribution & response chain &android to iOS insights

Three types of events for iOS: Touch Event/Motion Event/Remote control event

typedef enum {Uieventtypetouches,uieventtypemotion,uieventtyperemotecontrol,} Uieventtype;

Only objects that inherit the Uiresponder class can handle events, such as UIView, Uiviewcontroller, and UIApplication, which inherit from Uiresponder and can receive and handle events. The above three types of event-related processing methods are defined in Uiresponder:

The following mainly discusses touch events.

-(void) Touchesbegan: (Nsset *) touches withevent: (Uievent *) event;   -(void) touchesmoved: (Nsset *) touches withevent: (Uievent *) event;  -(void) touchesended: (Nsset *) touches withevent: (Uievent *) event;   -(void) touchescancelled: (Nsset *) touches withevent: (Uievent *) event;

Event Distribution: hit-testing View

When the user touches the screen of the device, iOS recognizes the series of touch events and encapsulates them inside the Uievent object, and puts them into the application event queue, where UIApplication takes the first event from the event queue and distributes the processing, when the event is processed. Normally he will send it to the main window, and the main window will then pass the event to an initial object, which is touch events

The event is first sent to the most appropriate object for processing. For touch events This object refers to Hit-test view, which refers to the first responder for other events.

UIKit first sends the event to the object which is 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.

Hit-testing refers to the process of finding the view on which the current touch event occurs: If the touch is within the bounds of a view, it will recursively check whether its sub-view contains a touch point. The outermost view that contains the touch point is called Hit-test view. When iOS determines hit-test view, it passes the touch event to the view for processing.

Hittest:withevent: The specific implementation:

Hittest:withevent: The method first calls the Pointinside:withevent: method, and if the touch point is inside the view, the method returns Yes. The next recursive call to all Pointinside:withevent: method returns the hittest:withevent of the child view of Yes: method.

If the touch point is not inside the view, call Pointinside:withevent: The method returns No,hittest:withevent: Nil is returned. If the child view returns no when calling Pointinside:withevent: then all child views with this child view as the parent will not have to be checked again. That is, if the touch point is not on a sub-view, it must not be on the sub view of the child view. That is, the part of any child view outside of the parent view is never able to receive touch events.

Touch events are never received when touching the red box of the topmost green control. This situation occurs when the Clipstobounds property of the view is set to No.

The following example shows the hittest:withevent: the process of a function

Suppose the user touches view E in the diagram. iOS finds Hit-test view in the following order

1. Touch point is inside a, so detect sub view B and C

2. The touch point is not in B, but inside C. Therefore, the sub-view D and E of C are detected.

3. The touch point is not in D, but inside E, and E is the outermost view that contains the touch point, so E is the hit-test view to find

hittest:withevent: The implementation code of the function:

1. Can you handle it yourself? No, return nil;

2. Point is not on the current control? No, return nil;

3. Description can handle touch events, and on the current control, is the appropriate control, but not necessarily the most appropriate. The most appropriate control (the view that contains the touch point) is to traverse its own child control from behind. If it is, return to the view.

4. The description did not find the appropriate view, return to their own.

-(UIView *) HitTest: (cgpoint) point withevent: (Uievent *) Event implementation:

-(UIView *) HitTest: (cgpoint) point withevent: (uievent *) event{    if (Self.hidden | |!self.userinteractionenabled | | Self.alpha < 0.01)    {        return nil;    }    if (![ Self pointinside:point withevent:event])    {        return nil;    }    __block UIView *hitview = self;    [Self.subviews enumerateobjectswithoptions:nsenumerationreverse usingblock:^ (id obj, Nsuinteger idx, BOOL *stop) {           Cgpoint thepoint = [self convertpoint:point toview:obj];        UIView *thesubhitview = [obj hittest:thepoint withevent:event];        if (Thesubhitview! = nil)        {            hitview = Thesubhitview;            *stop = YES;        }    }];    return Hitview;}

Response Chain

A response chain is a series of response objects in which the base class for all objects is uiresponder from Firstresponse to Application object end. Firstresponse means first receiving an event, the general first Responder is a view, and for touch events it is hit-test view.

As mentioned earlier, Uikit first sends the event to the most appropriate object for processing. For touch events This object refers to Hit-test view, which refers to the first responder for other events.

But actually the response chain is also used in touch events/motion events/REMOTE control events/etc.

If Hit-test view cannot handle an event, the event is passed up through the response chain (Hittestview is the first responder) until a responder is found that can be processed.

The order of delivery along the response chain is given. The difference between the two graphs is that the hierarchy of views is different. The response chain starts with the Firstresponse and next is its parent view, if there is no parent view until its controller (if any) goes to window and application.

Initial object may be hit-test view or first responder, no event is handled. Uikit will pass the event to next responder the next responder, each responder by invoking the

The-nextresponder method determines whether the event is handled or passed to the upper layer of the response chain until a responder has processed the event or no responder has been reached.

Sending a message directly to Nextresponder is not recommended:

<span style= "Font-family:microsoft Yahei;" >[self.nextresponder touchesbegan:touches withevent:event];</span>

Instead, it is recommended to call the implementation of the parent class so that Uikit can help us because the default implementation is to continue the event along the response chain to the next responder.

<span style= "Font-family:microsoft Yahei;" >[super touchesbegan:touches withevent:event];</span>

Note:

The concept of Hit-test view and the response chain was a little mixed up, until the document was taken a good look at it: When an event takes place, it is handled by the appropriate object. If it is a touch event, the object is Hit-test view. If it is a different event, the object refers to the first responder (in the response chain). The response chain is a relatively large category, in touch events, Hit-test view is the first responder in the response chain. That is, the hit-test view found through the Hittest:withevent: method in the Touch event is the first responder.

event distribution in Android

Go back and simply tidy up the process of event delivery in Android: Android View and ViewGroup event distribution

ViewGroup passed through the dispatchtouchevent--->onintercepttouchevent

Iterates through the child view from the back, if the child view can handle the event returns TRUE. Pass to this end

If the child view cannot handle the event, handle it yourself .... ontouchevent

View Handling Events

Dispatchtouchevent-> ontouch–-> ontouchevent

Setting the Listener Ontouch returns TRUE or returns false but Ontouchevent returns true to assume that the child view processed the event successfully

If False is returned, the event is thrown up, and the ViewGroup calls its own ontouchevent to handle the event.

In iOS, events are not handled/passed because of the opacity of 0, but can be in Android.

iOS if the parent control settings do not interact then the above sub-space can not get events, and Android inside even if the service layout settings enable false or clickable set to false, the above subspace can receive the event.

There is no view and view container in iOS, and Android has view and ViewGroup points, so event distribution is also a bit troublesome,

etc...

Feelings:

Learning iOS One months, found that the start is very fast, a lot of things and Android is similar, learning very fast, but it is always bothering me is when learning new things in iOS I always think of how the Android inside is how to achieve, the difference between the two. I am so puzzled also very interesting ^_^

iOS Learning 9_ Event Distribution & response chain &android to iOS insights