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

3. Dependency Injection
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 first chapter, you learned what dependency means and how you can limit its impact during the development of your app. You learned to prefer aggregation over composition because that allows you to change the implementation of Repository without changing the implementation of Server, as described by the following UML diagram:

Figure 3.1 - Aggregation
Figure 3.1 - Aggregation

In code, you can represent that concept like this:

class Server(val repository: Repository) {
  fun receive(data: Data) {
    repository.save(data)
  }
}

With this pattern, Server has no responsibility for the creation of the specific Repository. That syntax is just saying that Server needs a Repository to work. In other words, Server depends on Repository.

In the second chapter, you looked at the Busso App. You learned how to build and run both the server and the Android app. You also looked at its code to understand how the RxLocation and Navigator modules work. More importantly, you learned why the architecture for the Busso App is not the best and what you could do to improve its quality.

In this chapter, you’ll take your next step toward implementing a better app that’s easier to test and modify. You’ll keep the concept of mass of the project in mind, which you saw in the first chapter.

You’ll start by refactoring the Busso App in a world without Dagger or Hilt. This is important if you want to really understand how those frameworks work and how you can use them to solve the dependency problem in a different, easier way.

Dependency injection

Looking at the previous code, which component is responsible for the creation of the Repository implementation you need to pass as parameter of the Server primary constructor?

It’s Main, which contains all the “dirty” code you need to create the necessary instances for the app, binding them according to their dependencies.

OK, so how do you describe a dependency between different objects? You just follow some coding rules, like the one you already used in the Server/Repository example. By making Repository a primary constructor parameter for Server, you explicitly defined a dependency between them.

In this example, a possible Main component is the following main() function:

fun main() {
  // 1
  val repository = RepositoryImpl()
  // 2
  val server = Server(repository)
  // ...
  val data = Data()
  server.receive(data)
  // ...
}

This code creates:

  1. The instance of the RepositoryImpl as an implementation of the Repository interface.
  2. A Server that passes the repository instance as a parameter of the primary constructor.

You can say that the Main component injects a Repository into Server.

This approach leads to a technique called Dependency Injection (DI), which describes the process in which an external entity is responsible for creating all the instances of the components an app requires. It then injects them according to some dependency rules.

By changing Main, you modify what you can inject. This reduces the impact of a change, thus reducing dependency.

Note: Spoiler alert! Looking at the previous code, you understand that Server needs a Repository because it’s a required parameter of its primary constructor. The Server depends on the Repository. Is this enough to somehow generate the code you have into main()? Sometimes yes, and sometimes you’ll need more information, as you’ll see in the following chapters.

Currently, the Busso App doesn’t use this method, which makes testing and changes in general very expensive.

In the following sections of this chapter, you’ll start applying these principles to the Busso App, improving its quality and reducing its mass.

Types of injection

In the previous example, you learned how to define a dependency between two classes by making Repository a required constructor parameter for Server. This is just one way to implement dependency injection. The different types of injection are:

Constructor injection

This is the type of injection you saw in the previous example, where the dependent type (Server) declares the dependency on a dependency type (Repository) using the primary constructor.

Field injection

Constructor injection is the ideal type of injection but, unfortunately, it’s not always possible. Sometimes, you don’t have control over the creation of all the instances of the classes you need in your app.

Method injection

For completeness, take a brief look at what method injection is. This type of injection allows you to inject the reference of a dependency object, passing it as one of the parameters of a method of the dependent object.

Busso App dependency management

In the previous sections, you learned all the theory you need to improve the way the Busso App manages dependencies. Now, it’s time to get to work.

Xepabe 9.6 - Spi Yupci Akp
Davere 4.8 - Bde Hijcu Ixc

Dependency graph

When you want to improve the quality of any app, a good place to start is by defining the dependency graph.

Qamuci 6.3 - SklecjIkzejarg jagehfogcy miupduh
Zamafa 1.0 - FwrepnAxticalr yimevvemjy tuummor

The service locator pattern

Now, you have the dependency diagram for SplashActivity and you’ve learned how dependency injection works. Now, it’s time to start refactoring the Busso App.

The ServiceLocator interface

Next, create a new package named di in the com.raywenderlich.android.busso package for the Busso app. Then add the following to ServiceLocator.kt:

The initial ServiceLocator implementation

Now you can also provide an initial implementation for the ServiceLocator interface. Create ServiceLocatorImpl.kt in the same package of the interface with the following code:

Vonadi 7.8 - Jyoituit ix pra JarfageHikunix.qh jezu ofgu cna he medhuni
Xigoho 7.2 - Jbualuiv os vxu GafnebiNiluyas.vh kaca ambo zpu ja mohvuni

Using ServiceLocator in your app

Start by creating a new Main.kt file in the main package for the Busso App, then add the following content:

Baroci 9.5 - Jehaleoz pey qra EpjhuefQaxafiny.dzp cadi
Xowida 1.1 - Kijowuus map llu UrzjeemKuvohidc.dhk hupi

Using ServiceLocator with LocationManager

You’re now ready to use ServiceLocator to manage the instances of your app in a single place, thus simplifying its code.

Using ServiceLocator in SplashActivity

Now, you can use ServiceLocator for the first time in SplashActivity, completing the field injection. First, open SplashActivity.kt and remove the definition you don’t need anymore:

Vituse 7.2 - Xba Lijko Ayn
Niluno 9.2 - Ggi Hucbo Eny

Adding the GeoLocationPermissionChecker implementation

To prove that the small change you just made has a huge impact, just repeat the same process for the GeoLocationPermissionChecker implementation.

Bupego 3.9 - Nro CaoDesakuoxQilqecroenRbixvonObnt.gk jode
Noqipe 3.0 - Fla WuoKoxexooyWojcihqiihKkakyovEbny.zk texu

Bakocu 4.2 - Xsa Mikvo Ush
Helige 6.5 - Gzi Qotgu Ejs

Refactoring Observable<LocationEvent>

As mentioned above, the dependency diagram is useful when you need to improve the quality of your code. Look at the detail in Figure 3.9 and notice that there’s no direct dependency between SplashActivity and LocationManager or GeoLocationPermissionChecker. SplashActivity shouldn’t even know these objects exist.

Wolewe 1.1 - Yehajpucww cuqyiip DcdelxExcawivf ewt Iyxeglabyo<MutamaebOcewy>
Falito 3.7 - Xogidmadnw nokmiop GrpaslElzukipd urf Ezvagjuhma<LeropaopUkuqr>

Challenge

Challenge 1: Testing ServiceLocatorImpl

By following the same process you saw in the previous chapter, create a test for ServiceLocatorImpl. At this moment, you can implement the test as:

Key points

  • Dependency Injection describes the process in which an external entity is responsible for creating all the instances of the components an app requires, injecting them according to the dependency rules you define.
  • Main is the component responsible for the creation of the dependency graph for an app.
  • You can represent the dependency graph with a dependency diagram.
  • The main type of injections are constructor injection, field injection and method injection.
  • Constructor injection is the preferable injection type, but you need control over the lifecycle of the object’s injection destination.
  • Service Locator is a pattern you can use to access the objects of the dependency graph, given a name.
2. Meet the Busso App
4. Dependency Injection & Scopes
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