This is the 14th day of my participation in the November Gwen Challenge. Check out the event details: The last Gwen Challenge 2021

preface

The core of View usage is event distribution. Event distribution is not only an important part of gesture control, but also a problem that developers often encounter with gesture conflicts. Once you master the View event distribution mechanism, gesture conflicts and gesture touch operations can be easily solved.

Click event passing

When the screen is touched, the system passes the event to the View, which is the process of distribution. This process is performed by three methods: dispatchTouchEvent, onInterceptTouchEvent, and onTouchEvent. Developers may be more familiar with onTouchEvent and often use this callback method to handle ACTION_DOWN, ACTION_MOVE, ACTION_UP and other events in development. The onTouchEvent was also mentioned in the introduction to # View basics. In the event distribution mechanism, it can be understood that onTouchEvent is the current View that distributes the consumption of the action event and uses the event. It belongs to the user of the current event and other views lose the opportunity to operate. The following sections describe the specific invocation logic of these methods.

dispatchTouchEvent

DispatchTouchEvent is used for execution event distribution. This method is called when an event is passed to the current View and determines in the callback whether the current View consumes the current event.

onInterceptTouchEvent

OnInterceptTouchEvent determines whether to intercept an event. It is here to determine whether the current View needs to intercept the passed event when the callback is executed.

onTouchEvent

OnTouchEvent is called after dispatchTouchEvent when the event is allowed to be consumed by the current View. In onTouchEvent, determine whether an event does a real consumption operation, otherwise the event will not be accepted in the current sequence of events. For example, if the current View does not consume a Down operation, the View will not receive subsequent Move and Up events.

In general, the relation of event transmission is roughly as follows:

Flowchart of TD [dispathcTouchEvent] -- > A | B | interrupt {onInterceptTouchEvent}; B - > is | | C [onTouchEvent]; C --> D[return true/false]; Whether B -- -- -- - > | | E [child. DispathcTouchEvent];

When A touch event occurs in the root view, A’s dispathcTouchEvent is called. If A’s onInterceptTouchEvent returns true, it intercepts the current event. Then A’s onTouchEvent is called. If A’s onInterceptTouchEvent returns false, the event is not intercepted and is passed to its child view. The child view’s dispathcTouchEvent is called to continue the loop until the event is handled.

conclusion

In addition, several points worth noting are summarized:

  1. ViewThere is noonInterceptTouchEventThe callback,ViewGropwithonInterceptTouchEventCallback, forViewIt’s the only one that doesn’t have child objects.
  2. ViewGroptheonInterceptTouchEventThe callback returns false by default and does not intercept events.
  3. ViewtheonTouchEventCallbacks default to true.
  4. The order of event delivery is outside-in, first from parent to child, and thenrequestDisallowInterceptTouchEventMethod to control the superview distribution process in a child view.
  5. The currentViewProcessing events are received but not consumedDownEvent, and subsequent events of the same sequence of events are assigned to its parent viewonTouchEventCall back to deal with it. At the same time the currentViewChild views of the same event sequence are not received and consumed.
  6. The currentViewThe receive processing event is consumed onlyDownEvents that follow the same sequence of events are not consumed. Then subsequent events are presentViewEvents that are still received but not ultimately consumed are passed toActivityTo deal with