一点点入坑JetPack:实战前戏NetworkBoundResource篇

前言

最近很不顺利,天天晚上回家都打不到车!以前晚上10点很容易叫到车,不是说好996福报的么?难不成你们都在享受福报,司机都忙不过来了?管他呢,就算打不到车,我也要学习,毕竟一天不学习我浑身难受!android

以前几篇文章聊过JatPack中LiveData和ViewModel的基本使用和原理。历史文章以下:git

一点点入坑JetPack:ViewModel篇github

一点点入坑JetPack:Lifecycle篇api

一点点入坑JetPack:LiveData篇缓存

一点点入坑JetPack:实战前戏NetworkBoundResource篇网络

一点点入坑JetPack(终章):实战MVVM架构

今天我们继续看一下实际的应用。实战篇初步打算俩篇文章,分别是:app

  • Google Sample写的一个简易的网络框架:NetworkBoundResource。
  • MVVM项目实战

NetworkBoundResource篇

1、什么是NetworkBoundResource

首先来讲一下 NetworkBoundResource是什么,其实 NetworkBoundResource单纯就是一个类,全类也就100+行。是Google Sample中结合LiveData的一个颇为高效的网络处理逻辑规范框架

可是这个类结合LiveData,创造了极为便利的经常使用网络功能,好比:ide

  • 不请求网络,直接使用缓存
  • 自定义策略,是否请求网络
  • 网络加载失败后使用缓存
  • 返回类型处理
  • 等等

不说了,直接上代码!先看一段这个类的使用:

// UI层直接调用这个方法,拿到LiveData,监听便可(固然,正常来讲须要设计一番,UI层直接粗暴的调用,不大合适~)
fun loadData(queryId: Long = -1): LiveData<Resource<DataResp>> {
        return object :
            NetworkBoundResource<DataResp, DataResp>(
                appExecutors
            ) {

            override fun saveCallResult(item: DataResp) {
                // 此方法,在网络数据回来后调用,咱们能够作一些持久化的逻辑
            }

            override fun shouldFetch(data: DataResp?): Boolean {
	            // 本身控制,是否触发网络请求,若是false,则调用loadFromDb()
                return isUseNetWork
            }

            override fun loadFromDb(): LiveData<MusicStoreMainResp> {
	            // 本身实现从非网络环境下获取数据的逻辑(好比内存,DB)
                return data
            }

            override fun createCall(): LiveData<ApiResponse<DataResp>> {
                return 
        }.asLiveData()
    }
复制代码

咱们能够看到,4个实现方法,分别对应了:

  • 数据返回后的持久化回调
  • 是否走网络请求
  • 从本地请求数据(业务方本身实现)
  • 网络请求(业务方本身实现)

对于咱们业务方来讲,只须要调用oadData(),而后observe(),返回的LiveData便可。

固然对应的正真的业务请求须要本身实现

2、NetworkBoundResource流程图

也就是说NetworkBoundResource帮咱们抽象了一系列的逻辑,并且,它的实现很是的短,让咱们来看一下代码,NetworkBoundResource作了什么?能帮咱们如此简单的完成这么多逻辑?

3、NetworkBoundResource源码实现

上源码:

详细使用能够参考Google Sample:github.com/googlesampl…

abstract class NetworkBoundResource @MainThread constructor(private val appExecutors: AppExecutors) {
//这里是业务能拿到的数据,livedata
//MediatorLiveData很少说了吧,上文已经介绍过了
private val result = MediatorLiveData<Resource<ResultType>>()
init {
    // 先发一个LOADIN,通知业务放处理LOADING态
    result.value = Resource.loading(null)
    @Suppress("LeakingThis")
    //db也是一个数据源
    val dbSource = loadFromDb()
    result.addSource(dbSource) { data ->
        //db的第一次回调,是用来判断数据有效期的
        result.removeSource(dbSource)
        //是否有效,业务自行定义(请求网络的策略)
        if (shouldFetch(data)) {
            fetchFromNetwork(dbSource)
        } else {
            //数据有效,从新观察一次,观察者会立马收到一次回调{Source.plug}
            result.addSource(dbSource) { newData ->
                setValue(Resource.success(newData))
            }
        }
    }
}
@MainThread
private fun setValue(newValue: Resource<ResultType>) {
    if (result.value != newValue) {
        result.value = newValue
    }
}
private fun fetchFromNetwork(dbSource: LiveData<ResultType>) {
    val apiResponse = createCall()
    // 将dbsource从新add,它将快速地发送其最新值。db有数据,可是过时了,先回调给业务展现
    // 这里保证了,LOADING态时也能够拿到数据,并展现给用户。
    result.addSource(dbSource) { newData ->
        setValue(Resource.loading(newData))
    }
    result.addSource(apiResponse) { response ->
        //这里又是用来控制流程,移除,避免数据乱入,并且设计者不让add重复的source
        result.removeSource(apiResponse)
        result.removeSource(dbSource)
        when (response) {
            is ApiSuccessResponse -> {
                appExecutors.diskIO.execute {
                    //数据回来先存缓存,这样咱们下次请求过来时,可能保证LOADING态拿到的数据是最新的。 
                    saveCallResult(processResponse(response))
                    appExecutors.mainThread.execute {
                        // 原注释:we specially request a new live data,
                        // otherwise we will get immediately last cached value,
                        // which may not be updated with latest results received from network.
                        //从新从库里面读取
                        result.addSource(loadFromDb()) { newData ->
                            setValue(Resource.success(newData))
                        }
                    }
                }
            }
            is ApiEmptyResponse -> {
                appExecutors.mainThread.execute {
                    // reload from disk whatever we had
                    result.addSource(loadFromDb()) { newData ->
                        setValue(Resource.success(newData))
                    }
                }
            }
            is ApiErrorResponse -> {
                onFetchFailed()
                result.addSource(dbSource) { newData ->
                    setValue(Resource.error(response.exception, newData))
                }
            }
        }
    }
}
// 业务方自行处理的抽象方法
protected open fun onFetchFailed() {}
fun asLiveData() = result as LiveData<Resource<ResultType>>
@WorkerThread
protected open fun processResponse(response: ApiSuccessResponse<RequestType>) = response.data
@WorkerThread
protected abstract fun saveCallResult(item: RequestType)
@MainThread
protected abstract fun shouldFetch(data: ResultType?): Boolean
@MainThread
protected abstract fun loadFromDb(): LiveData<ResultType>
@MainThread
protected abstract fun createCall(): LiveData<ApiResponse<RequestType>>
}
复制代码

尾声

这一部分,建议你们好好理解一下。由于真的真的真的很好用,它的设计结合了LiveData一系列的巧妙应用。理解以后,你们绝对会对LiveData有更加深刻的理解,而且在接下来的MVVM中,也会感觉到这其中的巧妙和爽快。

接下来的实战篇,基本就是结合NetworkBoundResource的MVVM设计,但愿可以给你们在业务架构上带来帮助。

我是一个应届生,最近和朋友们维护了一个公众号,内容是咱们在从应届生过渡到开发这一路所踩过的坑,以及咱们一步步学习的记录,若是感兴趣的朋友能够关注一下,一同加油~

我的公众号:咸鱼正翻身
相关文章
相关标签/搜索