Ontouch event Transfer Process of Android View

Http://blog.csdn.net/starfeng11/article/details/7009338

 

Events triggered by touch. Android events: onclick, onscroll, onfling, and so on are composed of many touch events. The first status of touch must be action_down, indicating that the screen is pressed. Later, touch will have a follow-up event, which may be: action_move // indicates action_up as a mobile gesture.

Events triggered by touch.

Android events: onclick, onscroll, onfling, and so on are composed of many touch events. The first status of touch must be action_down, indicating that the screen is pressed. Later, touch will have a follow-up event, which may be:

Action_move // indicates a mobile gesture.

Action_up // indicates leaving the screen

Action_cancel // indicates that the canceling gesture is not generated by the user, but by the program.

One action_down, N action_move, and one action_up constitute many events in Android.
In Android, a type of control can also contain other child controls, which inherit from the viewgroup class, such as listview, gallery, and gridview.

Another type of controls cannot contain child controls, such as textview.

This article mainly discusses the trigger of nested event items of viewgroup controls.

An important method for viewgroup controls is onintercepttouchevent (), which is used to process events and change the transfer direction of events. Its return value is a Boolean value, determines whether the touch event needs to be passed to the Child view it contains. This method is to pass from the parent View to the Child view.

The ontouchevent () method is used to receive and process events. Its return value is also a Boolean value, which determines whether the event and subsequent events continue to pass up, this method is passed from the Child View to the parent view.

The transfer mechanism between onintercepttouchevent () and ontouchevent and each childview depends entirely on the return values of onintercepttouchevent () and ontouchevent. If the returned value is true, the event is correctly received and processed. If the returned value is false, the event is not processed and will continue to be passed (only when the transfer direction is different, onintercepttouchevent () is passed to the subview, while ontouchevent () is passed to the parent view ).

The details are as follows:

The action_down event is uploaded to the onintercepttouchevent of a viewgroup class. If false is returned, the down Event continues to be passed to the onintercepttouchevent of the child viewgroup class. If the child view is not a control of the viewgroup class, the ontouchevent passed to the sub-view.

If onintercepttouchevent returns true, the down event is passed to the ontouchevent of the viewgroup, and the subsequent events are also passed to the ontouchevent.

If the ontouchevent of a view returns false, the down Event continues to be passed to the ontouchevent of its parent viewgroup class. If true is returned, subsequent events will be directly passed to its ontouchevent for further processing. (Subsequent events will only be passed to ontouchevent that returns true for the required event action_down)

/////''''''''''''''''''''''''''''''''''' ''''''''''''''''''''''''''''''

In the past, Android was written, and the processing of events was not too deep, but the simple ontouchevent was OK. Now, the UI, many custom components, the parent view and the Child view both need to receive events, then process. If you do not understand its event transfer mechanism, it is difficult to have a good user experience.

In touchevent, if the returned value is true, the event is consumed. If the returned value is false, the event is not consumed and will be passed on. This is the most basic principle.

There are three types of touch-related events in view: dispatchtouchevent, intercepttouchevnet, and ontouchevent. Dispatchtouchevent is responsible for distributing events. After an event is passed out of the activity, the first event that arrives at the top-level view is the dispatchtouchevent, which is then distributed. If false is returned, the intercepttouchevent method assigned to the view determines whether to intercept this event. If intercepttouchevent returns true, that is, it is intercepted, it is handed over to its ontouchevent for processing. If intercepttouchevent returns false, then it is passed to the sub-view, and the dispatchtouchevent of the sub-view will start distributing the event.

If the event is passed to the ontouchevent of the subview of a certain layer, the method returns false, and the event will be passed up from this view, which is received by ontouchevent. If false is returned when the ontouchevent is passed to the top, the event will disappear and the next event will not be received. (An event refers to a series of events from down to up)

I drew a picture, see the attachment.

To sum up, if this event is not consumed by anyone, the system will not give you the next event, because he will think that this event is blocked and there is no need to give it to the next one. If ontouchevent is not consumed, it will be passed from the Child View to the parent view.

 

 

Another example:

 

Requirement: Create an interface to switch completely through the flip gesture. Use viewflipper as the container at the top layer and detect flip gestures.

Difficulty: The motionevent required for the flip gesture detection of viewflipper will be intercepted by the touch detection of each seed view. For example, if there is a button on the interface, when the finger presses the button (not lifted) and then flip generates the button, the top-level flip gesture detection is invalid.

Cause: the distribution logic of the android touch event is that the view is distributed from the upper layer to the lower layer (dispatchtouchevent function), and the lower layer first processes the event (montouchlistener and then ontouchevent) and return the processing status (Boolean value) up. If true is returned, the upper layer will not process it.

So we first thought that to ensure the flip gesture detection, we need to upload all the touch events to the upper layer.

However, there is another logic in addition to the Distribution logic. Android estimates that each trigger operation can only be completely responded by one view, and there is an additional logic for the action_down event: if a view returns false when processing the action_down event (that is, the view does not process this event ), this view will be directly ignored for other events subsequently generated (but longpress has another independent logic ). For example, if you return false when processing action_down, you will not be able to get action_move or action_down for this view.

The problem arises. If you want to upload all touch events to the upper layer (only false can be returned to the upper layer), then the lower layer view cannot process subsequent events.

Solution:

At first, I only focused on the callback process after touch event processing and thought about it for a long time. After all, what I want to achieve is an effect that needs to break the Android event processing logic (that is, a continuous operation, only when the upper-layer requirement is not met can the lower-layer processing be performed ). Then I suddenly thought of the event distribution process, and then I was suddenly enlightened:

Overwrite the dispatchtouchevent function of the top view. The Code is as follows:

@ Override
Public Boolean dispatchtouchevent (motionevent event ){

If (_ flipdetector. ontouchevent (event )){
Event. setaction (motionevent. action_cancel );
}

Return super. dispatchtouchevent (event );
}

So the effect is achieved. That is, gesture detection is performed before distribution. If the detection is successful, all lower-layer processing is canceled.

To sum up, onintercepttouchevent can accept all touch events, while ontouchevent is not necessarily.