Menu
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.
616
Setup a touch listener In order to make your OpenGL ES application respond to touch events, you must implement the onTouchEvent() method in your GLSurfaceView class. The example implementation below shows how to listen for MotionEvent. ACTION_MOVE events and translate them to an angle of rotation for a shape.
Add the touch point handlers to the specific target element (rather than the entire document or nodes higher up in the document tree). Add touchmove , touchend and touchcancel event handlers within the touchstart . The target touch element or node should be large enough to accommodate a finger touch.
float y = event. getY(pointerIndex); ... To support multiple touch pointers, you can cache all active pointers with their IDs at their individual ACTION_POINTER_DOWN and ACTION_DOWN event time; remove the pointers from your cache at their ACTION_POINTER_UP and ACTION_UP events.
Touch Event PropagationThe DOWN touch event is passed to "View C" onTouchEvent and the boolean result of TRUE or FALSE determines if the action is captured. Because "View C" returns true and is handling the gesture, the event is not passed to "ViewGroup B"'s nor "ViewGroup A"'s onTouchEvent methods.
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.
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.)
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.superDispatchTouchEvent(). Window is an abstract class. The actual implementation is PhoneWindow.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.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.ViewGroup will notify any children it has of the touch event, including any ViewGroup children. This is ViewGroup B in my diagrams above.ViewGroup can short-circuit the notification process by returning true for onInterceptTouchEvent().ViewGroup cut the notifications short, the natural end of the line for the notifications is when the View's dispatchTouchEvent() get's called.OnTouchListener, then it gets the first chance at handling the touch event with onTouch(). Otherwise, the View's onTouchEvent() gets to handle it.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.onTouchEvent().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.
93
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
