1. 程式人生 > >IM多類型holder封裝

IM多類型holder封裝

target 分享圖片 抽象 自己 適合 頭像 代碼 圖片 eat

如標題,這是一個在列表多類型視圖時的一個簡化封裝方法,減少多余代碼,提高復用性,更好叠代擴展,先看視圖列表效果圖

GitHub:https://github.com/1024477951/FragmentApp

技術分享圖片

咋一看感覺就是一個普通的列表,但是要講的也不是效果,可以看到一般im列表頁類型畢竟多,代碼邏輯較復雜,如果沒有好好的復用封裝後面冗余過多,擴展麻煩

最普通的寫法應該是直接在適配器的bind方法裏根據返回的類型,然後switch,碼不同的邏輯,因為每個類型的樣式都不同,而且邏輯也不一樣,所以在沒有什麽思路的情況下最容易的一種做法

當然,很多人都會想到這樣不好,要封裝一波,抽象成base,避免switch繁瑣的操作,然後在bind裏通過base類調用,達到復用的操作,我也覺得這樣挺好的,不過後來發現還是可以進一步的優化,而且這樣還能在原來的基礎上更好的達到復用的效果,

因為這樣一來就相當於把邏輯都放在了viewholder裏面,這樣也就導致了viewholder裏面會有很多重復的操作,比如設置頭像,變換消息狀態等,這樣一來是不是覺得還有優化的余地呢,因為基本上每個類型都少不了頭像和狀態,而且一般樣式都是統一的,

所以這就讓我生出一個優化的方法來了,把這些共同的地方抽出來當作base,裏面的內容視圖動態的填充進去,而且如果不想這樣或者想完全改變類型的樣式也能通過動態設置來解決,達到一個很好擴展的效果

實現思路:

  首先寫base xml,把頭像狀態一些通用的寫進去,然後在 createholder 給內容填充處一個容器視圖,創建具體的 holder,這一步操作大致跟通常的創建沒有什麽大區別,區別在於給視圖容器填充了內容視圖,以往的都是一整個xml直接加載,現在分為了base和內容。

  接下來是封裝 baseholder,這樣就可以把一些通用的方法操作邏輯寫進去,直接在bind裏調用,就算沒用填充的操作,其實也能直接在base裏封裝,只是這樣的話你在xml裏就顯的麻煩了,因為假如你的xml樣式需要修改一下,那麽你每個xml都要去修改

  baseholder寫好了,對繼承類提供抽象方法,這樣可以避免bind的時候轉換類型操作,直接通過base方法對每個不同的類型自定義邏輯

技術分享圖片

技術分享圖片

技術分享圖片

這樣一來無論是xml還是holder,還是adapter,都是很方便的修改擴展,比如你修改xml裏的一個狀態圖標,只需要在base xml裏修改一下就行了,邏輯都不用動,需要修改狀態邏輯也只需要在baseholder裏面修改一下就行了,每個類型的holder都通用,而差異化的邏輯一般只會在自定義的對應holder裏面改下就行了,擴展內容也是根據自己的需求在base或者child裏面編寫代碼,有沒有感覺很是適合IM類型適配器,會話列表

GitHub:https://github.com/1024477951/FragmentApp

  

IM多類型holder封裝