Android Jetpack架構中ViewModel介面暴露的不合理探究

2022-07-22 18:00:04

暴露 Mutable 狀態

ViewModel 對外暴露的資料狀態，無論是 LiveData 或是 StateFlow 都應該使用 Immutable 的介面型別進行暴露而非 Mutable 的具體實現。View 只能單向訂閱這些狀態的變化，避免對狀態反向更新。

class MyViewModel: ViewModel() {
   private val _loading = MutableLiveData<Boolean>()
   val loading: LiveData<Boolean>
       get() = _loading
}

未來避免暴露 Mutable 型別，我們需要像上面這樣處理，將 loading 的具體實現定義為一個 private 的 Mutable 型別，便於內部更新。

private val _loading : MutableStateFlow<Boolean?> = MutableStateFlow(null)
val loading = _loading.asStateFlow()

StateFlow 的寫法也類似，但是通過 asStateFlow 可以少寫一個型別宣告，但是要注意此時不要使用 custom get()，不然 asStateFlow 會執行多次。

每次都要多宣告一個帶劃線的私有變數會讓程式碼顯得有些累贅，也正因如此，有 issue 希望 Kotlin 增加類似下面的語法使得對外對內可以暴露不同型別。

//https://youtrack.jetbrains.com/issue/KT-14663
private val loading = MutableLiveData<Boolean>()
        public get(): LiveData<Boolean>

在新語法還未出現的當下，一個讓程式碼變整潔的思路是為 ViewModel 提取對外暴露的抽象類：

abstract class MyViewModel: ViewModel() {
   abstract val loading: LiveData<Boolean>
}
class MyViewModelImpl: MyViewModel() {
   override val loading = MutableLiveData<Boolean>()
   fun doSomeWork() {
     // ...
     loading.value = true
   }
}

如上， MyViewModelImpl 內重寫的 loading 可以作為 Mutable 型別使用。雖然這種做法會增加了一個抽象類程式碼量不減反增，但是它使 MyViewModelImpl 內的程式碼更加簡潔，而且對外可以隱藏更多 ViewModel 的實現細節，封裝性更好。

但是需要特別注意的是，為了建立 MyViewModel 必須使用自定義 Factory：

val vm : MyViewModel by viewModels { MyViewModelFactory() }

如果你的工程引入了 Hilt ，那麼可以通過 @Bind 繫結 ViewModel 的介面與實現，無需自定義 Factory 了，寫法跟以前一樣，直接使用 by viewModels() 即可

@Module
@InstallIn(ViewModelComponent::class)
abstract class MyViewModule {
    @Binds
    abstract fun MyViewModel(instance: MyViewModelImpl): MyViewModel
}
@HiltViewModel
class MyViewModelImpl @Inject constructor() : MyViewModel()

暴露 Suspend 方法

相對於暴露 Mutable 狀態，暴露 Suspend 方法的錯誤則更為常見。

按照單向資料流的思想 ViewModel 需要提供 API 給 View 用於傳送 Events，我們在定義 API 時需要注意避免使用 Suspend 函數，理由如下：

來自 ViewModel 的資料應該通過訂閱 UiState 獲取，因此 ViewModel 的其他方法方法不應該有返回值，而 suspend 函數會鼓勵返回值的出現。
理想的 MVVM 中 View 的職責僅僅是渲染 UI，業務邏輯儘量移動到 ViewModel 執行，利於單元測試的同時，ViewModelScope 可以保證一些耗時任務的穩定執行。如果暴露掛起函數給 View，則協程需要在 lifecycleScope 中啟動，在橫豎屏等場景中會中斷任務的進行。

因此，ViewModel 為 View 暴露的 API 應該是非掛起且無法返回值的方法，以下是官網的程式碼範例：

// DO create coroutines in the ViewModel
class LatestNewsViewModel(
    private val getLatestNewsWithAuthors: GetLatestNewsWithAuthorsUseCase
) : ViewModel() {
    private val _uiState = MutableStateFlow<LatestNewsUiState>(LatestNewsUiState.Loading)
    val uiState: StateFlow<LatestNewsUiState> = _uiState
    fun loadNews() {
        viewModelScope.launch {
            val latestNewsWithAuthors = getLatestNewsWithAuthors()
            _uiState.value = LatestNewsUiState.Success(latestNewsWithAuthors)
        }
    }
}
// Prefer observable state rather than suspend functions from the ViewModel
class LatestNewsViewModel(
    private val getLatestNewsWithAuthors: GetLatestNewsWithAuthorsUseCase
) : ViewModel() {
    // DO NOT do this. News would probably need to be refreshed as well.
    // Instead of exposing a single value with a suspend function, news should
    // be exposed using a stream of data as in the code snippet above.
    suspend fun loadNews() = getLatestNewsWithAuthors()
}

程式碼中建議暴露一個普通的無返回值的 loadNews ，而 latestNewsWithAuthors 的資訊應該通過訂閱 LatestNewsUiState 獲得。

有一點讓人迷惑的是，官方檔案上有這麼一句話：

Suspend functions in the ViewModel can be useful if instead of exposing state using a stream of data, only a single value needs to be emitted.

連結

對於單發資料的請求允許使用掛起函數返回。但我建議大家忘掉這句話，理由有兩點：

掛起函數的口子一開就容易不分場景的濫用，如果整體資料流結構造成破壞反而因小失大，索性應該從源頭禁止
理論上來說，UI 上不存在單發資料請求的必要性，完全可以通過良好的設計轉化成 UiState ，這也更符合響應式的程式設計模型。

到此這篇關於Android Jetpack架構中ViewModel介面暴露的不合理探究的文章就介紹到這了,更多相關Android ViewModel介面內容請搜尋it145.com以前的文章或繼續瀏覽下面的相關文章希望大家以後多多支援it145.com！

Android Jetpack架構中ViewModel介面暴露的不合理探究

目錄

暴露 Mutable 狀態

暴露 Suspend 方法

熱門文章