Skip to main content

Android UI Internal : Pipeline of View's Touch Event Handling

This article aims to give you a big picture regarding how the touch event is handled in Android.  Simply speaking , we are trying to answer the question: when I press a button in an app , how the touch event is dispatched to that button and how can I handle it? 

A picture is worth a thousand words. Therefore,  I come up with the one below. The left diagram is what we see as a normal user ; the right one illustrates how the views are organized as a tree ; the bottom one describes the pipeline of event dispatching and handling, from Input module down to the individual focused view.

view hierarchy and touch event handling pipeline
I wish the diagram is self explaining, and I'd stress a few key points:

1. DecroView is created by the framework for each Activity and it contains the status bar , navigation bar and your content view. It is the root view that added to the WindowManager.

2. The touch event is dispatched from top to bottom but handled from bottom to top. The event is dispatched by calling dispatchTouchEvent and handled by onTouchEvent. 

3. Child view take precedence over parent view in handling event. Only if the child view does not consume the event, parent view can have a chance to handle it. In diagram above , if steps 6 return false, contenview will call its owner onTouchEvent, that is step 7.  See ViewGroup::dispatchTouchEvent() below.

4. To handle a touch event, you have two ways : either thru Event Listener (setOnTouchListener) or Event Handler (onTouchEvent). Be aware that Event Listener is called before Event Handler, if Event Listener returns true, Event Handle won't be called, so you risk losing other translated events (onClick, onLongClick) handled in the default Event Handler.  see View::dispatchTouchEvent() below.

5. If none of the views in the content view hierarchy handles the touchEvent, Activity::onTouchEvent will have a chance to handle it. see Activity::dispatchTouchEvent() below.

Below are implementation of dispatchTouchEvent in View, Activity and ViewGroup.  Code are pruned for simplicity.

loading code..

To reiterate what we talked, I captured the stacks when the button was touched. From this call stack we can confirm the touch event dispatched from the window -> activity -> viewGroup.dispatchTouchEvent -> view.dispatchTouchEvent ->view.onTouchEvent as we described previously. Then the call stack will wind back.

event handling call stack
In addition to the pipeline we talked above, Android framework also has some optimization in ViewGroup's dispatchTouchEvent in order to deliver the touch event more efficiently. For example , if a DOWN event is deliver to Button 2 , Button 2 will be set as current deliver target, following events until next DOWN will be delivered to Button 2 directly without doing hit test on all his children. Besides, ViewGroup has a chance to intercept the touch events before dispatching them to his children. 

I hope this introduction will make you more confident when dealing with the touch event in Android.
For more information, check out following links: Android Guide UI EventMaster Android Touch SystemAndroid Training Gestures.

Check out other articles in Android UI Internal series 

Popular posts from this blog

Android Camera2 API Explained

Compared with the old camera API, the Camera2 API introduced in the L is a lot more complex: more than ten classes are involved, calls (almost always) are asynchronized, plus lots of capture controls and meta data that you feel confused about.

No worries. Let me help you out. Whenever facing a complex system need a little bit effort to understand, I usually turns to the UML class diagram to capture the big picture.

So, here is the class diagram for Camera2 API.

You are encouraged to read this Android document first and then come back to this article, with your questions. I'll expand what is said there, and list the typical steps of using camera2 API. 

1. Start from CameraManager. We use it to iterate all the cameras that are available in the system, each with a designated cameraId. Using the cameraId, we can get the properties of the specified camera device. Those properties are represented by class CameraCharacteristics. Things like "is it front or back camera", "outpu…

Java Collections Framework Cheat Sheet

Java Collections Framework (JCF) implements the Abstract Data Type  for Java platform. Every serious Java programmer should familiar himself on this topic and be able to choose the right class for specific need.  A thorough introduction to JCF is not the target of this small article and to achieve that goal you can start with this excellent tutorial . 

Instead, I'd like to
1) Provide an overview of JCF's classes ,   2) Provide a cheat sheet you can post in your cubicel for daily reference, 3) Underline the relationship between JCF's implementation and the data structure and algorithm you learned in your undergraduate course

With these goals in mind, I came up following diagram - Java Collection Cheat Sheet. You can click it to zoom in. There is no necessity for more explanation once your familiar with UML class diagram and have a basic understanding of common data structures.

Android Security: An Overview Of Application Sandbox

The Problem: Define a policy to control how various clients can access different resources. A solution: Each resource has an owner and belongs to a group.Each client has an owner but can belongs to multiple groups.Each resource has a mode stating the access permissions allowed for its owner, group members and others, respectively. In the context of operating system, or Linux specifically, the resources can be files, sockets, etc; the clients are actually processes; and we have three access permissions:read, write and execute.