安卓MVI架构真的来了?动手试着封装吧(二)上

简介: 安卓MVI架构真的来了?动手试着封装吧(二)

前言:由于框架本身也在不断地迭代,因此文章中的部分代码可能存在更新或者过时,如果你想阅读源码或者查看代码的在项目中的实际使用方法,可以查看笔者目前在维护的compose项目:Spacecraft: 《Spacecraft - 我的安卓技术实践平台》-查看代码请进入develop分支 (gitee.com)

本篇内容主要为如何把ViewModel改造成状态和事件的容器


当状态遇上了事件


  • 状态
    View在监听UI状态的时候,会记录初始值并初始化自身,如果后续的监听中,View发现了UI状态的值与之前发生了变化,就会更新自身(或者调用与之相关的逻辑代码)

image.png

image.png

  • 当状态中混杂了事件

image.png  可见,如果你把事件(例如toast事件)也当成UI状态的一部分的时候,那么这个只需要显示一次的toast就会被携带到下次UI重构中,以一种“状态”的方式复活,即数据倒灌。


事件与状态分手吧


  如果我们不希望事件以一种状态的方式被倒灌到下次UI重构中,就把它从状态中提取出来吧。在谷歌的开发者文档中,UiState是用kotlin语言中的StateFlow实现的,而StateFlow是一种特殊的SharedFlow,因此使用SharedFlow来表示事件流,而状态就用原本的StateFlow。

如果你对SharedFlow和StateFlow还不是特别理解,可以参考以下的文档(为掘金其他优秀作者撰写,仅供参考):


@Keep
interface UiState
@Keep
interface UiSingleEvent

  我并不希望对ViewModel进行直接封装成容器本身,即实现一套类似BaseViewModel的东东,这种继承重写的方式也许可以实现我的需求,但是过于生硬,也不容易对现有的代码进行重构(修改基类过于蛋疼),因此我更希望容器和viewModel的关系更像activity和viewModel的关系。


//activity中的viewModel
private val viewModel by viewModels<FriendViewModel>()
//希望实现类似的api
private val container by containers()

  接下来,写一个容器接口,容器拥有状态和事件的流。


/**
 * 状态容器,分别存储UI状态和单次事件,如果不包含单次事件,则使用[Nothing]
 */
interface Container<STATE : UiState, SINGLE_EVENT : UiSingleEvent> {
    //ui状态流
    val uiStateFlow: StateFlow<STATE>
    //单次事件流
    val singleEventFlow: Flow<SINGLE_EVENT>
}

  我们对原来的接口增加一个直接子类,增加2个修改方法。这样做参考了List和MutableList的关系,MutableContainer是对内提供的(例如给viewModel使用),允许取值和修改;Container是对外提供的(例如activity,fragment等),只允许取值,这样避免了UI绕过viewModel直接修改UI状态的值,确保数据单向流动。


interface MutableContainer<STATE : UiState, SINGLE_EVENT : UiSingleEvent> :
    Container<STATE, SINGLE_EVENT> {
    //更新状态
    fun updateState(action: STATE.() -> STATE)
    //发送事件
    fun sendEvent(event: SINGLE_EVENT)
}

  最后,得出一个实现类,RealContainer,其中UI状态使用了StateFlow,UI事件则使用SharedFlow(确保事件不会倒灌)。


internal class RealContainer<STATE : UiState, SINGLE_EVENT : UiSingleEvent>(
    initialState: STATE,
    private val parentScope: CoroutineScope,
) : MutableContainer<STATE, SINGLE_EVENT> {
    private val _internalStateFlow = MutableStateFlow(initialState)
    private val _internalSingleEventSharedFlow = MutableSharedFlow<SINGLE_EVENT>()
    override val uiSteFlow: StateFlow<STATE> = _internalStateFlow
    override val singleEventFlow: Flow<SINGLE_EVENT> = _internalSingleEventSharedFlow
    override fun updateState(action: STATE.() -> STATE) {
        _internalStateFlow.update { action(_internalStateFlow.value) }
    }
    override fun sendEvent(event: SINGLE_EVENT) {
        parentScope.launch {
            _internalSingleEventSharedFlow.emit(event)
        }
    }
}


到这里,其实容器已经可以直接使用的了:在ViewModel中新增一个成员变量,然后new一个容器对象,viewModel对容器对象进行赋值操作,View层分别订阅2个流即可完成状态和事件的分离,即可完成状态和事件的分离。


相关文章
|
1月前
|
前端开发 JavaScript 测试技术
android做中大型项目完美的架构模式是什么?是MVVM吗?如果不是,是什么?
android做中大型项目完美的架构模式是什么?是MVVM吗?如果不是,是什么?
83 2
|
1月前
|
存储 前端开发 Java
Android MVVM架构模式下如何避免内存泄漏
Android采用MVVM架构开发项目,如何避免内存泄漏风险?怎样避免内存泄漏?
85 1
|
2月前
|
IDE Android开发 iOS开发
深入解析Android与iOS的系统架构及开发环境差异
本文旨在探讨Android和iOS两大主流移动操作系统在系统架构、开发环境和用户体验方面的显著差异。通过对比分析,我们将揭示这两种系统在设计理念、技术实现以及市场策略上的不同路径,帮助开发者更好地理解其特点,从而做出更合适的开发决策。
140 2
|
4天前
|
前端开发 JavaScript 测试技术
android做中大型项目完美的架构模式是什么?是MVVM吗?如果不是,是什么?
在 Android 开发中,选择合适的架构模式对于构建中大型项目至关重要。常见的架构模式有 MVVM、MVP、MVI、Clean Architecture 和 Flux/Redux。每种模式都有其优缺点和适用场景,例如 MVVM 适用于复杂 UI 状态和频繁更新,而 Clean Architecture 适合大型项目和多平台开发。选择合适的架构应考虑项目需求、团队熟悉度和可维护性。
23 5
|
4天前
|
安全 搜索推荐 Android开发
深入探索Android与iOS的系统架构差异
【10月更文挑战第29天】 在当今的智能手机市场中,Android和iOS无疑是两大主流操作系统。本文旨在深入探讨这两个系统的架构差异,从底层的操作系统设计到用户界面的呈现,以及它们如何影响了开发者和用户的体验。通过对比分析,我们可以更清晰地理解这两种平台的优势与局限,为开发者在选择开发平台时提供有价值的参考,同时也为用户选择设备提供一定的指导。
16 2
|
13天前
|
前端开发 JavaScript 测试技术
Android适合构建中大型项目的架构模式全面对比
Android适合构建中大型项目的架构模式全面对比
30 2
|
14天前
|
存储 前端开发 测试技术
Android kotlin MVVM 架构简单示例入门
Android kotlin MVVM 架构简单示例入门
22 1
|
5天前
|
前端开发 Java 测试技术
android MVP契约类架构模式与MVVM架构模式,哪种架构模式更好?
android MVP契约类架构模式与MVVM架构模式,哪种架构模式更好?
9 0
|
1月前
|
前端开发 Java 测试技术
android MVP契约类架构模式与MVVM架构模式,哪种架构模式更好?
android MVP契约类架构模式与MVVM架构模式,哪种架构模式更好?
19 2
|
1月前
|
安全 Android开发 iOS开发
深入解析:安卓与iOS的系统架构及其对应用开发的影响
本文旨在探讨安卓与iOS两大主流操作系统的架构差异,并分析这些差异如何影响应用开发的策略和实践。通过对比两者的设计哲学、安全机制、开发环境及性能优化等方面,本文揭示了各自的特点和优势,为开发者在选择平台和制定开发计划时提供参考依据。
48 4