本文导语：
如果对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接口为例
我们看看在该框架下，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
（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架构的理解
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、几种设计模式以及他们各自的优缺点
4、本文Demo的Github地址：MVP_Retrofit_RxJava。
若工程编译存在问题，可参考各个 Android Gradle 插件版本所需的 Gradle 版本修正gradle插件版本来解决
最后，附上我的一个Kotlin编写+组件化开发的开源项目Designer
Kotlin+组件化开发实践—开源项目Designer-App
Designer项目算是倾注了我蛮多心血了，每个页面和功能都当成是上线的App来做，App的logo还特地做了UI设计😃力求做到精致和完善，其中还包括了很多自己项目开发中的经验汇总和对新技术的探索和整合，希望对各位读者有所帮助，欢迎点个star，follow，或者给个小心心，嘻嘻😝也可以分享给你更多的朋友一起学习，您的支持是我不断前进的动力。如果有任何问题，欢迎在GitHub上给我提issue或者留言。
