一點點入坑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設計,但願可以給你們在業務架構上帶來幫助。

我是一個應屆生,最近和朋友們維護了一個公衆號,內容是咱們在從應屆生過渡到開發這一路所踩過的坑,以及咱們一步步學習的記錄,若是感興趣的朋友能夠關注一下,一同加油~

我的公衆號:鹹魚正翻身
相關文章
相關標籤/搜索