如何延迟保存ViewModel的SavedStateHandle?

A1m*_*A1m 6 android viewmodel android-savedstate viewmodel-savedstate

我有一个屏幕,可以加载一堆请求并从同一屏幕上的用户和外部 WebView 收集一些数据。因此,我有一个包含这些复杂请求对象(+用户输入数据)的 ViewModel。我需要通过系统启动的进程死亡来持久保存这些数据,这SavedStateHandle是设计的目的。但我不想将这些数据保留在数据库中,因为它只与当前的用户体验相关。

我已将我的 ViewModel 与 Hilt 集成并收到了SaveStateHandle. 因为我有一些复杂的对象,可以在代码中的多个位置访问/修改它们,所以我无法“随时随地”保存它们。我让它们实现Parcelable,只是想立即保存它们。不幸的是,ViewModel 没有像onSaveInstanceState().

现在,我尝试使用onCleared()听起来像是写入句柄的好地方。但事实证明,.set()我在那里执行的所有操作都会丢失(我正在使用开发人员选项“不保留活动”进行测试。当我.set()在其他地方使用时,它确实有效)。因为 ViewModel 不依赖于单个片段/活动的生命周期,而是依赖于 NavGraph,所以我无法从它们的onSaveInstanceState().

我如何/在哪里可以正确地保留我的状态SaveStateHandle

ian*_*ake 5

这正是Lifecycle 2.3.0-alpha03 版本支持的用例:

SavedStateHandle现在支持惰性序列化,允许您调用setSavedStateProvider()给定的键,提供一个在被要求保存其状态时SavedStateProvider将获得回调的函数。(b/155106862saveState()SavedStateHandle

这使您可以处理任何复杂的对象,并在需要保存时准确地获取回调。

var complexObject: ComplexObject? = null

init {
    // When using setSavedStateProvider, the underlying data is
    // stored as a Bundle, so to extract any previously saved value,
    // we get it out of the Bundle, if one exists
    val initialState: Bundle = savedStateHandle.get<Bundle?>("complexObject")
    if (initialState != null) {
        // Convert the previously saved Bundle to your ComplexObject
        // Here, it is a single Parcelable, so we'll just get it out of
        // the bundle
        complexObject = initialState.getParcelable("parcelable")
    }

    // Now to register our callback for when to save our object,
    // we use setSavedStateProvider()
    savedStateHandle.setSavedStateProvider("complexObject") {
        // This callback requires that you return a Bundle.
        // You can either add your Parcelable directly or
        // skip being Parcelable and add the fields to the Bundle directly
        // The key is that the logic here needs to match your
        // initialState logic above.
        Bundle().apply {
            putParcelable("parcelable", complexObject)
        }
    }
}
Run Code Online (Sandbox Code Playgroud)

  • @ianhanniballake 这是有道理的。但我的建议是提供一个重写方法,向“ViewModel”发出信号,表明它很快就会进入保存状态,并且应该在该方法中将所需内容保存到“SavedStateHandle”中。与 Fragments 中的 override fun onSaveInstanceState(outState: Bundle) 类似,但它没有参数 Bundle - 其目的只是通知 ViewModel 现在应该保存任何状态。在我看来,对于开发人员来说,这样的解决方案将是一种更简单、更熟悉的解决方案,可以延迟保存状态,而无需创建子类。 (3认同)