Cause Analysis and Solution for its subcontrol changing to pressed status when you click viewgroup

This problem should have been analyzed at the beginning when analyzing touch event processing. However, I thought this code was not so close to touch's topic at the time,

I ignored it until I encountered a problem on it. In fact, Android development should have encountered this phenomenon more or less. I am in our own app.

I also found this phenomenon. I was puzzled at the beginning, because according to my own research and analysis, only when a view accepts the touch event pressed will it be transferred to the view

Change the background status by using the setpressed method. The case here obviously does not press this sub-view. The viewgroup is pressed, so it has been

I didn't think about it, so I didn't think much at the time, so it was so unclear. (now I want to go back and find out where the setpressed method is called in Android SRC,

This problem is solved ). One day, our review encountered related problems again. Coincidentally, our fix solved the original bug,

Unfortunately, this article is introduced. Again, the problem occurred. At the same time, another of our colleagues showed me the code in section viewgroup. At that time, I felt very excited.

Surprised. I was excited that the question that had plagued me for a long time was finally answered. I was surprised that I was not quite able to understand why Android would write such a piece of code that seems a little "nosy" to me. Okay, story

The background is almost explained, and the topic is directly entered below.

Everyone who knows about touch events knows that the view. setpressed (true) Call occurs in the view. ontouchevent method, either down

When an event or a down event is postponed after milliseconds of tap_timeout, the event is either handled by the up event. Let's take a look at the relevant source code:

/*** Sets the pressed state for this view. ** @ see # isclickable () * @ see # setclickable (Boolean) ** @ Param pressed pass true to set the view's internal state to "pressed ", or false to reverts * the view's internal state from a previusly set "pressed" state. */Public void setpressed (Boolean pressed ){
// Check whether the pressed status changes to final Boolean needsrefresh = pressed! = (Mprivateflags & pflag_pressed) = pflag_pressed); If (pressed) {// set the flag position mprivateflags | = pflag_pressed;} else {mprivateflags & = ~ Pflag_pressed;} If (needsrefresh) {// The status has changed, you need to refresh the drawable state, where the background will become a suitable refreshdrawablestate ();} dispatchsetpressed (pressed ); // pass the pressed status to the subview}/*** dispatch setpressed to all of this view's children. ** @ see # setpressed (Boolean) ** @ Param pressed the new pressed state */protected void dispatchsetpressed (Boolean pressed) {// The default value of view is do nothing, because it does not have children.} // viewg OUP's heavy load on dispatchsetpressed @ override protected void dispatchsetpressed (Boolean pressed) {// This is the viewgroup's final view [] children = mchildren; Final int COUNT = mchildrencount; for (INT I = 0; I <count; I ++) {final view child = children [I]; // children that are clickable on their own shocould not // show a pressed state when their parent view does. // clearing a pressed State always propagates. note Meaning to understand this comment if (! Pressed | (! Child. isclickable ()&&! Child. islongclickable ())){
// In fact, this If statement mainly involves two tasks. 1. If pressed is false, the setpressed (false) method of child is always called.
// In this case, always pass; 2. If pressed is true, only child cannot respond to the touch event, that is, clickable and longclickable are both false.
// Call the child. setpressed (true) method. To put it bluntly, if the child can handle the pressed event, they will handle it themselves; otherwise, the parent will
// Force the child to process the request. At the same time, note that this call is still recursive and will always be passed to future generations... Child. setpressed (pressed );}}}

In addition, we need to raise 1 point until android4.1.x starts viewgroup. dispatchsetpressed. This If judgment is added during the traversal of children, that is, before

Will directly call the child. setpressed (pressed) method. From the above analysis, we can see that the parent "Forces" child to process the pressed event, so in order to avoid

This document does not start with a bug. You can use either of the following methods:

1. Enable a view to handle touch events, that is, set clickable and longclickable to true;

2. If a view does not process touch events by itself, you should not set a stateful drawable for it, or at least do not set a separate state for its pressed state.

It does not matter even if setpressed (true) is called.

In our code, we chose 2nd solutions and removed their background directly from the code. This small article is a supplement to the previous touch event processing and is also in the development process.

Experience and Lessons, hope to help you, enjoy...

Finally, the same topic of the previous csdn article: http://blog.csdn.net/cpyyes/article/details/11144497

Cause Analysis and Solution for its subcontrol changing to pressed status when you click viewgroup