Lets assume I've a ViewGroup that handles a vertical scroll event. I already implemented the logic within onInterceptTouchEvent which will return true when the desired gesture is identified.
Lets say this gesture is a "Scroll down". When onInterceptTouchEvent returns true (scroll down is started) all subsequent touch events are going to be sent to my ViewGroup (correct :))
The problem is that as soon as the user scrolls up again (within the same gesture) i want to cancel myself as touch handler target and pass the events to my child view instead.
What should I use? calling dispatchTouchEvent within myViewGroup.onTouch as soon as i find the user started to "move up" ?
One way to stop handling a gesture previously "intercepted" through onInterceptTouchEvent->true is to call dispatchTouchEvent within your onTouch method.
You'll need to forge your own MotionEvent (ACTION_CANCEL).
I have a View which will sometimes be occluded by a PopupWindow whose showing is triggered by touching the View. When this happens, I'd like to immediately transfer the stream of touch events to the PopupWindow. I can't just overlay a View in the same hierarchy because this happens in an IME covering a fraction of the screen area I need to capture gestures in.
I've tried sending an ACTION_CANCEL the the View's root container and dispatching my own ACTION_DOWN MotionEvent to the Popwindow. I've also tried overriding the bottom Window's root dispatchTouchEvent and dispatchGenericPointerEvent methods to do nothing and return false when the popup is active. Neither of these approaches worked.
If I simply lift my finger after the PopupWindow appears and put it down again, obviously I receive touch events no problem. I need to understand what happens when I do this that makes my original window relinquish touch focus and reset its dispatch state. Calling requestFocusFromTouch on my PopupWindow's content view when it appears and before I lift my finger returns false.
I'm quite happy to subclass and override where necessary, as I have full control over all the components involved.
I have two scrollviews side by side, I want the user to be able to drag list items back and forth from left to right scrollviews. However, I can't find a way to handle the touch events. I can't set a touch listener for each scrollview seperately as the drag gesture gets dropped when passing from one to another. I tried creating an absolute layout over the top of both, which works from the drag and drop perspective, but it stops me from being able to scroll the scrollviews. Is there a simple solution to this? can anyone help me out?
Generally, onTouchListener returns a boolean that indicates whether the touch has been handled. It's up to you to decide whether the touch was handled or not. When the user touches a View, Android will call it's touch listener. If the touch listener returns true, then it regards the touch as handled then moves on. If the touch listener returns false, then it will go up one to the parent view (in this case whatever your ScrollView is). Then the parent view's touch listener is called and must decide how to handle the touch. It will keep cascading up the parent views until a true is returned or until it reaches the end.
In your case, you may have to decide what the user has to do in order to drag & drop vs. scrolling. Perhaps the user must do a long press on an item before he/she can drag it or something.
I'm not asking how to handle touch events, but what is going on behind the scenes? If there are several nested widgets, what order do they see the events in? Does the developer have any control over it? Ideally I would like a document on the subject.
Let's take a look at a visual example.
When a touch event occurs, first everyone is notified of the event, starting at the Activity and going all the way to the view on top. Then everyone is given a chance to handle the event, starting with the view on top (view having highest Z order in the touch region) and going all the way back to the Activity. So the Activity is the first to hear of it and the last to be given a chance to handle it.
If some ViewGroup wants to handle the touch event right away (and not give anyone else down the line a chance at it) then it can just return true in its onInterceptTouchEvent(). An Activity doesn't have onInterceptTouchEvent() but you can override dispatchTouchEvent() to do the same thing.
If a View (or a ViewGroup) has an OnTouchListener, then the touch event is handled by OnTouchListener.onTouch(). Otherwise it is handled by onTouchEvent(). If onTouchEvent() returns true for any touch event, then the handling stops there. No one else down the line gets a chance at it.
More detailed explanation
The above diagram makes things a little more simple than they actually are. For example, between the Activity and ViewGroup A (the root layout) there is also the Window and the DecorView. I left them out above because we generally don't have to interact with them. However, I will include them below. The description below follows a touch event through the source code. You can click a link to see the actual source code.
(Update: the source code has been updated so the line numbers are off now, but clicking the links will still get you to the right file. Just do a search for the method name.)
The Activity's dispatchTouchEvent() is notified of a touch event. The touch event is passed in as a MotionEvent, which contains the x,y coordinates, time, type of event, and other information.
The touch event is sent to the Window's superDispatchTouchEvent(). Window is an abstract class. The actual implementation is PhoneWindow.
The next in line to get the notification is DecorView's superDispatchTouchEvent(). DecorView is what handles the status bar, navigation bar, content area, etc. It is actually just a FrameLayout subclass, which is itself a subclass of ViewGroup.
The next one to get the notification (correct me if I'm wrong) is the content view of your activity. That is what you set as the root layout of your activity in xml when you create the layout in the Android Studio's Layout Editor. So whether you choose a RelativeLayout, a LinearLayout, or a ConstraintLayout, they are all subclasses of ViewGroup. And ViewGroup gets notified of the touch event in dispatchTouchEvent(). This is the ViewGroup A in my diagrams above.
The ViewGroup will notify any children it has of the touch event, including any ViewGroup children. This is ViewGroup B in my diagrams above.
Anywhere along the way, a ViewGroup can short-circuit the notification process by returning true for onInterceptTouchEvent().
Assuming no ViewGroup cut the notifications short, the natural end of the line for the notifications is when the View's dispatchTouchEvent() get's called.
Now it is time, to start handling the events. If there is an OnTouchListener, then it gets the first chance at handling the touch event with onTouch(). Otherwise, the View's onTouchEvent() gets to handle it.
Now all the ViewGroups recursively up the line get a chance to handle the touch event in the same way that View did. Although, I didn't indicate this in the diagram above, a ViewGroup is a View subclass, so everything I described about OnTouchListener.onTouch() and onTouchEvent() also applies to ViewGroups.
Finally, if no one else wanted it, the Activity also gets the last chance to handle the event with onTouchEvent().
FAQ
When would I ever need to override dispatchTouchEvent()?
Override it in the Activity if you want to catch a touch event before any of the views get a chance at it. For a ViewGroup (including the root view), then just override onInterceptTouchEvent() and onTouchEvent().
When would I ever need to override onInterceptTouchEvent()?
If you just want to spy of the touch notifications that are coming in, you can do it here and return false.
However, the main purpose of overriding this method is to let the ViewGroup handle a certain type of touch event while letting the child handle another type. For example, a ScrollView does this to handle scrolling while letting its child handle something like a Button click. Conversely, if the child view doesn't want to let its parent steal its touch event, it can call requestDisallowTouchIntercept().
What are the touch event types?
The main ones are
ACTION_DOWN - This is the start of a touch event. You should always return true for the ACTION_DOWN event in onTouchEvent if you want to handle a touch event. Otherwise, you won't get any more events delivered to you.
ACTION_MOVE - This event is continuously fired as you move your finger across the screen.
ACTION_UP - This is the last event of a touch event.
A runner up is ACTION_CANCEL. This gets called if a ViewGroup up the tree decides to intercept the touch event.
You can view the other kinds of MotionEvents here. Since Android is multi-touch, events are also fired when other fingers ("pointers") touch the screen.
Further study
Android onTouchEvent Part 1, Part 2, and Part 3 (YouTube video - good summary of some of the links below)
Mastering the Android Touch System (thorough video by Google developer)
Android UI Internal : Pipeline of View's Touch Event Handling
Managing Touch Events in a ViewGroup (Android docs)
Input Events (Android docs)
Gestures and Touch Events
From Activity viewpoint:
Touch events are delivered first to Activity.dispatchTouchEvent. It's where you may catch them first.
Here they get dispatched to Window, where they traverse View hierarchy, in such order that Widgets that are drawn last (on top of other widgets) have chance to process touch in View.onTouchEvent first. If some View returns true in onTouchEvent, then traversal stops and other Views don't receive touch event.
Finally, if no View consumes touch, it's delivered to Activity.onTouchEvent.
That's all your control. And it's logical that what you see drawn on top of something else, has chance to process touch event before something drawn below it.
Android Touch event
I have prepared a high level diagram that should illustrate a simple flow.
dispatchTouchEvent() - Activity, ViewGroup, View
onInterceptTouchEvent() - ViewGroup
onTouch() - ViewGroup, View. Using setOnTouchListener()
onTouchEvent() - Activity, ViewGroup, View
[iOS onTouch]
following Suragch's answer,
pseudocode:
public boolean dispatchTouchEvent(MotionEvent ev) {
boolean consume = false;
if (onInterceptTouchEvent(ev) {
consume = onTouchEvent(ev);
} else {
consume = child.dispatchTouchEvent(ev);
}
return consume;
}
ref:Android开发艺术探索
We are developing an application where we need to capture MotionEvents from multiple views simultaneously. When we try to do so, Android only dispatches events to the first touched view and, when touching another view simultaneously, it gives us an ACTION_POINTER_DOWN on the first view only, even if the pointer coordinates are outside its bounds and inside the other views'.
Is there any way we can get events dispatched to every touched view (in separate calls to OnTouch)?
We believe intercepting the touch events from a parent view and then manually dispatching them to each view might work, but even if it does, it would not be practical for what we are trying to achieve. Is there an easier way?
At least Android 3.0 adds support for splitting touch events between multiple Views.
Split touch events is enabled by default when AndroidManifest <uses-sdk> defines either android:minSdkVersion="11" or android:targetSdkVersion="11". For explanation See android:splitMotionEvents and android:windowEnableSplitTouch
Touch event is first catched by the view currently in focus. If you touched 1 view and have "consumed" event and are working with it, any other events will be dispatched to this view, no matter where you click.
If you return false from your touchListener (thus saying that event is not consumed) it will be delegated down to other views, but on another separate click new event will be dispatched to other view.
http://www.zdnet.com/blog/burnette/how-to-use-multi-touch-in-android-2-part-3-understanding-touch-events/1775
http://developer.android.com/guide/topics/ui/ui-events.html
While this should work automatically with Android SDK 11+, it wasn't working for my app. I was trying to capture touches in a main view, plus some views that were subviews of the main view; in that case, touches were only captured by the view "level" that received the first touch. I reorganized my view structure so that all the views were siblings and now they are capturing events as expected.