Android architecture components –viewModel

Overview



ViewModel, literally, it must be related to the view (View) and the data (Model). Just like its literal meaning, it is responsible for preparing and managing data classes related to UI components (Fragment/Activity), which means that ViewModel is used to manage For UI-related data, ViewModel can also be used for communication between UI components.

Previous problems



ViewModel is used to store and manage UI-related data. It can abstract out the data logic related to an Activity or Fragment component, and can adapt to the life cycle of the component. For example, when the screen rotates, the Activity is rebuilt. The data is still valid.



Before the introduction of ViewModel, there were several problems as follows:



 Usually the Android system manages the life cycle of UI controllers (such as Activity and Fragment). The system responds to user interaction or rebuilds components, and the user cannot control it. When the component is destroyed and rebuilt, the data related to the original component will also be lost. If the data type is relatively simple and the amount of data is not large, you can store the data through onSaveInstanceState(), and read the Bundle from it through onCreate() after the component is rebuilt. Data recovery. However, if it is a large amount of data that is inconvenient to serialize and deserialize, the above method will not be applicable.

 UI controllers often send a lot of asynchronous requests. It is possible that UI components have been destroyed but the request has not yet returned. Therefore, UI controllers need to do extra work to prevent memory leaks.

 When the Activity is destroyed and rebuilt due to configuration changes, the general data will be re-requested. In fact, this is a waste. It is best to keep the last data.

 UI controllers actually only need to be responsible for displaying UI data, responding to user interactions and system interactions. But often developers will write a lot of data request and processing work in Activity or Fragment, causing UI controllers code bloat, and also making unit testing difficult. We should follow the principle of separation of duties and separate data-related things from UI controllers.



Basic use of ViewModel



public class MyViewModel extends ViewModel {

 private MutableLiveData> users;

 public LiveData> getUsers() {

 if (users == null) {

 users = new MutableLiveData>();

 loadUsers();

}

 return users;

}



 private void loadUsers() {

 // Asynchronous call to get user list

}

}







The new Activity is as follows:



public class MyActivity extends AppCompatActivity {

 public void onCreate(Bundle savedInstanceState) {

 MyViewModel model = ViewModelProviders.of(this).get(MyViewModel. class);

 model.getUsers().observe(this, users -> {

 // Update UI

 });

}

}







If the Activity is recreated, it will receive the same MyViewModel instance created by the previous Activity. When the belonging Activity terminates, the framework calls the onCleared() method of the ViewModel to clear the resources.



 Because the ViewModel lives outside the specified Activity or Fragment instance, it should never refer to a View or hold any class that contains an Activity context reference. If the ViewModel needs the context of the Application (such as obtaining system services), you can extend the AndroidViewmodel and have a constructor to receive the Application.



Share data between Fragments



It is very common for multiple Fragments in an Activity to communicate with each other. Before each Fragment needs to define an interface description, the activity belongs to bind the two together. In addition, each Fragment must deal with situations where other Fragments are not created or are not visible. This pain point can be solved by using ViewModel. These Fragments can use their Activity to share ViewModel to handle communication:



public class SharedViewModel extends ViewModel {

 private final MutableLiveData selected = new MutableLiveData();



 public void select(Item item) {

 selected.setValue(item);

}



 public LiveData 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

 });

}

}







 Note: Both of the above two Fragments use the following code to get the ViewModel, getActivity() returns the same host Activity, so the same SharedViewModel object is returned between the two Fragments.



SharedViewModel model = ViewModelProviders.of(getActivity()).get(SharedViewModel.class);



 1



The benefits of this approach include:



 Activity does not need to do anything, nor does it need to know about communication

 Fragment does not need to know each other, except SharedViewModel to communicate. If one of them (Fragment) disappears, the rest will still work as usual.

 Each Fragment has its own life cycle and will not be affected by the life cycle of other Fragments. In fact, if one Fragment replaces another Fragment, the work of the UI will not be affected in any way.



The life cycle of ViewModel



The scope of the ViewModel object is determined by the Lifecycle passed to the ViewModelProvider when the ViewModel is obtained. The ViewModel stays in memory until the Lifecycle leaves permanently—for Activity, when it is finished, and for Fragment, when it is detached.

Write the picture description here



The left side of the above figure is the life cycle process of Activity, during which there is an operation to rotate the screen; the right side is the life cycle process of ViewModel.



Generally, the ViewModel is initialized by the following code:



viewModel = ViewModelProviders.of(this).get(UserProfileViewModel.class );



 1



This parameter is generally Activity or Fragment, so ViewModelProvider can get the life cycle of the component.



Activity may trigger onCreate() multiple times in its life cycle, while ViewModel will only be created at the first onCreate(), and then until the last Activity is destroyed.

ViewModel related class diagram



Borrowing Android architecture components (three)-ViewModel class diagram:

Write the picture description here



 ViewModelProviders is a ViewModel tool class, which provides methods to get ViewModel through Fragment and Activity, and the specific implementation is implemented by ViewModelProvider.



 ViewModelProvider is a tool class that realizes the creation and acquisition of ViewModel. An interface class for creating ViewModel-Factory is defined in ViewModelProvider. There is a ViewModelStore object in ViewModelProvider, which is used to store ViewModel objects.



 ViewModelStore is a class that stores ViewModels. The specific implementation is to save ViewModle objects through HashMap.



 ViewModel is an abstract class, which defines only one onCleared() method, which is called when the ViewModel is not in use. ViewModel has a subclass AndroidViewModel, this class is convenient to use Context object in ViewModel, because we mentioned earlier that we cannot hold Activity reference in ViewModel.



 ViewModelStores is the factory method class of ViewModelStore, it will be associated with HolderFragment, HolderFragment has a nested class-HolderFragmentManager.



ViewModel related timing diagram



Retrospecting to create a ViewModel source code, you will realize that there are a lot of steps required. Let's take the ViewModel object obtained in Fragment as an example to see the sequence diagram of the whole process.

Borrowing Android architecture components (three)-the sequence diagram of ViewModel:

Write the picture description here



The sequence diagram looks more complicated, but it only describes two processes:



 Get the ViewModel object.

 When the HolderFragment is destroyed, the ViewModel receives the onCleared() notification.



ViewModel related source code analysis



The concrete realization of ViewModelProviders class:



public class ViewModelProviders {



 private static Application checkApplication(Activity activity) {

 Application application = activity.getApplication();

 if (application == null) {

 throw new IllegalStateException("Your activity/fragment is not yet attached to "

 + "Application. You can‘t request ViewModel before onCreate call.");

}

 return application;

}



 private static Activity checkActivity(Fragment fragment) {

 Activity activity = fragment.getActivity();

 if (activity == null) {

 throw new IllegalStateException("Can't create ViewModelProvider for detached fragment");

}

 return activity;

}



 @NonNull

 @MainThread

 public static ViewModelProvider of(@NonNull Fragment fragment) {

 ViewModelProvider.AndroidViewModelFactory factory =

 ViewModelProvider.AndroidViewModelFactory.getInstance(

 checkApplication(checkActivity(fragment)));

 return new ViewModelProvider(ViewModelStores.of(fragment), factory);

}



 @NonNull

 @MainThread

 public static ViewModelProvider of(@NonNull FragmentActivity activity) {

 ViewModelProvider.AndroidViewModelFactory factory =

 ViewModelProvider.AndroidViewModelFactory.getInstance(

 checkApplication(activity));

 return new ViewModelProvider(ViewModelStores.of(activity), factory);

}



 @NonNull

 @MainThread

 public static ViewModelProvider of(@NonNull Fragment fragment, @NonNull Factory factory) {

 checkApplication(checkActivity(fragment));

 return new ViewModelProvider(ViewModelStores.of(fragment), factory);

}



 @NonNull

 @MainThread

 public static ViewModelProvider of(@NonNull FragmentActivity activity,

 @NonNull Factory factory) {

 checkApplication(activity);

 return new ViewModelProvider(ViewModelStores.of(activity), factory);

}







ViewModelProviders provides four of() methods, which have similar functions. Of(FragmentActivity activity, Factory factory) and of(Fragment fragment, Factory factory) provide methods to customize ViewModel creation.

1. Determine whether the Fragment is Attached to Activity and whether the Application object of the Activity is empty.

2. Creating a ViewModel object seems very simple, with one line of code.



new ViewModelProvider(ViewModelStores.of(fragment), factory)





Look at the ViewModelStores.of() method first:



 @NonNull

 @MainThread

 public static ViewModelStore of(@NonNull Fragment fragment) {

 if (fragment instanceof ViewModelStoreOwner) {

 return ((ViewModelStoreOwner) fragment).getViewModelStore();

}

 return holderFragmentFor(fragment).getViewModelStore();

}







Continue to find out that it actually implements an interface:



public interface ViewModelStoreOwner {

 @NonNull

 ViewModelStore getViewModelStore();

}







holderFragmentFor() is a static method of HolderFragment, HolderFragment inherits from Fragment. Let's first look at the specific implementation of the holderFragment() method



 @RestrictTo(RestrictTo.Scope.LIBRARY_GROUP)

 public static HolderFragment holderFragmentFor(Fragment fragment) {

 return sHolderFragmentManager.holderFragmentFor(fragment);

}



 @NonNull

 @Override

 public ViewModelStore getViewModelStore() {

 return mViewModelStore;

}





Continue to see the specific implementation of the HolderFragmentManager.holderFragmentFor() method



HolderFragment holderFragmentFor(Fragment parentFragment) {

 FragmentManager fm = parentFragment.getChildFragmentManager();

 HolderFragment holder = findHolderFragment(fm);

 if (holder != null) {

 return holder;

}

 holder = mNotCommittedFragmentHolders.get(parentFragment);

 if (holder != null) {

 return holder;

}



 parentFragment.getFragmentManager()

 .registerFragmentLifecycleCallbacks(mParentDestroyedCallback, false);

 holder = createHolderFragment(fm);

 mNotCommittedFragmentHolders.put(parentFragment, holder);

 return holder;

}



private FragmentLifecycleCallbacks mParentDestroyedCallback =

 new FragmentLifecycleCallbacks() {

 @Override

 public void onFragmentDestroyed(FragmentManager fm, Fragment parentFragment) {

 super.onFragmentDestroyed(fm, parentFragment);

 HolderFragment fragment = mNotCommittedFragmentHolders.remove(

 parentFragment);

 if (fragment != null) {

 Log.e(LOG_TAG, "Failed to save a ViewModel for "+ parentFragment);

}

}

 };



private static HolderFragment createHolderFragment(FragmentManager fragmentManager) {

 HolderFragment holder = new HolderFragment(); //  Create a HolderFragment object

 fragmentManager.beginTransaction().add(holder, HOLDER_TAG).commitAllowingStateLoss();

 return holder;

}



public HolderFragment() {

 //This is the key, which makes when the Activity is recreated, Fragment's onDestroy() and onCreate() will not be called

 setRetainInstance(true);

}





 setRetainInstance(boolean) is a method in Fragment. Setting this method to true can make the current Fragment survive when Activity is rebuilt, if not set or set to false, The current Fragment will also be rebuilt when the Activity is rebuilt, so that it is replaced by the newly created object.



 Put a special use in the Fragment where setRetainInstance(boolean) is true For the Map that stores the ViewModel, all ViewModels in the Map will naturally survive the activity reconstruction. Let the Activity and Fragment bind to one such Fragment, store the ViewModel in the Map of the Fragment, and the ViewModel component is implemented in this way.



So far, we have got the ViewStore object. The new ViewModelProvider (ViewModelStores.of(fragment), sDefaultFactory) we are creating ViewModelProvider object is implemented by this line of code. Now let’s look at the construction method of ViewModelProvider.



public ViewModelProvider(@NonNull ViewModelStore store, @NonNull Factory factory) {

 mFactory = factory;

 this.mViewModelStore = store;

}





Now you can get the ViewModel object through the ViewModelProvider.get() method, continue to see the specific implementation of this method



 @NonNull

 @MainThread

 public extends ViewModel> T get(@ NonNull String key, @NonNull Class modelClass) {

 ViewModel viewModel = mViewModelStore.get(key); //from cache Find out if there is an existing ViewModel object. 



 if (modelClass.isInstance(viewModel)) {

 //noinspection unchecked

 return (T) viewModel;

} else {

 //noinspection StatementWithEmptyBody

 if (viewModel != null) {

 // TODO: log a warning.

}

}



 viewModel = mFactory.create(modelClass); //Create ViewModel object , And then cache it. 

 mViewModelStore.put(key, viewModel);

 //noinspection unchecked

 return (T) viewModel;

}



 



The ViewModelProvider.get() method is relatively simple, as stated in the comments. Finally, we look at the specific implementation of the ViewModelStore class



public class ViewModelStore {



 private final HashMap mMap = new HashMap<>();



 final void put(String key, ViewModel viewModel) {

 ViewModel oldViewModel = mMap.get(key);

 if (oldViewModel != null) {

 oldViewModel.onCleared();

}

 mMap.put(key, viewModel);

}



 final ViewModel get(String key) {

 return mMap.get(key);

}



 public final void clear() {

 for (ViewModel vm: mMap.values()) {

 vm.onCleared();

}

 mMap.clear();

}

}



 



ViewModelStore is a class for caching ViewModel. The put() and get() methods are used to access ViewModel objects. In addition, a clear() method is provided to clear cached ViewModel objects. In this method, ViewModel.onCleared is called The () method informs the ViewModel that the object is no longer used.



ViewModel received onCleared() notification

HolderFragment's onDestroy() method



 @Override

 public void onDestroy() {

 super.onDestroy();

 mViewModelStore.clear();

 }



The ViewModelStore.clear() method is called in the onDestroy() method, and we know that the onCleared() method of the ViewModel will be called in this method. After you read the HolderFragment source code, you may have a question, where are the ViewModel objects stored in mViewModelStore added? If you are careful, you will find that in the ViewModelProvider construction method, the reference of the ViwModelStore object mViewModelStore in the HolderFragment has been passed to the mViewModelStore in the ViewModelProvider, and the ViewModel object will be added to the mViewModelStore in the ViewModelProvider.get() method.

Summary



 ViewModel's responsibility is to manage and request data for Activity or Fragment. The specific data request logic should not be written in the ViewModel, otherwise the ViewModel's responsibilities will become too heavy. Here we need to introduce a Repository to be responsible for data request related work . For details, please refer to Android Architecture Components.

 ViewModel can be used for the interaction of different Fragments within the Activity, and can also be used as a decoupling method between Fragments.

 ViewModel can also be responsible for handling part of the Activity/Fragment interaction with other modules of the application.

 The ViewModel life cycle (taking Activity as an example) starts at the first onCreate() of the Activity and ends at the final finish of the Activity.



Official:

https://developer.android.google.cn/topic/ libraries/architecture/viewmodel.html

————————————————

Copyright statement: This article is the original article of the CSDN blogger "Double-Smile", following the CC 4.0 BY-SA copyright agreement, please attach Link to the original source and this statement.

Link to the original text: https://blog.csdn.net/qq_24442769 /article/details/79426609