MTRVA2.0来啦

前言

从MTRVA的诞生到如今已经有一段时间了，当初第一个版本出来以后，我是很激动的，这能够说是我真正意义上的第一次创做，也是本身的一次历史性进步，写到这，又想起本身熬夜更新版本，躺在床上呆呆地思考着哪里须要优化修改...太多太多的回忆，那么MTRVA做为RecyclerViewAdapter的一股清流，到底有什么鸟用呢？

特色

• 使用简单快捷，可配合大多数Adapter
• 一行代码刷新单个level，可对应多个type，刷新带有动画
• 支持增删改查操做
• 支持异步，高频率刷新，可扩展(如配合RxJava)
• 单个level支持Loading(加载)，Empty(空)，Error(错误)页面切换
• 单个level支持header，footer
• 单个level支持展开和合拢(可设置合拢最小值)
• 支持加载全局Loading(加载)页面
• 支持注解生成类，减小工做量
• 支持刷新生命周期回调
• 兼容低版本RecyclerView
• 进阶用法，好比打造本身的headerView和footerView，让页面在多种页面之间自由切换

思想

这是MTRVA的架构图。

咱们先想象这样一个常见的场景（列表页），那么咱们首先要写一个Adapter，而后针对咱们每个type写一个xml，其次咱们要在Adapter中用一个list来控制item数量以及每一个item渲染所须要的实体类等等，若是对原有list插入逻辑很复杂，甚至复杂到要控制type的start和end的position，可能最初写逻辑代码的时候你很快写完了，幸运的是也没报错。悲剧的是过了几个月，忽然报错了，再回去看的时候，我相信你会和我同样，心情只能“卧槽”来形容。或者在一堆type控制position的代码中再加一个type，对不起，我选择辞职。

固然，辞职是开玩笑的，MTRVA这时候就发挥做用啦，在这里，你不用担忧数据逻辑处理（并且这些处理也不该该写在你的业务层代码中），你只要关心你的UI逻辑，而这些是你应该关心的，也必须关心的，也必须用心写的，由于咱们的业务不同，咱们不同。

那么机智的同窗确定要问，既然MTRVA是控制数据处理的，那是否是相似一个Helper类与Adapter组合使用，仍是传统的改造Adapter的架构达到目的？这个问题水平很高，奖励你一个女友，MTRVA另外一大亮点是与Adapter配合使用，只要你的Adapter是RecyclerViewAdapter，那么基本能够和MTRVA配合使用，若是有不能配合的，请联系我，我尽可能不影响你项目Adapter的使用。

这里有个小插曲，有几个同窗反映即便只写UI逻辑，若是type够多的话，代码依然很复杂，这其实不难，你能够定义一个处理UI逻辑的接口，针对于不一样type实现接口，把不一样type的UI逻辑给抽离出来，甚至能够复用。若是脑中仍是没有一个清晰的模型，能够参考个人demo，这是我应该作的（手动滑稽），但不要照搬，适合本身的才是最好的。

实战

关于实战我是真的不想再写了，由于实在太简单了，这里给出我在掘金发的一篇文章《BRVAH+MTRVA，复杂？不存在的》以及MTRVA的文档，看不懂的你打死我，而此次主要想写的是2.0更新了什么？若是我项目已经集成了MTRVA，我须要注意什么？我更想写的是这些，当初并不想发文章，但是我想着有些同窗可能用了一个版本以后，若是不是那个版本已经支持不了需求，是不会去更新版本的，用的好好的我干吗去更新啊？当这些同窗想更新的时候可能只能去看文档，而文档只有最新的使用方式，所以我秉承一向的做风，每次更新我都会写一篇文章来阐述版本之间的差距，而此次属于大版本更新，动静稍微大了点。

这里说个不少人问的问题，关于网格和线性混排的问题。这个其实不属于个人范畴，但我确定会细心解答的，最简单的就是嵌套，若是优雅一点能够研究下类GridLayoutManager的setSpanSizeLookup方法，能够参考这篇文章《RecyclerView:实现带header的grid》。

更新

既然是大版本更新，到底有什么骚操做呢？

背景

咱们先从大方向来，此次改版的核心思想是从type的思惟定势到level的重视和突破。这样说可能有点抽象，俗话说的好，No picture,say a J8!咱们来看看2.0版本的布局模型图与1.0版本的比较。

若是是老用户会发现2.0版本的设计更符合咱们的初衷。此次的改版跟你们意见和建议有着密不可分的关系，一我的能力再强也是有限的（这样夸本身真的好吗），而团队的力量是无限的，真的很感谢大家。

好了，咱们简单分析一下，这为何是突破。从1.0版本看，明明最外层定义的是level，而刷新的级别倒是type；注册资源的时候，一个type去对应一个level，这是矫情吗，我要这level有何用？若是两种type同一level使用起来特别不方便，局限性较大。而咱们再看2.0版本：

一种level能够注册多种type，在level里面type数据的顺序是无限制的，例如上面的type2在type1的中间，显然是能够无视顺序，让type1堆在一块儿这种，这样咱们的level可控制的UI更加丰富！虽然2.0版本以前也能实现，但对操做要求较高。

这是一次思想的突破，老是避免不了api的改动，而这时候就体现架构设计的重要性，你是一个一个去找出来再改仍是改一个地方就好了，你是要删这删那，仍是只要添加类就好了...这是咱们的语言，而专业一点，你要牢记Java的六大设计原则，虽然我用的也不够灵活，可是你不去用就永远也不会用。

我猜有些同窗已经不耐烦了，能不能说重点，到底改了啥啊？兄台，请放下你的40米大刀，我立刻说。

API差别

资源注册

首先咱们从注册资源开始，原来咱们是这样的：

registerMoudle(ItemEntity3.TYPE_3)
                .level(2)
                .layoutResId(R.layout.item_3)
                .register();
复制代码

而如今是这样的：

registerMoudle(LEVEL_FIRST)
                .type(TypeOneItem.TYPE_ONE)
                .layoutResId(R.layout.item_first)
                .type(TypeTwoItem.TYPE_TWO)
                .layoutResId(R.layout.item_second)
                .register();
复制代码

与上面说的同样，以level为主导，下面咱们能够定义多个type，每一个type对应一个布局xml，原来level的定义更多指的是type顺序的等级，而其它诸如header、footer、loading等不变。

刷新方法

其次一系列的notify方法，原先的type参数所有改成level，这也是影响比较大的地方，若是你是按照个人建议把helper刷新方法封装在adapter里面，改起来也是so easy!瞧，这就是设计的魅力！

例如经常使用的这些方法：

public void notifyMoudleDataChanged(List<? extends T> data, int level);
public void notifyMoudleDataAndHeaderChanged(List<? extends T> data, T header, int level);
public void notifyMoudleDataAndHeaderAndFooterChanged(T header, List<? extends T> data, T footer, int level);
复制代码

资源适配器

LoadingEntityAdapter修改点是同样的，原先回调参数只有type，此次多加一个参数level，虽然二者只要得其一就能计算出另外一个。举个栗子：

T createLoadingEntity(int type);===>T createLoadingEntity(int type, int level);
复制代码

方法

• getLevel方法从private改成public
• 去除getCurrentRefreshType方法并用getCurrentRefreshLevel方法替换
• 全局初始化loading(加载)类LoadingConfig以及相应Builder的setLoading方法参数type改成level
• 新增getDataWithLevel方法，根据level拿到相对应的数据
• 类HandleBase的type属性修改成level，这也是意料之中的事情

注解

我不知道这玩意有人用吗？反正先前版本已经分离出来了，若是想用要另外依赖库，具体能够看文档。

关于注解的改动其实和上面差很少，主要把原先定义为type的统统改成level，使用方法是不变的。

杂谈

就改动这么点东西？也要兴师动众吗？Sorry，就这么点东西，打扰了。甚至你能够无脑记type改level，但...可是我底层逻辑的修改可惨了，我已经记不清我改了多少地方，我只记得我一直在疯狂测试，生怕哪里没改动而影响升级了2.0版本的同窗使用。固然已经集成MTRVA的同窗并不必定要更新，此次是在架构上的一次改进，方便之后的扩展。若是跟我同样，喜欢新版本的同窗能够尝试更新版本，这里提供本身经常使用的更新新版本方法：首先下载官方提供的demo，疯狂玩，玩demo不过瘾的本身改代码再玩，玩得差很少的时候就集成到项目中，疯狂自测，没问题以后与版本测试一块儿交给咱们可爱的测试人员。若是有更好的方法能够联系我，我改完告知你们，你们一块儿学习。

细心的朋友发现咱们的篇幅并非很长，本次的主角就是MTRVA，就是一个库，但对我来讲是一种情怀。我先说说我本身选择库的标准，首先肯定库的特色是什么？对我如今的项目有什么好处？我如今项目中有没有相似的库，相比较怎么样？若是我选择使用，使用是否简单，集成是否复杂，会不会对我项目有很大影响，后期做者是否维护等等。这是本身的想法，但愿能帮到你，欢迎补充。

原本这个月发的文章主题是Android性能优化，以前公司是小公司（虽然如今仍是小公司），属于需求完成就万事大吉，但做为一名优秀的程序员，对本身开发的应用要求仅仅知足需求，那也太low了，早晚被淘汰。下个月可能发布我对性能优化的一点理解，但愿对你们有所帮助，拭目以待！这里插个嘴，个人项目CrazyDaily也跟着更新了，除了MTRVA的更新，还有替换内涵段子为搞笑视频，缘由你懂的！

这里强调一点，我开源的库我确定会一直更新下去，除非没人用了或者我已经不在这行业了。虽然有时候多个用户在同一段时间问了好几个问题，有几个仍是比较棘手的问题，本身也曾想过删库或者中止维护。但想一想别人用个人库是对个人一种承认，是看得起我，同时知足本身微不足道的虚荣心，我瞬间就来劲了，哈哈，不知道这是否是自我催眠。之后开源库可能会少写，但开源的精神必须有，一些比较装逼且实用的写法我都会集成在个人项目CrazyDaily中，喜欢的朋友能够star关注一波，剧透一波，将有一大波自定义控件与动画涌入项目。

最最最重要的一点是，你们能够在个人博客找到个人联系方式，随便加，但不必定即时回复，敬请谅解。经过好友后第一句不要叫我大佬（手动捂脸），我只是一只开发Android的渣渣。有几个同窗问我为啥不组个群啊？我相信你确定加了一堆的群，有没有用，你内心尚未一点13数吗？有问题就直接问好了！可能你的问题我也没碰到过，但我会尽力给你解决，你们一块儿学习，何乐而不为？固然能搜索到的就别来啦！

最后，感谢一直支持个人人！

传送门

Github：github.com/crazysunj/M…

文档：crazysunj.com/2017/08/14/…