London Tube Status App — gradle cleanup and dagger
Index:
- London Tube Status App — setting up
- London Tube Status App — gradle cleanup and dagger
- London Tube Status App — Retrofit and API setup
- London Tube Status App — wrapping up the data layer
- London Tube Status App — domain layer
- London Tube Status App — layouts and view model
- London Tube Status App — MVP implementation
- London Tube Status App — UI tests and going live
- London Tube Status App — from dagger to koin
- London Tube Status App — from MVP to MVVM
- London Tube Status App — from Rx to Coroutines
Hey everyone, welcome to article number 2 on this series. If you missed the first article, check it here. It covered an introduction to the project and the plan, as well as the initial setup and definition of clean architecture gradle modules. Today, before jumping into dagger we’ll do a little bit more gradle cleanup so it’s easier to manage dependencies.
Gradle cleanup
If we look back at the setup from the previous article, we can see that there are some dependencies which are shared between more than one module, for example:
dagger and rxAndroid are dependencies for both app and data
rxJava2 and ktlint task are dependencies for all modules
So, rather than having those dependencies repeated in more than one gradle script, we can have them in only one common gradle script and then apply that script in our modules gradle script.
Because we have dependencies that are shared only between Android modules and others shared between all modules, let’s create an android_common_gradle and a common_gradle script.
In android_common_gradle as expected we place our dependencies that are shared between android modules.
In common_gradle we place all the dependencies shared between all modules, Android and non-Android.
Then to apply these in our modules gradle scripts all we need to do is to add these lines to the top:
apply from: '../config/android-common.gradle'
apply from: '../config/common.gradle'For app and data modules we add both lines as they share both the Android and the common dependencies, and for domain we only add the second line as we don’t want android dependencies. And don’t forget to delete all those dependencies now handled in these common gradle scripts.
Ok, now that we have a cleaner gradle setup we can move on to the core part of the article and create a simple dagger setup for our app.
Dagger setup
This is going to be a relatively small project so our dagger setup will be also relatively small and simple. But let’s start with the dependencies.
You probably noticed in the previous article, and also above, that Dagger dependencies were already there, but let’s go step by step here again so we don’t miss anything. First, let’s check our Dependencies.kt file and make sure the following dependencies and versions are there:
Then, in our android-common.gradle we add the dagger dependencies (first 4) and in our common.gradle we add the javaxInject dependency so we can later use the @Inject annotation in our Interactors. You can check how in the snippets used above for the gradle cleanup part.
Ok, now that we have our dependencies sorted, let’s start building our dagger setup. First, let’s create a basic ApplicationComponent like this:
And an AppModule like this:
Now, let’s go ahead and create those other modules we see above in the ApplicationComponent class. We’ll leave them empty for now and we’ll populate them along the way when needed, in the next articles:
NetworkModule — this is where we’ll add retrofit, gson and other network dependencies
RepositoryModule — this will contain the repository dependencies
MappersModule — the network models to entity mappers will be handled here
InteractorsModule — all our interactors will be provided by this module
For now, because we’re leaving them empty, they all should look as simple as this:
Note: don’t know if you noticed but we only added the retrofit dependency on the data_build.gradle above. We don’t need retrofit in the other modules, and this means our NetworkModule will also live inside the data module.
To summarise, our ApplicationComponent and all the modules except the NetworkModule will live under a root di package on the app gradle module. And the NetworkModule will live under another root di package on the data gradle module.
And this is it, a very simple dagger setup for our app that is quite simple as well. Later we’ll populate those modules. We could live with everything in the AppModule but it’s nicer to break it down and separate in more files with clear responsibilities.
In the next article we’ll look into the API we’re going to use to fetch the line statuses and we’ll populate that NetworkModule above with all the retrofit service initialisation and configurations.
And that’s it for today, hope you enjoyed it and if you did, don’t forget to leave some 👏 and see you at number 3 for some network stuff 👋.
London Tube Status App — setting up ⬅ PREVIOUS
