Touch event Distribution

Touch event Distribution

There are only two protagonists in Touch event distribution: ViewGroup and View. The Touch event of an Activity is actually a Touch event that calls its internal ViewGroup and can be processed as a ViewGroup directly.

In ViewGroup, ViewGroup can also be in other viewgroups. In this case, the internal ViewGroup is used as View for analysis.

There are three events related to ViewGroup: onInterceptTouchEvent, dispatchTouchEvent, and onTouchEvent. There are only two View-related events: dispatchTouchEvent and onTouchEvent.

DispatchTouchEvent-onInterceptTouchEvent-onTouchEvent

First, analyze the processing process of ViewGroup. First, we need to have a structure model concept: ViewGroup and View form a tree structure, with the top layer being the ViewGroup of Activity. Below there are several ViewGroup nodes, there are several ViewGroup nodes or View nodes under each node, and so on.

 

When a Touch event (for example, a Touch event) arrives at the root node, that is, the ViewGroup of Acitivty, it is delivered in sequence, and the process of delivery is implemented by calling the dispatchTouchEvent method of the child View (ViewGroup. To put it simply, ViewGroup traverses the child View it contains and calls the dispatchTouchEvent method of each View. When the child View is a ViewGroup, the dispatchTouchEvent method of the ViwGroup will be called to continue calling the dispatchTouchEvent method of its internal View. In the above example, the message delivery order is as follows: ①-②-⑤-⑥-7-③-④. The dispatchTouchEvent method is only responsible for event distribution. It has a boolean type return value. If the return value is true, sequential delivery is interrupted. In the preceding example, if the return result of the 5th dispatchTouchEvent is true, neither of them will receive this Touch event. A simple version of the Code to deepen understanding:

/*** ViewGroup * @ param ev * @ return */public boolean dispatchTouchEvent (MotionEvent ev ){.... // other processing, regardless of View [] views = getChildView (); for (int I = 0; I
 
  
It can be seen that the dispatchTouchEvent of ViewGroup is actually executing the "distribution" work, while the dispatchTouchEvent method of View does not execute the distribution work, or it distributes objects to itself, decide whether to handle the touch event by yourself. The onTouchEvent event method is used. In fact, the Code actually executed by the dispatchTouchEvent method of the sub-View is as follows:
  
/*** View * @ param ev * @ return */public boolean dispatchTouchEvent (MotionEvent ev) {... // handle other operations, regardless of the return onTouchEvent (event );}
  
In general, we should not overwrite the dispatchTouchEvent method in a common View because it does not execute the distribution logic. When the Touch event arrives at the View, what we should do is whether to process it in the onTouchEvent event.
  
So when is the onTouchEvent event of ViewGroup handled? When all the child views in the ViewGroup return false, the onTouchEvent event is executed. Because ViewGroup inherits from View, it calls View's dispatchTouchEvent method to execute onTouchEvent.
  
 
  
In the current situation, it seems that as long as we return false for all ontouchevents, all the child controls can respond to this Touch event. However, it must be noted that the Touch event here is limited to the Acition_Down event, that is, the Touch event, but Aciton_UP and Action_MOVE will not be executed. In fact, a complete Touch event should be composed of one Down, one Up, and several moves. By means of dispatchTouchEvent distribution in the Down mode, the purpose of distribution is to find the View that really needs to process the complete Touch request. When the onTouchEvent event of a View or ViewGroup returns true, it indicates that it is the View that actually needs to process the request, and the Aciton_UP and Action_MOVE will be processed by it. When the onTouchEvent of all sub-views returns false, the Touch request will be handled by the root ViewGroup, that is, the Activity itself.
  
Let's take a look at the improved dispatchTouchEvent method of ViewGroup.
  
View mTarget = null; // Save the View public boolean dispatchTouchEvent (MotionEvent ev) processed by the capture Touch event ){//.... other processing, regardless of if (ev. getAction () = KeyEvent. ACTION_DOWN) {// every time the event is Down, it is set to Null if (! OnInterceptTouchEvent () {mTarget = null; View [] views = getChildView (); for (int I = 0; I
   
    
//... Other processing, No matter here}
    
// This step will not be executed in Action_Down. Only Move and UP will be executed. Return mTarget. dispatchTouchEvent (ev );}
    
 
    
ViewGroup also has an onInterceptTouchEvent, which is known as an interception event by its name. The interception event can be described in two cases:
    
1. if we return true for the Touch event whose Action is Down in the onInterceptTouchEvent of a ViewGroup, all the dispatch operations of the ViewGroup will be intercepted. In this case, mTarget is always null, because mTarget is assigned a value in the Down event. Because mTarge is null, The onTouchEvent event of the ViewGroup is executed. In this case, the ViewGroup can be treated as a View directly.
    
2. assume that, in the onInterceptTouchEvent of a ViewGroup, all Touch events whose Acion is Down are returned with false, and all others return True. In this case, Down events can be normally distributed, if all the sub-views return false, mTarget is still null, with no effect. If a sub-View returns true and mTarget is assigned a value, when Action_Move and Aciton_UP are distributed to the ViewGroup, A MotionEvent of Action_Delete is distributed to mTarget and the mTarget value is cleared, so that the next Action_Move (if the previous operation is not UP) will be processed by the onTouchEvent of ViewGroup.
    
Scenario 1 is used more often, and scenario 2 is not found yet.
    
Summary:
    
1. There are only two protagonists in Touch event distribution: ViewGroup and View. ViewGroup contains onInterceptTouchEvent, dispatchTouchEvent, and onTouchEvent. View contains dispatchTouchEvent and onTouchEvent. ViewGroup inherits from View.
    
2. ViewGroup and View form a tree structure. The root node is a ViwGroup contained in the Activity.
    
3. A touch event consists of Action_Down, Action_Move, and Aciton_UP. Among a complete touch event, there is only one Down event and one Up event. There are several Move events, which can be 0.
    
4. When Acitivty receives a Touch event, it traverses the sub-View to distribute the Down event. The traversal of ViewGroup can be seen as recursion. The purpose of distribution is to find the View that really needs to process the complete touch event. This View will return true in the onTouchuEvent result.
    
5. When a sub-View returns true, the distribution of the Down event is aborted and the sub-View is recorded in the ViewGroup. The next Move and Up events are processed by the sub-View. Because the child View is saved in ViewGroup, when the node Structure of the multi-layer ViewGroup, the parent ViewGroup saves the ViewGroup object where the View that actually handles the event is located, such as the structure of the ViewGroup0-ViewGroup1-TextView, textView returns true, which is saved in ViewGroup1, and ViewGroup1 returns true, which is saved in ViewGroup0. When a Move or UP event occurs, it is first transmitted from ViewGroup0 to ViewGroup1, and then transmitted from ViewGroup1 to TextView.
    
6. When no Down event is captured for all sub-views in the ViewGroup, The onTouch event of the ViewGroup is triggered. The trigger method is to call the super. dispatchTouchEvent function, that is, the dispatchTouchEvent method of the parent Class View. The onTouchEvent method of Acitivity is triggered when no child View is processed.
    
7. onInterceptTouchEvent has two functions: 1. Intercept the distribution of Down events. 2. Stop the Up and Move events and send them to the target View so that the ViewGroup where the target View is located can capture the Up and Move events.
    
 
    
In addition, the Code listed above is not the real source code. It just summarizes the core processing process of the source code in event distribution processing. You can view the real source code by yourself, including richer content.
    
Supplement:
    
"A touch event consists of Action_Down, Action_Move, and Aciton_UP. In a complete touch event, there is only one Down event and one Up event. There are several moves, which can be 0 .", In this example, the number of UP events may be 0.
    
 
    
Recently, I am working on a Demo of How to zoom in and out a mobile image with a gesture. I have a better understanding of this. For onInterceptTouchEvent events, its application scenarios are reflected in many viewgroups with scroll effects. Imagine that in another ViewPager, every Item is an ImageView. We need to perform Matrix operations on these imageviews, which inevitably captures Touch events, however, we need to ensure that ViewPager can capture the Move event without affecting the page turning Effect of ViewPager. Therefore, the onInterceptTouchEvent of ViewPager will filter the Move event, when a Move event with the appropriate condition (several events are sustained or several distances are moved, I did not read the source code but guessed it) is triggered, it is intercepted and a sub-View Action_Cancel event is returned. At this time, the sub-View will have no Up event, and many things that need to be processed in the Up will be processed in Cancel.