天天看點
傳回

BaseRecyclerViewAdapterHelper開源項目之BaseSectionQuickAdapter 實作分組效果的源碼學習

version:2.8.5 

更多分享請看：http://cherylgood.cn

今天我們來學習下BaseRecyclerViewAdapterHelpler開源項目中是如何實作分組想過的。

首先今天的學習我們還是按照前面的學習思路，根據getItemViewType->onCreateDefViewHolder->onBindViewHolder，即從确認viewholder類型->根據類型值建立viewholder->根據資料源類型綁定資料到viewholder上。

第一步：我們看一下BaseSectionQuickAdapter這個類的定義

跟前面分析的多類型BaseMultiItemQuickAdapter差不多，隻是我們的資料源需要繼承自SetionEntity。那麼這個SetionEntity做了什麼事呢，我們來看下源碼：

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為什麼又定義成接口類型呢，

public interface MultiItemEntity {

    int getItemType();

}

根據實際需求而定，因為我們在實作多類型時，隻需要使用者的資料源提供一個類型值給我們即可，是以此時定義成接口類是最為合适的，因為使用者資料源隻要實作了該接口，他必須實作接口的方法，而我們需要的恰恰是在使用時調用該接口即可。

但是在SetionEntity中，我們幫使用者多做點事，為其提供兩個構造方法，一個時分組頭，一個是分組體。而此時如果是定義成接口類，是不符合需求的，因為接口類的方法不能有方法體等。

SectionEntity代碼分析：從源碼可以看出，假如我們目前資料是分組頭，那麼我們在建立bean時使用

public SectionEntity(boolean isHeader, String header) {
        this.isHeader = isHeader;
        this.header = header;
        this.t = null;
    }

即可，目前定義分組頭隻有個string類型的分組頭名字，你在繼承時可以根據實際需求進行擴充，内部調用父類的該構造方法即可。

如果時普通的資料bean：調用以下構造方法即可，當然你也可以進行擴充，根據個人需求而定。

public SectionEntity(T t) {
        this.isHeader = false;
        this.header = null;
        this.t = t;
    }

看完了SectionEntity。我們來看BaseSectionQuickAdapter的源碼：

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是一樣的思路。

字段解析：

mSectionHeadResId用來儲存我們分組頭的布局資源ids；

定義了一個預設的分組頭類型。思想與實作多類型一緻；

我們在執行個體化BaseSectionQuickAdapter時需要多傳遞一個分組頭的資源ids過來，是以構造方法是這樣的：

/**
     * 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方法。

重寫該方法所做的事不多：

@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方法。

@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、增加一個分組頭資料綁定的抽象方法的調用；

@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，從字面上了解是設定充滿空間，我們來看下代碼：

/**
     * 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。

最後會調用一個方法

繼續看該方法源碼：

/**
         * 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時，會多出一個資料綁定的回調接口：

可能你還會看到以下代碼：

裡面有一句holder.getLayoutPosition()。

getLayoutPosition是幹什麼用的呢，因為RecyclerView的item的布局和渲染其實是交給layoutManager來完成的，是以adapter中的item的位置可能跟data的index比對不上，而getLayoutPosition将傳回給我們目前viewholder在recyclerView中的最新位置資訊。

總結：分析思路還是老套路，根據一個元件的生命周期及業務流程進行分析，掌握一個控件的執行流程是了解一個控件的實作的一個較好的方法，本人是這麼認為的，也是這麼做的，大家有更好的學習方法可以多多留言，多多交流，沒有最好，隻有更好！以上即為本次的代碼學習，希望對大家有幫助。後面會繼續分析其他功能的源碼，歡迎一起學習！

android BaseRecyclerViewAdap 開源項目
上一篇: BaseRecyclerViewAdapterHelper之BaseQuickAdapter的基礎用法
下一篇: 開源架構BaseRecyclerViewAdapterHelper

繼續閱讀