Chapters
Chapters

Chapters

Hide chapters

Dagger by Tutorials

First Edition · Android 11 · Kotlin 1.4 · AS 4.1

Before You Begin

Section 0: 4 chapters
Show chapters Hide chapters

Section I: DI Fundamentals

Section 1: 5 chapters
Show chapters Hide chapters

Section II: Introducing Dagger

Section 2: 4 chapters
Show chapters Hide chapters

Section III: Components & Scope Management

Section 3: 3 chapters
Show chapters Hide chapters

Section IV: Advanced Dagger

Section 4: 3 chapters
Show chapters Hide chapters

Section V: Introducing Hilt

Section 5: 5 chapters
Show chapters Hide chapters

Section VI: Appendices

Section 6: 2 chapters
Show chapters Hide chapters

5. Dependency Injection & Testability
Written by Massimo Carli

Heads up... You’re accessing parts of this content for free, with some sections shown as scrambled text.

Unlock our entire catalogue of books and courses, with a Kodeco Personal Plan.

Unlock now

Heads up... You’re accessing parts of this content for free, with some sections shown as scrambled text.

Unlock our entire catalogue of books and courses, with a Kodeco Personal Plan.

Unlock now

In the previous chapters, you refactored the Busso App to introduce the concept of dependency injection by implementing a ServiceLocator and an Injector. In particular, you focused on the lifecycles of objects like Observable<LocationEvent> and Navigator.

This has simplified the code a bit, but there’s still a lot of work to do. Busso contains many other objects, and the app’s test coverage is pretty low — not because of laziness, but because the code, as you learned in the first chapter, is difficult to test.

To solve this problem, you’ll use an architectural pattern — Model View Presenter — along with what you learned in the previous chapters to create a fully-testable app.

In this chapter, you’ll use techniques that would work in a world without frameworks like Dagger or Hilt. Using them will also prepare the environment for the next chapter, where you’ll finally get to use Dagger.

Note: In this chapter, you’ll prepare Busso for Dagger and, later, Hilt. You can skip ahead to the next chapter if you already know how to use the Model View Presenter architectural pattern — or if you just can’t wait.

Model View Presenter

Maintainability, testability and making changes easy to apply are some of the main reasons to use an architectural pattern. Understanding which pattern is best for your app is outside the scope of this book. For Busso, you’ll use Model View Presenter (MVP).

Note: To learn all about architectural patterns in Android, read our book, Advanced Android App Architecture.

As the name implies, MVP is a pattern that defines the following main components:

  • Model
  • View
  • Presenter

A pattern gives you some idea about the solution to a specific problem. Different projects implement patterns in different ways. In this book, you’ll use the implementation described in the diagram in Figure 5.1:

Figure 5.1 — The Model View Presenter Architectural Pattern
Figure 5.1 — The Model View Presenter Architectural Pattern

Before you move on, take a quick look at the responsibilities of each component and how you use them to define the main abstractions in code.

Note: You might have heard that Model View Controller is a design pattern, but that’s not technically true. Historically, the only design patterns are the ones listed in the famous book, Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides, also known as “The Gang Of Four”.

Model View Presenter, Layer, Model View Controller, Model View ViewModel and many others are architectural patterns. The scope and the set of problems they solve are at a higher level of abstraction compared to design patterns.

Next, you’ll take a closer look at each of the components that compose MVP.

Model

The Model is the data layer — the module responsible for handling the business logic and communication with the network or database layers. In Figure 5.2, this is the relationship the observes label shows between the Model and the Presenter.

Guxiju 0.0 — Mda Votor ufzegantueqt
Wileku 7.3 — Tze Hozuc urpequwheodj

Busso App’s Model

In Busso, the Model contains:

Testing Busso’s Model

Thinking about the Model components this way makes the test implementation easier. You already tested Observable<LocationEvent> in the libs/location/rx module. But what about the test for BussoEndpoint?

View & ViewBinder

The View component is the UI Layer. It has a bidirectional interaction with the Presenter. It’s an abstraction of the component responsible for receiving data and translating it into actual operations on the UI elements on the screen.

Hajace 2.8 — Fois iqsosixmiog
Birizi 7.3 — Woag ejqijolloas

Boheha 1.1 — Tnu HuilBukxes ujzwpakquoj uf cdo Fapte Xnecokc
Hezugi 3.3 — Fbe BuopSigrig asvsxicvuib eq the Pukro Gzevoxz

Using ViewBinder for the BusStopFragment

Open BusStopFragment.kt and look at the code. Keeping the View responsibility in Figure 5.3 in mind, find the place in the code where you:

Implementing BusStopListViewBinder

Your next goal is to move around some code to simplify BusStopFragment and make your app easier to test.

Creating the UI components

init()’s implementation is very simple. All it needs to do is to create the UI for the list of BusStops. It’s currently just a cut-and-paste from the current BusStopFragment to the BusStopListViewBinderImpl.

Displaying information in the UI components

In the BusStopListViewBinder interface, you now need to do two things: Implement the operation that displays the list of BusStops onscreen and show an error message.

Observing user events

Your BusStopListViewBinder implementation needs to manage two events:

Testing BusStopListViewBinderImpl

The BusStopListViewBinderImpl you just implemented isn’t difficult to test. Create the test class with Android Studio, just as you learned in Chapter 2, “Meet the Busso App”, and add the following code:

Presenter

As a mediator, the Presenter has two jobs. On one side, a Presenter receives the Model’s changes and decides what to display on the View and how to display it.

Baveto 5.6 — Ywi Swexovhod okvhzeqwueh oy pfu Robcu Gferumw
Dateqi 0.8 — Hfe Vjoyejliq ixpywirceos et hxo Rejli Mlirutt

Using a base Presenter implementation

Binding and unbinding the ViewBinder from the Presenter is very common. It’s useful to also provide a base implementation of the Presenter interface.

Bacire 2.0 — Kxi Xlimukziv diru olgrabalhemuod ik qko Fivqe Mlikegh
Gigeso 8.3 — Rme Bfavajzow diho ucyxedaykupier ix kme Xonqe Pyonaks

The BusStopListPresenter interface

Setting up the Presenter for BusStopFragment is simple. Create a new file named BusStopListPresenter.kt in ui.view.bustop and enter the following code:

The BusStopListPresenter implementation

Creating the BusStopListPresenter implementation is a matter of understanding its responsibility. Looking at the existing code in BusStopFragment, this class needs to:

Testing BusStopPresenterImpl

Testing BusStopPresenterImpl is now much simpler. You’ll create the test using the methods you learned in Chapter 2, “Meet the Busso App”. To start, enter the following code:

Putting it all together

Now that you’ve implemented the Model, ViewBinder and Presenter for the BusStopFragment, you need to connect all the dots. Following what you’ve done in the previous chapters, you need to:

Extending the FragmentServiceLocator

You now have two more objects to manage. Open FragmentServiceLocator.kt from the di.locators package for the app module, then add the following code without changing the existing fragmentServiceLocatorFactory definition:

Injecting BusStopListPresenter and BusStopListViewBinder into the BusStopFragment

Open BusStopFragment.kt and replace the existing code with the following:

Extending BusStopFragmentInjector

The very last step is to implement BusStopFragmentInjector. Open BusStopFragmentInjector.kt and replace the existing code with the following:

Hikicu 3.5 — Vwo Fwagipxok yaku ohxgakozyoriaz os hyi Lewnu Lfeguqb
Macupo 9.5 — Gqa Cpakuyhut qazu izqzizuhcuvuev ef tho Torgi Bculefr

Key points

  • Using an architectural pattern like Model View Presenter is a fundamental step toward the creation of a professional app.
  • Design Patterns and Architectural Patterns address different problems in different contexts.
  • Model, View and Presenter allow the creation of classes that are easier to test.
  • The Model is the data layer.
  • The View is the UI Layer.
  • Using a ViewBinder allows you to decouple the presentation logic from the specific Android component.
  • The Presenter mediates between View and Model. It’s often bound to the lifecycle of an Android standard component.

Where to go from here?

If you want to learn more about Mockito, Roboelectric and testing in Android, read the Android Test-Driven Development by Tutorials book.

4. Dependency Injection & Scopes
6. Hello, Dagger
Have a technical question? Want to report a bug? You can ask questions and report bugs to the book authors in our official book forum here.
© 2026 Kodeco Inc.

You’re accessing parts of this content for free, with some sections shown as scrambled text. Unlock our entire catalogue of books and courses, with a Kodeco Personal Plan.

Unlock now