【Android】第三方ONE开发之MVP架构的学习以及思考

前言

在这次的第三方ONE开发中,发现了如果是把发送请求、接受请求、解析结果等等的逻辑全部写到一个Activity/Fragment中,整个项目会显得比较臃肿,因此学习使用MVP架构,来对功能进行分离。

通过这个项目,学习到了MVP架构的使用,因此用项目中的例子,在此记录。

MVP架构的学习

为什么使用MVP架构

我们日常开发中的Activity和xml界面其实相当于一个MVC架构,Activity中要处理UI操作的同时还要进行数据的请求及处理。这里我们的Activity其实就是我们的View层和Controller层,而xml界面实际上就是我们的View层。

这种开发有一种缺点就是业务量大时,Activity文件的代码量就会飙升,想要改一处逻辑就要花费很长时间去找到相应位置,并且有的逻辑处理尽管是一样的,却不能写成通用的方法。

MVP为何就有效呢

MVP架构可以将Activity中的逻辑处理分离出来,只让Activity做UI逻辑处理,业务逻辑的代码就交给Presenter来处理。

不过MVP架构有一个明显的缺点:代码量增加了。

MVP介绍

MVP与MVC一样,分为三层:

  • View层:Acvtivity与Fragment,负责负责处理UI逻辑
  • Presenter层:业务处理层,既能处理UI逻辑,又能处理业务逻辑
  • Model层:具体的数据请求,数据源。

三层的调用顺序是:View=>Presenter=>Model 并且不可反向调用。而数据的反馈,则是由接口完成,底层的并不会直接给上层提供反馈,提供反馈是通过接口的调用,而接口的逻辑由上层实现该接口来完成。其中,Model=>Presenter是通过CallBack接口,而Presenter=>View是通过View接口。

  • View 中定义了 Activity 的具体操作,主要是些将请求到的数据在界面中更新之类的方法
  • Callback 中定义了请求数据时反馈的各种状态:成功、失败、异常等对应的方法。

MVP架构的实现

这里通过第三方ONE项目里的代码来详细说明MVP架构的组成,以及它的调用方式。

本次项目中,由于要求只能使用HttpUrlConnection来处理Http请求,因此我封装了一个Http请求的类HttpUtil,用它来处理Http请求。之后将请求到的数据通过JsonUtil的方法转换成对应的Bean对象,将Bean对象应用于View上。下面是请求文章内容部分由下到上每一层的介绍:

Model层

目录结构

Model层的文件目录如图,ArticleDetailModel接口中定义了Model层的具体功能,用于给Presenter调用,ArticleDetailModelImpl中实现了该接口,在这里写了网络请求相关的代码。而OnArticleDetailListener则是用于反馈给Presenter层的接口,也就是我们之前提到的CallBack接口,定义了请求数据时反馈的各种状态:成功、失败、异常等情况对应的方法。

ArticleDetailModel

里面只有一个方法getArticleDetail,它用于被Presenter层调用,来获取文章详情并反馈。

ArticleDetailModelImpl

方法中调用了HttpUtil的sendHttpRequest方法,并且在请求的CallBack中进行了不同处理

  • 在onResponse方法中将获取到的response文本通过JsonUtil转换为了对应的ArticleDetail对象,并调用用于反馈的OnArticleDetailListener的onSuccess方法将结果反馈。

  • 在onError方法中调用onArticlerDetailListener的onError方法,将错误信息反馈。

  • 在onStart方法中调用onArticlerDetailListener的onStart方法,让Presenter做开始请求时的业务处理。

  • 在onFinish方法中调用onArticlerDetailListener的onFinish方法,让Presenter做结束请求时的业务处理。

OnArticleDetailListener

里面的四个方法分别对应了网络请求的四种情况,用于给Model层向Presenter层反馈

Presenter层

目录结构

Presenter层文件目录如图,其中ArticleDetailPresenter接口里面定义了各种Presenter层给View层调用的方法,而ArticleDetailPresenterImpl则实现了这些方法。

ArticleDetailPresenter

里面只有一个方法getArticleDetail,用于被View层调用,来获取文章详情并反馈。

ArticleDetailPresenterImpl

实现了ArticleDetailPresenter的方法,它可能View层被调用也可以调用Model层,所以需要两个对象来处理

  • getArticleDetail方法调用了Model层的方法,来让Model层获取数据
  • 在onSuccess方法中将获取到的ArticleDetail对象调用View层的方法进行反馈。

  • 在onError方法中调用View层的onError方法,将错误信息反馈。

  • 在onStart方法中调用View层的onStart方法,让View层做开始请求时的UI处理。

  • 在onFinish方法中调用onArticlerDetailListener的onFinish方法,让View层做结束请求时的UI处理。

View层

目录结构

在ArticleDetailView中定义了接收到Presenter层反馈的各种处理对应的接口,而在ArticleDetailActivity中则是对当前View进行初始化以及执行对各种反馈的UI处理。

ArticleDetailView

定义了收到反馈时各种处理的接口,用于给Presenter层进行反馈

ArticleDetailActivity

用于初始化各种控件,并作出收到反馈后的UI处理,这里只展示了收到反馈时的处理的方法实现。

要清楚我们发送网络请求是在新的线程中发送的,因此进行UI操作要在UI线程,所以我们在此调用runOnUiThread来切换回我们的UI线程,再进行UI操作。其实这里的切换回UI线程可以放到Presenter层进行,因为已经知道了View层做的都是UI操作。

  • setArticle方法中,我们为每个控件设置了ArticleDetail对象中对应的值,其中为了美观,我们将可能为空的值我们都进行判断,为空则使该控件不可见。
  • onError方法中我们建立了一个提示Dialog,来显示提示信息。

  • onStart方法中我们设置了SwipeRefreshLayout为加载状态,直到加载完成后,才显示具体内容。

  • onFinish方法中我们设置了SwipeRefreshLayout为停止加载状态,此时请求已经收到回复,不再显示加载进度条,显示具体内容。


总结

MVP架构将项目分为了三层,每层负责不同的职责,通过一个链式的调用以及反馈,进一步地进行了解耦。它可以有效地将我们的逻辑分离,使得项目的结构更清晰,Activity所负责的事情更少。不过它也有一个缺点就是导致了代码量的提升,所以在以后的项目中需要视具体情况来判断是否需要使用MVP架构。

评 论 区

  1. 还没有任何评论,你来说两句吧

发表评论

%d 博主赞过: