Dagger in Multi-Module Clean Applications
In this tutorial, you’ll learn how to integrate Dagger in an Android multi-module project built using the clean architecture paradigm. By Pablo L. Sordo Martinez.
Sign up/Sign in
With a free Kodeco account you can download source code, track your progress, bookmark, personalise your learner profile and more!
Create accountAlready a member of Kodeco? Sign in
Sign up/Sign in
With a free Kodeco account you can download source code, track your progress, bookmark, personalise your learner profile and more!
Create accountAlready a member of Kodeco? Sign in
Sign up/Sign in
With a free Kodeco account you can download source code, track your progress, bookmark, personalise your learner profile and more!
Create accountAlready a member of Kodeco? Sign in
Contents
Dagger in Multi-Module Clean Applications
30 mins
- Getting Started
- Covering Key Concepts
- Multi-Module App
- Clean Architecture
- Dependency Injection With Dagger
- Analyzing the Problem
- Building Up the Dagger Graph
- Connecting the Data Layer
- Populing the Data Layer
- Domain Layer
- Presentation Layer
- Getting Familiar with Components and Subcomponents
- Buliding Activity Components
- Building the Application Component
- Wrapping Everything Up
- Performance Assessment
- Testing
- Testing the Presenter
- Testing the Use Case
- Testing the Repository
- Where to Go From Here?
Testing
There’s one minor thing you have to do to complete this tutorial: Fix the tests that were failing at the beginning.
There are three test files in the project, one per module: MainPresenterTest
, FetchNumberFactUcTest
and NumberDataRepositoryTest
. All of them comprise unit tests of certain functionalities.
Testing the Presenter
If you open MainPresenterTest.kt
and run the tests, you’ll see one is failing. Scroll down and you’ll find a // TODO:
which tells you what the problem is: The use case variable isn’t accessible. But after the changes you made in this tutorial, this should no longer be a problem. Go to the @Before
section and replace the mainPresenter
initialization with this one:
mainPresenter = MainPresenter(view = mockView, fetchNumberFactUc = mockUsecase)
That’s all! Now, since the presenter receives all the dependencies in the constructor, you can mock anything you want. Note that you haven’t even initialized Dagger whatsoever.
Now that you’ve fixed the main presenter tests, it’s time to fix up the FetchNumberFactUcTest
you looked at earlier.
Testing the Use Case
To fix the use case test that was failing — FetchNumberFactUcTest
— you only need to make a few changes. First, you’ll see there’s an error when instantiating the use case in the @Before
section. Change it to the following:
usecase = FetchNumberFactUc(numberDataRepository = mockRepository)
After that, scroll down to the failing test and stub the repository so that it returns a known value that can be assessed. Place the following below rightParams
, in the // given
subsection:
whenever(mockRepository.fetchNumberFact(request = rightParams)).doReturn(NumberFactResponse("None").right())
Easy peasy, isn’t it? Now you can run the tests and you’ll see them all pass. This means that the use case is doing what you expect, i.e. validating your logic.
Testing the Repository
Open NumberDataRepositoryTest.kt
and run the tests. As you can see, all of them pass. :] You might have not seen it when you started the tutorial, but this file contained two errors (lines 36 and 53). The problem occurred when trying to initialize the repository and passing a value for numberFactDataSource
, which was immutable at that time. The changes you made solved these issues.
Where to Go From Here?
You can download the final version of the project using the Download Materials button at the top or bottom of the tutorial.
There are several good references for the main topics addressed in this article:
- In addition to the links further up, this Clean Architecture Tutorial for Android: Getting Started tutorial is a great primer to this topic.
- When it comes to dependency injection using Dagger, don’t hesitate to look at the official site. It’s updated often.
- Implementing multi-module apps isn’t a paradigm, but it’s a good practice if you want a proper separation of concerns. You can read this article for more about it, and don’t forget to look at dynamic features if you feel brave. :]
Recently, Android added Dagger to the official documentation, so there are a good number of references.
Perhaps the best thing you can do after reading this article and completing the exercise is to migrate one of your own projects. In doing so, you’ll see which difficulties and challenges may arise in a real application. Have a look at the tips provided and use them to make your apps more flexible and reusable.
We hope you enjoyed this tutorial. If you have any questions or comments, please join the forum discussion below!