实际开发中,社交或者商城类,新闻类的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,我就会更新上去.