今天在温习ViewGroup的dispatchTouchEvent理解这篇文章的时候,偶然间发现了MotionEvent.ACTION_CANCEL使用的情景,温故而知新,说的就是这了。
还是直入主题吧。
情景:ScrollView中有一个Button。手指触下Button区域进行滑动的过程中,Button会收到ScrollView传给Button的MotionEvent.ACTION_CANCEL事件。
具体分析
声明:文中所述的代码行数对应android5.1(api22)的源码行数。
手指触下Button区域时,对应ACTION_DOWN。
ScrollView的dispatchTouchEvent()(即是ViewGroup的dispatchTouchEvent)收到event,执行ViewGroup的1960行,调用了ScrollView的onInterceptTouchEvent()方法,ScrollView的535–》582,ScrollView的onInterceptTouchEvent()返回false。ViewGroup执行1985–》1995–》2049,由于2049行中的dispatchTransformedTouchEvent()方法返回true(因为Button是可点击的,也就是clickable是true,Button的onTouchEvent必会返回true),执行2065行,mFirstTouchTarget被赋值,mFirstTouchTarget.child为该Button,2102–》2141。滑动过程中,对应ACTION_MOVE。
由于mFirstTouchTarget不为空,ViewGroup中执行1960,调用了ScrollView的onInterceptTouchEvent()方法,ScrollView的515,如果滑动量小于mTouchSlop,则onInterceptTouchEvent还是返回的false,当滑动量大于mTouchSlop时,onInterceptTouchEvent返回true。ViewGroup中不会进1985的if判断,执行2104行,cancelChild为true,执行2106–》2371–》2375,这里就传给Button一个ACTION_CANCEL的Event。
其实ViewGroup的dispatchTouchEvent理解中的结论三就是这种情景,都是父视图的onInterceptTouchEvent先返回false,子控件消费事件(dispatchTouchEvent返回true),然后在某种情况下onInterceptTouchEvent返回true,子控件就会收到ACTION_CANCEL的Event。
其应用场景的思考
对于View而言,在View的onTouchEvent中对ACTION_CANCEL的处理:
case MotionEvent.ACTION_CANCEL:
setPressed(false);
removeTapCallback();
removeLongPressCallback();
break;
SeekBar的onTouchEvent对ACTION_CANCEL的处理:
case MotionEvent.ACTION_CANCEL:
if (mIsDragging) {
onStopTrackingTouch();
setPressed(false);
}
invalidate(); // see above explanation
break;
ViewPager的onTouchEvent对ACTION_CANCEL的处理:
case MotionEvent.ACTION_CANCEL:
if (mIsBeingDragged) {
scrollToItem(mCurItem, true, 0, false);
mActivePointerId = INVALID_POINTER;
endDrag();
needsInvalidate = mLeftEdge.onRelease() | mRightEdge.onRelease();
}
break;
拿ViewPager来说,在ScrollView包含ViewPager的情况下,对ViewPager做左右滑动,滑到一页的一半时往上下滑,ViewPager收到MotionEvent.ACTION_CANCEL后就能够回到先前那一页,而不是停在中间。
关于MotionEvent的参考资料:安卓自定义View进阶-MotionEvent详解