Dagger Multibindings for Android (Part 2)
As promised in my introduction post, I will write now about something directly related to Android development - Viewmodels. With my current project, I finally got started with Android Viewmodels and the whole architecture components family. Despite all the critics I heard before, I really like to work with them so far.
As an Android developer, I was especially pleased when I saw that it was even possible to pass dependencies via a constructor. But of course, this new technique to create objects basically yourself (sounds crazy I know) needed a special class to handle this magic for you — a ViewModelFactory.
To be fair, what you get for this is really cool. All your panic attacks when you see users rotating devices are suddenly gone, as the ViewModel survives configuration changes. To get such a scoped ViewModel you have to use the ViewModelProvider.
The first argument is usually your Activity or your Fragment, you want your ViewModel to be scoped to. The second argument is the ViewModelFactory, which you only need to provide if you want to pass arguments to your ViewModel via a constructor (which you should want). And last you specify which ViewModel class you want to get a reference to.
This last information is needed so the ViewModelFactory will know which ViewModel it has to instantiate.
This is the interface your ViewModelFactory has to implement. You get the class information and give back a ViewModel, pretty straightforward, right ?
But what happens when you want to pass dependencies to your ViewModels ? Will you have to pass all dependencies for all ViewModels through your factory constructor ? Or will you have to make a ViewModelFactory for each of your ViewModels ? Doesn’t sound too nice, does it ?
And here again comes Dagger Multibindings to the rescue
First we will have to provide our ViewModel via Dagger. It is a good practice to use annotated constructors when possible. But be aware Dagger will create a new instance of our ViewModel, each time we inject it somewhere.
Now as Dagger knows how to instantiate our ViewModel, we will add it to a Multibindings map.
As you can see we don’t use a String key like in my previous post, but instead we created a new annotation to limit our key to ViewModel classes.
So why are we binding all our ViewModels in a map again ? Exactly ! To inject it in our ViewModelFactory !
So let’s do this slowly from top to bottom. First, you can see we made it Singleton scoped, as we will probably need only one instance of the factory and the map we are injecting can become quite big. Here it is considered a good practice to annotate the scope together with the class declaration, as it is part of the implementation details of the class.
Next let’s look at the annotated constructor. It takes our ViewModel map as a parameter. The key of the map is the ViewModel class we defined.
The value of the map is the interesting part. What you need to know here is, that Dagger has different options to provide objects for you. One of them is through a Provider, which is actually an Interface from Java.
So we have now a bunch of those Providers in our map. Which means that our Viewmodels are not created yet, but will be created as soon as we call get() on the Provider.
All we have to do in our factory is to check if we have the Provider for the ViewModel in our map and if so we create the ViewModel with the Provider and return it. Like this, we can configure our dependencies how we like it via Dagger and our ViewModelFactory stays simple.
You can find the source code for this example here. The next part of this series will be about Adapter Delegates, so stay tuned, thank you for reading and as always feedback is highly appreciated and feel free to connect.
