进阶之路:MVP+Retrofit+RxJava组合使用


总感觉时间有点快啊,又到了祝大家周末愉快的时候。本篇来自 申然哥哥 的投稿,不涉及相关基础知识(想了解的朋友可先自行搜索),着重于知识的应用,希望能给那些处于懵懂阶段的童鞋带来帮助。


申然哥哥 的博客地址:

http://blog.csdn.net/qq_27778869


前言


通过这几天对这三者开发中的使用,今天准备做一个小的总结,帮助需要爬坑的"道友"!


接下来先分别介绍一下这三个是什么东东。


MVP


MVP 是基于 MVC 的改进,相信大家都是从 MVC 走过的,可能很多人还会在项目中使用 MVC,我们传统的 MVC xml布局 充当就是 视图层(View)业务层兼模型层 的一些业务处理需要在我们 Activity 或 Fragment 中进行处理然后更新视图层。由于xml定义好的布局,一旦加载之后,只能通过动态更新,那么视图层和Model就建立了联系,因此二者的耦合度就提高了,那么一旦修改了其中的一个就有可能对另一产生影响。


同时所有的操作在我们的 Controller 中进行处理,Controller 就会显得十分的臃肿,可读性就降低了,导致后期的项目维护成本提高了不少。很多时候你需要和团队一起开发项目,如果你的同事有一天在你请假或者想修改功能的时候发现一个Activity都有上千行甚至更多的时候,他开始慌了,他慌的时候如果还找到你的话,你可能也慌了。有了 MVP 之后,妈妈再也不用担心我会慌了!


MVP model层 依然不变,只不过之前充当 Controller Activity或者Fragment 就变身为了 View层,而业务逻辑的实现是在我们的 Presenter 中。简单介绍完了 MVP,光说不练,一点效果都没有的,下面我们来进行 MVP 的三部曲。


本次案例是在进入程序的时候访问服务器的指定接口来获取当前服务器中apk的版本号,通过对比和当前应用程序的版本号,如果有新版本弹出一个土司提示用户更新,功能就这么简单。


  • 视图层需要哪些更新UI的操作?可能大家会好奇我为什么会问这个,这里我留下一个悬念,待会给大家细讲。这个问题的答案是弹出一个土司提示用户更新。

  • 怎么进行更新UI前的操作?

  • 何时告知视图层进行UI更新?


结合上面的三个问题,我们根据需求设计代码:


1. 定义一个 MvpView 的接口:


public Interface MvpView {
   //提示更新    void showMessage(); }


2. 定义一个 Model 类:




3. 定义一个基类 BasePresenter(当然大家也可以不用这么做):




4. 定义一个实际操作的 MvpPresenter




5. 开始视图层的构建了,不过在之前我们先创建一个 BaseMvpActivity 用于统一化管理我们的 MVP模式 的Activity的构建:




6. 正式写我们的应用Activity了(当前Activity的布局中仅有一个TextView):




7. 看到上面的 MvpActivity 是不是觉得代码很清爽,那还不是把业务处理的逻辑丢给了 Presenter了,好了我们来具体看看 MvpPresenter 怎么写:




Retrofit简单介绍及使用


相信大家在开发过程中被这个字眼给冲击过不少次,具体 Retrofit 是什么这里我就不详细介绍了,我们只针对它的简单应用来讲解:


1. 首先需要创建一个接口如 RetrofitCall,因为 Retrofit 是通过注解的形式构建方法的,下面我们来写一下:




2. 注册网络访问(这里的代码是在 Presenter 实现的):




3. 创建自定义接口实例并执行异步网络请求:




通过RxJava改进Retrofit


RxJava 是一个异步操作的库,主要采用的观察者模式,在这里我只是简单的介绍,需要详细了解可以参考抛物线这篇:


给Android开发工程师的一篇关于RxJava的详解(这个已经推荐好几次了,值得一看呐)

http://gank.io/post/560e15be2dca930e00da1083


在这里我就不作过多介绍了,我们来演示 Retrofit 依靠 RxJava 来改进上面的代码,我们在 RetrofitCall 中添加一个新的注解:


@GET("app/index/type")
Observable<VersionBean> getVerByRxJavaWithRetrofit(@Query("version") String ver);


 接着在 Presenter 中填入如下的方法:




总结


上面对这三者的结合使用有了一个直观的介绍,其实 MVP模式 可以理解为更新UI需要什么操作,什么时候开始更新UI,怎么更新UI;而我们的 MVP模式 就是把这三种状态巧妙地分开,因此会让思路显得很清晰。


RxJava 正式基于这种设计,被观察者通过被订阅的形式在自己有新动态的时候告知观察者我改变了,剩下的就交给观察者做自己应该做的事情了!这样的设计模式很符合我们需求,也很利于团队开发,换个模式你会觉得效率大大提高,让我们一起加入 MVP+RxJava+Retrofit 的队列之中吧!





如果你有好的技术文章想和大家分享,欢迎向我的公众号投稿,投稿具体细节请在公众号主页点击“投稿”菜单查看。


欢迎长按下图 -> 识别图中二维码或者扫一扫关注我的公众号:


MVP(Model View Presenter)其实就是一种项目的整体框架,能让你的代码变得更加简洁,说起框架大家可能还会想到MVC、MVVM。由于篇幅原因,这里我们先不讲MVVM,先来看一下MVC。其实Android本身就采用的是MVC(Model View Controllor)模式、其中Model指的是数据逻辑和实体模型;View指的是布局文件、Controllor指的是Activity。对于很多Android初学者可能会有这样的经历,写代码的时候,不管三七二十一都往Activity中写,当然我当初也是这么干的,根本就没有什么框架的概念,只要能实现某一个功能就很开心了,没有管这么多。当然项目比较小还好,一旦项目比较大,你会发现,Activity所承担的任务其实是很重的,它既要负责页面的展示和交互,还得负责数据的请求和业务逻辑之类的工作,相当于既要打理家庭,又要教育自己调皮的孩子,真是又当爹又当妈。。。那该怎么办呢?这时候Presenter这个继父来到了这个家庭。Presenter对Activity说,我来了,以后你就别这么辛苦了,你就好好打理好View这个家,我专门来负责教育Model这孩子,有什么情况我会向你反映的。这时Activity流下了幸福的眼泪,从此,Model、View(Activity)、Presenter一家三口过上了幸福的生活。。。好了磕个药继续,由于Presenter(我们自己建的类)的出现,可以使View(Activity)不用直接和Model打交道,View(Activity)只用负责页面的显示和交互,剩下的和Model交互的事情都交给Presenter做,比如一些网络请求、数据的获取等,当Presenter获取到数据后再交给View(Activity)进行展示,这样,Activity的任务就大大减小了。这便是MVP(Model 还是指的数据逻辑和实体模型,View指的是Activity,P就是Presenter)框架的工作方式。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值