前言
在App中,對于網(wǎng)絡請求狀態(tài)一般性的就分為加載中、請求錯誤、請求成功、請求成功但數(shù)據(jù)為null。為了用戶體驗,不同的狀態(tài)需要對用戶展示不同的界面,例如網(wǎng)絡異常的提醒,點擊重新請求等。
之前項目一直都是以Retrofit+RxJava+OkHttp為網(wǎng)絡請求框架,RxJava已經(jīng)很好的封裝了不同的請求狀態(tài),onSubscribe、onNext、onError等,只需要在不同的回調(diào)中做出相應的動作就ok了。
RxJava很好用,但隨著新技術(shù)的出現(xiàn),RxJava的可替代性也就越高。Kotlin的協(xié)程就是這么一個存在。
本文是以Jetpack架構(gòu)為基礎(chǔ),協(xié)程+Retrofit+Okhttp為網(wǎng)絡請求框架,對不同的請求狀態(tài)(loading,error,empty等)做了封裝,讓開發(fā)者不用再去關(guān)心哪里需要loading,哪里需要展示error提示。
同時,在封裝的過程中,Jetpack和協(xié)程的使用也存在著幾個坑,本文也將一一描述。
協(xié)程的基本使用
API:www.wanandroid.com/project/tre… 來自鴻洋大大的wanandroid
如果需要使用協(xié)程,則添加依賴
dependencies {
implementation 'org.jetbrains.kotlinx:kotlinx-coroutines-android:1.3.9'
}
復制代碼
在Retrofit2.6.0前,我們使用協(xié)程,api請求后返回的數(shù)據(jù)可以用Call或者Defeerd包裹處理,2.6后,可以直接返回數(shù)據(jù),只不過需要加上suspend的修飾,如下:
interface ProjectApi {
@GET("project/tree/json")
suspend fun loadProjectTree(): BaseResp<List<ProjectTree>>
}
復制代碼
因為使用的是Jetpack架構(gòu),所以將整個網(wǎng)絡請求主要分為UI、ViewModel、Repository三層,以LiveData為媒介進行通信。
首先是Repository層進行網(wǎng)絡請求,
class ProjectRepo{
private lateinit var mService: ProjectApi
init {
mService = RetrofitManager.initRetrofit().getService(ProjectApi::class.java)
}
suspend fun loadProjectTree(): List<ProjectTree> {
return mService.loadProjectTree()
}
}
復制代碼
利用Retrofit和OkHttp創(chuàng)建了一個apiService,內(nèi)部細節(jié)在這里就先不展開,接著直接調(diào)用loadProjectTree()進行網(wǎng)絡請求,將數(shù)據(jù)返回。loadProjectTree()用suspend關(guān)鍵字進行標記,Kotlin 利用此關(guān)鍵字強制從協(xié)程內(nèi)調(diào)用函數(shù)。
接著ViewModel層,
class ProjectViewModel : ViewModel(){
//LiveData
val mProjectTreeLiveData = MutableLiveData<List<ProjectTree>>()
fun loadProjectTree() {
viewModelScope.launch(Dispatchers.IO) {
val data = mRepo.loadProjectTree()
mProjectTreeLiveData.postValue(data)
}
}
}
復制代碼
創(chuàng)建類ProjectViewModel并繼承ViewModel,內(nèi)部新建一個LiveData做UI通信使用,利用viewModelScope.launch(Dispatchers.IO) 創(chuàng)建一個新的協(xié)程,然后在 I/O 線程上執(zhí)行網(wǎng)絡請求,請求的數(shù)據(jù)利用LiveData通知給UI。
這里提到了viewModelScope.launch(Dispatchers.IO),viewModelScope是一個協(xié)程的作用域,ViewModel KTX 擴展中已經(jīng)將此作用域封裝好,直接使用就可以。Dispatchers.IO 表示此協(xié)程在 I/O線程上執(zhí)行,而launch則是創(chuàng)建一個新的協(xié)程。
最后是UI層,
class ProjectFragment : Fragment {
override fun initData() {
//請求數(shù)據(jù),調(diào)用loadProjectTree
mViewModel?.loadProjectTree()
mViewModel?.mProjectTreeLiveData?.observe(this, Observer {
//更新UI
})
}
復制代碼
UI層開始調(diào)用ViewModel的請求方法執(zhí)行網(wǎng)絡請求,LiveData注冊一個觀察者,觀察數(shù)據(jù)變化,并且更新UI。
到這里,網(wǎng)絡請求的邏輯基本上通順了。
在一切環(huán)境正常的情況下,上面的請求是可以的,但是app還存在網(wǎng)絡不暢,異常,數(shù)據(jù)為null的情況,上述就不在滿足要求了,接下來就開始對數(shù)據(jù)異常的情況進行處理。
網(wǎng)絡請求異常處理
對于協(xié)程異常的處理,Android開發(fā)者的官網(wǎng)上也給出了答案(developer.android.google.cn/kotlin/coro… ) ,直接對網(wǎng)絡請求進行一個try-catch處理,發(fā)生異常了,直接在catch中做出相應動作就ok了,我們就來看看具體實現(xiàn)。
class ProjectViewModel : ViewModel(){
//LiveData
val mProjectTreeLiveData = MutableLiveData<List<ProjectTree>>()
fun loadProjectTree() {
viewModelScope.launch(Dispatchers.IO) {
try {
val data = mRepo.loadProjectTree()
mProjectTreeLiveData.postValue(data)
} catch (e: Exception) {
//異常
error(e)
} finally {
}
}
}
}
復制代碼
還是在ViewModel層,對mRepo.loadProjectTree()的請求加上了try-catch塊,當發(fā)生異常時根據(jù)Exception類型對用戶做出提示。
到這里,異常的來源已經(jīng)找到了,接著就需要將異常顯示在UI層來提醒用戶。我們都知道m(xù)ProjectTreeLiveData利用PostValue將數(shù)據(jù)分發(fā)給了UI,如法炮制,也就可以利用LiveData將異常也分發(fā)給UI。
說干就干。
網(wǎng)絡請求狀態(tài)封裝
1、 [Error狀態(tài)]
依舊在ViewModel層,我們新添加一個針對異常的LiveData:errorLiveData
class ProjectViewModel : ViewModel(){
//異常LiveData
val errorLiveData = MutableLiveData<Throwable>()
//LiveData
val mProjectTreeLiveData = MutableLiveData<List<ProjectTree>>()
fun loadProjectTree() {
viewModelScope.launch(Dispatchers.IO) {
try {
val data = mRepo.loadProjectTree()
mProjectTreeLiveData.postValue(data)
} catch (e: Exception) {
//異常
error(e)
errorLiveData.postValue(e)
} finally {
}
}
}
}
復制代碼
在UI層,利用errorLiveData注冊一個觀察者,如果有異常通知,則顯示異常的UI(UI層代碼省略)。這樣確實可以實現(xiàn)我們一開始要的功能:請求成功則顯示成功界面,失敗顯示異常界面。但是有一個問題,就是不夠優(yōu)雅,如果有多個ViewModel,多個UI,那就要每個頁面都要寫errorLiveData,很冗余。
那我們可以將公共方法抽離出來,新建一個BaseViewModel類,
open class BaseViewModel : ViewModel() {
val errorLiveData = MutableLiveData<Throwable>()
fun launch(
block: suspend () -> Unit,
error: suspend (Throwable) -> Unit,
complete: suspend () -> Unit
) {
viewModelScope.launch(Dispatchers.IO) {
try {
block()
} catch (e: Exception) {
error(e)
} finally {
complete()
}
}
}
}
復制代碼
除了定義errorLiveData外,還將新建協(xié)程的操作放到其中,開發(fā)者只需要將每個ViewModel繼承BaseViewModel,重寫launch()即可,那么上面的案例中的ViewModel就修改成下面這種,
class ProjectViewModel : BaseViewModel(){
//LiveData
val mProjectTreeLiveData = MutableLiveData<List<ProjectTree>>()
fun loadProjectTree() {
launch(
{
val state = mRepo.loadProjectTree()
mProjectTreeLiveData.postValue(state.data)
},
{
errorLiveData.postValue(it)
},
{
loadingLiveData.postValue(false)
}
)
}
}
復制代碼
同樣的,UI層也可以新建一個BaseFragment抽象類,在onViewCreated中利用errorLiveData注冊觀察者,收到異常通知,則進行相應的動作。
abstract class BaseFragment<T : ViewDataBinding, VM : BaseViewModel> : Fragment(){
override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
super.onViewCreated(view, savedInstanceState)
mViewModel = getViewModel()
mViewModel?.errorLiveData?.observe(viewLifecycleOwner, Observer {
Log.d(TAG, "onViewCreated: error ")
showError()
throwableHandler(it)
})
}
}
復制代碼
每個子Fragment只需要繼承BaseFragment即可,具體的異常監(jiān)聽就不用開發(fā)者管理。
2、 [Loading狀態(tài)]
除了異常狀態(tài)外,請求必不可少的就是Loading,這里Loading分為兩種,一種是整個頁面替換為Loading,例如Recyclerview列表時,就可以直接整個頁面先Loading,而后顯示數(shù)據(jù);還有一種是數(shù)據(jù)界面不替換,只是個Loading Dialog顯示在上層,例如點擊登錄時,需要一個loading。
Loading和異常處理的思路一致,可以在BaseViewModel中添加一個LoadingLiveData,數(shù)據(jù)類型為Boolean,在每個請求一開始LoadingLiveData.postValue(true),結(jié)束請求或者請求異常時,就LoadingLiveData.postValue(false)。UI層BaseFragment中,則可以監(jiān)聽LoadingLiveData發(fā)出的是true還是false,以便對Loading的顯示和隱藏進行控制。
ViewModel層:
open class BaseViewModel : ViewModel() {
//加載中
val loadingLiveData = SingleLiveData<Boolean>()
//異常
val errorLiveData = SingleLiveData<Throwable>()
fun launch(
block: suspend () -> Unit,
error: suspend (Throwable) -> Unit,
complete: suspend () -> Unit
) {
loadingLiveData.postValue(true)
viewModelScope.launch(Dispatchers.IO) {
try {
block()
} catch (e: Exception) {
Log.d(TAG, "launch: error ")
error(e)
} finally {
complete()
}
}
}
}
復制代碼
在BaseViewModel 中l(wèi)aunch一開始就通知Loading顯示,在try-catch-finally代碼塊的finally中將請求結(jié)束的通知分發(fā)出去。
UI層:
abstract class BaseFragment<T : ViewDataBinding, VM : BaseViewModel> : Fragment(){
override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
super.onViewCreated(view, savedInstanceState)
mViewModel = getViewModel()
//Loading 顯示隱藏的監(jiān)聽
mViewModel?.loadingLiveData?.observe(viewLifecycleOwner, Observer {
if (it) {
//show loading
showLoading()
} else {
dismissLoading()
}
})
//請求異常的監(jiān)聽
mViewModel?.errorLiveData?.observe(viewLifecycleOwner, Observer {
Log.d(TAG, "onViewCreated: error ")
showError()
throwableHandler(it)
})
}
}
復制代碼
注冊一個loading的觀察者,當通知為true時,顯示loading,false則隱藏。
3、 [Empty狀態(tài)]
數(shù)據(jù)為空的狀態(tài)發(fā)生在請求成功后,對于這種情況,可以直接在UI層中,請求成功的監(jiān)聽中對數(shù)據(jù)是否為null進行判斷。
到這里,網(wǎng)絡請求的基本封裝已經(jīng)完成,但是在運行測試的過程中,存在幾個問題需要去解決,例如網(wǎng)絡不通的情況下try-catch卻不會拋出異常。接下來就開始進行二次封裝。
暴露問題二次封裝
問題一:網(wǎng)絡請求異常,try-catch卻不會將異常拋出
因為業(yè)務場景比較復雜,只依賴try-catch來獲取異常,明顯也會有所遺漏,那這種情況下我們可以直接以服務器返回的code,作為請求狀態(tài)的依據(jù)。以上面Wanandroid的api為例,當errorCode=0時,則表示請求成功,其他的值都表示失敗,那這就好辦了。
我們新建一個密封類ResState,存放Success和Error狀態(tài),
sealed class ResState<out T : Any> {
data class Success<out T : Any>(val data: T) : ResState<T>()
data class Error(val exception: Exception) : ResState<Nothing>()
}
復制代碼
對Repository層請求返回的數(shù)據(jù)進行code判斷處理,新建一個BaseRepository類,
open class BaseRepository() {
suspend fun <T : Any> executeResp(
resp: BaseResp<T>, successBlock: (suspend CoroutineScope.() -> Unit)? = null,
errorBlock: (suspend CoroutineScope.() -> Unit)? = null
): ResState<T> {
return coroutineScope {
if (resp.errorCode == 0) {
successBlock?.let { it() }
ResState.Success(resp.data)
} else {
Log.d(TAG, "executeResp: error")
errorBlock?.let { it() }
ResState.Error(IOException(resp.errorMsg))
}
}
}
}
復制代碼
當errorCode == 0時,將ResState置為Success并將數(shù)據(jù)返回,errorCode !=0時,則將狀態(tài)置為Error并將Exception返回。而子Repository則只需要繼承BaseRepository即可,
class ProjectRepo : BaseRepository() {
suspend fun loadProjectTree(): ResState<List<ProjectTree>> {
return executeResp(mService.loadProjectTree())
}
復制代碼
修改后返回值用ResState<>包裹,并直接將請求的結(jié)果傳給executeResp()方法,而ViewModel中也做出相應的修改,
class ProjectViewModel : BaseViewModel() {
val mProjectTreeLiveData = MutableLiveData<List<ProjectTree>>()
fun loadProjectTree() {
launch(
{
val state = mRepo.loadProjectTree()
//添加ResState判斷
if (state is ResState.Success) {
mProjectTreeLiveData.postValue(state.data)
} else if (state is ResState.Error) {
Log.d(TAG, "loadProjectTree: ResState.Error")
errorLiveData.postValue(state.exception)
}
},
{
errorLiveData.postValue(it)
},
{
loadingLiveData.postValue(false)
}
)
}
}
復制代碼
ViewModel層新增了一個ResState判斷,通過請求的返回值ResState,如果是ResState.Success則將數(shù)據(jù)通知給UI,如果是ResState.Error,則將異常通知給UI。
以服務器返回的code值進行判斷,無疑是最準確的。
問題二:errorLiveData注冊觀察者一次后,不管請求失敗還是成功,它還是會收到通知。
這是MutableLiveData的一個特性,只要當注冊的觀察者處于前臺時,都會收到通知。那這個特性又影響了什么呢? 我在errorLiveData的監(jiān)聽中,對不同的異常進行了Toast的彈出提醒,如果每次進入一個頁面,雖然請求成功了,但是因為errorLiveData還是能接收到通知,就會彈出一個Toast提醒框?,F(xiàn)象如下:
那我們針對MutableLiveData將其修改為單事件響應的liveData,只有一個接收者能接收到信息,可以避免不必要的業(yè)務的場景中的事件消費通知。
class SingleLiveData<T> : MutableLiveData<T>() {
private val mPending = AtomicBoolean(false)
@MainThread
override fun observe(owner: LifecycleOwner, observer: Observer<in T>) {
if (hasActiveObservers()) {
Log.w(TAG, "多個觀察者存在的時候,只會有一個被通知到數(shù)據(jù)更新")
}
super.observe(owner, Observer { t ->
if (mPending.compareAndSet(true, false)) {
observer.onChanged(t)
}
})
}
override fun setValue(value: T?) {
mPending.set(true)
super.setValue(value)
}
@MainThread
fun call() {
value = null
}
companion object {
private const val TAG = "SingleLiveData"
}
}
復制代碼
將BaseViewModel中的MutableLiveData替換為SingleLiveData就可以了。
最后
至此,協(xié)程+Retrofit網(wǎng)絡請求狀態(tài)封裝也就完成了,對于Error、Empty等view的切換以及點擊重新請求等操作,這里就不一一展示了,可以移步到github里查看。最后我們來看一下請求效果。
本文在開源項目:https://github.com/Android-Alvin/Android-LearningNotes 中已收錄,里面包含不同方向的自學編程路線、面試題集合/面經(jīng)、及系列技術(shù)文章等,資源持續(xù)更新中...