Slidingmenu believe that we are already familiar with the source code hosted in Https://github.com/jfeinstein10/SlidingMenu. First of all I would like to thank the original author of the Dauntless spirit, because open source and great, haha. If we only want to use Slidingmenu in our project, we'll have to pull out the Slidingmenu control. This is what I'm pulling out of. Slidingmenu Control Source code (everyone has the need to download learning). as follows:
Slidingmenu Control Source Code
I am proud to be using this open source control in my own company's projects, but after testing by the company's testers, I find a problem, Slidingmenu fast switching back and forth (when Slidingmenu is on, one finger clicks the slidingmenu layout (in the code: custom Customviewbehind), Another finger at the same time click on the top of the Slidingmenu layout (customviewabove), the frequent operation will appear this phenomenon (not required OH): When Slidingmenu closed, let me click on the layout above the control, the event is not responding, initially thought it was the application card is dead, but by the device on the exit, The app can exit normally. So my initial position is that customviewabove this custom viewgroup to intercept the gesture events so that the child view can not accept the event, it will not respond.
  Span style= "font-size:18px" > Then we can go directly to the Slidingmenu control source, find Customviewabove.java, and then we find this method onintercepttouchevent () onintercepttouchevent returns True, It means that the viewgroup does not pass the event to its child Childview, and returns false to not intercept the event. So I think customviewabove.java in the above phenomenon onintercepttouchevent method returns True, so the various gesture events do not respond to the
@Override
public boolean onintercepttouchevent (Motionevent ev) {
if (!menabled)
return false;
Final int action = Ev.getaction () & Motioneventcompat.action_mask;
if (DEBUG)
if (action = = Motionevent.action_down)
LOG.V (TAG, "Received action_down");
if (action = = Motionevent.action_cancel | | action = = MOTIONEVENT.ACTION_UP
|| (Action! = Motionevent.action_down && Misunabletodrag)) {
EndDrag ();
return false;
}
Switch (action) {
Case Motionevent.action_move:
Determinedrag (EV);
Break
Case Motionevent.action_down:
int index = MOTIONEVENTCOMPAT.GETACTIONINDEX (EV);
Mactivepointerid = Motioneventcompat.getpointerid (EV, index);
if (Mactivepointerid = = Invalid_pointer)
Break
Mlastmotionx = Minitialmotionx = Motioneventcompat.getx (EV, index);
Mlastmotiony = motioneventcompat.gety (EV, index);
if (thistouchallowed (EV)) {
Misbeingdragged = false;
Misunabletodrag = false;
if (Ismenuopen () && Mviewbehind.menutouchinquickreturn (mcontent, Mcuritem, Ev.getx () + mscrollx)) {
Mquickreturn = true;
}
} else {
Misunabletodrag = true;
}
Break
Case MOTIONEVENTCOMPAT.ACTION_POINTER_UP:
Onsecondarypointerup (EV);
Break
}
if (!misbeingdragged) {
if (Mvelocitytracker = = null) {
Mvelocitytracker = Velocitytracker.obtain ();
}
Mvelocitytracker.addmovement (EV);
}
Returnmisbeingdragged | | Mquickreturn}
See source code discovery, and Mquickreturn (whether to return quickly) two member variables are determined. So in a particular scenario, the reasonable situation is when Slidngmenu has
closed, isbeingdragged and Mquickreturn should be false at the same time, but the reason for the above phenomenon is mquickreturn is true. We did not deal with these two variables because of the frequent unconventional operations. Look at the source code, I found every time action_down
isbeingdragged and Mquickreturn should be set to false, because the Action_down event occurs when it is not possible to drag or Slidingmenu
Close quickly. See the two lines of code I added (below):
< Span style= "FONT-FAMILY:SIMSUN; line-height:26px "> case Motionevent.action_down:
misbeingdragged = false;
mquickreturn = false;
OK, this bug is resolved, stating that the values of isbeingdragged and Mquickreturn are problematic after each slidingmenu shutdown, so I decided to Action_down both variables to false. Source code is still a lot of, want to fully understand or take time drops, can only solve the problem of the phenomenon first.