Introduction

dispatchTouchEvent and onInterceptTouchEvent are related, but they do different jobs in Android's touch pipeline. dispatchTouchEvent is the routing method that decides where an event goes next, while onInterceptTouchEvent is a parent ViewGroup hook that can stop a child from receiving that event stream.

The Basic Event Flow

When a touch event enters a view hierarchy, Android delivers it through a sequence like this:

1. parent dispatchTouchEvent
2. parent onInterceptTouchEvent if the parent is a ViewGroup
3. child dispatchTouchEvent
4. child onTouchEvent

That means dispatchTouchEvent is the broad event dispatcher, and interception is just one decision inside the ViewGroup branch of that process.

What dispatchTouchEvent Does

Every View has dispatchTouchEvent. Its responsibility is to deliver the event to the appropriate next handler.

• for a plain View, that usually means deciding whether to call onTouchEvent
• for a ViewGroup, that may mean forwarding the event to a child
• it returns true if the event was consumed somewhere downstream

A simple custom view example looks like this:

1@Override
2public boolean dispatchTouchEvent(MotionEvent ev) {
3    Log.d("Touch", "dispatchTouchEvent: " + ev.getAction());
4    return super.dispatchTouchEvent(ev);
5}

You usually override dispatchTouchEvent only when you need to observe or alter routing behavior explicitly.

What onInterceptTouchEvent Does

Only ViewGroup has onInterceptTouchEvent. It gives the parent a chance to take control before a child handles the event sequence.

If it returns:

• 'false, the event can continue to the child'
• 'true, the parent intercepts and the child stops receiving subsequent events in that gesture stream'

This is how scrolling containers decide whether a drag should belong to the container or to one of its children.

1@Override
2public boolean onInterceptTouchEvent(MotionEvent ev) {
3    switch (ev.getActionMasked()) {
4        case MotionEvent.ACTION_DOWN:
5            return false;
6        case MotionEvent.ACTION_MOVE:
7            return shouldStartDragging(ev);
8        default:
9            return false;
10    }
11}

That is the classic pattern for a parent that allows taps through but takes over when the gesture becomes a drag.

A Practical Example

Imagine a horizontal pager that contains clickable child views. On the initial ACTION_DOWN, the pager should usually not intercept because it does not yet know whether the user intends a tap or a swipe.

Once the finger moves far enough horizontally, the parent can intercept and handle the rest of the gesture itself.

That design would be implemented with onInterceptTouchEvent, not by rewriting the whole dispatch system.

When To Override Which Method

Override onInterceptTouchEvent when the question is:

"Should this parent steal the gesture from its child?"

Override dispatchTouchEvent when the question is:

"Do I need to observe or customize the routing process itself?"

In ordinary application code, interception is much more common than custom dispatch.

Relationship To onTouchEvent

Neither method is the final event consumer by default. Actual handling often ends in onTouchEvent.

A parent that intercepts touches usually handles them in its own onTouchEvent. A child that receives touches normally responds in the child's onTouchEvent.

That distinction matters because developers often log interception and assume interception itself performs the gesture logic. It does not. It only decides who gets the gesture.

Common Pitfalls

A common mistake is overriding dispatchTouchEvent when onInterceptTouchEvent is the correct tool. That usually makes the code harder to reason about because you are rewriting routing logic instead of making an interception decision.

Another issue is returning true from onInterceptTouchEvent too early, such as on ACTION_DOWN, which prevents child clicks from working.

Developers also sometimes forget that touch handling is a gesture stream, not a set of unrelated events. Once a parent starts intercepting, the child may stop seeing the rest of that sequence.

Finally, do not confuse logging with control flow. Seeing dispatchTouchEvent in the logs does not mean the current view consumed the event. It only means the event passed through that method.

Summary

• 'dispatchTouchEvent routes touch events through the view hierarchy.'
• 'onInterceptTouchEvent lets a ViewGroup decide whether to take a gesture away from its child.'
• Use interception when a parent may need to claim drag or scroll behavior.
• Use custom dispatch only when you truly need to alter or observe routing logic.
• Actual event handling usually happens in onTouchEvent, not in the interception decision itself.