4

阅读 Android 的新架构组件，建议使用各种 ViewModel 实例将数据提供给活动和片段。

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

第二个重要原则是您应该从模型驱动您的 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 与新架构无关吗？

4

1 回答 1

8

似乎我们的活动没有理由再明确地将重要值存储到/从已保存实例状态中获取/检索。

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

savedInstanceState 与新架构无关吗？

不。

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

  • 配置更改（例如，屏幕旋转），或
  • 进程终止（如用户离开应用，Android终止进程，用户半小时内返回应用）

因此，例如，假设我们有一个带有表单的活动。当用户填写表单并单击“保存”操作栏项目时，我们希望保留表单的内容。而且，在某些情况下，我们会在一些已经持久化的现有数据上打开表单，因此我们想要加载它。这些是 Android 架构组件（尤其是 Room）旨在帮助解决的问题。

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

但是，另外假设，在编辑字段之后，用户点击一个ImageButton来选择一个联系人。这用于ACTION_PICK调出联系人选择器，用户在那里选择一个联系人。控制返回到原始活动，该活动可能具有TextView显示联系人姓名，或者可能ImageButton使用联系人头像更新。现在用户旋转屏幕。再一次，我们可能还不想坚持这一点。但是，这一次，活动不会自动保留Uri我们的联系人，因为它不知道如何去做。因此，我们自己将其置于已保存的实例状态中Bundle，覆盖onSaveInstanceState().

数据存储（例如，数据库）代表单一的“真实来源”，但决定数据何时变为“真实”的是应用程序逻辑，而实例状态是处理未来可能变为真实但不是真实的数据的常用方法真相呢。

于 2017-06-06T15:46:18.627 回答