資訊專(zhuān)欄INFORMATION COLUMN
摘要：，無(wú)法復(fù)用，假如有多個(gè)頁(yè)面有多個(gè)，那么就要寫(xiě)多個(gè)。綁定，主要作用是綁定數(shù)據(jù)到正確的視圖上?？删S護(hù)性不同的列表類(lèi)型由添加處理，哪怕添加多個(gè)，相互之間互不干擾，代碼簡(jiǎn)潔，維護(hù)成本低。
目錄介紹
01.先看看實(shí)際需求
02.adapter實(shí)現(xiàn)多個(gè)type
03.這樣寫(xiě)的弊端
04.如何優(yōu)雅實(shí)現(xiàn)adapter封裝
好消息博客筆記大匯總【16年3月到至今】，包括Java基礎(chǔ)及深入知識(shí)點(diǎn)，Android技術(shù)博客，Python學(xué)習(xí)筆記等等，還包括平時(shí)開(kāi)發(fā)中遇到的bug匯總，當(dāng)然也在工作之余收集了大量的面試題，長(zhǎng)期更新維護(hù)并且修正，持續(xù)完善……開(kāi)源的文件是markdown格式的！同時(shí)也開(kāi)源了生活博客，從12年起，積累共計(jì)N篇[近100萬(wàn)字，陸續(xù)搬到網(wǎng)上]，轉(zhuǎn)載請(qǐng)注明出處，謝謝！
鏈接地址：https://github.com/yangchong2...
如果覺(jué)得好，可以star一下，謝謝！當(dāng)然也歡迎提出建議，萬(wàn)事起于忽微，量變引起質(zhì)變！
01.先看看實(shí)際需求比如一個(gè)APP的首頁(yè)，包含Banner區(qū)、廣告區(qū)、文本內(nèi)容、圖片內(nèi)容、新聞內(nèi)容等等。
RecyclerView 可以用ViewType來(lái)區(qū)分不同的item,也可以滿足需求，但還是存在一些問(wèn)題，比如：
1，在item過(guò)多邏輯復(fù)雜列表界面，Adapter里面的代碼量龐大，邏輯復(fù)雜，后期難以維護(hù)。
2，每次增加一個(gè)列表都需要增加一個(gè)Adapter，重復(fù)搬磚，效率低下。
3，無(wú)法復(fù)用adapter，假如有多個(gè)頁(yè)面有多個(gè)type，那么就要寫(xiě)多個(gè)adapter。
4，要是有局部刷新，那么就比較麻煩了，比如廣告區(qū)也是一個(gè)九宮格的RecyclerView，點(diǎn)擊局部刷新當(dāng)前數(shù)據(jù)，比較麻煩。
02.adapter實(shí)現(xiàn)多個(gè)type
通常寫(xiě)一個(gè)多Item列表的方法
根據(jù)不同的ViewType 處理不同的item，如果邏輯復(fù)雜，這個(gè)類(lèi)的代碼量是很龐大的。如果版本迭代添加新的需求，修改代碼很麻煩，后期維護(hù)困難。
主要操作步驟
在onCreateViewHolder中根據(jù)viewType參數(shù)，也就是getItemViewType的返回值來(lái)判斷需要?jiǎng)?chuàng)建的ViewHolder類(lèi)型
在onBindViewHolder方法中對(duì)ViewHolder的具體類(lèi)型進(jìn)行判斷，分別為不同類(lèi)型的ViewHolder進(jìn)行綁定數(shù)據(jù)與邏輯處理
代碼如下所示
public class HomePageAdapter extends RecyclerView.Adapter {
public static final int TYPE_BANNER = 0;
public static final int TYPE_AD = 1;
public static final int TYPE_TEXT = 2;
public static final int TYPE_IMAGE = 3;
public static final int TYPE_NEW = 4;
private List mData;
public void setData(List data) {
mData = data;
}
@Override
public RecyclerView.ViewHolder onCreateViewHolder(ViewGroup parent, int viewType) {
switch (viewType){
case TYPE_BANNER:
return new BannerViewHolder(LayoutInflater.from(parent.getContext()).inflate(R.layout.home_banner_layout,null));
case TYPE_AD:
return new BannerViewHolder(LayoutInflater.from(parent.getContext()).inflate(R.layout.home_ad_item_layout,null));
case TYPE_TEXT:
return new BannerViewHolder(LayoutInflater.from(parent.getContext()).inflate(R.layout.home_text_item_layout,null));
case TYPE_IMAGE:
return new BannerViewHolder(LayoutInflater.from(parent.getContext()).inflate(R.layout.home_image_item_layout,null));
case TYPE_NEW:
return new BannerViewHolder(LayoutInflater.from(parent.getContext()).inflate(R.layout.home_news_item_layout,null));
}
return null;
}
@Override
public void onBindViewHolder(RecyclerView.ViewHolder holder, int position) {
int type = getItemViewType(position);
switch (type){
case TYPE_BANNER:
// banner 邏輯處理
break;
case TYPE_AD:
// 廣告邏輯處理
break;
case TYPE_TEXT:
// 文本邏輯處理
break;
case TYPE_IMAGE:
//圖片邏輯處理
break;
case TYPE_NEW:
//視頻邏輯處理
break;
// ... 此處省去N行代碼
}
}
@Override
public int getItemViewType(int position) {
if(position == 0){
return TYPE_BANNER;//banner在開(kāi)頭
}else {
return mData.get(position).type;//type 的值為T(mén)YPE_AD，TYPE_IMAGE，TYPE_AD，等其中一個(gè)
}
}
@Override
public int getItemCount() {
return mData == null ? 0:mData.size();
}
public static class BannerViewHolder extends RecyclerView.ViewHolder{
public BannerViewHolder(View itemView) {
super(itemView);
//綁定控件
}
}
public static class NewViewHolder extends RecyclerView.ViewHolder{
public VideoViewHolder(View itemView) {
super(itemView);
//綁定控件
}
}
public static class AdViewHolder extends RecyclerView.ViewHolder{
public AdViewHolder(View itemView) {
super(itemView);
//綁定控件
}
}
public static class TextViewHolder extends RecyclerView.ViewHolder{
public TextViewHolder(View itemView) {
super(itemView);
//綁定控件
}
}
public static class ImageViewHolder extends RecyclerView.ViewHolder{
public ImageViewHolder(View itemView) {
super(itemView);
//綁定控件
}
}
}
03.這樣寫(xiě)的弊端
上面那樣寫(xiě)的弊端
類(lèi)型檢查與類(lèi)型轉(zhuǎn)型，由于在onCreateViewHolder根據(jù)不同類(lèi)型創(chuàng)建了不同的ViewHolder，所以在onBindViewHolder需要針對(duì)不同類(lèi)型的ViewHolder進(jìn)行數(shù)據(jù)綁定與邏輯處理，這導(dǎo)致需要通過(guò)instanceof對(duì)ViewHolder進(jìn)行類(lèi)型檢查與類(lèi)型轉(zhuǎn)型。
不利于擴(kuò)展，目前的需求是列表中存在5種布局類(lèi)類(lèi)型，那么如果需求變動(dòng)，極端一點(diǎn)的情況就是數(shù)據(jù)源是從服務(wù)器獲取的，數(shù)據(jù)中的model決定列表中的布局類(lèi)型。這種情況下，每當(dāng)model改變或model類(lèi)型增加，我們都要去改變adapter中很多的代碼，同時(shí)Adapter還必須知道特定的model在列表中的位置（position）除非跟服務(wù)端約定好，model（位置）不變，很顯然，這是不現(xiàn)實(shí)的。
不利于維護(hù)，這點(diǎn)應(yīng)該是上一點(diǎn)的延伸，隨著列表中布局類(lèi)型的增加與變更，getItemViewType、onCreateViewHolder、onBindViewHolder中的代碼都需要變更或增加，Adapter 中的代碼會(huì)變得臃腫與混亂，增加了代碼的維護(hù)成本。
04.如何優(yōu)雅實(shí)現(xiàn)adapter封裝
核心目的就是三個(gè)
避免類(lèi)的類(lèi)型檢查與類(lèi)型轉(zhuǎn)型
增強(qiáng)Adapter的擴(kuò)展性
增強(qiáng)Adapter的可維護(hù)性
當(dāng)列表中類(lèi)型增加或減少時(shí)Adapter中主要改動(dòng)的就是getItemViewType、onCreateViewHolder、onBindViewHolder這三個(gè)方法，因此，我們就從這三個(gè)方法中開(kāi)始著手。
既然可能存在多個(gè)type類(lèi)型的view，那么能不能把這些比如banner，廣告，文本，視頻，新聞等當(dāng)做一個(gè)HeaderView來(lái)操作。
在getItemViewType方法中。
減少if之類(lèi)的邏輯判斷簡(jiǎn)化代碼，可以簡(jiǎn)單粗暴的用hashCode作為增加type標(biāo)識(shí)。
通過(guò)創(chuàng)建列表的布局類(lèi)型，同時(shí)返回的不再是簡(jiǎn)單的布局類(lèi)型標(biāo)識(shí)，而是布局的hashCode值
