Shulou(Shulou.com)05/31 Report--

This article mainly introduces "how to implement the event distribution mechanism in android". In the daily operation, I believe that many people have doubts about how to implement the event distribution mechanism in android. The editor consulted all kinds of materials and sorted out simple and easy-to-use operation methods. I hope it will be helpful to answer the doubts about "how to implement the event distribution mechanism in android". Next, please follow the editor to study!

In Android development, event distribution mechanism is an important knowledge system of Android. Understanding and being familiar with the whole distribution mechanism will help to better analyze all kinds of click and slide failure problems, better expand the event function of controls and develop custom controls. At the same time, event distribution mechanism is also one of the necessary test points for Android interviews. If you can draw some event distribution diagrams on the spot, it will definitely add a lot of points.

Android event distribution stream

There are many blog posts about the Android event distribution mechanism, but many of them are to write a Demo and then post the output Log or take the source code analysis, and then a bunch of comments and instructions, if you look at it attentively, it will certainly gain a lot, but it is really difficult to explain and remember the whole process. I used to try desperately to remember the whole process, but I forgot for a while. I think it will be much clearer to analyze this kind of problem and the trend of the event flow. I will explain and explain the event distribution flow chart according to an event distribution flowchart drawn below. explain the final trend of the event after the user clicks and returns different values in different functions.

Figure 1.

Note:

If you look carefully, the picture is divided into three layers, followed by Activity, ViewGroup and View from top to bottom.

The event starts with the white arrow in the upper left corner and is distributed by dispatchTouchEvent of Activity

The word above the arrow represents the method return value, (return true, return false, return super.xxxxx (), super means to call the parent class implementation.

There is a word "true-- > consumption" in the boxes of dispatchTouchEvent and onTouchEvent, which means that if the method returns true, then the event is consumed and will not be passed anywhere else, and the event is terminated.

At present, all the events in the diagram are aimed at ACTION_DOWN, and we * analyze ACTION_MOVE and ACTION_UP.

No matter what dispatchTouchEvent of Activity returns, it will call dispatchTouchEvent of ViewGroup (see the source code for yourself)

If we look at the whole picture carefully, we can draw several conclusions about the direction of the event flow. (I hope the reader will pay attention to figure 1 below and read it several times, so that he can have a clearer idea.)

1. If the event is not interrupted, the whole flow direction of the event is a U-shaped diagram. Let's take a look at this diagram, which may better understand the meaning of the U-shaped diagram.

Figure 2.

So if we do not rewrite or change the return value of the method in the control, but directly call the default implementation of the parent class with super, then the whole event flow should be from Activity-- > ViewGroup- > View to call the dispatchTouchEvent method from top to bottom, until the leaf node (View), and then from View- > ViewGroup- > Activity to call the onTouchEvent method from bottom to top.

2. DispatchTouchEvent and onTouchEvent once return true, the event stops passing (reaching the end point) (no one can receive the event again). As long as the return true event is no longer passed on in the figure below, for return true, we often say that the event has been consumed, which means that the event ends here and will not be passed down, and no one can receive the event any more.

Figure 3.

3. DispatchTouchEvent and onTouchEvent return false events are passed back to the onTouchEvent processing of the parent control.

Figure 4.

Looking at the dark blue line in the image above, in the case of returning false, the event is passed to the parent control onTouchEvent for processing.

For dispatchTouchEvent to return false, it should mean that the event stops passing and distributing to the child View and starts backtracking to the parent control (the onTouchEvent of the parent control starts backtracking from the bottom up to an onTouchEvent return true). The event distribution mechanism is like recursion, and the meaning of return false is that recursion stops and then starts backtracking.

It is relatively simple for onTouchEvent return false, which does not consume events and allows them to continue to flow from the bottom up in the direction of the parent control.

4 、 dispatchTouchEvent 、 onTouchEvent 、 onInterceptTouchEvent

The default implementation of these methods of ViewGroup and View is to make the whole event installation U-shaped complete, so return super.xxxxxx () will let the event complete the entire event flow path in the U-shaped direction, with no changes, no backtracking, no termination, and every step.

Paste_Image.png

So if you see the method return super.xxxxx (), then the next direction of the event is to go to the next U-shaped target, remember the above figure a little bit, and you can quickly tell which function of which control the next direction is.

5. The function of onInterceptTouchEvent

Figure 5.

Intercept means to intercept. Every time each ViewGroup makes a distribution, ask the interceptor if you want to intercept (that is, ask yourself if you want to handle this event yourself). If you want to handle it yourself, return true will give it to your own onTouchEvent in the onInterceptTouchEvent method. If you don't intercept, you will continue to upload it to the child control. By default, it will not be intercepted, because the sub-View also needs this event, so the onInterceptTouchEvent interceptor return super.onInterceptTouchEvent () is the same as return false and will not be intercepted, and the event will continue to be passed to the dispatchTouchEvent of the sub-View.

6. Event flow direction when the dispatchTouchEvent method of ViewGroup and View returns super.dispatchTouchEvent ().

Figure 6

First of all, let's take a look at ViewGroup's dispatchTouchEvent. Return true is the final delivery. Return false is the onTouchEvent that goes back to the parent View, and then how can ViewGroup distribute events to its own onTouchEvent processing through the dispatchTouchEvent method? neither return true nor false can, so you can only intercept events to your own onTouchEvent through Interceptor, so the default implementation of the ViewGroup dispatchTouchEvent method is to call onInterceptTouchEvent. Keep this in mind.

Well, for View's dispatchTouchEvent return super.dispatchTouchEvent (), where will the event go? it is a pity that View does not have an interceptor. But by the same token, return true is the end. Return false is the onTouchEvent of the parent class, so how to distribute events to your own onTouchEvent handling? only the default implementation of the dispatchTouchEvent () method of the return super.dispatchTouchEvent,View class can help you call View's own onTouchEvent method.

Having said so much, I don't know if I have made it clear. I would like to sum up on my side:

For dispatchTouchEvent,onTouchEvent,return true, it is the termination of event delivery. Return false is the onTouchEvent method that goes back to the parent View.

If ViewGroup wants to distribute itself to its own onTouchEvent, it needs the interceptor onInterceptTouchEvent method return true to intercept the event.

ViewGroup's interceptor onInterceptTouchEvent does not intercept by default, so return super.onInterceptTouchEvent () = return false

View does not have an interceptor, and the dispatchTouchEvent default implementation (super) for View to distribute events to its own onTouchEvent,View is to distribute events to its own onTouchEvent.

The dispatchTouchEvent of ViewGroup and View is to do event distribution, so there are four possible targets for this event to be distributed

Note:-- > the latter represents what the event target needs to do.

1. Consume by yourself and end the transmission. -- > return true

2. Give your own onTouchEvent processing-> call super.dispatchTouchEvent () the system will call onInterceptTouchEvent by default, and assign events to its own onTouchEvent processing in onInterceptTouchEvent return true.

3. Pass to child View-- > call super.dispatchTouchEvent () the default implementation will call onInterceptTouchEvent in onInterceptTouchEvent return false, and the event will be passed to the subclass.

4. Do not pass to the child View, the event stops passing down, the event starts backtracking, and from the onTouchEvent of the parent View, the event returns from bottom to top to execute the onTouchEvent--- > return false of each control.

Note: since View does not have a child View, there is no need for onInterceptTouchEvent to control whether to pass events to child View or intercept, so View event distribution defaults to passing events to its own onTouchEvent handling (equivalent to intercepting) when calling super.dispatchTouchEvent (). Compared to ViewGroup's dispatchTouchEvent event distribution, View event distribution does not have the third point of the four targets mentioned above.

The onTouchEvent methods of ViewGroup and View do event handling, so there are only two ways to handle this event:

1. If you consume it, the event ends, and you will not pass it on to anyone-- > return true

2. Continue to upload from the bottom up without consuming the event, so that the parent View can also receive this event-- > the default implementation of return false;View is not consumed. So super==false.

The onInterceptTouchEvent method of ViewGroup has two situations for events:

1. Intercept it and give it to your own onTouchEvent-> return true

2. Do not intercept, but pass the event down to the child View-- > return false,ViewGroup. It is not intercepted by default, so super==false

About ACTION_MOVE and ACTION_UP

The above is all about event delivery for ACTION_DOWN. ACTION_MOVE and ACTION_UP are not the same as ACTION_DOWN in the process of passing. If you return false when you execute ACTION_DOWN, a series of other action will not be executed. To put it simply, when dispatchTouchEvent is doing event distribution, it will receive ACTION_MOVE and ACTION_UP events only if the previous event (such as ACTION_DOWN) returns true. Many bloggers have said this sentence, but what does it mean? Let's take a look at the following specific analysis.

As mentioned above, if the event is not interrupted, it will continue to be sent down to the leaf layer (View), and then it will be sent back to Activity,dispatchTouchEvent and onTouchEvent to consume the event through return true, ending the event delivery, while onInterceptTouchEvent can not consume the event. It is equivalent to a fork port that acts as a diversion port. In which functions will ACTION_MOVE and ACTION_UP be called? as I said earlier, it is not which function received the ACTION_DOWN. You will receive follow-up events such as ACTION_MOVE.

Let's take a look at the specific trends of ACTION_MOVE events and ACTION_UP events in different scenarios and summarize the rules.

1. We return true consumption of this event in the dispatchTouchEvent method of ViewGroup1

The ACTION_DOWN event ends after (Activity's dispatchTouchEvent)-- > (ViewGroup1's dispatchTouchEvent), and the event is consumed (such as the flow direction of the ACTION_DOWN event with the red arrow code below).

/ / print log Activity | dispatchTouchEvent-- > ACTION_DOWN ViewGroup1 | dispatchTouchEvent-- > ACTION_DOWN-> consumption

What will happen to ACTION_MOVE and ACTION_UP in this scenario? take a look at the log below.

Activity | dispatchTouchEvent-- > ACTION_MOVE ViewGroup1 | dispatchTouchEvent-- > ACTION_MOVE-TouchEventActivity | dispatchTouchEvent-- > ACTION_UP ViewGroup1 | dispatchTouchEvent-- > ACTION_UP

In the following picture

The red arrow represents the flow direction of the ACTION_DOWN event

The blue arrows represent the flow of ACTION_MOVE and ACTION_UP events

Paste_Image.png

2. Our dispatchTouchEvent in ViewGroup2 returns true to consume this event.

Activity | dispatchTouchEvent-- > ACTION_DOWN ViewGroup1 | dispatchTouchEvent-- > ACTION_DOWN ViewGroup1 | onInterceptTouchEvent-- > ACTION_DOWN ViewGroup2 | dispatchTouchEvent-- > ACTION_DOWN-> cancellation Activity | dispatchTouchEvent-- > ACTION_MOVE ViewGroup1 | dispatchTouchEvent-- > ACTION_MOVE ViewGroup1 | onInterceptTouchEvent-- > ACTION_MOVE ViewGroup2 | dispatchTouchEvent-- > ACTION_MOVE-TouchEventActivity | dispatchTouchEvent-- > ACTION_UP ViewGroup1 | dispatchTouchEvent-- > ACTION_UP ViewGroup1 | onInterceptTouchEvent-- > ACTION_UP ViewGroup2 | dispatchTouchEvent-- > ACTION_UP

The red arrow represents the flow direction of the ACTION_DOWN event

The blue arrows represent the flow of ACTION_MOVE and ACTION_UP events

Paste_Image.png

3. Our dispatchTouchEvent in View returns true to consume this event.

I won't just draw this, and the effect is similar to that of dispatchTouchEvent return true in ViewGroup2. The same dispatchTouchEvent function that receives ACTION_DOWN can receive ACTION_MOVE and ACTION_UP.

So we can basically conclude that if the true consumption termination event is put back in the dispatchTouchEvent of a control, then the function that receives the ACTION_DOWN will also receive ACTION_MOVE and ACTION_UP.

4. Our onTouchEvent in View returns true to consume this event.

The red arrow represents the flow direction of the ACTION_DOWN event

The blue arrows represent the flow of ACTION_MOVE and ACTION_UP events

5. Our onTouchEvent in ViewGroup 2 returns true to consume this event.

The red arrow represents the flow direction of the ACTION_DOWN event

The blue arrows represent the flow of ACTION_MOVE and ACTION_UP events

6. Our onTouchEvent in ViewGroup 1 returns true to consume this event.

The red arrow represents the flow direction of the ACTION_DOWN event

The blue arrows represent the flow of ACTION_MOVE and ACTION_UP events

Paste_Image.png

7. Our onTouchEvent in Activity returns true to consume this event.

The red arrow represents the flow direction of the ACTION_DOWN event

The blue arrows represent the flow of ACTION_MOVE and ACTION_UP events

8. Our dispatchTouchEvent in View returns false and the onTouchEvent of Activity

Return to true consumption for this event

The red arrow represents the flow direction of the ACTION_DOWN event

The blue arrows represent the flow of ACTION_MOVE and ACTION_UP events

9. We returned false in dispatchTouchEvent of View and onTouchEvent of ViewGroup 1 returned true to consume this event

The red arrow represents the flow direction of the ACTION_DOWN event

The blue arrows represent the flow of ACTION_MOVE and ACTION_UP events

10. We return false in dispatchTouchEvent of View and true in onTouchEvent of ViewGroup 2 to consume this event

The red arrow represents the flow direction of the ACTION_DOWN event

The blue arrows represent the flow of ACTION_MOVE and ACTION_UP events

11. We return false in dispatchTouchEvent of ViewGroup2 and true in onTouchEvent of ViewGroup1 to consume this event

The red arrow represents the flow direction of the ACTION_DOWN event

The blue arrows represent the flow of ACTION_MOVE and ACTION_UP events

12. We return true to intercept the event in the onInterceptTouchEvent of ViewGroup2 and true to consume the event in the onTouchEvent of ViewGroup 1.

The red arrow represents the flow direction of the ACTION_DOWN event

The blue arrows represent the flow of ACTION_MOVE and ACTION_UP events

Suddenly drew a lot of pictures, there are several cases will no longer draw, I believe you also see the pattern, for the onTouchEvent consumption event: in which View onTouchEvent returns true, then ACTION_MOVE and ACTION_UP events are no longer passed down to this View from up to down, but directly to their own onTouchEvent and end the event delivery process.

For ACTION_MOVE and ACTION_UP summary: where the ACTION_DOWN event is consumed (return true), then ACTION_MOVE and ACTION_UP will do event distribution from top to bottom (through dispatchTouchEvent) to upload to the control, and will only be transferred to this control, not further uploaded. If the ACTION_DOWN event is consumed in dispatchTouchEvent, then the event stops passing at this point, if the ACTION_DOWN event is consumed in onTouchEvent. Then the ACTION_MOVE or ACTION_UP event is passed to the onTouchEvent processing of the control and the delivery ends.

At this point, the study on "how to implement the event distribution mechanism in android" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.