【翻译】安卓架构组件(5)-ViewModel
相关文章:
- 【翻译】安卓架构组件(1)-App架构指导
- 【翻译】安卓架构组件(2)-添加组件到你的项目中
- 【翻译】安卓架构组件(3)-处理生命周期
- 【翻译】安卓架构组件(4)-LiveData
- 【翻译】安卓架构组件(6)-Room持久化类库
- 【翻译】安卓架构组件(7)-分页库
ViewModel
被设计用于存储并管理UI相关的数据,因此可以在配置变化时存活下来,例如当屏幕旋转的时候。
app组件,例如Activity
和Fragment
拥有可以被安卓框架所管理的生命周期。框架可以决定销毁或创建它们,这是基于一些用户的行为或者设备的事件,而这一切都在你的控制范围外。
因为一些对象可能会被操作系统销毁或重新创建,任何你所持有的数据都会丢失。例如,你的Activity
拥有一组用户列表,当Activity
由于配置变化而重新创建时,新的Activity
不得不重新获取用户列表。对于简单的数据,Activity
可以使用onSaveInstanceState()
方法并从onCreate()
的bundle
里恢复数据,但是这种方法仅仅适合于少量数据,例如UI状态,不适用于大量数据,例如一组用户列表。
另一个问题是,这些UI控制器(Activity
、Fragment
等)需要频繁地异步调用,可能会需要一些时间返回。UI控制器需要管理这些调用,并当被销毁的时候清除它们,以避免潜在的内存泄漏。这需要很多的代码维护,并且在由于配置变化而重新创建的情况下是很浪费资源的,因为需要重新进行相同的调用。
另外,这些UI控制器已经响应用户行为或处理操作系统交互。当它们也需要手动处理资源的时候,会使得类急速膨胀。上帝的Activity或上帝的Fragment,是指一个试图处理所有app工作的单独类,而不是分派到其他类去完成。这样也会使得测试工作很难进行。
将我们的UI和控制逻辑分离变得越来越容易和高效了。Lifecycle
提供了一个新类叫做ViewModel
,一个负责为UI准备数据的帮助类。ViewModel
会在配置发生变化的时候自动保存,所以其所持有的数据会在新的Activity
或新的Fragment
立即可用。在上面我们所提及的例子中,应当是ViewModel
的职责来获取并保持用户列表,而不是Activity
或Fragment
。
public class MyViewModel extends ViewModel {
private MutableLiveData<List<User>> users;
public LiveData<List<User>> getUsers() {
if (users == null) {
users = new MutableLiveData<List<Users>>();
loadUsers();
}
return users;
}
private void loadUsers() {
// 异步调用获取用户列表
}
}
现在新的Activity
如下:
public class MyActivity extends AppCompatActivity {
public void onCreate(Bundle savedInstanceState) {
MyViewModel model = ViewModelProviders.of(this).get(MyViewModel.class);
model.getUsers().observe(this, users -> {
// 更新 UI
});
}
}
如果Activity
被重新创建了,它会收到被之前Activity
创建的相同MyViewModel
实例。当所属Activity
终止后,框架调用ViewModel
的onCleared()
方法清除资源。
因为
ViewModel
在指定的Activity
或Fragment
实例外存活,它应该永远不能引用一个View,或持有任何包含Activity context
引用的类。如果ViewModel
需要Application
的context(如获取系统服务),可以扩展AndroidViewmodel
,并拥有一个构造器接收Application
。
在Fragment
间共享数据
一个Activity
中的多个Fragment
相互通讯是很常见的。每个Fragment
需要定义接口描述,所属Activity
将二者捆绑在一起。此外,每个Fragment
必须处理其他Fragment
未创建或不可见的情况
通过使用ViewModel
可以解决这个痛点。想象一种情况,一个Fragment
从列表项中选择一项,在另一个Fragment
显示被选中项的内容。
这些Fragment
可以使用它们的Activity
共享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 onActivityCreated() {
model = ViewModelProviders.of(getActivity()).get(SharedViewModel.class);
itemSelector.setOnClickListener(item -> {
model.select(item);
});
}
}
public class DetailFragment extends LifecycleFragment {
public void onActivityCreated() {
SharedViewModel model = ViewModelProviders.of(getActivity()).get(SharedViewModel.class);
model.getSelected().observe(this, { item ->
// update UI
});
}
}
请注意,两个Fragment
都使用了getActivity()
,以通过ViewModelProviders
获取SharedViewModel
。
这种方式的好处包括:
Activity
不需要做任何事情,也不需要知道通讯的事情Fragment
不需要知道彼此,除了SharedViewModel
进行联系。如果它们(Fragment
)其中一个消失了,其余的仍然能够像往常一样工作- 每个
Fragment
有自己的生命周期,而且不会受其它Fragment
生命周期的影响。事实上,一个Fragment
替换另一个Fragment
,UI的工作也不会受到任何影响。
ViewModel的生命周期
ViewModel
对象的范围由获取ViewModel
时传递至ViewModelProvider
的Lifecycle
所决定。ViewModel
始终处在内存中,直到Lifecycle
永久地离开—对于Activity
来说,是当它终止(finish)的时候,对于Fragment
来说,是当它分离(detached)的时候。