Dagger 2 Android playground:

Let’s play with different configurations and tests.

Update: There is a second part of this post: Let’s play with different configurations and tests… in a multi-module app

Recently I came across Android injectors for Dagger 2. As I have always used dependent components in my Dagger configurations and only sometimes Subcomponents, I decided to create a small pet project where every possibility is tried.

I won’t explain here how Dagger 2 works or the different configurations we can use, There are plenty of posts about it, the idea of this post is to provide a repository to play with.

Specifically I wanted a project with:

  • App level singletons.
  • Scope level singletons.
  • Constructor and property injection samples.
  • Instrumentation test with module substitution.
  • Unit tests with and without Android framework dependencies.

And I wanted to try it with the following configurations:

  • Dependent components.
  • Subcomponents
  • Subcomponents and builders
  • Android injectors

Sample app

The project can be found in Github.

There are four different branches for each of the above configurations.

The application consist in three activities (Main, Detail and Another) each one with a property injected Presenter. Each presenter has a instance of the Navigator and different collaborators injected by constructor.

I have added two collaborator classes: AppCollaborator simulates something needed at application level, like a Repository. It must be singleton and we must be able to substitute it for a mocked version during instrumentation tests. ActCollaborator is a scoped singleton and in the real world it would be any Activity or Service collaborator class.

A scoped injected class means that that class will exist only during the life of the scoped component. In this example it means each activity life.

And finally, the Navigator is the class in charge of navigating between activities. It has the ApplicationContext, both collaborators and the current activity injected. Only the later is really needed but logging all those classes in Navigator will allow us to understand instance lifecycles.

In order to get familiar with the lifecycle and the different configurations each branch README file will propose several exercises:

1- Open the app, navigate to detail, another and check the logs:Context and AppCollaborator share the same instance in Navigator logs, why?Activity and ActCollaborator are different instances in Navigator logs, why?ActCollaborator share the same instance between DetailPresenter and the second Navigator log, why?...

The DI system

We want to maintain things simple, so there are only one ActivityComponent that can be used in every activity. We instantiate the component in a BaseActivity, but we still do the injections in each top level activity:

dependencies = ApplicationComponent.class,
modules = ActivityModule.class
public interface ActivityComponent {

void inject(MainActivity mainActivity);

void inject(DetailActivity detailActivity);

void inject(AnotherActivity anotherActivity);

//Exposed to sub-graphs.
BaseActivity activity();


public class BaseActivity extends AppCompatActivity {
private ActivityComponent activityComponent;

public void onCreate(Bundle savedInstanceState) {
this.activityComponent = DaggerActivityComponent.builder()
.activityModule(new ActivityModule(this))


public class MainActivity extends BaseActivity {

MainPresenter presenter;


public void onCreate(Bundle savedInstanceState) {

This trick can be done using Components or Subcomponents, but I have not been able of doing it using Android Injectors. Here we will need an ActivityComponent for each activity if you need that activity to be injectable in collaborators, like the Navigator in this example.

@Subcomponent(modules = {ActivityModule.class, MainActivityModule.class})
public interface MainActivityComponent extends AndroidInjector<MainActivity> {

abstract class Builder extends AndroidInjector.Builder<MainActivity> {

Apart from this, I cannot see any real advantage or disadvantage of each method. Maybe Dependent components give us better fine control of what is made available to inner components from external ones. Or maybe the use of builders with subcomponents make the code more clean.

Android injectors pretend to be more SOLID compliant making the Activities unaware of the parent components. I don’t think it is really necessary, Activities won’t be SOLID compliant in any case, and it complicates things unnecessarily.

But judge yourself: Open a class, select the different branches and see how that class is for each configuration.

Unit tests:

Unit testing a presenter is easy: We simply instantiate the class with mock collaborators. That’s why injection by constructor is so powerful:

public class MainPresenterShould {

Navigator navigator;
IAppCollaborator collaborator;

private MainPresenter presenter;

public void setup() {
presenter = new MainPresenter(navigator, collaborator);

Testing the Navigator class is slightly more difficult. It is Android framework aware (There are Logs, Context, Activities and Intents on it). So we need to mock the Android framework. The easiest way to do so is running the test with Robolectric test runner:

public class NavigatorShould {

Instrumentation tests:

In order to do instrumentation tests, we usually need to substitute the data source for a mocked one. We will simulate this substituting the AppCollaborator class. This class provides the title for the MainActivity and we will want a different title while testing with Espresso.

To do so we need to extend AndroidJUnitRunner with our own TestRunner that will instantiate the TestAndroidApplication class that extends the AndroidApplication one (Our Application instance) . This way, we can use a different application component, the TestApplicationComponent, that will use TestApplicationModule instead ApplicationModule.

Seems complicated? It is not. Take a moment to follow my previous explanation in Android Studio or the Github repo. On a real world, our Application component will use several modules, and now we will be able to change only those we need to have a different behaviour under tests.

In this sample case both AppCollaborator and TestAppCollaborator extend from IAppCollaborator (Sorry for the old naming, but I wanted to leave it clear that this is an interface), so the module only have to change the instance returned:

IAppCollaborator provideAppCollaborator() {
return new TestAppCollaborator();

Hope this playground helps you test different dagger configurations and understand the different behaviours and testing systems.




Principal Android Developer in the healthcare industry.

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

Fast growing architectures with serverless and .NET Core

Launch EC2 Instance With Terraform — Steps to provision

Top Features You Need from Office Software

How to Migrate JSON Data from MongoDB to MaxCompute

Invalid HTTP Method: PATCH

How to use WooCommerce Variations and Attributes with FooEvents — Tutorial

Introducing GitPOAP

Haskell Book: Chapter 11 — Algebraic Data Types

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Miguel Sesma

Miguel Sesma

Principal Android Developer in the healthcare industry.

More from Medium

Unit Testing Starting Guide for Android Developers

How To Use Hilt to Setup a Solid Architecture in Android

Taming Android Unit Test when using different flavors and build types

Kotlin scope functions: let, run, with, also, apply