Explain touch event dispatch in a ViewGroup with a clickable child

It tests touch routing through the three key methods. A strong answer traces ACTION_DOWN from root to target, notes intercepting halts child delivery, and onTouchEvent true consumes while false bubbles up.
What's really being asked
This question probes whether you understand the contract between dispatchTouchEvent, onInterceptTouchEvent, and onTouchEvent inside Android's view hierarchy. Interviewers care if you can predict event flow when a parent ViewGroup contains a clickable child View, because mishandling this breaks gestures, scrolling, and nested interactions.
The full answer
First, the entry point is dispatchTouchEvent on the root view, which traverses down the hierarchy. Second, a ViewGroup gets a chance to observe or steal the event in onInterceptTouchEvent before the child sees it. Third, if the parent does not intercept, the event reaches the child's dispatchTouchEvent and then its onTouchEvent. Fourth, if the child returns true from onTouchEvent, it claims the event stream for the remainder of the gesture, meaning subsequent ACTION_MOVE and ACTION_UP events flow to the child unless the parent intercepts mid gesture. Fifth, if the child returns false, the event bubbles back up to the parent's onTouchEvent. Sixth, returning true from onInterceptTouchEvent during ACTION_DOWN prevents the child from ever receiving that gesture, while intercepting later during ACTION_MOVE sends ACTION_CANCEL to the child and redirects future events to the parent's onTouchEvent.
The mistakes people make
A red flag is claiming that onInterceptTouchEvent exists on View instead of ViewGroup. Another mistake is saying the parent always receives onTouchEvent before the child, when actually the child gets the first shot if the parent does not intercept. Some candidates also forget that intercepting after ACTION_DOWN sends ACTION_CANCEL to the child, which leads to broken touch states in custom views.
Likely follow ups
The interviewer may ask how nested scrolling changes this flow, or how requestDisallowInterceptTouchEvent allows a child to prevent its parent from intercepting. They might also ask you to debug a scenario where a ListView inside a ScrollView fights over vertical swipes, or how to implement a custom ViewGroup that only intercepts horizontal drags while letting vertical taps pass to a child button.
A concrete example
Imagine a FrameGroup containing a Button. When the user presses the button, the FrameGroup's dispatchTouchEvent receives ACTION_DOWN. The FrameGroup's onInterceptTouchEvent runs and returns false, so the event travels to the Button. The Button's onTouchEvent returns true because it is clickable, consuming the ACTION_DOWN. The framework now marks the Button as the target for this pointer. On ACTION_UP, the event again enters through the FrameGroup's dispatchTouchEvent, skips onInterceptTouchEvent unless the parent explicitly requests it, and reaches the Button's onTouchEvent to fire the click. If the FrameGroup instead returned true from onInterceptTouchEvent during ACTION_MOVE, the Button would receive ACTION_CANCEL, and all remaining events would go to the FrameGroup's onTouchEvent.
Interview question
What happens when a ViewGroup returns true from onInterceptTouchEvent during ACTION_MOVE while a child is handling the gesture?
- a.The child continues receiving events until ACTION_UP, then the ViewGroup takes over
- b.The ViewGroup's onTouchEvent receives the current ACTION_MOVE and the child is not notified
- c.The child receives ACTION_UP immediately and the ViewGroup handles the next gesture
- d.The child receives ACTION_CANCEL and all remaining events are delivered to the ViewGroup's onTouchEventCorrect
Why? this is the answer
When a ViewGroup intercepts during ACTION_MOVE, the framework sends ACTION_CANCEL to the child that previously handled ACTION_DOWN and redirects all subsequent events for that gesture to the parent's onTouchEvent. Option A is tempting because many assume interception only affects future gestures, but it immediately disrupts the current one.
Just read this? Test yourself on what you have been reading.
Read the original → developer.android.com
- #android
- #viewgroup
- #touchevents
- #dispatch
- #interview
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on android — each one lists the topics its interview covers.
See open roles