實際開發中,社交或者商城類,新聞類的app,大部分的頁面都是列表.git
寫列表adapter的速度,基本決定整個app的開發速度.github
還記得剛作安卓的時候,寫listview的adpater,寫一個列表寫一下午.簡直喪心病狂.設計模式
以後出現了RecyclerView,還有一大批優秀的開源Adapter.代碼已經很省心了.bash
然而,在作一個項目時,不一樣的列表可能會出現部分重複,靠寫adapter來複用就搞不定了。 再好比,複雜的多type列表仍是會出現上百行代碼在onBindViewHolder裏面的狀況,維護不易。app
最開始目的,僅僅是爲了解決多級摺疊列表.ide
傳送門:一個RecyclerView實現多級摺疊列表(一) 傳送門:一個RecyclerView實現多級摺疊列表(二)佈局
可是更新到如今,TreeRecyclerView這個名字其實已經不適合了.post
隨着具體使用,更新優化,我發現RecyclerView的Adapter能夠換種思想,換個寫法.優化
爲了便於閱讀,下文會用item來表示列表的條目。動畫
如下我的看法
M:塞給adapter的list數據就是modle
V:recyclerview
P:adapter。
若是把不一樣type的item當作一個個能夠複用的presenter.
每寫一種item,就表明該項目裏多一個能夠複用的presenter
adapter的onbindviewholder將沒有具體的綁定邏輯
綁定操做在各類item裏完成,邏輯更清晰,修改維護更容易。
複製代碼
每一種Item對應一種Model.
能夠跟後臺設計model的屬性,
根據特定的屬性來控制要展現的item樣式.
而後經過建立工廠,生成List<Item>
一行搞定item的建立
不用多寫其餘代碼.
M能夠決定建立什麼樣的Item.也就是P
複製代碼
每一種Item,都須要對應的view類型,我目前直接用佈局id來表明view
這一塊仍是缺陷,目前的設計,我的以爲不完美.
複製代碼
若是把每種item之間關係看做View和ViewGruop同樣.
那麼組合就會有無限可能. 什麼多級列表多type(有些設計仍是會不和諧,得從layoutmanager下手)都不是問題。
ViewGroup能夠包含多種類型的子View,而且繼承於View.
對於改動需求,某些功能,用裝飾者模式來完成修改是快速的.且不影響原代碼 好比添加頭部和尾部view,添加emptyView,item側滑刪除功能.
各類封裝adpater之間隨意裝飾組合,我的以爲比較高效,可是裝飾過多難掌控.
建立item不該該是一個苦力活,大能夠經過工廠來生成各類item.只需配置一下數據model和Item的對應關係. 責任鏈: item寫了個簡單的事件攔截 策略模式: 基本就是抽象功能.可以用子類實現替換.這種用的地方挺多的
需求定下來了,一個好友列表.展現好友,點擊跳轉(分分鐘搞定)
這個時候產品說這樣不行,得加個首字母分類,側邊索引定位 ......因而,吐槽一番去找索引定位的demo.而後adapter一堆改.(改你mb)
光有索引也不行,再加個下拉刷新,上啦加載分頁.加載時動畫,空數據頁面 好,去找demo.繼續改(心力憔悴)
哥們,這個好友列表再加上側滑刪除怎麼樣?? .....(信不信我刪庫跑路) 這個時候,是否是有砍人的衝動了.. 沒辦法,接着找demo.而後對着adapter一頓加功能. 到這個狀態,若是不用裝飾,不用繼承.我估計是寫不下去的.
這個列表能不能加個頭部啊,上次那個需求好像不太好,去掉吧. 這個列表能實現點擊摺疊嗎?這個有bug啊.....(已陣亡) 咱們的大部分時間就花在這些修改上面了.雖然描述的有點喪心病狂 但確確實實,基本都會改個幾回的. 懟產品也不能解決問題.自身強大才是硬道理
不論是加功能仍是去功能,改動地方並不會特別大.
水平有限,設計模式也是懂點皮毛.設計上不少問題.一我的設計確實挺難的.但也學到了不少東西. 這篇文章主要講個思路,具體用法其實在其餘兩篇文章裏面寫的挺詳細的了.雖然如今有些類刪了,有些類更名了.思路和前兩篇文章也有點出路 但大體用法沒變的.有興趣能夠看看.
但願個人經歷能讓你學到點東西
下一篇文章,大概會把這個項目demo裏的例子都詳細描述一下.
---------------------------------分割線---------------------------------------
傳送門:TreeRecyclerView
已經有87顆星了,挺高興的.哈哈
喜歡與回覆是我最大的動力-_-
只要有新的idea,我就會更新上去.