Android touch event monitoring (activity layer, ViewGroup layer, view layer) details

Android touch event monitoring at different levels

In app development, we often encounter operations related to gesture processing, such as sliding right to return to the previous page. As for the handling of touch events, we can roughly handle them at different levels.

Activity layer: it can be regarded as the top layer of touch event acquisition. ViewGroup layer can independently control whether to let sub views acquire touch events. View layer: it can decide whether to really consume touch events. If not, it will be thrown to the upper ViewGroup

Activity level gesture monitoring: (slide right to return to the upper interface)

Usage scenario of gesture monitoring in activity layer: it is generally used when there are not too many gestures to be processed in the current page, and there are click events at most. For the requirement of right sliding back to the upper interface, it can be defined in a baseactivity. If the child activity needs to be implemented, it can be opened through a switch.

matters needing attention:

1. In the activity layer, you can grab all events with dispatch.

2. For sliding, set a distance threshold mdistancegat to mark whether the gesture is valid, and pay attention to the processing of sliding back.

3. If there is a click item at the bottom layer, in order to prevent color change during sliding, the touch event can be shielded in time: manually construct the cancle event and send it actively, which is to be compatible with the most basic click effect. However, the move event should be sent normally before meeting the judgment of click gesture. The specific implementation is as follows:

4. To prevent the backward sliding of the gesture, it is best to use the gesturedecoder to judge. If there is backward sliding, the gesture is invalid. The use method is as follows:

5. How to handle up events: whether the dispatch is sent down. Specifically, the up must be distributed down if the gesture is invalid according to whether the gesture is valid or not. If it is valid, follow the subsequent operations, because sometimes in order to prevent the child view from obtaining unnecessary click events. The specific implementation is as follows

6. It is best to record down in the patch_ X、down_ Y. For later processing and judgment, because you can get the event in the dispatch. At the same time, ensure the distribution of dispatch events,

Second: gesture monitoring at the parent container level

Note: container level listening should at least force the current container to obtain the focus of the gesture. As for how to obtain the focus, you can write your own ontouch event and return true. However, we put the judgment processing in the dispatch, which can ensure the complete acquisition of events. Because, if the underlying consumes events, ontouch cannot get complete events, but we have enough ability to ensure that dispatch gets complete events. Regardless of the ontouch consumption in this layer or the bottom consumption, dispatch is used to avoid omission. For the container of gestures, it is better to use padding instead of magin. Why? Because margin is not inside the container.

1. Usage scenario of parent container listening

2. Realize

There is no interaction event in the child view:

This kind of container can be implemented by dispatch, but it needs to force to obtain the focus and release the focus in time. The specific implementation is as follows: how to ensure that this layer will receive subsequent down events. The down event of the dispatch can return true.

How to ensure that this layer is not accidentally shielded, use getparent(). Requestdisallowintercepttouchevent (true). Of course, forced acquisition should also be released in time. When the gesture is determined to be invalid, it should be released. The specific implementation is as follows:

There are interaction events in the sub view: if there are interaction events in the sub view, it is necessary to use the combination of dispatch and ontouch. In order to judge the effectiveness of gestures, dispatch must start from the container layer and forcibly obtain the focus. It doesn't care how the bottom layer forcibly obtains the focus. If there is no consumption down here, it means that the underlying view is consumed. At the same time, it shall be compatible with invalid gestures to force the release of focus acquisition and prevent uploading and scrolling view. The specific implementation is as follows:

The main purpose of processing response events in ontouch is to prevent the upper layer from processing after the lower layer obtains them

3. The parent container gesture is intercepted. Sometimes, the child view has a click event, and the click changes color. After a certain fault-tolerant space is given, events are forcibly intercepted. The dispatch returns true to ensure that the event is transmitted down. Don't worry

Fourth: monitor the sliding gesture in the horizon Scrollview edge state. The specific implementation is as follows, mainly the gesture judgment at the edge.

Fifth: prevent the vertical Scrollview from prematurely shielding events: rewrite the interceptor function:

Sixth: slide gesture on the first page of viewpager;

1. Prevent premature interception

2. Prevent sliding back, etc

Seventh: getparent(). Requestdisallowintercepttouchevent

This function can only ensure that the event is not masked. However, if the dispatch of this layer returns false when it is down, the event processing will be invalid, even if the focus is forcibly obtained

Thank you for reading, hope to help you, thank you for your support to this site!