之前写了一篇RecyclerView左滑删除的博客(RecyclerView仿ios左滑删除的轻量级实现)，本文对里面的event处理部分进行分析，并且增加了ListView与ExpandableListView的左滑删除。
最近发现项目里面可能要用到Expandable RecyclerView，github上又查找一番，没有发现好的方法。现阶段的Expandable RecyclerView都通过adapter来做，实现部分没有像ExpandableListView里面一样对数据进行save、restore，当然这一点也无所谓了。其它的方面，例如添加header、footer，特别是分隔线，麻烦了点。Expandable列表解决方案还是ExpandableListView用起来简单点。所以，修改了左滑部分，实现了SwipeExpandableListView及SwipeListView。
项目地址：https://github.com/fornana/swipeitemlayout
效果图如下：
一、ExpandableListView左滑的一些问题与解决方法
ExpandableListView与ListView的左滑删除使用方法与上一篇文章一样，只是将基类分别换成SwipeExpandableListView、SwipeListView。这个没办法像RecyclerView那样轻量级，因为一定要介入ListView的onInterceptTouchEvent处理，除了重写，没有其它方式。
ExpandableListView用起来方便，不过有一点不好，就是设置分隔线。很多时候ui设计的，group divider与child divider是不一样的，但是只提供了child divider的设置。所以，通过添加view来代替group divider。结果有的手机child divider不显示。所以，干脆用view来代替group divider和child divider，并封装成了一个adapter。详细见ExpandableListViewDividerAdapter。
使用方式：new ExpandableListViewDividerAdapter(adapter)，adapter即我们写的adapter。这样就可以给ExpandableListView添加group divider、child divider了。
ExpandableListView好像还有一个问题，不过不太确定，网上查到的很早之前的一篇文章提到的，没碰到过，就是数据删除以后无法更新。现在ExpandableListView应该不会存在这个问题了。在写demo的时候碰到过数据更新的问题，但是是自己有个地方写错了。
不像RecyclerView的左滑那样与SwipeRefreshLayout配合很好，不冲突，ListView调用requestDisallowInterceptTouchEvent是无效的。这就意味着左滑时，可能被SwipeRefreshLayout拦截掉，通过重写ListView的canScrollVertically解决了该问题。其它下拉刷新没有试过，不过解决起来应该还好。
至于回调与点击效果，第一种是通过设置ListView的item listener与listSelector，注意这个时候要禁止内部button等获取焦点，即focusable=false,clickable=false,focusableInTouchMode=false；第二种就是设置view的click listener以及background的方式，就像RecyclerView的做法一样。
二、SwipeExpandableListView与RecyclerView.SwipeItemLayout的实现分析
主要分析一下event的处理。二者几乎一样，就以RecyclerView为主，event部分从上到下有三者：listener、parent、item，listener是OnItemTouchListener，parent是RecyclerView。从以下几个使用场景来分析：
1、item处于open，此时点击另外一个item或者点击其它位置
event应该先交给listener，listener close处于open的item，然后再交给parent。
2、手指拖拽item1，使其open；同时另外一个手指拖拽item2，使其open
也就是多点触控，将move消息交给item来处理，就是说由item来处理拖拽，item自己慢 慢划开。当action_pointer_down产生时，注意该消息是针对RecyclerView的，而不是item。 所以，这个消息不会传给item1处理，它对item2来讲是action_down。所以，如果将拖拽交给 item自己处理，就无法处理RecyclerView的多点触控问题。只能够将拖拽放在listener部分。
结论：event处理的先后顺序是listener、parent、item，而且，move等消息放在listener部分。
3、手指按下，慢慢想下滑，直达RecyclerView被拖动，然后左滑
正确的情况肯定是RecyclerView被拖动以后，后续的move都交给parent来处理。但是前述结论是listener先于parent处理move，listener先判断是否是左滑，结果不是，然后交给parent判断是否是上下拖拽。listener怎么知道parent的判断结果呢？
针对场景3，产生的问题进行分析，即listener怎么知道parent有没有被拖动？这个问题很关键，因为由前述知道listener先处理event，如果是上下拖动，listener就不需要在后续对move消息进行处理。
通常判断是否拖动的做法是根据拖动的距离与touchSlop进行比较，即此处即为yDiff>touchSlop，认定parent被拖动。然后listener就让parent处理后续的move，这样就不会冲突。更好一点的方法是根据parent的onInterceptTouchEvent结果来判断，如果返回true，就被认定为上下拖拽。
但是这个方法在ListView里面就很有问题。具体原因在于，ListView不像RecyclerView那样不处理item click与long click。就因为ListView将click部分自己来处理，就会导致onInterceptTouchEvent()返回一直为false。因为onInterceptTouchEvent()只有在mTouchMode为TOUCH_MODE_DOWN时才判断是否产生拖拽，其余情况下直接返回false。ListView的CheckForTap会将TOUCH_MODE_DOWN变为TOUCH_MODE_DONE_WAITING。ListView的onTouchEvent会导致CheckForTap，通过onTouchEvent无法判断ListView是否将move判定为上下拖拽，因为它总是返回true。确实比较乱，好久才找到原因。
总之，最后决定根据diff与touchSlop来判断是否产生拖拽。具体为listener先根据xDiff>mTouchSlop&& xDiff>yDiff，判断是否属于左滑；然后，根据yDiff>mTouchSlop判断是否是上下滑动。如果是上下滑动，就将后续event交给parent处理。
4、item处于open，此时点击该item，如果是删除等按钮，正常调用callback，但是点击item的main部分，应该将item close，并且没有任何点击效果出现，就像QQ那样。
前述将item的拖拽等放在了listener部分，这里将这些特殊的click放在item内部实现，更方便。
