ViewModel类的设计目的是以生命周期意识的方式存储和管理与UI相关的数据。

1.1. Implement a ViewModel

Arch体系结构组件提供ViewModel帮助器类。在Activity或者Fragment配置更改时，ViewModel对象会自动保留，以便它们保存的数据立即可用于下一个Activity或Fragment实例。例如，如果需要在应用程序中显示用户列表，请确保将获取用户列表的责任分配给ViewModel，而不是活动或片段，如下面的示例代码所示：

public class MyViewModel extends ViewModel {
    private MutableLiveData<List<User>> users;

    public LiveData<List<User>> getUsers() {
        if (users == null) {
            users = new MutableLiveData<List<User>>();
            loadUsers();
        }
        return users;
    }

    private void loadUsers() {
        // Do an asynchronous operation to fetch users.
    }
}

然后，您可以从以下活动访问列表：

public class MyActivity extends AppCompatActivity {
    public void onCreate(Bundle savedInstanceState) {
        // Create a ViewModel the first time the system calls an activity's onCreate() method.
        // Re-created activities receive the same MyViewModel instance created by the first activity.

        MyViewModel model = ViewModelProviders.of(this).get(MyViewModel.class);
        model.getUsers().observe(this, users -> {
            // update UI
        });
    }
}

如果Activity被重新创建，它将接收到第一个Activity创建的相同MyViewModel实例。当owner活动完成时，框架调用viewModel对象的onCleared()方法，以便清理资源。

视图模型决不能引用View、Lifecycle或任何可能包含对Activity的Context有引用的类。

ViewModel对象被设计为比View或LifecycleOwners存在更长的时间，这种设计还意味着您可以编写测试来更容易地覆盖一个ViewModel，因为它不知道View和Lifecycle对象。ViewModel对象可以包含LifecycleOwners，例如LiveData对象。然而，ViewModel对象绝不能观察到生命周期感知的可观察到的变化，例如LiveData对象。如果ViewModel需要应用程序上下文，例如为了获取系统服务，你可以扩展AndroidViewModel类，并有一个在构造函数中接收应用程序的构造函数，因为应用程序类扩展了Context。

1.2. Lifecycle of ViewModel

在获取ViewModel时，ViewModel对象的作用域是传递给ViewModelProvider的生命周期。ViewModel将一直保留在内存中，直到它的作用域永久消失：对于Activity，当它Finish时，而对于Fragment，当它detach时。

下图说明了一个Activity在经历一个旋转然后完成时的各种生命周期状态。图中还显示了关联活动生命周期旁边的ViewModel的生命周期。这个特殊的图说明了一个Activity的状态。同样的基本状态也适用于Fragment的生命周期。

viewmodel

通常在系统第一次调用Activity对象的onCreate()方法时请求ViewModel。在活动的整个生命周期中，系统可能会多次调用onCreate()，例如当设备屏幕旋转时。从您第一次请求ViewModel开始，到活动完成并销毁为止，都存在该ViewModel。

1.3. Share data

一个Activity中的两个或多个片段需要相互通信是很常见的。设想一个主细节片段的常见情况，其中有一个片段，用户从列表中选择一个项目，另一个片段显示所选项目的内容。这种情况永远都不简单，因为两个Fragment都需要定义一些接口描述，并且所有者Activity必须将这两个Fragment绑定在一起。此外，两个Fragment都必须处理另一个Fragment尚未创建或还不可见的场景。

使用ViewModel对象可以解决这个常见的痛点。这些Fragment可以使用其Activity的scope共享一个ViewModel来处理此通信，如下面的示例代码所示：

public class SharedViewModel extends ViewModel {
    private final MutableLiveData<Item> selected = new MutableLiveData<Item>();

    public void select(Item item) {
        selected.setValue(item);
    }

    public LiveData<Item> getSelected() {
        return selected;
    }
}

public class MasterFragment extends Fragment {
    private SharedViewModel model;
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        model = ViewModelProviders.of(getActivity()).get(SharedViewModel.class);
        itemSelector.setOnClickListener(item -> {
            model.select(item);
        });
    }
}

public class DetailFragment extends Fragment {
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        SharedViewModel model = ViewModelProviders.of(getActivity()).get(SharedViewModel.class);
        model.getSelected().observe(this, { item ->
           // Update the UI.
        });
    }
}

请注意，这两个Fragment都检索包含它们的Activity。当Fragment各自获得ViewModelProvider时，它们会收到相同的SharedViewModel实例，该实例的作用域是此Activity的作用域。

这种方法有以下好处：

  • 该活动不需要做任何事情，也不需要知道任何有关此通信的信息。
  • 除了SharedviewModel之外，Fragment不需要互相了解。如果其中一个Fragment消失了，另一个仍然能正常工作。
  • 每个Fragment都有自己的生命周期，并且不受另一个Fragment生命周期的影响。如果一个Fragment替换另一个Fragment，那么UI将继续工作而不会出现任何问题。

1.4. Replacing Loaders

像CursorLoader这样的加载器类经常用于保持应用程序UI中的数据与数据库同步。您可以使用ViewModel和其他一些类来替换加载程序。使用ViewModel将UI控制器与数据加载操作分开，这意味着类之间的强引用更少。

在使用加载器的一种常见方法中，应用程序可能使用CursorLoader来观察数据库的内容。当数据库中的值更改时，加载程序自动触发数据重新加载并更新用户界面：

ViewModel-Loader

ViewModel使用Room和LiveData来替换loader。ViewModel确保数据在设备配置更改后仍然存在。当数据库发生变化时，Room会通知您的LiveData，而LiveData会反过来用修改后的数据更新您的UI。

ViewModel-Replace-Loader

1.5. Use coroutines

ViewModel包括对Kotlin Coroutines的支持。有关更多信息，请参见Use Kotlin coroutines with Android Architecture Components.

1.6. Further information

随着数据变得越来越复杂，您可能会选择单独的类来加载数据。ViewModel的目的是封装UI控制器的数据，以使数据在配置更改后仍然存在。有关如何跨配置更改加载、保持和管理数据的信息，请参阅Saving UI States。

Samples

Codelabs

Blogs

Videos

results matching ""

    No results matching ""