View Model Creation in Android — Android Architecture Components & Kotlin

I have just recently started using Google’s Android Architectural Components, mainly ViewModel and LiveData, specially because now you can use LiveData object as an observable field in data binding expressions. When building an application using ViewModels, data is retained as long as its scope is alive (it can be a Fragment or an Activity), avoiding unnecessary recreation of objects and data refetching. This really helps in situations like configuration changes (rotation, for example). There are a lot of very good articles better explaining what ViewModel and LiveData are, how and why to use them. I’d recommend reading them first. This article focuses on how to create an instance of a ViewModel, some flaws of the methods provided by the library and how to improve them.

As previously mentioned, the ViewModel is scoped to an Activity or Fragment, and must live as long as the scope is still alive. Therefore, we must not instantiate it during the onCreate , for example, as it might get called multiple times in the same activity, and would cause the unnecessary recreation of the ViewModel, losing its data and states. This issue is solved by the Architecture Components with the ViewModelProviders , which does the job of keeping the ViewModel alive and paired with the scope:

This way, the ViewModel will only be instantiated if it does not yet exist in the same scope. If it already exists, the library will return the same instance it was already using. So even if you do not use the lazy delegate, and make this call in the onCreate , you are guaranteed to receive the same ViewModel every time. It will only be created once. This is great! 🎉

What is the problem then? As the library is the one responsible for creating the ViewModel, we do not get to call its constructor, the library is doing that internally, and by default it will always call the empty constructor, making it impossible to pass data to it. To make matters even worse, a fatal runtime exception will be caused if the ViewModel does not have an empty constructor.

One might try to initialize the ViewModel by defining a public method and calling it as soon as the ViewModel is created, in the onCreate , for example, but this is wrong, as this might get called multiple times during the life of the Activity or Fragment. This will lead to strange behaviour, as it might cause data refetching and state changes on a ViewModel that was already ready and being used.

The correct way of doing this, is to create factory for the ViewModel, and to pass it to the ViewModelProviders. We are basically teaching the library how to create the ViewModel we want, so it will use the factory for that, when needed. This is the factory:

And this is how we pass it to the ViewModelProviders:

In this example I am sending a user ID to the ViewModel, getting it from the intent’s bundle.

Here is the ViewModel I created for this example:

I am not really using the ID in this example, just setting a value to the name LiveData to test the binding. But code put in this init block is guaranteed to execute only once, when the library creates the ViewModel and pairs it to the Activity or Fragment.

This solution provided by the library definitely works, but it has a couple of problems:

• A lot of boilerplate code. Most of the time we have one ViewModel per Fragment or Activity, and we end up not using it elsewhere. Having to write a factory for every ViewModel is really cumbersome.
• It is not typesafe, the UserViewModelFactory could very well return a different ViewModel, and the project would still compile, but the app would crash during runtime because we are getting a different type than that specified at the ViewModelProviders .

We can avoid the creation of one factory per different ViewModel by creating a BaseViewModelFactory that receives the creation logic from the outside, through a lambda, and just calls it when necessary, this already reduces a lot of the boilerplate code:

And this is how we can use it:

The creation logic is now this block of code passed to the BaseViewModelFactory and that will be executed by it.

We are still not typesafe, and I still feel like we could further reduce the code we need to write. So using some cool Kotlin features, we can improve this even more. This code is, unfortunately, not callable from Java, as inline along withreified are Kotlin-specific features used to overcome problems introduced by Java’s type erasure. These extension functions should not go inside any class, they can be on any Kotlin file:

We are writing an extension function for both the Fragment and the Activity because they are the different possible scopes for the ViewModel.

To get our ViewModel we simply use getViewModel() if we want to use the default, empty constructor, or getViewModel{} passing the creation logic inside, if we want to use a different constructor, or customize the creation anyhow. Our previous example now looks like this:

We reduced even further the verbosity and made it typesafe! If the logic inside the getViewModel{} returns a different type of that previously declared in the val, the project will not compile. Much better than getting a runtime error. It is also much less redundant, as we infer the type whenever possible, and no longer need to pass a ::class.java type.

We can call getViewModel in a couple of different ways:

If the val is not explicitly declared of a particular type, and no custom logic is used during the creation (a constructor is not explicitly called and an object returned), we need to pass the type to the method.

Complete code of the activity created, and its XML layout (using data binding):

The complete code for the ViewModel was already posted above.

Bonus

If called within a Fragment, getViewModel will return a ViewModel scoped to that Fragment. We can scope it to the activity to which the Fragment is attached by calling activity?.getViewModel() . This is really powerful, because the same rule as before applies: the ViewModel will be scoped to the activity and will live as long as it lives, and there will be only one instance. This is a super effective way to share data between fragments attached to the same activity, and allows them to react to changes super effectively if data binding is being used. No more need to implement interfaces in the activity and hold references to them inside the fragment to change shared data.

The End!

Hope you find this article useful and that it helps you create your ViewModels in a faster way, with less code and avoiding runtime errors 😄