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

17. Hilt — Dagger Made Easy
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 chapter, you learned how Dagger Android works and Android needs a special library to use Dagger. You learned that Dagger can’t instantiate Android standard components because their lifecycle is the responsibility of the Android system, which works as a container. Dagger Android has not been very successful but it taught Google lessons that they used when making architectural decisions for Hilt.

Dagger Android highlighted the most important topics to address:

  • Make Dagger easier to learn and to use.
  • Standardize the way developers create @Scopes and apply them to @Components.
  • Make implementing tests easier.

You’ll learn everything you need to know about testing with Hilt in this chapter, including:

  • What Hilt’s architectural decisions are.
  • How to install Hilt in your app.
  • What @AndroidEntryPoint is and how to use it.
  • What a Hilt @Module is and how it differs from Dagger’s.
  • How to deal with different @Scopes with Hilt.
  • Which tools Hilt provides to handle common use cases.

Of course, you’ll put all these things to work in the Busso App.

Note: At this time, Hilt is still in alpha release. Things might change in future versions of the library.

Hilt’s architectural decisions

Looking at a high-level summary of what you’ve done in the Busso app is a useful way to understand the main architectural decisions Google made for Hilt. In Busso, you:

  1. Created three different @Scopes: @ApplicationScope for objects that live as long as the Application, @ActivityScope for objects that live as long as a specific Activity and FragmentScope for objects that live as long as a Fragment.
  2. Implemented a different @Component or @Subcomponent for each @Scope. You have an ApplicationComponent interface and Dagger Android generated a @Subcomponent for each Activity and Fragment for you, as you saw in the last chapter.
  3. Defined a dependency relationship between different @Components using either @Subcomponents or @Component’s dependencies attribute. This allows you to make objects with @ApplicationScope visible to Activitys and objects with @ActivityScope visible to the Fragments they contain.
  4. Provided Application to ApplicationComponent and Activity to the Subcomponent for the Activitys. You also added these objects to the corresponding dependency graph.
  5. Defined different @Modules to tell Dagger how to bind a specific class to a given type.

To do this, you had to learn many different concepts and several ways to give Dagger the information it needs. As you’ll learn in detail in this chapter, Hilt makes things much easier by:

  1. Providing a predefined set of @Scopes to standardize the way you bind an object to a specific @Component’s lifecycle.

  2. Doing the same for @Components. Hilt provides a predefined @Component for each @Scope, with an implicit hierarchy between them.

  3. Making some of the most important Context implementations, like Application or Activity, already available to some of the predefined @Components.

  4. Defining a new way to bind a @Module to a specific @Component. Now you install a @Module in one or more @Components.

This will become clearer when you start using Hilt for your Busso App.

Migrating Busso to Hilt

Migrating the Busso App to Hilt is a relatively smooth process — and it gives you an opportunity to experience Hilt’s main concepts. You’ll dive into those concepts more deeply later in the tutorial.

Installing what you need to use Hilt

Your first step is to install the Hilt plugin and dependencies in your app.

Pojoqi 65.4 — Ezefoot Hmojojq Gxhevwube
Yupahu 78.5 — Agumeoh Vyezasq Yzsuryiba

Tayofu 67.5 — waixr.cfadfe om qnu niog az hla Dumwe jrawesj
Sipiqu 73.0 — doerz.rkikva aq vfa voek is dmi Valbu fhuhulx

Cigove 48.0 — loony.ycijzo zod pgi elt tetoma
Cavuyu 37.2 — puiqm.vdahru sef cju eyk ralixi

Enabling Hilt in Application

Building the Busso App now will give you some errors. That’s because you need to follow some new conventions with different annotations when you use Hilt.

Defining the entry point for the dependency graph

In Busso, you need to add your Application implementation in Main.kt in app. Open Main.kt and change the content of the file to this:

Adding Application to the dependency graph

That looks good, but you might wonder if something’s missing. In the previous implementation of Main, you had the following:

Adding a @Module

You already know how to solve the first point: you need a @Module. Open ApplicationModule.kt in di and add the following definition:

Binding @Module’s objects to ApplicationComponent

Now, you need to bind the objects in this @Module to ApplicationComponent. But there’s something very important to note: The ApplicationComponent you want to use now is not the one you defined in ApplicationComponent.kt in di.

Using a predefined @Scope for ApplicationComponent

In the previous section, you learned that Hilt creates ApplicationComponent for you. You just need to tell it which objects to put into its dependency graph. But in the introduction for the chapter, you also read that Hilt provides some predefined @Scopes.

Quyine 70.3 — @AzvfesokiucGqiva amesut
Sebife 53.2 — @UnnrogiqeunCmufa umixuq

Migrating Activitys to Hilt using @AndroidEntryPoint

In the previous section, you fixed most of the dependencies related to ApplicationComponent by using @Singleton. You also learned that Hilt provides a @Component and a @Scope for the Activitys as well.

Nugira 72.5 — @OljotodpHqelu ovodeh
Sayute 31.6 — @AjmusijfZbida oficeg

Migrating Fragments to Hilt

In the previous step, you told Dagger which @ActivityScoped objects you want to inject in Busso’s Activitys. Now, you have to do the same for Fragments. In this case, you’ll need a @Scope and a @Component for Fragments that Hilt provides with:

Yicaba 69.0 — @BnagpusxQlago abusot
Fowile 66.9 — @BmewvotrWnuro aducen

Installing @Modules in @Components

Busso is a multi-module app that defines different @Modules in different Gradle modules. To complete the migration, you need to:

Fixing the Navigator injection

Build the app now and you’ll get an error related to the Navigator implementation. In the previous chapter, you introduced qualifiers and bindings in NavigatorModule.kt in di.navigator. The good news is — you don’t need these anymore. To fix the errors, you need to:

Fabona 49.8 — Wgo Hapfo Avx
Zarosi 20.0 — Lse Wuyso Ecx

Reviewing your achievements

At this point, it’s important to review what you learned while migrating Busso from using Dagger Android to Hilt. Here’s what you discovered:

Hilt’s main APIs

While migrating Busso to Hilt, you learned that the main concepts you need to know are:

Entry point using @AndroidEntryPoint

In this book, you referred to Application, Activitys and Fragments as dependency targets. These are the objects that are destinations of an injection operation, and you annotate them with @AndroidEntryPoint.

Using predefined @Components & @Scopes

In terms of @Components and @Scopes, Hilt provides what’s shown in Figure 17.8:

Golago 58.1 — Qcararomey @Gukbukewrn usd @Rfikif
Jilaqe 81.5 — Yxigukemay @Felqoqajjf ird @Nyanex

Hilt utility APIs

Hilt provides some utility APIs, which help migrate existing apps. The main ones are:

Using @AliasOf

When you migrated Busso to Hilt, you deleted the custom @Scopes you implemented in the previous chapters. You deleted @ApplicationScope, @ActivityScope and @FragmentScope in favor of the predefined @Singleton, @ActivityScoped and @FragmentScoped.

Using @ApplicationContext

Another very useful tool from Hilt is related to Context. You’ve seen that some of the predefined @Components have an Application for default bindings, while others have an Activity. As you know, they’re both implementations of the Android Context and if you want to distinguish one from the other, you use a qualifier. In this specific case, however, Hilt already provides the qualifier you need.

Using @ActivityContext

You can do the same when you need the Context of an Activity. In that case, you also have the opportunity to improve Busso’s resource management.

Updating where you had LocationModule

Now, you need to fix the places where you used LocationModule. Open ApplicationModule.kt in di and add the following definition:

Key points

  • The main goal of Hilt is to make Dagger easier to learn and to use.
  • Hilt provides a predefined set of @Components and @Scopes.
  • Using @InstallIn, you install the binding of a @Module in a specific @Component.
  • Each predefined Hilt @Component provides a set of default bindings.
  • There’s an implicit hierarchy between Hilt’s predefined @Components.
  • @AndroidEntryPoint allows you to tell Dagger which injection target to use.
  • @AliasOf simplifies the migration of existing apps to Hilt.
  • Hilt provides some utility APIs like the @ApplicationContext and @ActivityContext qualifiers.
16. Dagger & Android
18. Hilt & Architecture Components
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