【Retrofit第三篇】CallAdapter，即使是有趣的灵魂，也需要铸造合适的身体。 2021-05-15 23:27:34

你是否觉得，想请求一个结果，需要调用一个enqueue，还要判断状态码这些，是一个蛋疼的设计？甚至感觉为了调用一个enqueue去写一个interface，似乎也多此一举？

如果转换器铸造的是灵魂，那么适配器便是铸造了身体，这也是retorfit经久不衰的原因之一(其实就是朋友多，例如适配了rxjava还适配了协程)。实际开发中，enqueue并不是常用的回调方案(底层是)，我们往往需要加上合适的适配器。

(最大的缺陷大概就是，需要写一堆类，如果还没多少代码，那就是一堆内部类)

假设我们需求是，执行了enqueue后，把回调简化，不需要判断是否请求成功啥的，不成功统一交给error。内容不多，直接上代码吧。

class MyAdapterFactory private constructor() : CallAdapter.Factory() {

companion object {
        @JvmStatic @JvmName("create")
        operator fun invoke() = MyAdapterFactory()
    }

override fun get(returnType: Type, annotations: Array<out Annotation>, retrofit: Retrofit): CallAdapter<*, *>? {
        //获取返回的数据类型
        val responseType = getParameterUpperBound(0, returnType as ParameterizedType)
        return object : CallAdapter<Any, MyCall<*>> {
            //告诉Factory，返回的数据类型是什么
            override fun responseType(): Type {
                return responseType
            }

override fun adapt(call: Call<Any>): MyCall<*> {
                return CompletableMyCall(call)
            }

}
    }

//实现一个请求接口，用于请求
    private class CompletableMyCall<T>(private val call: Call<T>) : MyCall<T>
    {
        override fun enqueue(callback: MyCallBack<T>) {
            call.enqueue(object : Callback<T> {
                override fun onResponse(call: Call<T>, response: Response<T>) {
                    if (response.isSuccessful) {
                        callback.success(response.body()!!)
                    } else {
                        callback.error(HttpException(response))
                    }
                }

override fun onFailure(call: Call<T>, t: Throwable) {
                    callback.error(t)
                }

})
        }

}

//这是一个用于请求的接口
    //为了便于演示，这里我就只提供一个方法
    interface MyCall<T> {
        //请求
        fun enqueue(callback: MyCallBack<T>)
    }

//我们也需要定义一个用于返回的callback
    interface MyCallBack<T> {
        //请求成功时返回
        fun success(response: T)
        //请求失败时返回
        fun error(throwable: Throwable)
    }
}

请求

这样我们就能明白，为什么retrofit请求前还要多创建一个interface，因为适配器的存在，让你的请求结果更具有灵活力。总之，代码执行过程，你爱怎么封装就怎么封装

不过适配器说白了就是让自己写得更爽而已，一般情况下都不需要自己写，都有开源好的。

例如，你想配合rxjava，添加依赖即可。

首先，添加依赖：

修改你的然后请求过程变成这样

再来一个例子，我们用的是kotlin写的，那怎能忘了协程呢？

添加依赖：

请求方式改为如下：

我特喜欢用协程请求，至少比rxjava舒服很多。

适配器就这些吧，也没什么难的，更多写法建议一些例子，例如retrofit2.DefaultCallAdapterFactory，或者协程的源码：com.jakewharton.retrofit2.adapter.kotlin.coroutines.CoroutineCallAdapterFactory

原创文章,转载请注明出处

【Retrofit第三篇】CallAdapter，即使是有趣的灵魂，也需要铸造合适的身体。 2021-05-15 23:27:34

警告