1、導包：
2、封裝：
我們先來看一下，一個完整的 Retrofit+Rxjva 的請求：
OkHttpClient.Builder builder = new OkHttpClient().newBuilder();
builder.readTimeout(DEFAULT_TIME, TimeUnit.SECONDS);
builder.connectTimeout(DEFAULT_TIME, TimeUnit.SECONDS);
//設置攔截器
builder.addInterceptor(new BasicParamsInterceptor.Builder().addParamsMap(getCommonMap()).build());
builder.addInterceptor(new HttpLoggingInterceptor().setLevel(HttpLoggingInterceptor.Level.BODY));
OkHttpClient okHttpClient = builder.build();
Retrofit retrofit = new Retrofit.Builder()
.baseUrl(BASE_URL)
.client(okHttpClient)
.addConverterFactory(CustomGsonConverterFactory.create())
.addCallAdapterFactory(RxJava2CallAdapterFactory.create())
.build();
ApiService api=retrofit.create(ApiService.class);
api.login(username,password)
.subscribeOn(Schedulers.io()) //在IO線程進行網(wǎng)絡請求
.observeOn(AndroidSchedulers.mainThread()) //回到主線程去處理請求結果
.subscribe(new Observer<LoginResponse>() {
@Override
public void onSubscribe(Disposable d) {
//為請求提供一個取消的手段
}
@Override
public void onNext(LoginResponse value) {
//請求成功
}
@Override
public void onError(Throwable e) {
//請求出錯
}
@Override
public void onComplete() {
//請求完成
}
});考慮到每次請求接口的時候都需要去實例化一個 Retrofit 對象，而且每次都需要用 RxJava 來進行線程的切換，因此我就想到把它們都寫到一個基類里面去。
public abstract class BaseRetrofit {
protected Retrofit mRetrofit;
private static final int DEFAULT_TIME = 10; //默認超時時間
private final long RETRY_TIMES = 1; //重訂閱次數(shù)
public BaseRetrofit() {
//創(chuàng)建okHttpClient
if (null == mRetrofit) {
OkHttpClient.Builder builder = new OkHttpClient().newBuilder();
builder.readTimeout(DEFAULT_TIME, TimeUnit.SECONDS);
builder.connectTimeout(DEFAULT_TIME, TimeUnit.SECONDS);
//設置攔截器
builder.addInterceptor(new BasicParamsInterceptor.Builder().addParamsMap(getCommonMap()).build());
builder.addInterceptor(new HttpLoggingInterceptor().setLevel(HttpLoggingInterceptor.Level.BODY));
OkHttpClient okHttpClient = builder.build();
mRetrofit = new Retrofit.Builder()
.baseUrl(HttpServletAddress.getInstance().getServletAddress())
.client(okHttpClient)
.addConverterFactory(CustomGsonConverterFactory.create())
.addCallAdapterFactory(RxJava2CallAdapterFactory.create())
.build();
}
}
}然后結合我們上周講的 MVP，讓 BaseModel 繼承它，然后調用方法進行請求，上周我們還沒有細節(jié)講它是怎么樣進行網(wǎng)絡請求的，回到剛才那個完整的請求的例子，可以看到，這里發(fā)起請求需要兩個東西，一個 Observer，另一個是 api.login()的返回值 Observable，這就是大佬們口中說的觀察者和被觀察者，他們之間有一個很微妙的關系，叫訂閱；被觀察者負責網(wǎng)絡請求，觀察者負責觀察網(wǎng)絡請求的回調，每發(fā)生一次接口請求，都會有訂閱發(fā)生，所以在這里我把訂閱公共的邏輯放到了 BaseRetrofit中：
protected <T> void toSubscribe(Observable<T> observable, Observer<T> observer) {
observable.subscribeOn(Schedulers.io()) // 指定subscribe()發(fā)生在IO線程
.observeOn(AndroidSchedulers.mainThread()) // 指定Subscriber的回調發(fā)生在io線程
.timeout(DEFAULT_TIME, TimeUnit.SECONDS) //重連間隔時間
.retry(RETRY_TIMES)
// .repeatWhen(new Function<Observable<Object>, ObservableSource<?>>() {
// @Override
// public ObservableSource<?> apply(@NonNull Observable<Object> objectObservable) throws Exception {
// return null;
// }
// })
.subscribe(observer); //訂閱
}這樣每次我們組裝好 Observable 和 Observer 之后就調用這個方法進行訂閱就好了。這里我有一個困惑，已經很久了，希望知道的讀者能幫忙解惑，重寫 retryWhen 的時候，如何根據(jù)錯誤類型進行重試。講到這里可能有人就要問了，LZ你不還是沒有講是怎么進行網(wǎng)絡請求的嗎？大兄弟別急，我這就告訴你，它是通過自定義接口的形式來進行網(wǎng)絡請求的，好吧，說了好像也白說，換個場景你自個去深入了解去吧：
Retrofit 網(wǎng)絡請求框架的基本使用 http://blog.csdn.net/zw904448290/article/details/52717384
好了，接著我們下面的封裝：
被觀察者已經當作接口被我們處理掉了，那么下面我們重點關注觀察者；很久之前我老大跟我講網(wǎng)絡請求封裝這一塊，他當時說我們只關注請求成功的數(shù)據(jù)，其他的不需要特別關注；首先，我們得有一套統(tǒng)一的回調樣式，如下：
由于我們這邊都把返回的 json 數(shù)據(jù)都轉成 BaseResponse<T>格式了，如果你們回調的數(shù)據(jù)格式不統(tǒng)一的話，那就去找后端撕逼去吧；然后我們只需要重寫Observer 就行了，Observer 接口中有四個方法，上面例子中我們簡單介紹了一下，它們的執(zhí)行順序分別是 onSubscribe——>onNext——>onComplete（onError），這里需要簡單提一下，onComplete 和 onError方法二者不會同時都執(zhí)行，具體來看一下LZ封裝的：
public abstract class BaseObserver<T> implements Observer<T> {
private static final String TAG = "BaseObserver";
protected abstract void onBaseError(Throwable t);
protected abstract void onBaseNext(T data);
protected abstract boolean isNeedProgressDialog();
protected abstract String getTitleMsg();
private ProgressDialogHandler mProgressDialogHandler;
private BaseImpl mBaseImpl;
public BaseObserver(BaseImpl baseImpl) {
mBaseImpl = baseImpl;
if (null != mBaseImpl) {
if (null == mProgressDialogHandler) {
mProgressDialogHandler = new ProgressDialogHandler(baseImpl.getContext(), true);
}
}
}
private void showProgressDialog() {
if (mProgressDialogHandler != null) {
mProgressDialogHandler.obtainMessage(ProgressDialogHandler.SHOW_PROGRESS_DIALOG, getTitleMsg()).sendToTarget();
}
}
private void dismissProgressDialog() {
if (mProgressDialogHandler != null) {
mProgressDialogHandler.obtainMessage(ProgressDialogHandler.DISMISS_PROGRESS_DIALOG).sendToTarget();
mProgressDialogHandler = null;
}
}
@Override
public void onSubscribe(Disposable d) {
//顯示進度條
if (isNeedProgressDialog()) {
showProgressDialog();
}
if (null != mBaseImpl) {
if (null != d) {
mBaseImpl.addDisposable(d);
}
}
}
@Override
public void onNext(T value) {
//成功
Log.d(TAG, "http is onNext");
if (null != value) {
onBaseNext(value);
}
}
@Override
public void onError(Throwable e) {
//關閉進度條
Log.e(TAG, "http is onError");
if (isNeedProgressDialog()) {
dismissProgressDialog();
}
onBaseError(e);
}
@Override
public void onComplete() {
//關閉進度條
if (isNeedProgressDialog()) {
dismissProgressDialog();
}
}
}這里考慮到有些界面需要進度框，所以我把這一部分也整合到觀察者里面，這里根據(jù)外面調用的地方有沒有設置 Title來判斷是否顯示進度框，然后再進行相應的回調，進度框使用的是系統(tǒng)的 ProgressDialog，當然了，你也可以自定義一個進度框樣式，詳細見 demo。前面我們說到我們只關心成功的數(shù)據(jù)，失敗的數(shù)據(jù)我們需要在內部處理掉，即再封裝一層，吃掉 onBaseError：
public abstract class CygBaseObserver<T> extends BaseObserver<T> {
private static final String TAG = "CygBaseObserver";
private boolean isNeedProgress;
private String titleMsg;
public CygBaseObserver() {
this(null, null);
}
public CygBaseObserver(BaseImpl base) {
this(base, null);
}
public CygBaseObserver(BaseImpl base, String titleMsg) {
super(base);
this.titleMsg = titleMsg;
if (TextUtils.isEmpty(titleMsg)) {
this.isNeedProgress = false;
} else {
this.isNeedProgress = true;
}
}
@Override
protected boolean isNeedProgressDialog() {
return isNeedProgress;
}
@Override
protected String getTitleMsg() {
return titleMsg;
}
@Override
protected void onBaseError(Throwable t) {
StringBuffer sb = new StringBuffer();
sb.append("請求失敗：");
if (t instanceof NetworkErrorException || t instanceof UnknownHostException || t instanceof ConnectException) {
sb.append("網(wǎng)絡異常");
} else if (t instanceof SocketTimeoutException || t instanceof InterruptedIOException || t instanceof TimeoutException) {
sb.append("請求超時");
} else if (t instanceof JsonSyntaxException) {
sb.append("請求不合法");
} else if (t instanceof JsonParseException
|| t instanceof JSONException
|| t instanceof ParseException) { // 解析錯誤
sb.append("解析錯誤");
} else if (t instanceof ApiException) {
if (((ApiException) t).isTokenExpried()) {
sb.append("Token出錯");
}
} else {
FRToast.showToastSafe(t.getMessage());
return;
}
Log.e(TAG, "onBaseError: " + sb.toString());
FRToast.showToastSafe(sb.toString());
}
}最開始的例子當中有一個 Disposable 的概念，這個是用來切斷觀察者與被觀察者之間的關系的，每次請求都會產生一個響應的 Disposable，所以這里我用了一個接口 BaseImpl 的形式來回收它，在產生的地方收集它，在 BaseActivity 的 onDestroy 中來回收它，詳細的請參見 demo；好了，到這里我們的封裝就完成了 90% 了，讓我們回到上一次博客當中，組裝 Observable的時候我們還進行了一個 map 操作：
這里 map 就是進行一個中間的操作，這個操作叫做變換，我們來看一下HttpFunction 的實現(xiàn)是怎樣的：
public class HttpFunction<T> implements Function<BaseResponse<T>, T> {
@Override
public T apply(BaseResponse<T> response) throws Exception {
if (!response.isRequestSuccess()) {
throw new ApiException(response.getStatus(), String.valueOf(response.getMsg()));
}
return response.getData();
}
}相信看完方法的實現(xiàn)大家應該知道這個是干什么用的了，沒錯，這個方法就是將 BaseResponse<T> 轉換成 T，因為我們只關注成功的數(shù)據(jù)，而且只關注data 里面的數(shù)據(jù)，由于返回的數(shù)據(jù)是 BaseResponse<T>，而我們需要關注的數(shù)據(jù)是T，所以在這里需要轉換一下，然后判斷請求是否成功就行了。
好了，到這里基本的網(wǎng)絡請求封裝就完成了，如果你有更好的方法，請私信我一起交流，同時感謝以上引用到博客的博主。最后的最后，放出最后的代碼，歡迎 star 和 fork
MVP 主工程代碼
https://github.com/Jakemesdg/MVPDemo
MVP module工程代碼
https://github.com/Jakemesdg/cygmodule
