开发笔记之打造通用下拉刷新（介绍篇）
开发笔记之打造通用下拉刷新（细节篇）
开发笔记之打造通用下拉刷新（重难点篇）
本篇不讲总体实现思路和每一个细节，只讲一下实现过程中遇到的几个关键问题，虽然叫重难点，但也并不是什么高级复杂的技术，只是一些实现过程中遇到的问题并且通过不断思考和尝试之后才得到的结果。
一、在哪里实现事件处理逻辑
我们知道，安卓给我们提供了三个事件处理的方法：onTouchEvent、onInterceptTouchEvent、dispatchTouchEvent。一般我们自定义控件的时候，事件的拦截有两种思路（来自《android 开发艺术探索》）：
- 外部拦截法，点击事件先经过父容器判断，如果父容器需要此事件就拦截，否不拦截，这种方法比较符合点击事件的分发机制。此方法需要重写父容器的onInterceptTouchEvent方法，拦截事件后在onTouchEvent方法中写控件逻辑.
- 内部拦截法，父容器不拦截任何事件，所有的事件都传递给子元素，如果子元素需要此事件就消耗掉，否则就交给父容器去处理，这种方法和android中的事件分发机制不一致，需要配合requestDisallwInterceptTouchEvent方法才能正常工作，需要子元素重写dispatchTouchEvent方法。
现在来考虑ptrLayout的实现，内部拦截法对子元素有特定的要求，需要上下配合，不符合我们的要求，因为ptrLayout不知道也不应该知道子view的具体实现。再看外部拦截法，在onInterceptTouchEvent方法中拦截事件，同样不符合ptrLayout的要求，原因如下：
- 我们在acton_down的时候是无法判断事件是否要拦截或消费的，需要通过action_move计算方向才能决定，但是如果没有view消费down，那就不会有后续的move，那就无从谈拦截的事了。
- 父容器一旦拦截了某个move事件，从此以后子view再也无法收到任何事件了，无法实现我在细节篇提到的下拉与子view滑动的衔接
那么在ptrLayout是如何控制事件呢？——所有的逻辑都在dispatchTouchEvent中实现。ptrLayout重写了dispatchTouchEvent方法，在这个方法中，如果希望子元素接收到事件，则调用 super.dispatchTouchEvent()，否则不调用。这样一来就可以灵活地控制事件的传递。另外，为了防止没有view消费down事件从而无法接收后续的move事件，任何时候都要在dispatchTouchEvent方法的down事件中返回true。
二、子view按下效果的取消
在上一节提到过，手指按下的时候无法判断是否要拦截事件，所以action_down是一定会传到子view，如果子view是listview或者button等控件，就会出现被按下的效果（比如颜色加深、5.0的ripple波纹），如果随后的move事件被ptrLayout拦截了，那么子view的按下效果是不会消失的，会一直显示着被按住状态。如图
那么为什么我们平时用onInterceptTouchEvent拦截事件的时候不会有这样的问题呢？原因就是如果父容器拦截了事件，那么其子view就会收到一个action_cancel事件，从而让子view知道事件被拦截了，取消当前的效果。既然知道了原因，那么解决办法自然就出来了，那就是在我们拦截的时候，自己手动向下发一个acion_cancel事件，主要的代码是这样的：
public boolean dispatchTouchEvent(MotionEvent ev)
{
switch (ev.getAction())
{
...
case ACTION_MOVE:
if(需要拦截并通知下层取消事件)
{
//构造一个cancel事件，其他参数与当前事件一致
MotionEvent cancelEvent = MotionEvent.obtain(ev.getDownTime(), ev.getEventTime() + ViewConfiguration.getLongPressTimeout(), MotionEvent.ACTION_CANCEL, ev.getX(), ev.getY(), ev.getMetaState());
super.dispatchTouchEvent(cancelEvent);
}
}
...
}
这样一来，子view的问题就可以解决了。当然，我们应该控制cancel事件只向下发一次，就是刚开始拦截的那一次，之后就不用再发了，以免无谓的方法调用浪费运算资源。
三、下拉与子view滑动的衔接
这个点已经提到过两次了（具体效果看细节篇），前面的dispatchTouchEvent的重写就是为了实现这一特性。首先我们应该要清楚，ptrLayout什么时候该拦截事件，什么时候该传递事件，然后用第一节说的方法去拦截和传递就可以了。关于判断拦截条件这一点，涉及到的条件判断太多了，这里不一一细说，有兴趣可以看具体的代码，里面有各种注释，代码比文字更容易明白。这里只说一种情况，又是需要手动发事件才能解决的。文字描述比较乏力，看图
子view在Y1处收到down事件到在Y2处收到move事件。从上一节我们知道，子view在收到down事件后会马上收到一个cancel事件，然后再收到move事件，也就是等于子view直接收到move事件的，这时子view可能有两种处理方法：
- 直接忽略这些Move事件，因为没有收到down事件，无法判断滑动的距离。这是大部分滑动控件的做法。忽略move事件，就意味着整个滑动没有衔接起来。
- 处理move事件，按上一次的down事件的位置来计算滑动的距离，但是由于Y2到Y1是有一定的距离的，子view会在一瞬间滑动Y1-Y2的距离，虽然滑动衔接起来了，还是画面没有衔接起来。
这里解决办法的思路和第二节一样，既然缺一个action_down事件，那么我们就手动发一个就可以了，发的时机就是手指刚到达Y2的时候。代码大概是这样的：
public boolean dispatchTouchEvent(MotionEvent ev)
{
switch (ev.getAction())
{
...
case ACTION_MOVE:
if(不再拦截move事件)
{
if(还没发送down事件)
{
//构造一个down事件，其他参数与当前事件一致
MotionEvent downEvent = MotionEvent.obtain(ev.getDownTime(), ev.getEventTime() + ViewConfiguration.getLongPressTimeout(), MotionEvent.ACTION_Down, ev.getX(), ev.getY(), ev.getMetaState());
return super.dispatchTouchEvent(downEvent);
}
}else//已经发送过down事件了,直接向下传递move事件
{
return super.dispatchTouchEvent(ev);
}
}
}
...
}
四、横向滑动处理
当我们的子view存在横向滑动的时候，比如viewPager，我们就需要考虑横向滑动的处理了。首先，并不是任何时候子view都可以横向滑动的，所以设置一个mHasHorizontalChild变量，当这个功能开启的时候才会去考虑横向的处理。
我们怎么判断滑动是横向的还是纵向的呢?这是一个简单的几何数学题，无非就是计算滑动前后两个点的连线的斜率，k = ΔY / ΔX, 我们可以简单地认为当k大于1时为纵向，小于1时为横向（当然这个1可以是其他值，可以根据横纵向的灵敏度来设置）。但是，考虑到实现的使用体验，当我们手指开始横向滑动时就不太可能想要下拉刷新了，意思是，当手指横向滑动了一段距离，手指突然向下移动，也不应该去触发下拉的逻辑，不然子view向右滑动到一半然后下拉，头部显示出来就会变得十分奇怪，反之亦然。
这里只是一个细节问题，实现的方法很简单，开始滑动时判断当前的滑动方向，就记住当前的判断结果，以后就按照这个结果来处理事件，直到下一次的滑动，这里就不再多讲。
