如何使用SavedStateHandle保存数据

当系统

MainActivity.java

public class MainActivity extends AppCompatActivity  implements SavedStateRegistryOwner {
    ActivityMainBinding binding;
    MyViewModel myViewModel;
    final static String KEY_NUMBER = "my_number";
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        binding = DataBindingUtil.setContentView(this, R.layout.activity_main);

        SavedStateViewModelFactory savedStateViewModelFactory = new SavedStateViewModelFactory(getApplication(), this);
        myViewModel = savedStateViewModelFactory.create(MyViewModel.class);

        binding.setData(myViewModel);
        binding.setLifecycleOwner(this);
    }
}

MyModelView

public class MyViewModel extends ViewModel {
    private SavedStateHandle state;

    public MyViewModel(SavedStateHandle savedStateHandle){
        state = savedStateHandle;
    }

    public MutableLiveData getNumber() {
        if(!state.contains(MainActivity.KEY_NUMBER)){
            state.set(MainActivity.KEY_NUMBER,0);
        }
        return state.getLiveData(MainActivity.KEY_NUMBER);
    }

    public void add(){
        getNumber().setValue(getNumber().getValue()+1);
    }
}

 布局文件




    
        
    

    

        

        

 构建文件

plugins {
    id 'com.android.application'
}

android {
    compileSdk 32

    defaultConfig {
        applicationId "com.tjjingpan.study.viewmodelresotre1"
        minSdk 23
        targetSdk 32
        versionCode 1
        versionName "1.0"

        testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner"
        dataBinding.enabled = true
    }

    buildTypes {
        release {
            minifyEnabled false
            proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
        }
    }
    compileOptions {
        sourceCompatibility JavaVersion.VERSION_1_8
        targetCompatibility JavaVersion.VERSION_1_8
    }
}

dependencies {

    implementation 'androidx.appcompat:appcompat:1.2.0'
    implementation 'com.google.android.material:material:1.3.0'
    implementation 'androidx.constraintlayout:constraintlayout:2.0.4'
    implementation 'androidx.lifecycle:lifecycle-viewmodel-savedstate:2.3.1'
    testImplementation 'junit:junit:4.+'
    androidTestImplementation 'androidx.test.ext:junit:1.1.2'
    androidTestImplementation 'androidx.test.espresso:espresso-core:3.3.0'
}

以下文档来自developer.android.com

保存界面状态

bookmark_border

本指南介绍了用户对界面状态的预期,以及可用于保持状态的选项。

在系统销毁 activity 或应用后,快速保存和恢复 activity 的界面状态对打造良好的用户体验至关重要。用户希望界面状态保持不变,但系统可能会销毁 activity 及其存储状态。

如需使系统行为符合用户预期,您可组合使用以下方法:

  • ViewModel 对象。
  • 以下情境中的已存实例状态:
    • Jetpack Compose:rememberSaveable。
    • 视图:onSaveInstanceState() API。
    • ViewModels:SavedStateHandle。
  • 本地存储空间,以便在应用和 activity 过渡期间保持界面状态。

最佳解决方案取决于界面数据的复杂程度、应用的使用场景,以及数据访问速度与内存用量之间的平衡。

确保您的应用符合用户的预期,并提供快速的自适应界面。避免在将数据加载到界面时出现延迟,尤其是在发生常见配置更改(比如旋转)之后。

ViewModel Saved instance state Persistent storage
存储位置 在内存中 在内存中 在磁盘或网络上
在配置更改后继续存在
在系统发起的进程终止后继续存在
在用户完全关闭 activity 或触发 onFinish() 后继续存在
数据限制 支持复杂对象,但是空间受可用内存的限制 仅适用于基元类型和简单的小对象,例如字符串 仅受限于磁盘空间或从网络资源检索的成本/时间
读取/写入时间 快(仅限内存访问) 慢(需要序列化/反序列化) 慢(需要磁盘访问或网络事务)

针对复杂或大型数据使用本地持久性存储来处理进程终止

只要您的应用安装在用户的设备上,持久性本地存储(例如数据库或共享偏好设置)就会继续存在(除非用户清除应用的数据)。虽然此类本地存储空间会在系统启动的活动和应用进程终止后继续存在,但由于必须从本地存储空间读取到内存,因此检索成本高昂。这种持久性本地存储空间通常已经是应用架构的一部分,用于存储您打开和关闭 activity 时不想丢失的所有数据。

ViewModel 和已保存实例状态均不是长期存储解决方案,因此不能替代本地存储空间,例如数据库。您只应该使用这些机制来暂时存储瞬时界面状态,对于其他应用数据,应使用永久性存储空间。请参阅应用架构指南,详细了解如何充分利用本地存储空间长期保留您的应用模型数据(例如在重启设备后)。

管理界面状态:分而治之

您可以通过在各种类型的保留机制之间划分工作,高效地保存和恢复界面状态。在大多数情况下,这些机制中的每一种都应存储 activity 中使用的不同类型的数据,具体取决于数据复杂度、访问速度和生命周期的权衡:

  • 本地持久性存储:存储在您打开和关闭 activity 时不希望丢失的所有应用数据。
    • 示例:歌曲对象的集合,其中可能包括音频文件和元数据。
  • ViewModel:将显示关联界面所需的所有数据(即屏幕界面状态)存储在内存中。
    • 示例:最近搜索的歌曲对象和最近的搜索查询。
  • 保存的实例状态:存储少量的数据,以便在系统停止界面后又重新创建时,用于轻松重新加载界面状态。这里不存储复杂对象,而是将复杂对象保留在本地存储空间中,并将这些对象的唯一 ID 存储在保存的实例状态 API 中。
    • 示例:存储最近的搜索查询。

例如,假设有一个用于搜索歌曲库的 activity。应按如下方式处理不同的事件:

当用户添加歌曲时,ViewModel 会立即委托在本地保留此数据。如果新添加的这首歌曲应显示在界面中,则您还应更新 ViewModel 对象中的数据以表明该歌曲已添加。切记要在主线程以外执行所有数据库插入操作。

当用户搜索歌曲时,从数据库加载的任何复杂歌曲数据都应作为屏幕界面状态的一部分立即存储在 ViewModel 对象中。

当 activity 进入后台且系统调用保存的实例状态 API 时,应将搜索查询存储在保存的实例状态中,以备进程重新创建时使用。由于加载在此过程中保留下来的应用数据需要用到搜索查询,因此应将其存储在 ViewModel SavedStateHandle 中。这些就是加载数据并让界面恢复到当前状态所需的所有信息。

恢复复杂的状态:重组碎片

当到了用户该返回 activity 的时候,重新创建 activity 存在两种可能情况:

  • 在系统停止 activity 后,需要重新创建该 activity。系统已将查询保存在保存的实例状态捆绑包中,如果未使用 SavedStateHandle,则界面应将查询传递给 ViewModelViewModel 看到没有缓存任何搜索结果时,会委托使用指定的搜索查询加载搜索结果。
  • 在配置更改后创建 activity。由于 ViewModel 实例尚未销毁,因此 ViewModel 会将所有信息缓存在内存中,而无需重新查询数据库。

注意:最初创建 activity 时,保存的实例状态捆绑包中不含任何数据,ViewModel 对象也是空白的。创建 ViewModel 对象时,您将传递空白查询,以此告知 ViewModel 对象还没有要加载的数据。因此,activity 启动时为空白状态。

你可能感兴趣的:(android,java,开发语言)