RxRetroHttp is created for adapting multiple API requests

Preface

"The backend is updated and replaced, the new interface returns all new rules, and the old interface remains unchanged!" . . WTF!

"We want to build a unified app for these websites, and the backend is ready-made, and this is the API document." . . The API specifications and requested Host addresses of several websites are completely different? . . . WTF!

Switch BaseUrl in real time? Retrofit annotation is all added to @Url? . . . have no choice. . .

Although there are already many Http request frameworks, there are also many secondary encapsulations for RxJava+Retrofit, and there are also many frameworks that dynamically replace BaseUrl. However, if you need to better deal with requirements other than BaseUrl, such as different interception processing, different return exception logic processing, etc., most of them have no solutions. Therefore, RxRetroHttp came into being.

Overview

Let's first take a look at how RxRetroHttp handles this situation.

initialization

First of all, the necessary stage for most libraries: initialization. Let's first look at the initialization code and execute it in the onCreate of Application

(this)
      .setBaseUrl("/")
      .setApiResultClass()
      .generateRetroClient()

In this way, the initialization is done. . . There should be applause here. . .

What about the promised handling multiple API rules! ! ! ”

Ugh, cough. . . Don't be impatient. . . Come slowly when I say

Through the initialization just now, you have set up the basic configuration for the main API request in the App. If your app needs to connect to multiple sets of API rules as described in the preface, then after initialization, add the following code

()
      .setBaseUrl("/")
      .setApiResultClass()
      .generateRetroClient("API2")

I believe everyone has seen the difference. That's right, a tag is added to the generateRetroClient method, and this tag is the key to handling multiple API requests.

In the setApiResultClass method, the base class for the API specification is passed in, and the specific situation will be discussed later.

Call

How to call after initialization is completed

().getApi2Info()

We can see that this is how Retrofit style calls.

Here, Api2Service is also the Retrofit-style ApiService, but it is also slightly different

@RetroTag("API2")
public interface Api2Service {
  @GET("test/info")
  Observable<Api2Info> getApi2Info();
}

Let's see what's the difference. Here's how to write pure Retrofit

public interface Api2Service {
  @GET("test/info")
  Observable<Api2Result<Api2Info>> getApi2Info();
}

Yes, the difference is:

1. This layer of package is eliminated in the base class. The reason for this is that I personally think that at the ApiService level, it is inhumane to set an ApiResult package for each interface definition, hahaha.

2. The RetroTag interface is used to indicate the tag. Of course, this is an API request for the tag set during initialization.

Of course, if you still want to wrap it in the base class, it is OK, that is, when initializing, you just don't call the setApiResultClass method.

In addition, if you don't want to add RetroTag annotation, it is also OK. When calling, you need to call another method and put the tag, as follows:

(, "API2").getApi2Info()

ApiResult

Now, let's take a look at ApiResult.

What is passed in the setApiResultClass method is the request return base class that implements the IApiResult interface. The simple sample code is as follows

public class Api2Result<T> implements IApiResult<T> {
  private int code;
  private String msg;
  private T result;
  @Override
  public boolean isSuccess(){
    return code == 1;
  }
  @Override
  public T getData(){
    return result;
  }
  @Override
  public String getResultMsg(){
    return msg;
  }
  @Override
  public String getResultCode(){
    return (code);
  }
  @Override
  public String getDataField(){
    return "result";
  }
}

The corresponding return json is as follows

{
  code: 1,
  msg: "Request succeeded",
  result: {
    ...
  }
}

This is a relatively common API return format, and what we need to do is to implement several basic methods. Among them, isSuccess() returns the judgment of the request success, getData() returns the specific data requested, getResultMsg() returns the API request information, getResultCode() represents the return code, and getDataField() returns the field in json data that represents the specific data (in the above json example, it is "result").

More configurations

It is impossible for Http requests to have no related configurations, and this framework does not have many configuration methods built in for everyone. The reason is that I don’t think this is the main function of this framework. Of course, you can also customize the configuration, the configuration method is as follows:

(this).setXXX().setXXX();
 retrofitBuilder = ();
().setXXX();
 okHttpBuilder = ();
().setXXX();
().generateRetroClient();
//().generateRetroClient("YourTag")

Of course, the configuration between each set of API requests is also isolated. The framework also provides some simple and fast configuration methods, such as addInterceptor, addNetworkInterceptor, etc. More configurations can be configured through the above methods, obtain retrofitBuilder and okHttpBuilder.

The method of using tags may not be the best. I will continue to try other methods to compare convenience. If you have a better solution, I hope to leave a message to tell me. Thank you.

Summarize

The above is the entire content of this article. I hope that the content of this article has certain reference value for your study or work. Thank you for your support. If you want to know more about it, please see the relevant links below