Indicates whether the event is blocked and returns false to Not intercept @overridepublic boolean onintercepttouchevent (Motionevent arg0) {return false;} /** * Rewrite Ontouchevent event, nothing to do */@Overridepublic boolean ontouchevent (Motionevent arg0) {return false;}
/** * Event distribution, request parent control and ancestor control to intercept event */@Overridepublic Boolean dispatchtouchevent (motionevent ev) {if (Getcurrentitem ()! = 0) {get Parent (). Requestdisallowintercepttouchevent (true);//use GetParent to request,//do not intercept} else {//If it is the first page, you need to display the sidebar, Requests that the parent control intercept GetParent (). Requestdisallowintercepttouchevent (false);//Intercept}return super.dispatchtouchevent (EV);}
Opening language: The recent program in a small effect, to use the touch, the results of the cloud inside the fog, and simply a good look at the Android touch mechanism, hehe.
Each ViewGroup subclass in the Android system has the following methods that are closely related to the next three and touchevent processing:
1) Public boolean dispatchtouchevent (motionevent ev) This method is used to distribute TouchEvent
2) Public boolean onintercepttouchevent (motionevent ev) This method is used to intercept touchevent
3) Public boolean ontouchevent (motionevent ev) This method is used to process touchevent
Note: Not all of the view's subclasses, many of the tutorials are talking about all of the view's subclasses, only the control that can add view to it needs to be distributed, such as TextView itself is the smallest view, so no longer to its sub-view distribution, it also has no sub-view, So it has no dispatch and intercept, only touchevent.
Description: White is the outermost layer and it fills the entire screen;
Red is the middle area, which belongs to a layer of white;
Black is the central area and must be a layer in the red.
Note: They are essentially: linearlayout, not relativelayout or other layouts.
1. Handle touch events from the central area
The layout file is as follows:
- <?xml version= "1.0" encoding= "Utf-8"?>
- <linearlayout xmlns:android= "Http://schemas.android.com/apk/res/android"
- Android:layout_width= "Fill_parent"
- android:layout_height= "Fill_parent"
- android:orientation= "Vertical" >
- <com.kris.touch.widget.touchview
- Android:id= "@+id/view_out"
- Android:layout_width= "Fill_parent"
- android:layout_height= "Fill_parent"
- Android:background= "#fff"
- android:gravity= "Center" >
- <com.kris.touch.widget.touchview
- Android:id= "@+id/view_mid"
- Android:layout_width= "300px"
- android:layout_height= "400px"
- Android:background= "#f00"
- android:gravity= "Center" >
- <com.kris.touch.widget.touchview
- Android:id= "@+id/view_center"
- Android:layout_width= "150px"
- android:layout_height= "150px"
- Android:background= "#000"
- android:gravity= "Center"
- Android:clickable= "true" >
- </com.kris.touch.widget.TouchView>
- </com.kris.touch.widget.TouchView>
- </com.kris.touch.widget.TouchView>
- </LinearLayout>
Copy Code
Note: android:clickable= "true"
Next we look at the printed log:
The combination is the above log, we can look at the Action_down event processing flow:
Description
First touch event occurs (Action_down), the event is distributed by the system calling the activity's Dispatchtouchevent method. This event is passed to the out Dispatchtouchevent processing based on the coordinates of the touch event, and out calls Onintercepttouchevent to determine whether the event is handled by itself or continues to be distributed to the child view. Because out does not handle the touch event, the event is passed to the immediate child view of the out (that is, middle), based on the event's coordinates.
Middle and center in the event processing process ibid. But because the center component is clickable that it can handle touch events, the Onintercepttouchevent method in the center passes events to the center's own ontouchevent method processing. At this point, this touch event has been processed without continuing delivery.
2. Do not specify who will handle the touch event
The layout file is as follows:
- <?xml version= "1.0" encoding= "Utf-8"?>
- <linearlayout xmlns:android= "Http://schemas.android.com/apk/res/android"
- Android:layout_width= "Fill_parent"
- android:layout_height= "Fill_parent"
- android:orientation= "Vertical" >
- <com.kris.touch.widget.touchview
- Android:id= "@+id/view_out"
- Android:layout_width= "Fill_parent"
- android:layout_height= "Fill_parent"
- Android:background= "#fff"
- android:gravity= "Center" >
- <com.kris.touch.widget.touchview
- Android:id= "@+id/view_mid"
- Android:layout_width= "300px"
- android:layout_height= "400px"
- Android:background= "#f00"
- android:gravity= "Center" >
- <com.kris.touch.widget.touchview
- Android:id= "@+id/view_center"
- Android:layout_width= "150px"
- android:layout_height= "150px"
- Android:background= "#000"
- android:gravity= "Center" >
- </com.kris.touch.widget.TouchView>
- </com.kris.touch.widget.TouchView>
- </com.kris.touch.widget.TouchView>
- </LinearLayout>
Copy Code
Note: Just less than the last layout android:clickable= "true"
Next we'll look at the printed log
The combination is the above log, we can look at the Action_down event processing flow:
Description
The event processing flow is roughly the same as the difference is that in this state, all components do not handle the event, and the event is not "consumed" by the center's Ontouchevent method, the event is passed back to the activity at a layer level, and if the activity does not handle this event, This event is equivalent to disappearing (no effect).
For subsequent move, up events, the up event is handled by the activity's dispatchtouchevent directly to its own Ontouchevent method because the first down event has been determined by the activity to handle the event.
Please see the final attachment for the code.
Summarize:
1) TouchEvent, the return value is true, it means that the event is consumed, the return value is false, it is not consumed, will continue to pass, this is the most basic. 2) Two ways of event delivery:
Tunnel mode: Passes from the root element down to the most inner child element or in an intermediate element because a condition stops passing.
Bubbling: passes outward from the most inner child element to the root element or to an element in the middle because a condition stops passing. Android's distribution logic for touch event is that the view is distributed from the upper layer to the lower layer (dispatchtouchevent function) similar to tunneling, then the lower level first begins processing the event (first Montouchlistener, Ontouchevent) and returns the processing status (Boolean value), if true, the upper layer is no longer processed. Similar to bubbling mode
So the problem arises, if you try to reach the top of the touch event (only by returning false to the upper layer), then the various sub-view below will not be able to handle the subsequent events. And sometimes we need to handle touch events on the lower and upper levels.
For example, Viewflipper used to detect gestures, in the interior we put a few images, a bit like the gallery effect, that is, the left and right slide to switch the picture, but sometimes we hope that the image can be enlarged zoom out! There is a need for a touch event in the Viewflipper, and a touch event in the image (you can drag the picture when the picture is the size of the screen, rather than toggling the picture around).
My first idea is to start the event back to the way, study n long, the actual n long, have not reached their desired results, I even to the source of gallery and Gallery3d download down to see n long also no way to solve, here casually say gallery it, Gallery Although in this effect, but people are not viewflipper plus image to achieve, people are like the game with a view to unify processing, we can simply understand the custom of a control, so that the touch event want to deal with how to deal with, But the logic is complex, we want to lazy there is no way, hehe ...
Finally try and try Ah, think of a workable plan, but I think it is not very reliable, that is: we viewflipper here, we first cut all the touch, and then in his ontouchevent, We first call ImageView's Ontouchevent event, if it returns true to prove the event, ImageView to use, then viewflipper when nothing happens, if ImageView returns False, Call your own touchevent. The pseudocode is as follows:
- Customizing a myviewflipper inherits from Viewflipper, and implements Ontouchevent mode,
Copy Code
I think the reason why he is not reliable is: 1. He interrupted Android's original mechanism, not very advocating.
2. You must first know the control inside the Viewflipper, or you can get it through some kind of path.
3. If there is more control in the Viewflipper, the egg hurts.
Well, if you have any comments or suggestions, we will discuss them together.
Android Touch Event Delivery mechanism parsing