RecyclerView再封裝

 

RecyclerView作爲ListView的替代品，已經出了好久了，既然是替代品，那天然有些ListView沒有的優勢。好比說：能夠隨意切換list,grid,stagger。能夠指定一個或多個item刷新，而再也不是所有刷新。另外能夠爲每一個item添加動畫，在體驗上更進一步。

可是也有很多「缺點」

1. divider沒之前好畫了，實際上是由於divider支持多種樣式，方便本身定義了。之前divider就是一根線，如今能夠加margin，加多條線，某行不加divider等需求。ItemDecoration=>Item裝飾器，名副其實。
2. 沒有OnItemClickListener，RecyclerView的解耦方式太漂亮了，LayoutManager負責計算佈局，Adapter負責適配，Holder負責渲染Item，ItemDecoration負責items間隔，ItemAnimator負責item動畫，Recycler負責回收複用。RecyclerView就是個中控啊，只負責調度。因此它爲了避免破壞本身的解耦，就讓每一個item本身去實現點擊事件，萬一要Drag，Move，Swipe呢，對吧。
3. 阿西巴，沒有header footer，上述2中已經說過了。RecyclerView不愛幹實事兒，就負責調度，UI的事都是Adapter負責乾的啊。你給RecyclerView了它也不知道給你加到哪裏去。想實現，就去找Adapter吧。

關於API，以及RecyclerView的用法Stay就很少說了，網上都有。咱們來討論討論，如何將RecyclerView真正投入到項目中去。

咱們不肯意使用新東西，一是怕有bug，二是怕不知足需求，三是怕沒有現成的成熟的封裝類能夠用，不想本身寫。

github上有不少基於RecyclerView的封裝，Stay以爲還不夠完全。使用起來仍是不夠方便。特別是UltimateRecyclerView，根本不叫封裝，簡直就是堆代碼，看起來功能強大，實際上能用到10%的樣式就不錯了。請勿使用這種代碼，功能越多，改起來就更復雜啊。

Stay理想的封裝模式是這樣的：

1. 你們還記得ListActivity嘛，就是那個將ListView和Adapter定義在父類，讓子類去繼承的。如今RecyclerView支持List，Grid，Stagger，不作個BaseListActivity多惋惜，好多默認配置均可以放父類，最簡單的子類Activity只須要load數據以及bindHolder就完了。連Adapter都不用寫了。
2. 以SwipeRefreshLayout爲例，想要RecyclerView支持下拉刷新，加載更多，必然要將二者封裝到一塊兒，再建一個Controller類，這個Controller仍是負責調度，將SwipeRefreshLayout與RecyclerView的調度方法再寫一遍，外層只須要跟Controller溝通。
3. 想要實現加載更多，須要讓Adapter去負責，原生的Adapter不支持，那就須要再抽一個BaseListAdapter來擴展，itemType，itemCount，onCreateFooterViewHolder都由這個抽象類來filter，這樣子類就不須要管footer這事，只須要繼承BaseListAdapter，就自動支持加載更多。
4. 加載更多的footer有兩個坑，在stagger模式下，findLastVisiblePositions這返回的是數組,在list，grid模式下返回的是int，在將來可能會自定義LayoutManager，那可能又會發生變化，那麼就須要定義一個算法，而後不一樣的模式都實現它，這樣在Controller中只須要調這個算法，拿到值就搞定了。你能夠用策略模式來解決它。用策略模式，是不想在Controller中instanceOf與強轉，而且若是有自定義的LayoutManager，那之後就須要去改動Controller。
5. 加載更多另外一個坑就是，在grid和stagger模式下，footer要佔滿一行而不是一個span。因此grid須要SpanSizeLookup來動態改footer所佔的spanCount。而stagger呢，須要將viewholder中的itemView的LayoutParams中isFullSpan設置爲true。確實很麻煩，但你依然能夠用策略模式來解決它。
6. 假如要實現Section分組，那就再定義一個BaseSectionListActivity去繼承BaseListActivity，再作一次封裝與隔離。這樣子類只要繼承BaseSectionListActivity就擁有了一個支持分組，下拉刷新，加載更多的這樣一個控件。而且支持list，grid。

以上是Stay所想的封裝方式，沒有什麼高深的算法，只是簡單的經過控件的組合，API的靈活運用。固然若是你要支持drag，move，sticky-section-header，那就須要額外作工做了。但那些畢竟是少數，將業務需求中經常使用的UI形式進行封裝纔是必要的。

沒錯，接下來，Stay要安利了。年前一直在籌備重錄快速搭建項目MaterialDesign版課程(第三遍)，如今終於有心得有感悟的來錄製了。目前課程還在更新中，以前購買過課程的同窗能夠提早學習了。學封裝架構的思惟方式，比看3個開源項目還有用。

雖然說是收費課程，但絕對物有所值，比起那些API教學，Stay的課程有養分的多。咱們不講某個具體API的調用，不講某個功能實現或者複雜的UI特效（這些能夠google，能夠找開源lib）咱們講，如何去思考，站在用戶的角度去理解需求，站在PM的角度去把控項目，站在架構師的角度去設計總體結構。至於剩下的，相信我，都很簡單。