有一段时间没有更新文章了，最近都在忙公司的项目偶尔闲下来也是针对之前的框架补一些七七八八的功能。包括一些第三方的以及工具类。
这次主要是针对之前 Rxjava+retrofit二次封装的修改：添加mvp的架构思想。之前一直没有添加是因为感觉自己封装的网络请求其实已经算是很简便了。
一个请求添加上返回数据的封装类，Activity继承HttpOnNextListener 重新 onNext方法就可以实现一个基本的网络请求过程了。
其实之后的mvp写法，代码量和这个差不多。那么既然都可以这么简单了为什么还要用mvp模式呢？实际上这种架构的写法好处不仅仅体现在代码量的多少更在于他的维护。
一、MVP的理解
在Android开发中，Activity和Fragment承载了太多的开发任务，它们不仅负责展示UI，更由于它们有生命周期这一特性，我们同样会把许多的业务逻辑(controller层)的东西写在activity中，这样就造成的Activity和Fragment非常的臃肿，维护起来相当的麻烦。为了解决这种问题，在程序开发中使用mvp设计模式显得十分必要。
MVP模式的核心思想：
MVP把Activity中的UI逻辑抽象成View接口，把业务逻辑抽象成Presenter接口，Model类还是原来的Model。
Mvp模式的好处:
1.分离了视图逻辑和业务逻辑，降低了耦合
2.Activity只处理生命周期的任务，代码变得更加简洁
3.视图逻辑和业务逻辑分别抽象到了View和Presenter的接口中去，提高代码的可阅读性
4.Presenter被抽象成接口，可以有多种具体的实现，所以方便进行单元测试
5.把业务逻辑抽到Presenter中去，避免后台线程引用着Activity导致Activity的资源无法被系统回收从而引起内存泄露和OOM
好了，理论和例子网上肯定是很多很多的，那么我们开始实践，以下例子是在前一篇基础上做修改的传送门（数据请求然后页面显示请求的json数据）。
1、首先我们创建一个model获取数据
定义一个model的父类实现基本的初始化以及回调
这里我们还实现了一个HttpOnNextListener实现数据的回调（rxjava+retrofit二次封装的结果，onNext方法即可获取结果数据，之前我们写在activity的代码由于使用了mvp模式，故将此逻辑代码写在model层）可以看到我们使用了一个CallBack将数据回调出去。
定义一个Model类继承父类并实现接口。
2、实现View层
view层其实很简单，主要是获取请求得到的数据，这里我只定义了成功和失败的接口方法：
当然，这里可以添加请求进度的方法，比如实现回调过程是一个进度对话框，请求成功对话框消失。因为这里我对rxjava+retrofit进行了进度对话框的封装，故没有在view层再做这个任务。
3、实现 presenter层
presenter是view层和model层的桥梁，起到一个非常大的作用。presenter将model层的数据处理结果返回给view层做页面逻辑的处理
首先定义个接口类
其中 onInit()方法主要是数据的初始化，这里我们主要做的是请求参数的封装（通过map集合的方式）
onDataCreate()方法是主要数据的处理
可以看到数据通过callBack回调出来，然后实现view层的setdata的方法，这样就将数据填充进去，Activity或者Fragment就可以实现View层的接口得到数据
4、Activity、Fragment实现
Activity或者Fragment实现View层的接口
重写setData()方法
总结：
mvp的基本写法就是以上这样的一个网络请求的例子，当然mvp架构思想并不是统一的一个写法，他是一种思想。所以每个人可以根据自己具体的项目写成自己方便的写法。
最后：
如果有哪些值得改进的欢迎提出意见。
