Offline first Android App with MVVM, Dagger2, RxJava, LiveData and Room

Part1 → Setting up Dagger2

MVVM components and basic interactions.

Part 1 → Setting up Dagger 2
Part 2 → Setting up Room
Part 3 → Setting up Retrofit
Part4 → Setting up Repository and ViewModel
Part 5 → Setting up de List with “infinite” scrolling

As an Android Developer, during the last 2 or 3 years I had only worked with apps using MVP design architecture pattern and I hadn’t had much time to take a look at MVVM, Dagger2, RxJava, LiveData and Room, all together in the same project. But finally I decided to dedicate some leisure and learning time to a new way to build an Android app with these tech stack in addition to the offline first strategy, which is nowadays very common, useful and interesting.

This is the first article in a series of several in which I’m going to show how I approached this tech stack trying to implement a simple app which consumes the CoinmarketCap’s API to initially query the list of some cryptocurrencies listed there, then all the data is stored in a local DB and finally show them in the app in a single screen. Maybe in the future I can add new features and screens leveraging the different endpoints.

Now as a way of work, my idea is to create different branches, in which we can see the evolution and the step by step of the job done.

First Branch and first project configuration

In the first branch I’m going to configure Dagger 2. I know that we can work with Dagger2 in several ways, and everyone of us tackles it using different approaches, but in the end we’ll achieve the same or similar results. In this project, the version I’m using is 2.13, so the configuration in app’s build.gradle file as follows:

Starting in version 2.11 new Dagger2’s versions are a subtle evolution of the previous ones, and the changes introduced are aimed to facilitate Android-specific dependency injection. Modules are still used to provide dependencies and we still inject AppComponent in App class as well. A new major change is the use of AndroidInjector class to reduce injection into Activities, Fragments, Services, BroadcastReceivers and ContentProviders down to one line of code like this:

Then, in order to add concrete Activity class to the dependency graph, we can use special @ContributesAndroidInjector annotation within a new injection module named BuildersModule in which we say to Dagger where to apply the injection:

And the AppModule as follow:

Finally, the AppComponent looks like this (we need to indicate to the component which modules are going to be used: the new AndroidInjectorModule from Dagger’s library, the AppModule as usual and the new BuildersModule):

Remember to set your app’s Application class rather than the generic Application class, this will ensure that when you are injecting the dependencies, you won’t face problems in runtime.

As a hint when injecting all dependencies, the app’s application class must implement Dagger2’s HasActivityInjector interface and create the activity injector (DispatchingAndroidInjector<Activity>) which will be provided when activityInjector method is overridden. It only needs to be done one time. The Application class looks like this:

Now, clean the project, rebuild it and it’s done, this branch already has Dagger2 configured.

You can get the code from Github:

In the next article, I’m going to configure Room, so stay tuned ;)

Headline image taken from ProandroidDev.