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

10. Understanding Components
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 learned how to deal with @Modules in Dagger. You learned how a @Module helps you structure the code of your app and how you can use them to control the way Dagger creates instances of the objects in the dependency graph.

You also had the opportunity to meet the most important concept in Dagger: the @Component. You learned that a @Component defines the factory methods for the objects in your app’s dependency graph. When you get a reference to an object using a @Component’s factory method, you’re confident that Dagger has resolved all its dependencies. You saw this in both the simple Server-Repository example and in the more complex RaySequence app.

In this chapter, you’ll go back to working on the Busso App. You’ll learn how to:

  • Migrate the existing ServiceLocators and Injectors to Dagger’s equivalent @Modules and @Components.
  • Provide existing objects with a customized Builder for the @Component using @Component.Builder.
  • Use @Component.Factory as a valid alternative to @Component.Builder.

These are fundamental concepts you must understand to master Dagger. They’re also a prerequisite for the next chapter, where you’ll learn all about scopes. So get ready to dive in!

Migrating Busso to Dagger

As mentioned earlier, @Components are one of the most important concepts in Dagger. As you saw in the previous examples, a @Component:

  • Is the factory for all the objects in the dependency graph.
  • Allows you to implement the object you referred to as an Injector in the first section of the book.

Don’t worry if you don’t remember everything. With Busso’s help, you’ll review all the concepts over the course of this chapter. In particular, you’ll see how to:

  • Remove the Injector implementations, delegating the actual injection of the dependent objects to the code Dagger generates for you from a @Component.
  • Replace the ServiceLocator implementations with @Modules.

To start, use Android Studio to open the Busso App from the starter folder in the downloaded materials for this chapter. As you see in the code, the app uses the model view presenter and has ServiceLocator and Injector implementations for all the Activity and Fragment definitions.

In Figure 10.1, you can see the project structure of the di package, which you’ll switch over to Dagger first.

Figure 10.1 — Starting project structure of the Busso app
Figure 10.1 — Starting project structure of the Busso app

It’s always nice to delete code in a project and make it simpler. So let the fun begin!

Installing Dagger

The first thing you need to do is to install the dependencies Dagger needs for the project. Open build.gradle from the app module and apply the following changes:

Beyaso 10.2 — Qsjc Tyidju nuho umer
Qacalu 48.0 — Tnnt Jmuhje paye iwip

Studying the dependency graph

In the previous examples, you learned that a:

Tamefa 54.7 — BqnovdOhbasipn xumugfowwd ccecz
Xodoli 37.2 — LgyedqEdhucikp dezohromfk ggizz

Removing the injectors

Start by opening SplashActivityInjector.kt from di.injectors and looking at the current implementation:

Creating the @Module

Create a new file named AppModule.kt in the di package and add the following code:

Creating SplashPresenter and SplashViewBinde

Now, Dagger knows which classes to use when you need an object of type SplashPresenter or SplashViewBinder. It doesn’t know how to create them, though. To start solving that problem, open SplashPresenterImpl.kt from ui.splash and look at its header:

Handling SplashViewBinderImpl

Open SplashViewBinderImpl.kt from ui.splash and look at the class’ header:

Creating & using the @Component

Now that you’ve created AppModule, Dagger knows everything it needs to bind the objects for the SplashActivity implementation. Now, you need a way to access all those objects — which means it’s time to implement the @Component.

Kukeyo 31.9 — Cge Ruyno Uwp
Tekule 95.4 — Gya Qigho Ulc

Completing the migration

If you’re reading this, you decided to complete Busso’s migration to Dagger. Great choice! Now that SplashActivity is done, it’s time to continue the migration for the other components. You’ll notice this is really simple.

Migrating MainActivity

Open MainActivityInjector.kt from di.injectors and look at the following code:

Revibe 04.3 — CaozAdhuwijs funoqsuvnc qtizz
Qojite 49.1 — RiidOtrefehr hakifsevrg gnujx

Migrating Busso’s fragments

Migrating BusStopFragment and BusArrivalFragment to Dagger is easy now. There’s just one small thing to consider: They both extend Fragment but they need access to the AppComponent implementation you created in MainActivity. That’s because they use classes that depend on:

Exposing AppComponent to the fragments

Here, you need to make the AppComponent available to the app’s Fragments. You’ll learn how Dagger solves this problem in the following chapters. At the moment, the easiest way is to add a simple utility method.

Adding the NetworkModule

You’re now going to create a @Module to tell Dagger how to get an implementation of BussoEndpoint to add to the dependency graph. Create a new file named NetworkModule.kt in the network package for the app and add this content:

Creating the NetworkModule instance

Next, open MainActivity and add the following:

Handling deprecated @Modules

Before proceeding, it’s worth mentioning that the editor might display something like you see in Figure 10.6:

Gexiwe 59.8 — I rettalusex @Xijado
Nuleto 08.2 — I zivvigokor @Xuboko

Migrating BusStopFragment

Your next step is to quickly migrate the BusStopFragment following the same process you used above. Open AppModule.kt and add the following bindings:

Using AppComponent in BusStopFragment

Your last step is to use AppComponent in BusStopFragment. First, open AppComponent.kt and add the following definitions:

Migrating BusArrivalFragment

You’re very close to completing the migration of Busso to Dagger. Open AppModule.kt and add the following bindings:

Cleaning up the code

The errors you see after building the app are due to the existing ServiceLocator and Injector implementations. To fix them, you just have to delete the:

Digomu 78.7 — Cazi nqruzlowo aqxig Fujmaj wohyeraan
Zonube 49.2 — Wixe zqnijluho osyeg Nocvuv qeqfiyaoy

Customizing @Component creation

As you saw in the previous code, providing the reference to existing objects like Context or Activity isn’t uncommon. In your case, you just provided an activity as a parameter for the primary constructor of the @Module, as in AppModule.kt:

Using @Component.Builder

Open AppComponent.kt and add the following code:

Using @Component.Factory

Using @Component.Builder, you learned how to customize the Builder implementation for the @Component Dagger creates for you. Usually, you get the reference to the Builder implementation, then you invoke some setter methods that pass the parameter you need and finally, you invoke build() to create the final object.

Key points

  • The most important concept to understand in Dagger is the @Component, which works as the factory for the objects in the dependency graph.
  • You migrated Injectors to Dagger @Components and ServiceLocators to Dagger @Modules.
  • A dependency diagram helps you migrate an existing app to Dagger.
  • @Component.Builder lets you customize the Builder implementation that Dagger creates for your @Component.
  • With @Component.Factory, you ask Dagger to create a factory method to create your @Component implementation.
9. More About Modules
11. Components & 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