打造Android MVP模式 retrofit+rxjava（二）

本篇内容主要讲解如果使用retrofit+rxjava作为网络层，为MVP的M层提供网络数据源

需要引入的依赖库如下：

compile ‘io.reactivex:rxjava:1.1.0’
compile ‘io.reactivex:rxandroid:1.1.0’
compile ‘com.squareup.retrofit2:retrofit:2.0.0-beta4’
compile ‘com.squareup.retrofit2:converter-gson:2.0.0-beta4’
compile ‘com.squareup.retrofit2:adapter-rxjava:2.0.0-beta4’
compile ‘com.google.code.gson:gson:2.6.2’

在上一篇文章中，我们在domain包底下的repository目录创建了一个IWeatherRepository接口，接口中写了数据获取的抽象方法。算是为数据源提供方的实现进行了接口规范。

作为常规的网络访问，通常在请求的时候会给方法传入几个参数
1. 用于标记当前访问的标识符（int flag）
2. 具体网络请求需要的参数(String local,long timestamp)
3. 网络访问的回调监听 （RepCallback callback）

那么我们来看看具体的repository(实现)层的结构

可以看到repository(实现)层中分为三层：

1. interfaces（retrofit网络请求定义）
   

2. network （网络访问的框架的整合）
   
   在我们使用第三方框架的时候，通常会对这些框架进行管理，其中包括为retrofit初始化抽取单例，配置拦截器、为回调提取基类操作等。network层主要也是做这些工作。
   网络访问主要为以下两个类：
   Api：网络访问常量的接口，主要用于存放网络访问的链接（baseUrl）
   ApiManager : 对retrofit的初始化管理和网络接口实例的管理
   
   额外的类：
   BaseSubscriber : subscriber的基类，主要用于基础功能扩展（例如：日志打印）
   RepCallback : 访问响应的封装，主要封装了成功和失败，可以加入取消等相关
   RepCallbackAdapter ： 用于转化RepCallback 为retrofit所需要的callback
   
   这里主要解析一下RepCallback和RepCallbackAdapter的作用
   
   RepCallback作为一个接口统一了数据调用的响应模式，这里主要是考虑到其他数据源或者在使用其他网络访问框架的时候不需要再去修改回调的实现。
   其中RepCallbackAdapter就是把 RepCallback 转化为 retrofit.Callback的作用
   这里就不贴代码了，有兴起的可以点下面的链接下载源码。

3. Impl(实现了IWeatherRepository接口)
   
   
   NetWeatherRepositoryImpl类实现了IWeatherRepository接口，实现了getWeatherData（…）方法。可以看出，实际的网络请求是由enqueue(callback)执行。

---

retrofit的网络访问为我们提供了两种模式的数据返回
1. Call<数据实体>
2. Observable<数据实体>

上面我们介绍了使用call模式的访问，下面我们来看看Observable模式。当然Observable模式必须先看看rxjava的基础语法和操作符。点击这里可以跳转到rxjava基础教程

为什么要用Observable模式呢？
其实如果有学过rxjava的童鞋们应该能回答，rxjava大法好嘛。rxjava能够在不同线程间调度，链式编程更直观的表示出代码的含义

那么我们来看看Observable模式下的修改
1. domain.repository中增加了IRxWeatherRepository接口

这里对一个接口提供了3种方式的调用，主要为了分析哪一种方式更加符合我们

2. repository.Impl中增加了RxNetWeatherRepositoryImpl类实现了IRxWeatherRepository接口

方式一：把Subscriber作为参数传入，所有操作在RxNetWeatherRepositoryImpl完成，P层调用的时候只需要传入参数和实现Subscriber
方式二：和方式一的区别是把Subscription返回给P层，让P层可以控制观察者的取消订阅（unsubscribe）
方式三：只传入网络请求需要的参数，线程调度也只是指定了数据源的调度，返回一个Observable(被观察者)给P层。

相比于方式一和方式二，我更喜欢方式三的调用方式，RxNetWeatherRepositoryImpl作为数据源，负责的应该是数据的提供，也就是数据的获取和数据获取线程的指定，而订阅者的操作已经不属于这个层所做的事情了,故应该分离开来。这里我也讲解一下方法三的调用，方式一和方式二比较简单，这里就不做讲解。

首先，我们在presentation.presenters.impl中增加一个P类RxWeatherPresenterImpl
调用Observable模式的访问


我们来分析一下这个方法（把匿名内部类先提取出来所得）

mRxWeatherRepository.getWeatherData("101010100",System.currentTimeMillis())                .observeOn(AndroidSchedulers.mainThread())                .subscribe(baseSubscriber.setFlag(10086)                ));

这里只是把observeOn和subscribe提取到P层，让P层自由的控制该由哪个线程执行哪个观察者的事件。

mCompositeSubscription又是什么呢？
其实CompositeSubscription是rx.subscriptions.CompositeSubscription包底下用于管理Subscription的一个集合操作类，本质是一个Set< Subscription> subscriptions
这里我在P层基类里面定义了一个CompositeSubscription主要用于管理P层中的Subscription，代码如下：

总结：
1. retrofit让我们有了2种模式的选择，选择哪一种就看项目需要，call模式对于大家来说比较容易入手，毕竟是最常使用的模式，Observable模式上手难度比较高，必须先学习rxjava，但代码方面却减少了callback的嵌套，形成链式，代码表达意思更加直观

源码下载点击这里

参考博文：
http://blog.csdn.net/iamzgx/article/details/51607387