version:2.8.5
更多分享请看：http://catbro.cn
今天我们来学习下BaseRecyclerViewAdapterHelpler开源项目中是如何实现分组想过的。
首先今天的学习我们还是按照前面的学习思路，根据getItemViewType->onCreateDefViewHolder->onBindViewHolder，即从确认viewholder类型->根据类型值创建viewholder->根据数据源类型绑定数据到viewholder上。
第一步：我们看一下BaseSectionQuickAdapter这个类的定义
1
|
public abstract class BaseSectionQuickAdapter extends BaseQuickAdapter<T, K> {
|
跟前面分析的多类型BaseMultiItemQuickAdapter差不多，只是我们的数据源需要继承自SetionEntity。那么这个SetionEntity做了什么事呢，我们来看下源码：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
|
package com.chad.library.adapter.base.entity;
/**
* https://github.com/CymChad/BaseRecyclerViewAdapterHelper
*/
public abstract class SectionEntity {
public boolean isHeader;
public T t;
public String header;
public SectionEntity(boolean isHeader, String header) {
this.isHeader = isHeader;
this.header = header;
this.t = null;
}
public SectionEntity(T t) {
this.isHeader = false;
this.header = null;
this.t = t;
}
}
|
从源码可以看出，他是一个抽象类,可能你会问，为什么要定义成抽象类呢，为什么不定义成接口或者普通类呢。
以下理由仅由我意想得出，大家也可以发表下自己的看法：
1、我们定义SectionEntity这个类，目的自然是希望用户的bean都具有某些规范，而我们的BaseSectionQuickAdapter将根据该规范进行数据的处理。虽然使用普通类一样能达到相同的效果，但是不推荐，我觉得这让有可能会让用户忽略我们所需要让用户知道的规范。
2、接口类，接口类其实是特殊的抽象类，上次分析的MultiItemEntity为什么又定义成接口类型呢，
1
2
3
4
5
|
public interface MultiItemEntity {
int getItemType();
}
|
根据实际需求而定，因为我们在实现多类型时，只需要用户的数据源提供一个类型值给我们即可，所以此时定义成接口类是最为合适的，因为用户数据源只要实现了该接口，他必须实现接口的方法，而我们需要的恰恰是在使用时调用该接口即可。
但是在SetionEntity中，我们帮用户多做点事，为其提供两个构造方法，一个时分组头，一个是分组体。而此时如果是定义成接口类，是不符合需求的，因为接口类的方法不能有方法体等。
SectionEntity代码分析：从源码可以看出，假如我们当前数据是分组头，那么我们在创建bean时使用
1
2
3
4
5
|
public SectionEntity(boolean isHeader, String header) {
this.isHeader = isHeader;
this.header = header;
this.t = null;
}
|
即可，当前定义分组头只有个string类型的分组头名字，你在继承时可以根据实际需求进行扩展，内部调用父类的该构造方法即可。
如果时普通的数据bean：调用以下构造方法即可，当然你也可以进行扩展，根据个人需求而定。
1
2
3
4
5
|
public SectionEntity(T t) {
this.isHeader = false;
this.header = null;
this.t = t;
}
|
看完了SectionEntity。我们来看BaseSectionQuickAdapter的源码：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
|
package com.chad.library.adapter.base;
import android.view.ViewGroup;
import com.chad.library.adapter.base.entity.SectionEntity;
import java.util.List;
/**
* https://github.com/CymChad/BaseRecyclerViewAdapterHelper
*/
public abstract class BaseSectionQuickAdapter extends BaseQuickAdapter<T, K> {
protected int mSectionHeadResId;
protected static final int SECTION_HEADER_VIEW = 0x00000444;
/**
* Same as QuickAdapter#QuickAdapter(Context,int) but with
* some initialization data.
*
* @param sectionHeadResId The section head layout id for each item
* @param layoutResId The layout resource id of each item.
* @param data A new list is created out of this one to avoid mutable list
*/
public BaseSectionQuickAdapter( int layoutResId, int sectionHeadResId, List data) {
super(layoutResId, data);
this.mSectionHeadResId = sectionHeadResId;
}
@Override
protected int getDefItemViewType(int position) {
return mData.get(position).isHeader ? SECTION_HEADER_VIEW : 0;
}
@Override
protected K onCreateDefViewHolder(ViewGroup parent, int viewType) {
if (viewType == SECTION_HEADER_VIEW)
return createBaseViewHolder(getItemView(mSectionHeadResId, parent));
return super.onCreateDefViewHolder(parent, viewType);
}
@Override
public void onBindViewHolder(K holder, int positions) {
switch (holder.getItemViewType()) {
case SECTION_HEADER_VIEW:
setFullSpan(holder);
convertHead(holder, mData.get(holder.getLayoutPosition() - getHeaderLayoutCount()));
break;
default:
super.onBindViewHolder(holder, positions);
break;
}
}
protected abstract void convertHead(BaseViewHolder helper, T item);
}
|
大家可以看到，源码比较少，跟BaseMultiItemQuickAdapter是一样的思路。
字段解析：
1
|
protected int mSectionHeadResId;
|
mSectionHeadResId用来保存我们分组头的布局资源ids；
1
|
protected static final int SECTION_HEADER_VIEW = 0x00000444;
|
定义了一个默认的分组头类型。思想与实现多类型一致；
我们在实例化BaseSectionQuickAdapter时需要多传递一个分组头的资源ids过来，所以构造方法是这样的：
1
2
3
4
5
6
7
8
9
10
11
12
|
/**
* Same as QuickAdapter#QuickAdapter(Context,int) but with
* some initialization data.
*
* @param sectionHeadResId The section head layout id for each item
* @param layoutResId The layout resource id of each item.
* @param data A new list is created out of this one to avoid mutable list
*/
public BaseSectionQuickAdapter( int layoutResId, int sectionHeadResId, List data) {
super(layoutResId, data);
this.mSectionHeadResId = sectionHeadResId;
}
|
构造好之后，我们也是利用来adapter的生命周期方法：
1、重写getDefItemViewType方法，前面也解释过为什么不是重写Recycler.adapter的getItemViewType方法，以为我们的BaseQuickAdapter对其进行来包装。最终在getItemViewType方法中会调用我们的getDefItemViewType方法。
重写该方法所做的事不多：
1
2
3
4
|
@Override
protected int getDefItemViewType(int position) {
return mData.get(position).isHeader ? SECTION_HEADER_VIEW : 0;
}
|
根据我们当前位置的数据bean，判断当前节点的数据bean是不是分组头bean，如果是，返回SECTION_HEADER_VIEW告诉BaseQuickAdapter，你要创建的viewholder是分组头类型的viewholder。否则返回0（0时RecyclerView.Adapter的缺省值，前面有分析）
接下来，我们也同样是重写了onCreateDefViewHolder方法。
1
2
3
4
5
6
7
|
@Override
protected K onCreateDefViewHolder(ViewGroup parent, int viewType) {
if (viewType == SECTION_HEADER_VIEW)
return createBaseViewHolder(getItemView(mSectionHeadResId, parent));
return super.onCreateDefViewHolder(parent, viewType);
}
|
根据返回的类型值，如果是SECTION_HEADER_VIEW 那么我们就创建一个分组头viewholder返回。否则调用父类的方法按原流程走。
在这里我们还需要重写onBindViewHolder方法，因为我们要多做两件事情：
1、对我们的分组头进行特殊处理；
2、增加一个分组头数据绑定的抽象方法的调用；
1
2
3
4
5
6
7
8
9
10
11
12
|
@Override
public void onBindViewHolder(K holder, int positions) {
switch (holder.getItemViewType()) {
case SECTION_HEADER_VIEW:
setFullSpan(holder);
convertHead(holder, mData.get(holder.getLayoutPosition() - getHeaderLayoutCount()));
break;
default:
super.onBindViewHolder(holder, positions);
break;
}
}
|
里面有个很有趣的方法。setFullSpan，从字面上理解是设置充满空间，我们来看下代码：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
/**
* When set to true, the item will layout using all span area. That means, if orientation
* is vertical, the view will have full width; if orientation is horizontal, the view will
* have full height.
* if the hold view use StaggeredGridLayoutManager they should using all span area
*
* @param holder True if this item should traverse all spans.
*/
protected void setFullSpan(RecyclerView.ViewHolder holder) {
if (holder.itemView.getLayoutParams() instanceof StaggeredGridLayoutManager.LayoutParams) {
StaggeredGridLayoutManager.LayoutParams params = (StaggeredGridLayoutManager.LayoutParams) holder
.itemView.getLayoutParams();
params.setFullSpan(true);
}
}
|
里面原来是对Layoutmanager为StaggeredGridLayoutManager类型时做特殊处理，大家可以去了解下StaggeredGridLayoutManager这种类型的LayoutManager。
最后会调用一个方法
1
|
params.setFullSpan(true);
|
继续看该方法源码：
1
2
3
4
5
6
7
8
9
10
11
|
/**
* When set to true, the item will layout using all span area. That means, if orientation
* is vertical, the view will have full width; if orientation is horizontal, the view will
* have full height.
*
* @param fullSpan True if this item should traverse all spans.
* @see #isFullSpan()
*/
public void setFullSpan(boolean fullSpan) {
mFullSpan = fullSpan;
}
|
该方法是StaggeredGridLayoutManager提供的，英文说明的大意是：
如果你设置true，当前item将使用布局的所有空间。如果是垂直的，会沾满水平方向的宽度空间，如果是水平，会占满垂直方向的高度空间。
然后将holder和当前节点的数据bean作为参数调用convertHead函数。
所以当你实现的是帶分组头的adapter时，会多出一个数据绑定的回调接口：
1
|
protected abstract void convertHead(BaseViewHolder helper, T item);
|
可能你还会看到以下代码：
1
|
convertHead(holder, mData.get(holder.getLayoutPosition() - getHeaderLayoutCount()));
|
里面有一句holder.getLayoutPosition()。
getLayoutPosition是干什么用的呢，因为RecyclerView的item的布局和渲染其实是交给layoutManager来完成的，所以adapter中的item的位置可能跟data的index匹配不上，而getLayoutPosition将返回给我们当前viewholder在recyclerView中的最新位置信息。
总结：分析思路还是老套路，根据一个组件的生命周期及业务流程进行分析，掌握一个控件的执行流程是理解一个控件的实现的一个较好的方法，本人是这么认为的，也是这么做的，大家有更好的学习方法可以多多留言，多多交流，没有最好，只有更好！以上即为本次的代码学习，希望对大家有帮助。后面会继续分析其他功能的源码，欢迎一起学习！