Android touch event Transmission

Android touch event Transmission

There are some plug-ins on the Internet to explain how touch event transmission works, from the source code perspective, from the actual example perspective. Here I just want to record my understanding. I may not be very familiar with other things. If I have any mistakes, I beg to comment and correct them.

 

Directly analyzes the transfer of touch events against illustrations and text.

 

(1) messy graphic version:

(2) figure-based speaking:

 

(2.1)Activity is not included. Activity does not have the onInterceptTouchEvent method. By default, the implementation is directly passed down.

 

(2.2)The following describes the meaning of the Three touch Event Control Methods and Their returned values:

 

<1> onInterceptTouchEvent

OnInterceptTouchEvent is a method unique to ViewGroup. Activity and View do not have this method. It is used to intercept touch events and no longer pass them to subviews (Activity and View do not have subviews, therefore, this method is logical. If the sub-View is intercepted, the sub-View will not accept the touch event at all, and any method of the sub-View's related touch event will not be called. (Note: I will talk about exceptions later) (in special cases)

Returns true:
Blocks touch events. Instead of calling the dispatchTouchEvent method of the sub-View, you can directly call your onTouchEvent method. (In special cases)

Returns false:
It indicates that the event is not intercepted and the dispatchTouchEvent of the subview is called.

 

<2> dispatchTouchEvent

This method is used to assign a touch event. It must be noted that an event is dispatched, rather than an event. This method determines the event Transmission Direction, rather than processing the consumption of a touch event.

Returns true:

It indicates that you want to consume this event, but it is not consumed immediately, but if its sub-View is not consumed, it is consumed by yourself. The event will continue to be passed down, but if it still reaches itself during the transfer-up process, it will be consumed.

Returns false:

This indicates that you do not consume this event. If both onTouchEvent and false are returned, the onTouchEvent will be passed to the parent.

 

<3> onTouchEvent

This method is used to process events. If you want to process touch events and make corresponding actions, you should do so in this method.

Returns true:

It indicates that you want to consume this event and it will take effect immediately. The consumption will immediately stop the event.

Returns false:

It indicates that you do not want to consume this event. If true is returned before checking dispatchTouchEvent, you will find that: Oh, I said that no sub-View is processed, so I will handle it. Well, if I want to keep my promise, let me handle it. Don't pass it on again.

 

Note the difference between dispatchTouchEvent and onTouchEvent returned true:

 

If dispatchTouchEvent is consumed by no one, it will be handed over to me for consumption. If no one of you wants it, just give it to me. You guys are really good guys.

OnTouchEvent is what I want to consume now, and no one else can afford it. What do I do? It's so domineering and so capricious.

 

(2.3) what may happen during transmission

The first receiver of a touch event is always Activity. Generally, the Activity does not consume the touch event, but is directly transmitted to the View tree set within the scope of the touch event. In the View tree, the level position corresponds to the position in the touch event, that is, the View on the outer layer is located at the top layer, while its child is located at the bottom layer. That is, the Activity is at the top layer, followed by the container control, and the final View is at the bottom layer.

 

In general:

The event first goes from top to bottom and goes through every dispatchTouchEvent. When the last View is reached, the onTouchEvent is called to start the transfer process from bottom to top, passing through every onTouchEvent. This is the case where no View wants to consume touch events.

Possible turning points:

<1>During the top-down process, if the onInterceptTouchEvent of a View returns true, it indicates that the event is intercepted and the event will not be passed down. Instead, the onTouchEvent of the View is called directly, note that this does not mean that this View consumes this event. It only intercepts this event and continues to pass it down. It denies the consumption right of the subview and starts the process from bottom up in advance, whether it is consumed depends on whether its onTouchEvent return value is true. (In special cases)

<2>During the process from bottom up, if the onTouchEvent of a View returns true, it indicates that you want to consume the event, the event will not continue to be passed up, and the event transfer ends.

<3>Or in the process from bottom up, if a View returns true in the previous dispatchTouchEvent method, it indicates that if all child views do not consume this event, so let me consume it. The event will not be passed up and the event will be passed over.
(This event is not consumed by all sub-views. This means that both dispatchTouchEvent and onTouchEvent of all sub-views return false. Otherwise, the event will be consumed early and passed over, and it will not reach itself again .)

<4>This is rarely used. A subview calls the parent's requestDisallowInterceptTouchEvent method, indicating that the parent request does not intercept events. In this case, the parent's onInterceptTouchEvent returns true and cannot intercept events, that is, the onInterceptTouchEvent method is invalid. This is the special situation marked by the three above (with special circumstances.

 

(2.4) Memory Function

The memory function means that if a View consumes a Down event, the next Move, Up, and other events will still be passed Down from the top layer of the Activity, but when passed to this View, even if this View does not use the onInterceptTouchEvent method to intercept events, the events will still be intercepted and processed directly by this View. That is, if a View consumes a Down event, the next Move and Up events will be handed over to it for consumption.

The reason for doing so is: Generally, a single touch event cannot form a valid action. For example, a drag action requires a Down event and a continuous Move event, and a click action requires at least one Down event and an Up event. Assigning a single touch event to different views often leads to no meaningful action. Therefore, this memory function is added to reduce event transmission.

 

(3) Just say something

Understanding the transfer of touch events is generally used to solve the conflict between touch events. When dealing with touch events, pay attention to the following points:

What we need to deal with is who will handle the touch event, rather than modifying how the View that consumes the event should be handled.

It's a bit of a dirty interface, right? In other words, we should control who will handle it, rather than how to handle it. Each View has its own processing logic, so we should not modify it.
Example:
When the left and right fingers cannot drag ViewPager, we have to think about how to allow ViewPager to get the consumption right of the touch event when dragging the left and right fingers, instead, let alone how to make the ViewPager scroll with its fingers after the touch event is received. This function has been implemented by ViewPager itself. You can give the touch event to it and it will be able to roll.

 

Now, this article is complete. It is recommended that you write an example for verifying the touch event transfer mechanism and print some logs. Then, Baidu and Google will look at the common touch conflicts and their solutions.