Android viewmodel by viewmodels

Optimizing Android ViewModel with Lifecycle 2.2.0

Initialization, passing arguments, and saved state

T he Lifecycle 2.2.0 update including simplified initialization with by viewModels() , by activityViewModels() , and by navGraphViewModels(. ) syntax for the ViewModel (VM) component is great for quickly creating VMs. What about re-using the VM instance throughout fragments, passing arguments/parameters into the VM while also enabling saved state? With a bit of customization, the above can be achieved as I recently shipped in the latest version of the Coinverse app .

Sample Code

Coinverse Open App

Coinverse open source app.

Setup

To take advantage of the latest VM component, declare the most recent Lifecycle dependencies in the build.gradle (Module: app) file for lifecycle-viewmodel-ktx and lifecycle-livedata-ktx . The jvmTarget also needs to be defined in order to implement the by viewModels syntax we’ll use below.

If the navigation component version of the VM is being implemented, the navigation components’ libraries, navigation-ui-ktx and navigation-fragment-ktx are required.

Initializing the ViewModel for Reusability

As the ViewModel documentation outlines, a major advantage of utilizing VMs in an activity/fragment is the ability to save view state data that comprises the user interface. Otherwise, large portions of data would need to be reloaded every time there is a configuration change, or when the app temporarily goes into the background.

The documentation shows initiating the VM in onCreate as a method level var , and then later on as a class level val . Creating the VM in onCreate requires reassigning the variable on the class level in order to use the VM throughout the activity/fragment. For this reason, it’s preferred to create the VM as a class level val .

Rather than creating a lateinit var instance variable, declare a VM immutable val . The VMs values can only be accessed after the activity is attached to the application.

🔎 Differences between by viewModels, activityViewModels, and navGraphViewModels

• Use by viewModels when the activity/fragment creating the VM will be the only activity/fragment accessing the VM’s data.

Behind the scenes viewModels is an extension function applied to either an activity/fragment that returns a VM with a lifecycle tied to that activity/fragment. A VM factory may optionally be defined which can be used to pass parameters/arguments as we’ll see below.

• Use by activityViewModels in fragments, when the fragment is sharing data/communicating with another activity/fragment.

This is useful for sharing information between views. activityViewModels is an extension function applied to a fragment that returns a fragment’s parent’s activity’s VM. A VM factory may be defined here too.

• Use by navGraphViewModels(R.id.some_nav_graph) in a fragment where the VM benefits by being scoped to a specific navigation graph or nested graph.

This is useful for managing the business logic of features organized in a nested graph to ensure sure data is not leaked to other parts of the app, and that the lifecycle is handled properly. A VM factory may be defined here as well.

📦 Storing view state data

The VM is a great location to store cached view state data using an observable data structure such as LiveData, Coroutines, or RxKotlin.

• Use immutable public values to observe data.
• Use mutable private variables to edit values in the VM.
• Use a pattern that allows the readability of the values in the VM, such as LiveData’s transform or Coroutine’s collect.

♻️ VM lifecycle overview

• Created the first time an activity calls onCreate
• When an activity is recreated, it receives the same VM instance.
• When the creating activity/fragment is finished/detached, VM’s onCleared is called

How to pass Arguments/Parameters to ViewModels

The advantage of passing data into the VM upon creation is that an important process may begin upon VM initialization, such as retrieving data to populate a view, rather than the process being tied to the fragment/activity lifecycle. This is important because as Lyla Fuijwara, a Google developer advocate explains, the VM instance is created once inside the activity/fragment. Then, the VM is stopped only when a user closes the view holding the VM, closes the app entirely, or if the Android system needs to clear the memory while the app is in the background.

If an initialization process is tied to an activity/fragment lifecycle event, it may unintentionally occur if the activity/fragment is recreated. When the process runs in the VM’s init <..>function, it will be tied to the VM lifecycle.

🤷🏻‍♂ Can’t we just use AndroidViewModel (AVM)?

AVM is an Android architecture component after all and allows one to pass parameters while providing application context. This seems tempting at first, however, it is problematic for unit tests. Unit tests should not deal with any of the Android lifecycle, such as context.

☝🏻 Data not to pass to the ViewModel

• Context, views, activities, fragments, adapters, Lifecycle, observe lifecycle-aware observables or hold resources, drawables etc. This information should be handled by the view and tethered to the view lifecycle.
• Don’t load resources, instead pass resource ids, and load in view. See: Locale changes and the AndroidViewModel antipattern

Enabling SavedState with Arguments/Parameters

The saved state module is a lifecycle component enabling saving data in the VM that will persist when the VM is stopped by the Android system. This may replace the functionality of saving data inside onSaveInstanceState (OSIS) using the activity/fragment bundle. Lyla also highlights the differences between onSaveInstanceState and SavedState (SS) in detail. The main difference with SS is that the data is stored within the VM instead of in the activity/fragment with OSIS.

OSIS and SS are meant to serve the same use case, saving small amounts of information required to restore the view state of the screen. The majority of data in the VM is meant for saving larger amounts of data that make up the view state. Therefore, SS may replace OSIS in order to organize both the smaller and larger view state data in one place, the VM.

With the Lifecycle 2.2.0 release, the saved state module comes standard with by viewModels or by activityViewModels syntax, without needing to create a ViewModelProvider.NewInstanceFactory . However, if setting default values for the saved state module or passing arguments/parameters to a VM, an AbstractSavedStateViewModelFactory factory is required, as the documentation notes. The factory class must handle the saved state owner, default values, and custom parameters.

🚦 DefaultArgs

The Bundle defaultArgs is recommended to pass into the ViewModelFactory, as the values will be used as defaults in the SavedStateHandle if there is not a value for the given key being requested by the saved state.

See: Public constructors of the AbstractSavedStateViewModelFactory

💾 Saved State

An Int is saved with the method saveSomeInt , in the SavedStateHandle to represent important information that needs to survive the VM being cleared. Then, someInt may be retrieved when needed. Because a default argument is defined for the key SOME_INT_KEY , the saved state will always have a value to work with for that key.

Источник

Android viewmodel by viewmodels

ViewModel and ViewModel Factory in Android with Examples

• Post author:Sagar Paliwal
• Post published: August 26, 2021
• Post category:Android Development
• Post comments:1 Comment

This article will cover the internals of ViewModel and ViewModel Factory, which is a component of the Android Architecture Components. We will first go over the various uses of ViewModel in Android and then we will go into detail about how ViewModel actually works and how it retains itself on configuration changes.

What is ViewModel?

The ViewModel class is used to store and manage user interface data in a lifecycle-aware manner. It allows data to survive screen rotations and other configuration changes. It also enhances the implementation of the MVVM (Model-View-ViewModel) design pattern, which is Google’s recommended Android app architecture for Android applications.

Its dependency

implementation(“androidx.lifecycle:lifecycle-viewmodel-ktx:2.4.0-alpha03”)

• The lifecycles of UI controllers such as activities and fragments are managed by the Android framework. The framework may decide to destroy or recreate a UI controller in response to user actions or device events over which you have no control.
• Any temporary UI-related data you store in UI controllers is lost if the system destroys or recreates them. For example, one of your app’s activities could include a list of users. When an activity is re-created to accommodate a configuration change, the new activity must re-fetch the list of users. For simple data, the activity can use the onSaveInstanceState() method and restore its data from the bundle in onCreate(), but this approach is only appropriate for small amounts of data that can be serialized then deserialized, not potentially large amounts of data such as a list of users or bitmaps.
• Another issue is that UI controllers frequently need to make asynchronous calls, which can take a while to finish . To avoid potential memory leaks, the UI controller must manage these calls and make sure that the system cleans them up after they’re destroyed. This management requires tons of maintenance, and re-creating the thing for a configuration change may be a waste of resources because the thing may need to reissue calls it’s already made.

Activities and fragments are UI controllers that are specifically designed to display UI data, respond to user actions, or handle operating system connectivity, such as permission requests. Making UI controllers responsible for data loading from a database or network brings bloat to the class. Excessive responsibility for UI controllers can result in a single class attempting to handle all of an app’s work on its own rather than delegating work to other classes. Assigning excessive responsibility to UI controllers in this manner also makes testing much more difficult.

Advantages

• Handle configuration changes: When an activity is recreated due to configuration changes, ViewModel objects are automatically retained.
• It’s objects are also aware of their lifecycle. When the Lifecycle they are watching is permanently destroyed, they are automatically cleared.
• ViewModels make it simple to share data between fragments in an activity.
• Support for Kotlin-Coroutines: It includes Kotlin-Coroutine support. As a result, they are easily integrated into any asynchronous processing.

The lifecycle of a ViewModel

ViewModel objects are bound to the Lifecycle passed to the ViewModelProvider when the ViewModel is obtained and It remains in memory until the Lifecycle to which it is scoped is permanently removed, in the case of an activity, when it completes, and in the case of a fragment, when it is detached.

Given below figure shows the various lifecycle states of an activity as it rotates and then is completed. The illustration also depicts the ViewModel’s lifetime alongside the associated activity lifecycle. The states of activity are depicted in this diagram. The same fundamental states apply to a fragment’s lifecycle.

When the system calls an activity object’s onCreate() method for the first time, you usually request a ViewModel. The system may call onCreate() several times during the lifetime of an activity, for instance, when a device screen is rotated. The ViewModel exists from the time you request it until the activity is completed and destroyed.

Example – Without ViewModel

Step 1: Open the activity main.xml file.

Navigate to the app > res > layout > activity main.xml file and paste the code given below into it. The code for the activity main.xml file is shown below.

Step 2: Working with the MainActivity.kt file.

Refer to the following code in the MainActivity.kt file. The MainActivity.kt file’s code is shown below.

Output:

Simply click the button five to six times to see the incremented number appear on the screen. Simply rotate your emulator or device now.

You will notice that the number decreases to zero, because rotating the screen, erases the value.

• In the above image, when our activity is created, the system calls onCreate(), then onStart(), and finally onResume(). However, when we rotate the screen, our activity is destroyed, and the system calls onCreate() and other functions one after the other. As a result of our activity being destroyed, our activity data has also vanished.
• To solve this issue , we use ViewModel, which retain data even after configuration changes such as screen rotation.

Example – with ViewModel

Get Started:

Step 1: Add this dependencies in the build.gradle file:

// ViewModel implementation(“androidx.lifecycle:lifecycle-viewmodel-ktx:2.4.0-alpha03”)

Step 2: Create the MainViewModel.kt Kotlin class file and add the code given below into it.

Step 3: Working with the MainActivity.kt file.

Update the following code in the MainActivity.kt file. The MainActivity.kt file’s code is shown below.

Run the application and you see that even after rotating the screen we get the same value.

Output:

What is ViewModel Factory?

The factory is responsible to create your instance of ViewModel. If your ViewModel has dependencies and you want to test your ViewModel then you should create your own ViewModelProvider. Factory and passed dependency through ViewModel constructor and give value to the ViewModelProvider.

Why we use ViewModel Factory?

We’ve seen how objects survive configuration changes using ViewModel (On Screen-Rotate), but we didn’t create ViewModel on our own because ViewModelProviders instantiate ViewModels with no-arg constructors by default.

So, if I have a ViewModel with multiple arguments, I need to use a Factory that I can pass to ViewModelProviders to use when an instance of ViewModel is required.

What is difference between AndroidViewModel and ViewModel?

The difference between the ViewModel and the AndroidViewModel class is that the AndroidViewModel one provides you with an application context, which you need to provide when you create a view model of the type AndroidViewModel.

AndroidViewModel is a subclass of ViewModel that is aware of the Application context. However, having access to a context can be dangerous if you aren’t observing or reacting to the context’s lifecycle. It is best to avoid dealing with objects that have a lifecycle in ViewModels.

Why we need ViewModel Factory?

• We are unable to create ViewModel on our own. To create ViewModels, we need the ViewModelProviders utility provided by Android.
• ViewModelProviders, on the other hand, can only instantiate ViewModels with no arg constructor.
• So, if I have a ViewModel with multiple arguments, I must use a Factory that I can pass to ViewModelProviders to use when an instance of MyViewModel is needed.

• To create an instance of ViewModel, I need to have a factory that ViewModelProviders can use.
• ViewModelProviders Utility is unable to create a ViewModel instance with an argument constructor because it does not know how or what objects to pass in the constructor.

For Example:

If we need to pass some input data to the ViewModel constructor, we must create a factory class for it.

class MainViewModelFactory(val counter: Int) : ViewModelProvider.Factory < override fun create(modelClass: Class ): T < return MainViewModel(counter) as T > >

We cannot directly create the object of the ViewModel as it would not be aware of the lifecycleOwner. So we use:

mainViewModel = ViewModelProvider(this,MainViewModelFactory(5))[MainViewModel::class.java]

Example using ViewModel Factory

Now we are going to add ViewModelFactroy to the example given above to pass some input data to the ViewModel constructor, we must create a factory class for it.

Get Started with continuing the above example:

Step 1: Create a MainViewModelFactory and add the given below code into it.

Step 2: The MainViewModel looks like this:

Step 3: In MainActivity.kt file– Add the MainViewModelFactory and pass the 5 as an argument in ViewModelProvider. the code looks like this:

Output:

When you run the application and you will get the default value of five.

That’s all about the AndroidViewModel.

If you are interested in learning Data binding and View Binding, you can go through Data Binding in Android with Example, and View Binding in Android with Example here I have explained Data Binding, One-way, and Two-way Data Binding, @BindingAdapter, View Binding in detail with suitable Examples in Android, and several scenarios in which data and view binding can be useful. and I assure you that till the end, you will have a clear understanding of this commonly used library.

• We hope that this guide will assist you in understanding all the concepts of Android ViewModel and ViewModel Factory in android. We have concentrated on making basic, meaningful, and easy-to-learn concepts of it and Factory with suitable examples. Still, if you have any problems regarding it, please post them in the comments section, we will be glad to assist you.

Источник