New Android architecture components in action: creating a restaurants map application with Room, ViewModel, LiveData and Dagger 2
Part 2: ViewModel, View and Dagger.
Part 1: Architecture overview; Room, web server and Repository components.
Part 3: Tests
In the first part we started building a restaurants map application using the new Android architecture components. In this part we’ll see how to implement ViewModel component and wire things together using Dagger.
The thing with ViewModels is that they live longer then the Views they are serving. To make this work correctly, we use ViewModelProviders class to instantiate the concrete ViewModel class:
ViewModelFactory is a Factory Method for constructing ViewModel classes:
RestaurantsViewModel implementation takes a Repository to fetch restaurants from it, and provides a LiveData observable:
Result of restaurants is a Transformation from MutableLiveData<Int> to LiveData<Resource<List<Restaurant>>>, which is a recommended way of working with ViewModels to avoid creating new LiveData objects each time we subscribe.
To glue this all together we need to use dependency injection. There is a lot of information about dependency injection and Dagger 2, I personally recommend this post, I love how they explain theoretical basis. One caveat is that there have been subtle changes in Dagger, and it took me a while to understand that the latest library version 2.13 I was using works differently compared to, say, version 2.10. Documentation and examples at the official Dagger website are notoriously useless.
The changes introduced in the latest versions of Dagger, nevertheless, were aimed to facilitate Android-specific dependency injection. We still use Modules to provide dependencies, still inject AppComponent into the Application class, but now we have AndroidInjector class which reduces injection into Activities, Fragments, Services, BroadcastReceivers and ContentProviders down to one line of code:
In order to add concrete Activity class to the dependency graph, we can use special @ContributesAndroidInjector annotation:
After that we add this module to the AppComponent, inject it into Application and we’re done. See the dagger package on the project’s Github page for the whole implementation.
Our View essentially is a map with markers representing restaurants we get from the ViewModel. The logic here is to wait for the map to load, and then subscribe to the ViewModel’s restaurants:
Depending on the Resource status we show a ProgressBar for loading, markers for success or an error. That way we maintain visual representation logic only in the View, observing changes coming from the ViewModel, while the latter has no knowledge about who observes it. ViewModel survives configuration changes like screen rotations and provides cached values whenever possible. If you’re feeling lucky, there is a way more detailed example in this article.
As a tiny bonus, let’s try to use Vector Drawables for markers. With Android Studio, it’s quite simple actually. New -> Vector Asset, add the vector icon you need and that’s it.
To be able to use it, we need to add this to gradle:
and a couple of helper methods:
Finally, use getBitmap() later when constructing the marker options:
Thank you for reading. In the next part we’ll go through unit, integration and functional testing of this creature. Check the whole project at Github:
