使用Android的新架构组件,saveInstanceState是否重要？

阅读Android的新架构组件,建议使用各种ViewModel实例将数据提供给Activities和Fragments.

还有一种从单个持久模型驱动数据的概念:

第二个重要原则是您应该从模型驱动UI,最好是持久模型.持久性是理想的两个原因:如果操作系统破坏您的应用程序以释放资源,您的用户将不会丢失数据,即使网络连接不稳定或未连接,您的应用程序也将继续工作.模型是负责处理应用程序数据的组件.它们独立于应用程序中的视图和应用程序组件,因此它们与这些组件的生命周期问题隔离开来.

一个类似的单一事实来源的概念:

在此模型中,数据库充当单一事实来源,应用程序的其他部分通过存储库访问它.无论您是否使用磁盘缓存,我们都建议您的存储库将数据源指定为应用程序其余部分的唯一真实来源.

在我看过的代码示例中,它们确实将savedInstanceState包传递给超类的实现,例如:

@Override
public void onActivityCreated(@Nullable Bundle savedInstanceState) {
    super.onActivityCreated(savedInstanceState);
    String userId = getArguments().getString(UID_KEY);
    viewModel = ViewModelProviders.of(this).get(UserProfileViewModel.class);
    viewModel.init(userId);
}

但是,似乎我们的活动没有理由将任何重要值显式存储/保存到savedInstanceState中.

savedInstanceState与新架构无关吗？

我们的活动似乎没有任何理由明确地将重要值存储到/从savedInstanceState中检索.

这完全取决于活动中的内容.

savedInstanceState与新架构无关吗？

没有.

保存的实例状态背后的想法一直并且将继续帮助活动假装好像它一直存在,即使活动已被破坏并在此过程中重新创建,或者是因为:

配置改变(例如,屏幕旋转),或

进程终止(例如,用户离开应用程序,Android终止进程,用户在半小时内返回应用程序)

因此,例如,假设我们有一个带有表单的活动.当用户填写表单并单击"保存"操作栏项时,我们希望保留表单的内容.并且,在某些情况下,我们正在打开一些已经存在的现有数据的表单,因此我们想要加载它.这些是Android架构组件(特别是Room)旨在提供帮助的问题.

但是,假设用户填写表单上的字段,然后旋转屏幕.在这种情况下,我们很可能还不想保存数据库中的更改,因为用户没有单击"保存"以表示对持久保存此更改的兴趣.所以,我们依靠onSaveInstanceState()为我们处理这个问题.在这种情况下,内置onSaveInstanceState()处理这个,因为一个EditText明显的用户可变状态的内容.

但是,假设另外,在编辑字段之后,用户点击ImageButton以选择联系人.这用于调ACTION_PICK出联系人选择器,用户在那里选择联系人.控制返回到原始活动,可能有一个TextView显示联系人姓名,或者可能更新ImageButton联系人头像.现在用户旋转屏幕.再一次,我们可能不想坚持这一点.但是,这次,活动不会自动保留Uri我们的联系人,因为它不知道如何.所以,我们自己把它放在保存的实例状态中Bundle,压倒一切onSaveInstanceState().

数据存储(例如,数据库)代表单一的"事实来源",但是应用程序逻辑决定数据何时变为"真实",而实例状态是处理可能在未来成为真理的数据的常用方法,但不是真相呢.