有一定经验的Android开发者应该都遇到过类似的需求,看图
简单来说就是外层一个ScrollView,在内部又需要一个ListView来展示数据,在滑动时ListView上部的控件需要先收起来。
现在为了达到这种效果,主流是两种做法:
1.编写一个UnscrollListView,即不可滑动的ListView,然后将其嵌套在ScrollView中,这样就避免了滑动冲突的问题了。但是这样ListView的缓存优势就没了,需要将Adapter中的item全部绘制出来,对内存的影响是不可忽视的。
2.采用CoordinatorLayout相关的布局和控件,这个是Google推出的Design包里的东西,确实很好用,功能非常强大,而且对传统的控件几乎是一种颠覆,具体就不详细说了,但是也有一些限制,比如ListView必须要实现NestedScrollingChild接口,当然可以直接采用RecyclerView来代替。不过如果是在旧页面中修改的话,这工作量是挺大的,而且还需要额外引入各种Support包,导致apk体积变大。
如果是新界面或者新应用,建议直接采用CoordinatorLayout,以后就再也不怕UI给你提样式需求了。
所以,博主决定以身犯险,来探一探究竟能不能把方案1给优化一下。。。
1.初定方案
首先,我们的需求是在方案1的基础上做一些优化,最好是不需要改动ListView,将冲突在ScrollView中解决掉。因为ListView我们用得很多,也经常需要对它进行一些改动,ScrollView相对来说会稳定很多,基本就是充当一个容器的作用。
所以,我们决定修改ScrollView来解决冲突的问题。
在这里先简单说下滑动冲突的解决方案,一般来说可以分为外部解决和内部解决两种方式。
外部解决,就是说在Parent中处理冲突,即重写父View的onInterceptTouchEvent方法,该方法就是判断父View是否需要拦截Event传递,我们的任务就是编写代码来设定什么时候要拦截,什么时候不拦截。
内部解决,是在child中去处理冲突,这个一般会在子View的onTouchEvent方法中去处理,因为ViewGroup有一个叫做requestDisallowInterceptTouchEvent的方法,可以设置父View是否拦截事件。
那结合我们上面的分析,我们就选择外部解决方案了。
2.处理滑动冲突
首先,需要新建一个ModifierScrollView,继承自ScrollView,然后重写onInterceptTouchEvent方法。
代码如下
@Override
public boolean onInterceptTouchEvent(MotionEvent ev) {
super.onInterceptTouchEvent(ev);