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

4. Dependency Injection & Scopes
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 what dependency injection is and how to use it to improve the architecture of the Busso App. In a world without frameworks like Dagger or Hilt, you ended up implementing the Service Locator pattern. This pattern lets you create the objects your app needs in a single place in the code, then get references to those objects later, with a lookup operation that uses a simple name to identify them.

You then learned what dependency lookup is. It differs from dependency injection because, when you use it, you need to assign the reference you get from ServiceLocator to a specific property of the dependent object.

Finally, you used ServiceLocator in SplashActivity, refactoring the way it uses the LocationManager, the GeoLocationPermissionCheckerImpl and the Observable<LocationEvent> objects.

It almost seems like you could use your work from the previous chapter to refactor the entire app, but there’s a problem — not all the objects in the app are the same. As you learned in Chapter 2, “Meet the Busso App”, they have different lifecycles. Some objects live as long as the app, while others end when certain activities do.

This is the fundamental concept of scope, which says that different objects can have different lifecycles. You’ll see this many times throughout this book.

In this chapter, you’ll see that Scope and dependency are related to each other. You’ll start by refactoring how SplashActivity uses Navigator. By the end, you’ll define multiple ServiceLocator implementations, helping you understand how they depend on each other.

You’ll finish the chapter with an introduction to Injector as the object responsible for assigning the looked-up objects to the destination properties of the dependent object.

Now that you know where you’re heading, it’s time to get started!

Adding ServiceLocator to the Navigator implementation

Following the same process you learned in the previous chapter, you’ll now improve the way SplashActivity manages the Navigator implementation. In this case, there’s an important difference that you can see in the dependency diagram of the Navigator shown in Figure 4.1:

Figure 4.1 — The dependency between Navigator and SplashActivity
Figure 4.1 — The dependency between Navigator and SplashActivity

In the dependency diagram, you see that NavigatorImpl depends on Activity, which IS-A Context but also an abstraction of AppCompatActivity. This is shown in the class diagram in Figure 4.2:

Figure 4.2 — Class Diagram for the Main and SplashActivity classes
Figure 4.2 — Class Diagram for the Main and SplashActivity classes

In this class diagram, note that:

  1. Activity extends the Context abstract class. When you extend an abstract class, you can also say that you create a realization of it. Activity is, therefore, a realization of Context.
  2. AppCompactActivity extends Activity.
  3. SplashActivity IS-A AppCompactActivity and so IS-A Activity. Thus, it also IS-A Context.
  4. Application IS-A Context.
  5. Main IS-A Application and so IS-A Context.
  6. Busso depends on the Android framework.

Note: Some of the classes are in a folder labeled Android and others are in a folder labeled Busso. The folder is a way to represent packages in UML or, in general, to group items. An item can be an object, a class, a component or any other thing you need to represent. In this diagram, you use the folder to say that some classes are in the Android framework and others are classes of the Busso App. More importantly, you’re using the dependency relationship between packages, as in the previous diagram.

The class diagram also explicitly says that Main IS-NOT-A Activity.

You can see the same in NavigatorImpl.kt inside the libs/ui/navigation module:

class NavigatorImpl(private val activity: Activity) : Navigator {
  override fun navigateTo(destination: Destination, params: Bundle?) {
    // ...
  }
}

From Main, you don’t have access to the Activity. The Main class IS-A Application that IS-A Context, but it’s not an Activity. The lifecycle of an Application is different from the Activity’s.

In this case, you say that the scope of components like LocationManager is different from the scope of components like Navigator.

But how can you manage the injection of objects with different scopes?

Note: Carefully read the current implementation for NavigatorImpl and you’ll notice it also uses AppCompatActivity. That means it depends on AppCompatActivity, as well. This is because you need to use the support FragmentManager implementation. This implementation detail doesn’t affect what you’ve learned about the scope.

Using ServiceLocator with different scopes

The ServiceLocator pattern is still useful, though. In ServiceLocator.kt in the di package, add the following definition, just after the ServiceLocator interface:

Accessing ActivityServiceLocator

As noted in the last paragraph, you can get the reference to ActivityServiceLocator using the same Service Locator pattern.

Using ActivityServiceLocator

For your last step, you need to use ActivityServiceLocator. Open SplashActivity.kt and apply the following changes:

Vomiyo 3.0 — Yta Ledqe Ivr
Zuteli 6.3 — Gga Kepwo Axt

Using multiple ServiceLocators

At this point, you’re using two different ServiceLocator implementations in the SplashActivity: one for the objects with application scope and one for the objects with activity scope. You can represent the relationship between ServiceLocatorImpl and ActivityServiceLocator with the class diagram in Figure 4.4:

Nicore 6.6 — XavpuziLugotig’z opine ir WpcuxwOcgekodc
Gavuze 6.7 — HebpoyeSewateh’q enowe it JqquzvEpdotojc

Huxuho 8.4 — SehgowuBabaqet’z ezoya ef YywinpInjokazm
Lajawu 2.6 — LaqluxeQotudit’b atuze ik SsfuvkAxzayovd

ServiceLocator dependency

You can create a diagram to see the different objects within their scope, just as you did in Figure 2.14 of Chapter 2, “Meet the Busso App”. In this case, the result is the following:

Nizipe 1.7 — Jitxo Ehq’h NokciyeLequjil Lmituq
Judare 1.1 — Gozcu Otm’b BoqhaneDegekel Lqozaw

Creating a ServiceLocator for objects with different scopes

In the last paragraph, you learned how to access objects with different scopes using different ServiceLocator implementations. But what if you want to use the same ServiceLocator to access all your app’s objects, whatever their scope is?

Using a single serviceLocator

You’re now ready to simplify the code in SplashActivity. Open SplashActivity.kt and change the implementation of onCreate() to this:

Witagi 5.2 — Wwa Sapyu Opw
Tabufo 6.9 — Wze Yisfo Apd

Going back to injection

Dependency lookup is not exactly the same as dependency injection. In the first case, it’s your responsibility to get the reference to an object and assign it to the proper local variable or property. This is what you’ve done in the previous paragraphs. But you want to give the dependencies to the target object without the object doing anything.

The injector interface

Create a new file named Injector.kt in the di package and enter the following code:

An injector for SplashActivity

From the type parameter, you know that the target of the injection for the SplashActivityInjector is SplashActivity. You can then replace the code in SplashActivityInjector.kt with this:

Foluko 5.9 — Vne Pasla Elk
Wizexo 8.7 — Swa Cotdo Esc

Key points

  • Not all the objects you look up using ServiceLocator have the same lifecycle.
  • The lifecycle of an object defines its scope.
  • In an Android app, some objects live as long as the app, while others live as long as an activity. There’s a lifecycle for each Android standard component. You can also define your own.
  • Scope and dependency are related topics.
  • You can manage the dependency between ServiceLocator implementations for different scopes.
  • ServiceLocator lets you implement dependency lookup, while the Injector lets you implement dependency injection.
3. Dependency Injection
5. Dependency Injection & Testability
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