高级MVP+Retrofit+RxJava实战——一步步带你搭建
study.png
本文导语：
如果对Rxjava+Retrofit联网不熟悉的朋友，可以参考下我之前写的几篇文章，有比较详细的讲解。
1、优雅封装Retrofit+RxJava联网的统一管理类
2、分分钟使用Retrofit+Rxjava实现网络请求
3、轻松搞定Retrofit不同网络请求方式的请求参数配置
为了方便大多数朋友理解，我使用Java代码写了个Demo。会使用Kotlin的同学，可以直接使用Kotlin语言写，结合DataBinding一起使用，在项目中使用起来更方便简洁哦~
阅读完本文你将收获到：
1、如何将Retrofit+RxJava联网框架，结合泛型MVP架构，优雅灵活地运用到项目中。
2、BaseMvpActivity和BaseMvpFragment的封装
3、统一封装接口返回的json数据
4、自定义接口对网络请求的异常回调进行统一的处理。
5、MVC、MVP架构的理解
使用MVP+Retrofit+RxJava框架后
下面是本文中Demo的演示效果:
还是以请求天气信息http://t.weather.sojson.com/api/weather/city/101030100接口为例
Animation.gif
我们看看在该框架下，Activity的代码是如何写的：
/**
* 测试MVP + Retrofit +RxJava
*/
public class MainActivity extends BaseMvpActivity<MainPresenter, MainModel> implements MainContract.View {
@BindView(R.id.tv_quality)
TextView tv_quality;
@BindView(R.id.tv_pm)
TextView tv_pm;
@BindView(R.id.tv_wendu)
TextView tv_wendu;
@BindView(R.id.tv_notice)
TextView tv_notice;
@Override
protected int getContentViewLayoutID() {
return R.layout.activity_main;
}
@Override
protected void initViewAndEvents() {
//发起请求
mMvpPresenter.getWeather("101030100", mMultipleStateView);
}
/**
* 接口请求成功的回调方法
*
* @param bean
*/
@Override
public void getWeather(WeatherEntity bean) {
Log.e("TAG", "请求成功");
tv_quality.setText("空气质量：" + bean.quality);
tv_pm.setText("Pm10" + bean.pm10);
tv_wendu.setText("温度：" + bean.wendu);
tv_notice.setText("提醒：" + bean.ganmao);
}
}
可以看到，在此项目架构中，Activity的代码非常简洁，此时的Activity，只需要关心发出指令（即发起请求）和接收指令的返回结果（即处理接口请求返回的数据），然后进行相应的UI更新操作即可。相比MVC，在MVP中，Presenter承担了业务逻辑处理的职责，这样大大减轻了Activity的负担，让其不再臃肿、难以维护。下面详细的介绍这套框架的搭建思路。
《一》对Retrofit+RxJava联网框架的优化
阅读过优雅封装Retrofit+RxJava联网的统一管理类这篇文章的朋友应该知道，通过一个统一管理类，我们已经可以很方便的在项目中进行联网操作了。如下：
RetrofitManager.getInstance().getRequestService().getWeather("101030100")
.compose(RxSchedulers.io_main())
.subscribeWith(new DisposableObserver<Object>() {
@Override
public void onNext(Object result) {
Log.e("TAG", "result=" + result.toString());
}
@Override
public void onError(Throwable e) {
Log.e("TAG", "onError=" + e.getMessage());
}
@Override
public void onComplete() {
Log.e("TAG", "onComplete");
}
});
如果不做任何处理，当然也是可以实现需求的。不过往往在实际项目开发过程中，不同公司的后台定义的json格式可能有所区别，不过大同小异的是，一般而言我们实际需要用到的数据都在data字段里。例如我们来看一下获取天气信息的免费API：
http://t.weather.sojson.com/api/weather/city/101030100
image.png
（1）一般而言，后端返回的json数据会有一些统一状态信息。例如message、status、time等。每个json串都对应着Java中的一个实体，此时我们可以把返回json数据对应的实体类型进行简单的封装。如下：
public class BaseHttpResponse<T> {
public int status; //具体含义由后端定义
public String message; //请求结果的描述-成功/失败/参数错误等
public T data; //实际有用的数据
}
（2）我们通过一个自定义接口，来处理网络请求中的回调：
public interface BaseObserverListener<T> {
void onSuccess(T result);
void onComplete();
void onError(Throwable e);
void onBusinessError(ErrorBean errorBean);
}
（3）对应的，我们在RetrofitManager中，对接口返回结果及数据进行统一处理：
/**
* 建立请求
*/
public <T> DisposableObserver<BaseHttpResponse<T>> doRequest(Observable<BaseHttpResponse<T>> observable, final BaseObserverListener<T> observerListener) {
return observable
.compose(RxSchedulers.<BaseHttpResponse<T>>io_main())
.subscribeWith(new DisposableObserver<BaseHttpResponse<T>>() {
@Override
public void onNext(BaseHttpResponse<T> result) {
if (result.status == 200) {
observerListener.onSuccess(result.data);
} else {
ErrorBean errorBean = new ErrorBean();
errorBean.setCode(result.status + "");
errorBean.setMsg(result.message);
observerListener.onBusinessError(errorBean);
}
}
@Override
public void onError(Throwable e) {
observerListener.onError(e);
}
@Override
public void onComplete() {
observerListener.onComplete();
}
});
}
（4）实际上对我们而言，网络请求的返回结果，我们可以广义的理解为两种情况：成功或失败。
① 成功肯定就一种情况，那就是请求获取到了页面展示需要的数据,也就是接口返回的结果，走到了onSuccess（）的回调中；
② 但是失败的情形可能有多种 ：接口请求失败(服务端异常)、无网络、接口数据返回错误（如data返回null）等。
我们其实只关心接口成功，因为我们需要拿成功的数据去渲染页面，那么失败的情形，很多时候就是给用户一个友好的Toast提示或者是显示错误页面。那么此时，我们可以把失败的情形，做一下统一处理，同时将具体的处理交给View负责。如下：
public abstract class RxObserverListener<T> implements BaseObserverListener<T> {
private IBaseView mView;
protected RxObserverListener(IBaseView view) {
this.mView = view;
}
/**
* 统一处理异常情况：包括没网、数据返回错误等
*
* @param e
*/
@Override
public void onError(Throwable e) {
RetrofitException.ResponseThrowable responseThrowable = RetrofitException.getResponseThrowable(e);
Log.e("TAG", "e.code=" + responseThrowable.code + responseThrowable.message);
ErrorBean errorBean = new ErrorBean();
errorBean.setMsg(responseThrowable.message);
errorBean.setCode(responseThrowable.code + "");
if (mView != null) {
mView.showException(errorBean);
mView.dismissDialogLoading();
Toast.makeText(MyApplication.getContext(), responseThrowable.message, Toast.LENGTH_SHORT);
}
}
/**
* 接口http结果返回200，但是后台数据返回错误。
* @param errorBean
*/
@Override
public void onBusinessError(ErrorBean errorBean) {
if (mView != null) {
mView.showBusinessError(errorBean);
mView.dismissDialogLoading();
// CommonUtils.makeEventToast(BaseApplication.getInstance(), errorBean.getMsg(), false);
Log.e("TAG", "onBusinessError msg=" + errorBean.getMsg());
}
}
@Override
public void onComplete() {
}
}
public interface IBaseView {
/**
* show loading message
*
* @param msg
*/
void showLoading(MultipleStatusView multipleStatusView, String msg);
/**
* hide loading
*/
void hideLoading();
/**
* dialog loading
*/
void showDialogLoading(String msg);
/**
* dismiss dialog loading
*/
void dismissDialogLoading();
/**
* show business error :网络异常及数据错误等异常情况
*/
void showBusinessError(ErrorBean error);
void showException(ErrorBean error);
}
通过上面的处理，我们的网络请求就可以简化成下面的形式：
RetrofitManager.getInstance().doRequest(mModel.getWeather(city_code), new RxObserverListener<WeatherEntity>() {
@Override
public void onSuccess(WeatherEntity result) {
//接口返回成功
}
});
《二》MVP架构的搭建及BaseMvpActivity的封装
（1）创建一个基类View，定义View层的行为，所有View接口都必须实现。
public interface IBaseView {
/**
* show loading message
* @param msg
*/
void showLoading(MultipleStatusView multipleStatusView, String msg);
/**
* hide loading
*/
void hideLoading();
/**
* show business error :网络异常及数据错误等异常情况
*/
void showBusinessError(ErrorBean error);
void showException(ErrorBean error);
}
（2）创建一个基类的Presenter，在类上规定View和Model的泛型，然后定义绑定和解绑的方法。
public abstract class BasePresenter<V, M > {
public M mModel;
public V mView;
public RxManager rxManager = new RxManager();
/**
* 绑定
*/
public void setVM(V v, M m) {
this.mView = v;
this.mModel = m;
}
/**
* 解绑： 防止内存泄漏
*/
public void onDestroy() {
rxManager.clear();
rxManager = null;
mView = null;
}
}
（3）创建一个基类Model，定义Model层的行为，所有Model接口都必须实现。
public interface BaseModel {
}
（4）定义一个契约类（接口）Contract。使用契约类来统一管理view与presenter的所有的接口，这种方式使得view与presenter中有哪些功能，一目了然，维护起来也很方便。例如Demo中的MainContract：
public interface MainContract {
interface View extends IBaseView {
void getWeather(WeatherEntity bean);
}
interface Model extends BaseModel {
Observable<BaseHttpResponse<WeatherEntity>> getWeather(String city_code);
}
abstract class Presenter extends BasePresenter<MainContract.View, MainContract.Model> {
public abstract void getWeather(String city_code, MultipleStatusView multipleStatusView);
}
}
（5）创建一个基类的Activity，通过反射创建Presenter的对象。这样在具体的Activity中，我们就可以直接拿着Presenter的对象进行相应的操作。BaseMvpFragment的封装思路同BaseMvpActivity，在这里就不赘述了。
public abstract class BaseMvpActivity<P extends BasePresenter, M extends BaseModel> extends AppCompatActivity implements IBaseView {
protected P mMvpPresenter;
protected M mModel;
protected MultipleStatusView mMultipleStateView;
private Unbinder unBinder;
@Override
protected void onCreate(@Nullable Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
if (getContentViewLayoutID() != 0) {
mMultipleStateView = new MultipleStatusView(this);
setContentView(View.inflate(this, getContentViewLayoutID(), mMultipleStateView));
unBinder = ButterKnife.bind(this);
} else {
throw new IllegalArgumentException("You must return a right contentView layout resource Id");
}
//MVP
mMvpPresenter = ClassReflectHelper.getT(this, 0);
mModel = ClassReflectHelper.getT(this, 1);
if (this instanceof IBaseView) {
if (mMvpPresenter != null && mModel != null) {
mMvpPresenter.setVM(this, mModel);
}
}
initViewAndEvents();
}
protected abstract int getContentViewLayoutID();
protected abstract void initViewAndEvents();
@Override
protected void onDestroy() {
super.onDestroy();
unBinder.unbind();
if (mMvpPresenter != null) {
mMvpPresenter.onDestroy();
}
}
@Override
public void showLoading(MultipleStatusView multipleStatusView, String msg) {
}
@Override
public void hideLoading() {
}
@Override
public void showBusinessError(ErrorBean error) {
mMultipleStateView.showError();
}
//
@Override
public void showException(ErrorBean error) {
mMultipleStateView.showNoNetwork();
}
}
《三》MVC与MVP架构的理解
image.png
MVP是从更早的MVC演变而来的，我们先来简单了解一下MVC框架。
（一）MVC（Model-View-Control）
Model(模型)：即数据模型，负责数据持久化。
View(视图)：负责界面显示和接收用户的输入操作。
Controller(控制器)：负责业务逻辑处理。
Activity职责：
（1）C作为M和V之间的连接, 负责获取输入的业务数据, 然后将处理后的数据输出到界面上做相应展示。因此C起到了桥梁的作用，来控制V层和M层直接的通信以达到分离视图和业务逻辑层。
（2）在MVC中，Activity持有了Model模型的对象，向Model模型发起数据请求。当Model模型处理数据结束后，通过Model层的接口回调更新UI。
所以在MVC中，Activity作为Controller控制层负责业务逻辑的处理。
缺点：
由于在MVC中，控制层的重任通常落在了众多的Activity的肩上，随着界面操作及业务逻辑的复杂度越来越高，Activity的代码将会越来越臃肿，变得难以管理和维护。为了解决这个问题，MVP架构应运而生。
（二）MVP（Model-View-Presenter）
View:负责绘制UI元素、与用户进行交互(在Android中体现为Activity)
Model:负责存储、检索、操纵数据(有时也实现一个Model interface用来降低耦合)
Presenter:作为View与Model交互的中间纽带，处理与用户交互的负责逻辑。
在MVP中，我们将Activity复杂的逻辑处理移至另外的一个类（Presenter）中时，Activity其实就是MVP模式中的View，它负责UI元素的初始化，建立UI元素与Presenter的关联（Listener之类），同时自己也会处理一些简单的逻辑（复杂的逻辑交由 Presenter处理）。
MVP的Presenter是框架的控制者，承担了大量的逻辑操作，而MVC的Controller更多时候承担一种转发的作用。因此在App中引入MVP的原因，是为了将此前在Activty中包含的大量逻辑操作放到控制层中，避免Activity的臃肿。
两种模式的主要区别：
① View与Model并不直接交互，而是通过与Presenter交互来与Model间接交互。而在MVC中View可以与Model直接交互（最主要的区别）
② 通常View与Presenter是一对一的，但复杂的View可能绑定多个Presenter来处理逻辑。而Controller是基于行为的，并且可以被多个View共享，Controller可以负责决定显示哪个View
③ Presenter与View的交互是通过接口来进行的，更有利于添加单元测试。
MVP优点：
① 模型与视图完全分离，我们可以修改视图而不影响模型；
② 可以更高效地使用模型，因为所有的交互都发生在一个地方——Presenter内部；
③ 我们可以将一个Presenter用于多个视图，而不需要改变Presenter的逻辑。这个特性非常的有用，因为视图的变化总是比模型的变化频繁；
写在结尾：
1、关于MVC、MVP架构的介绍，更多详细的案例分析可以参考： Android App的设计架构：MVC,MVP,MVVM与架构经验谈
2、关于MVP的优化：高级MVP架构封装演变全过程
3、本文Demo的Github地址：MVP_Retrofit_RxJava。
