ExtraViewWrapperAdapter--添加额外头部尾部功能的装饰adapter
2016-07-11 16:58
344 查看
目录
目录概述
关于头部和尾部
分离原始数据及装饰数据
headerView与footerView的创建与显示
使用唯一的标签
关于headerView与FooterView位置的计算
头部尾部的判断方式
与HeaderRecycleAdapter的接口相关
其它
使用方式
GitHub地址
示例图片
概述
对于ListView有自带的方法添加headerView及footerView,但是
RecycleView仅仅只是维护缓存的View,本身并不处理内容显示,都交给了
RecycleView.Adapter处理,所以如果想要让
RecycleView也可以添加headerView和footerView的话,只有两种方式
是重写
RecycleView
是通过Adapter的方式去解决这个问题,将headerView及footerView转换成内部数据的形式显示出来.
针对这个问题,这里使用第二种方式,扩展了Adapter,通过装饰者模式,只需要将自己的Adatper包括进外层的Adapter中,即可直接添加headerView及footerView,同时不会对原有的数据造成任何影响.
这里需要注意的是,此处的
ExtroViewWrapperAdaper包装类是通用的,但是更针对于
HeaderRecycleAdatper,包括实现了
HeaderRecycleAdapter相关的一些接口用于扩展.
对于普通的Adapter,也是可以直接使用.
关于头部和尾部
由于通过Adapter来完成头部与尾部的功能添加(这样做的好处是在任何的RecycleView上都是可以使用的),所以实现方式上跟普通的多类型item的Adapter的实现方式是一致的,这里不再强调.主要说明如何进行装饰.
分离原始数据及装饰数据
对于Adapter,由于每个Adapter完成的功能都不同,所以我们只能不能知道Adapter是具体如何完成的,那么我们需要尽量将原始的数据与装饰的数据(头部/尾部)分离开来.ExtraViewWrapperAdapter主要就是要处理这个.
首先是保存原有Adapter的引用.对于头部和尾部一般是只添加一个,但这里考虑到可能会添加多个,所以是允许添加多个的.
对于添加多个的情况,每一个headerView都可能不同,这时就需要提供每一个headerView的一个viewTag(标志),这个标志是唯一的,用于分辨不同的headerView的类型以显示出来.
对此使用一个内部类来管理添加的headerView或者footerView.
/** * 头部/尾部添加额外View的缓存处理类 */ public static class HeaderFooterViewCache { private List<Map.Entry<Integer, View>> mViewCacheMap; private Map<Integer, Integer> mIndexMap; public HeaderFooterViewCache() { mViewCacheMap = new LinkedList<Map.Entry<Integer, View>>(); mIndexMap = new ArrayMap<Integer, Integer>(); } //返回当前保存的View的个数 public int size(); //根据位置获取对应的标签 public int getViewViewTag(int position); //根据标签获取对应的view public View getView(int viewTag); //检测是否已经存在某个标签 public boolean isContainsView(int viewTag); //添加新view及其唯一标签,当该标签已经存在某个view时,将替换该view,返回被替换的view,或者是null;若view为null,返回null,添加失败 public View addView(int viewTag, View view); //移除某个标签对应的view public boolean removeView(int viewTag); //清除所有的view public void clearAllView(); //获取view的标签列表,标签应该是唯一的 public Set<Integer> getViewTags(); }
这里仅给出部分方法签名及其作用说明.具体实现暂不给出.这里缓存时使用两个不同的数据结构,一个是List,一个是Map,原因是List用来保存添加的view的顺序,Map是用于根据标签匹配并保存添加的view.
headerView与footerView的创建与显示
Adapter是自己加载layout并创建view的,但是headerView与footerView是不同的,是直接添加的view并不通过adapter加载与绑定数据.所以在这里使用的ViewHolder也只是一个临时保存的容器而已.
在
onCreateViewHolder()中创建headerView与footerView的holder
@Override public RecyclerView.ViewHolder onCreateViewHolder(ViewGroup parent, int viewType) { return new ExtraViewHolder(mHeaderCache.getView(viewType)); }
ExtraViewHolder类的实现仅仅是继承
RecycleView.ViewHolder而已,并没有任何其它的操作.这里只是为了配合Adapter的实现方式.
headerView与footerView的创建完全由外部处理,Adapter并不作任何处理(仅仅是缓存并显示而已),view的获取是通过缓存的
HeaderFooterViewCache类通过唯一的viewTag(标签)进行获取的.
使用唯一的标签
由以上可知,headerView与FooterView是被HeaderFooterViewCache缓存的,并且使用唯一的viewTag进行标识.
使用Map的原因是标签必须是唯一的,一个标签也只能用于一个view,这样在Adapter加载view时才不会导致有关viewType问题.
以下为Adapter需要实现的一些方法.
//根据位置获取view的类型 public int getItemViewType(int position){ //这里仅给出headerView位置的代码,其它位置代码忽略 return mHeaderCache.getViewViewTag(position); } //根据view的类型加载view public RecyclerView.ViewHolder onCreateViewHolder(ViewGroup parent, int viewType){ //这里仅给出headerView的holder创建 return new ExtraViewHolder(mHeaderCache.getView(viewType)); }
Map中的唯一的viewTag标签就是用于此处的viewType,由于加载holder是通过viewType来创建的,所以不同的viewTag代表了不同的viewType,也是代表了不同的view.
通过这种方式处理的原因是,headerView与footerView是在创建
ExtraViewHolder时需要使用的,而创建一个holder只会在
onCreateViewHolder()中进行创建.此时参数来源仅有两个:
parent,父容器
viewType,item类型
这两个参数显然仅有第二个参数可以使用.由于headerView和FooterView理论上也不会有很多,因此可以通过指定唯一的viewTag匹配对应的view,同时将viewTag传递到
onCreateViewHolder()就可以获取到该tag对应的view了.
对此,在Adapter的
getItemViewType()方法中返回的viewType实际上也就是view所对应的viewTag.这样在一定程度上可以减少很多的计算与匹配工作.
关于headerView与FooterView位置的计算
RecycleView很重要的一个特点是根据position进行显示item.由于添加了headerView与FooterView,所以原始Adapter中position相对于原来的位置必定会改变.
这里需要计算headerView与FooterView的数量.关于这部分在前面给出的缓存类
HeaderFooterViewCache中已经有相关的方法了,所以可以通过该方法直接获取其对应的数量.
private int getHeaderViewCount() { return mHeaderCache.size(); }
这里需要注意,headerView是通过mHeaderCache缓存管理的,footerView是通过mFooterCache缓存管理的,并不是同一个类管理两种view.
得到headerView或者footerView的数量后,就可以很方便地计算了.headerView必定在InnerAdapter的item之前,所以position对应的前面都是headerView.
//headerView的position int headerPosition=position; //innerAdapter中item的position,除去header部分 int innerPosition=position-headerViewCount; //footerView的position,除去header及innerAdapter的item数量 int footerPosition=position-headerViewCount-innerAdapter.getItemCount();
ExtraViewWrapperAdapter提供了获取内部adapter的位置的方法,该方法就是基于以上的方式进行计算得到的.
//这里的wrapAdapterPosition指 ExtraViewWrapperAdapter 对应的position public int getInnerAdapterPosition(int wrapAdapterPosition) { int headerViewCount = getHeaderViewCount(); int innerPosition = wrapAdapterPosition - headerViewCount; if (mInnerAdapter != null && innerPosition < mInnerAdapter.getItemCount()) { return innerPosition; } else { return -1; } }
头部尾部的判断方式
通过以上计算头部尾部的位置,我们是可以得到他们的判断方式的.因为判断头部尾部是给定一个position,判断其是否为头部或者尾部.//当position在前面的位置且位于headerViewCount的数量范围内,则说明当前位置为头部 private boolean isHeaderView(int position) { //计算头部view结束的位置 int headerEndPosition = getHeaderViewCount(); return position >= 0 && position < headerEndPosition; }
尾部的计算方式也是相同的.都是计算当前位置是否在指定的view类型范围内即可.
与HeaderRecycleAdapter
的接口相关
由于ExtraViewWrapperAdapter是为了兼容
HeaderRecycleAdapter,所以实现了与其相同的一些接口,包括:
IStickerHeaderDecoration,用于显示固定头部
ISpanSizeHandler,用于兼容显示GridLayout的布局方式
由于innerAdapter有自己的接口实现,wrapperAdapter并不能代替其实现的功能,所以只能是通过保存对应的接口实现,并在实现这些接口时(与position有关的方法中)屏蔽headerView及footerView的部分,有关innerAdapter的item部分由其对应的接口自行处理.
大致类似以下的处理方式,此处与两个接口有关,需要了解的请查看
HeaderRecycleAdapter及
StickHeaderItemDecoration两个类的分析文章.
//如 IStickerHeaderDecoration 接口中,判断当前position的item是否有固定头部时 @Override public boolean hasStickHeader(int position) { //当前位置的item为headerView或者footerView,都不存在固定头部 if (isHeaderView(position) || isFooterView(position)) { return false; } else if (mIStickHeaderDecoration != null) { //若不是,则说明当前位置应该是innerAdapter中的item,计算innerAdapter中对应的位置并回调其相关的接口处理 return mIStickHeaderDecoration.hasStickHeader(getInnerAdapterPosition(position)); } else { return false; } }
这里涉及到了原innerAdapter相关的一些接口问题.由于
HeaderRecycleAdapter是已经实现了相关的接口,所以可以在保存adapter时保存其实现接口的引用.
public void setInnerAdapter(@NonNull RecyclerView.Adapter innerAdapter) { mInnerAdapter = innerAdapter; //当前adapter实现了 IStickerHeaderDecoration接口,则保存其接口引用 if (mInnerAdapter != null && mInnerAdapter instanceof StickHeaderItemDecoration.IStickerHeaderDecoration) { mIStickHeaderDecoration = (StickHeaderItemDecoration.IStickerHeaderDecoration) mInnerAdapter; } //当前adapter实现了 ISpanSizeHandler接口,则保存其接口引用 if (mInnerAdapter != null && mInnerAdapter instanceof HeaderSpanSizeLookup.ISpanSizeHandler) { mISpanSizeLookup = (HeaderSpanSizeLookup.ISpanSizeHandler) mInnerAdapter; } }
通过直接判断adatper是否实现了对应接口直接保存引用,可以更准确地绑定innerAdapter及其相关接口的实现.同时,也存在相关的接口直接设置方法手动绑定当前innerAdapter的实现接口.
其它
ExtraViewWrapperAdapter大致实现的原理如上,主要是为了增加headerView及footerView的添加功能,同时又能兼容原有innerAdapter的功能(主要指
HeaderRecycleAdapter).
同时提供了添加多个headerView及footerView的功能,并额外添加了refreshView(刷新View)及loadView(加载View)分别在顶部及底部显示,默认为null不存在.
//设置刷新显示的view mExtraAdapter.setRefreshingHeaderView(yourRefreshView); //切换刷新/加载/header/footer显示的状态 ExtraViewWrapAdapter.setRefreshingViewStatus(true,true,rv);
使用方式
使用方式很简单,需要添加headerView或者footerView时,直接进行添加,然后设置原始数据innerAdatper,如果是实现了ISpanSizeHandler及
IStcikerHeaderDecoration接口的adapter则不需要作额外处理,否则需要考虑一下是否要设置相关的接口实现.
//设置innearAdapter mExtraAdapter = new ExtraViewWrapAdapter(mNormalAdapter); //添加headerView mExtraAdapter.addHeaderView(R.id.header_view, yourView); //使用extraViewWrapperAdapter代码原有的adapter作为recycleView的数据绑定 rv.setAdapter(mExtraAdapter);
GitHub地址
https://github.com/CrazyTaro/RecycleViewAdapter与之前的RecycleView相关的都置于同一个项目中
示例图片
相关文章推荐
- 使用C++实现JNI接口需要注意的事项
- Android IPC进程间通讯机制
- Android Manifest 用法
- [转载]Activity中ConfigChanges属性的用法
- Android之获取手机上的图片和视频缩略图thumbnails
- Android之使用Http协议实现文件上传功能
- Android学习笔记(二九):嵌入浏览器
- android string.xml文件中的整型和string型代替
- i-jetty环境搭配与编译
- android之定时器AlarmManager
- android wifi 无线调试
- Android Native 绘图方法
- Android java 与 javascript互访(相互调用)的方法例子
- android 代码实现控件之间的间距
- android FragmentPagerAdapter的“标准”配置
- Android"解决"onTouch和onClick的冲突问题
- android:installLocation简析
- android searchView的关闭事件
- SourceProvider.getJniDirectories