IOS learning 9_event distribution & amp; Response Chain & amp; small sentiment of converting android to iOS, and ios event Distribution

IOS learning 9_event distribution & Response Chain & Small sentiment of converting android to iOS, and ios event Distribution

Three events for iOS: Touch events, motion events, and remote control events

typedef enum {UIEventTypeTouches,UIEventTypeMotion,UIEventTypeRemoteControl,} UIEventType;

Only objects that inherit the UIResponder class can process events. For example, UIView, UIViewController, and UIApplication all inherit from UIResponder and can receive and process events. The preceding three types of Event-related processing methods are defined in UIResponder:

Next we will mainly discuss 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 will recognize this series of touch events and encapsulate them into the UIEvent object, and put them in the application event queue. When processing events, UIApplication extracts the first event from the event queue and distributes it for processing. Generally, it sends the event to the main window. Then, the main window passes the event to an initial object for processing, this object is Touch events for a Touch event.

First, the event is sent to the most appropriate object for processing. For a touch event, this object refers to the hit-test view. For other events, this object refers to the first responder.

UIKit first sends the event to the object that is best suited to handle the event. for touch events, that object is the hit-test view, and for other events, that 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 in the border of a View, it recursively checks whether its sub-View contains touch points. The View containing the touch point is called the hit-test view. After iOS determines the hit-test view, it will pass the touch event to the View for processing.

HitTest: withEvent: specific implementation:

HitTest: withEvent: The method first calls pointInside: withEvent: method. If the touch point is inside the View, the method returns YES. Next, recursively call all pointInside: withEvent: Methods to return the hitTest: withEvent: Method of the Child view of YES.

If the touch point is not in the View, call pointInside: withEvent: The method will return NO, hitTest: withEvent: nil. If the child view returns NO when pointInside: withEvent: is called, all the child views with this child view as the parent view do not have to be checked. That is to say, if the touch point is not on a subview, it is certainly not on the subview of the subview. That is to say, the part of any child view outside the parent view cannot receive the touch event.

When you touch the red frame of the green control on the top, you will never receive a touch event. This situation occurs when the clipsToBounds attribute of view is set to NO.

The following example shows the hitTest: withEvent: function process.

Assume that you have touched view E in the figure. IOS searches for hit-test view in the following order

1. The touch point is inside A, so the sub-view B and C are detected.

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

3. The touch point is not in D, but in E, and E is the view containing the touch point in the outermost layer. Therefore, E is the hit-test view to be searched.

HitTest: withEvent: function implementation code:

1. Can I handle it by myself? No, return nil;

2. Is the point not in the current control? No, return nil;

3. It indicates that it can handle touch events and is a suitable control on the current control, but not necessarily the most suitable. Traverse your child control from the back to the front to see if it is the most suitable control (including the View of the touch point ). If yes, the View is returned.

4. It indicates that no View is suitable for you and you are returned.

-(UIView *) hitTest :( CGPoint) point withEvent :( UIEvent *) Implementation of event:

- (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

The response chain is a series of response objects. In the response chain, the base classes of all objects are UIResponder starting from firstResponse to the end of the application object. FirstResponse means that the event is received first. Generally, the first responder is a view, which is hit-test view for a touch event.

As mentioned above, UIKit will first send the event to the most appropriate object for processing. For a touch event, this object refers to the hit-test view. For other events, this object refers to the first responder.

But in fact, the response chain is also used for touch events, motion events, remote control events, and so on.

If the hit-test view cannot process an event, the event is passed through the response chain (hitTestView is the first Responder) until a Responder can be processed is found.

The order of delivery along the response chain is given. The difference between the two graphs is that the hierarchical relationship of the view is different. The response chain starts from firstResponse and then comes to its parent view. If there is no parent view until its controller (if any) goes to window and application.

The initial object may be hit-test view or first responder and does not process the event. UIkit will pass the event to next responder for the next responder.

-The nextResponder method determines whether to process the event or send it to the upper layer of the response chain until a responder processes the event or has no responder.

It is not recommended to send messages directly to nextResponder:

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

We recommend that you call the implementation of the parent class so that UIKit can help us, because the default implementation is to pass the event along the response chain to the next responder.

[super touchesBegan:touches withEvent:event];

Note:

The hit-test view and response chain concepts were mixed at the beginning, and they were not understood until they looked good at the document: when an event needs to be handled, suitable objects will be processed. If it is a touch event, the object is hit-test view. For other events, this object refers to the first responder (in the response chain ). Response chain is a relatively large category. In Touch events, hit-test view is the first responder in the response chain. In other words, the hit-test view found through the hitTest: withEvent: Method in the touch event is the first responder.

Event distribution in Android

Finally, I simply sorted out the process of event passing in android: View and ViewGroup event distribution in Android.

When the ViewGroup is passed, it experienced dispatchTouchEvent ---> onInterceptTouchEvent

Traverse the child View from the back. If the child View can process the event, return true. Transfer ends here

If the sub-View cannot process this event, process it yourself... onTouchEvent

View event processing

DispatchTouchEvent-> onTouch --> onTouchEvent

If the listener onTouch returns true or false, but the onTouchEvent returns true, the subview successfully processes the event.

If false is returned, the event is throttled, And the ViewGroup calls its own onTouchEvent to process the event.

In iOS, events cannot be processed or transmitted because the transparency is 0, but can be handled in android.

In iOS, if the parent control settings cannot interact with each other, the preceding sub-spaces cannot obtain events. In android, even if the server layout settings enable to false or clickable is set to false, all the sub-spaces above can receive events.

There are no view and view containers in iOS, but there are View and view groups in android, which makes event distribution a little effort,

...

Thoughts:

I learned iOS for a month and found that it was very fast to get started. Many things are similar to android, and they are very fast to learn, but what has plagued me all the time is that whenever I learn new things in iOS, I always think about how it was implemented in android before, the difference between the two. I am so puzzled also very interested ^_^