The requestdisallowintercepttouchevent of the Android event processing mechanism

Ext.: http://blog.csdn.net/chaihuasong/article/details/17499799

When the finger touches the screen, the system invokes the ontouchevent of the corresponding view and passes in a series of action. When there are multiple levels of view, the action is passed down until the deepest view is encountered, as allowed by the parent level. So the touch event is the first to call the ontoucheent of the bottom view, and if the view's ontouchevent receives a touch action and handles it accordingly, there are two return returns of True and return False , return true tells the system that the current view needs to handle this touch event, and the subsequent system's action_move,action_up still needs to be monitored and received, and this ACTION has been disposed of. The view of the parent layer is impossible to set off ontouchevent. So each action can have a maximum of one ontouchevent interface to return true. If return is false, the system is notified that the current view does not care about this one touch event, at which point the action is passed to the parent, calling the ontouchevent of the parent view. But after this one touch event, the view is no longer accepted, and ontouchevent is never triggered in this one touch event, that is, once the view returns False, then the Action_move, Action_up and so on will not be in the view, but the next touch event will be passed in.(I think this short words do not need reference, a simple reading can be looked down.) I think the original author of the article is not accurate here, the following content is not a problem. 2015-1-31)
The front says that the underlying view can receive this event with a precondition: at the parent level. Assuming that the parent-level dispatch method is not changed, the parent view's Onintercepttouchevent method is called before the system calls the underlying ontouchevent, and the parent view is not going to intercept the action after the touch event. If Onintercepttouchevent returns True, then all actions after this touch event will no longer pass to the deep view, and all will pass to the ontouchevent of the negative layer view. That is, the parent has intercepted the touch event, and then the action does not have to ask Onintercepttouchevent, Onintercepttouchevent will not be called again after the action issued after this touch event. Know that the next touch event is coming. If Onintercepttouchevent returns false, the action will be sent to a deeper view, And then each action will ask the parent onintercepttouchevent need not intercept this touch event. Only the ViewGroup has the Onintercepttouchevent method, because a normal view is definitely located in the deepest View,touch event can be reached here is the last stop, will definitely call the view of the ontouchevent.
for the underlying view, there is a way to block the view intercept touch event of the parent layer, which is to call GetParent (). Requestdisallowintercepttouchevent (True); Once the underlying view receives the touch action and calls this method, the parent view will no longer invoke onintercepttouchevent, nor can it intercept the subsequent action.
Use an example to summarize the sequence of calls for Onintercepttouchevent and ontouchevent:
Suppose the top view is called outerlayout, the middle layer view is called innerlayout, the bottom view is called MyView. The invocation order is this (assuming that each function returns false)
Outerlayout.onintercepttouchevent->innerlayout.onintercepttouchevent->myview.ontouchevent-> Innerlayout.ontouchevent->outerlayout.ontouchevent.

@Override        Public Boolean dispatchtouchevent (motionevent ev) {         getParent (). Requestdisallowintercepttouchevent (true );         return Super . dispatchtouchevent (EV);      }

This sentence is to tell the parent view that my event is handled by myself

 Public BooleanOnTouch (View V, motionevent event) {Switch(Event.getaction ()) { CaseMotionEvent.ACTION_MOVE:pager.requestDisallowInterceptTouchEvent (true);  Break;  Casemotionevent.action_up: CaseMotionEvent.ACTION_CANCEL:pager.requestDisallowInterceptTouchEvent (false);  Break; }}

Can also be written similar to the above, when the user presses, we tell the parent component, do not intercept my events (this time the child components can be normal response to events), picked up will tell the parent component can block.

There is also an incident response problem for child controls and parent controls
When there are child controls in the parent control, and both the parent control and the child space have event handling (such as a click event). At this point, clicking on the child control will invalidate the Click event of the parent control.

For example, a linearlayout has a child control TextView, but the size of TextView is not linearlayout large

① if both LinearLayout and TextView have a click event set, then

• When you click on the TextView area, the TextView event is triggered.

• When you click outside the TextView, the LinearLayout event is triggered.

② if LinearLayout set a click event and TextView does not set the Click event, then

• The LinearLayout Click event that is triggered, regardless of whether you clicked the TextView area or the area other than TextView

If the size of the linearlayout is the same as the TextView, then

① if both LinearLayout and TextView have a click event set, then

• Only TextView Click events are valid

② if LinearLayout set a click event and TextView does not set the Click event, then

Triggered by a LinearLayout click event

The requestdisallowintercepttouchevent of the Android event processing mechanism