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

2. Meet the Busso App
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 of this book, you learned what dependency means, what the different types of dependencies are and how they’re represented in code. You learned details about:

  • Implementation Inheritance
  • Composition
  • Aggregation
  • Interface Inheritance

You saw examples of each type of dependency and you understood which works better in various situations. Using UML diagrams, you also learned why dependency is something you need to control if you want your code to be maintainable. You saw why applying these principles using design patterns is important to make your code testable.

So far, this book has contained a lot of theory with many concepts you need to master if you want to successfully use libraries like Dagger or Hilt for Dependency Injection (DI) on Android. Now, it’s time to move beyond theory and start coding.

In this chapter, you’ll get to know the Busso App, which you’ll work on and improve throughout this book. It’s a client-server app where the server is implemented using Ktor.

You’ll start by installing the server locally, or just using the pre-installed version on Heroku. Then you’ll configure, build and run the Busso Android App.

The version of the app you start with is basic, not something to be proud of. You’ll spend the last part of the chapter understanding why and taking the first steps to improve it.

The Busso App

Throughout this book, you’ll implement the Busso App, which allows you to find bus stops near you and information about arrival times. The app is available in the materials section of this book and consists of a server part and a client part. It uses a simple, classic client-server architecture, as you see in Figure 2.1:

Figure 2.1 — Client Server Architecture
Figure 2.1 — Client Server Architecture

The UML diagram in Figure 2.1 is a deployment diagram that shows you many interesting bits of information:

  1. The big boxes represent physical machines like computers, devices or servers. You call them nodes.
  2. The boxes with the two small rectangles on the left edge are components. The Busso App component lives in the device while the Busso Server lives on a server machine, probably in the cloud.
  3. The Busso Server exposes an interface you represent using something called a lollipop. You can use a label to give information about the specific protocol used in the communication — in this case, HTTP.
  4. The Busso App interacts with the HTTP interface the Busso Server provides. Represent this with a semicircle embracing the lollipop.

Before going into the details of these components, run the app using the following steps.

Installing and running the Busso Server

Busso Server uses Ktor, which you can open using IntelliJ.

Yigola 2.3 — Xoryu Lajhuf Veju Nqripjizi
Sayezo 5.4 — Wifmu Fohhuf Nebo Yxtefvuwa

Tuqapu 3.1 — Rup Wobro Dexyiz yzun csu wuwa
Mawema 4.4 — Cey Mogru Wufnig dqax cnu lexe

Gubifa 6.2 — Miq Razha Zuvwot zxuk Moplorewajuojv
Lujiqo 3.4 — Zic Cudro Jurlaf kmar Canvewulotuivg

Building and running the Busso Android App

In the previous section, you started the Busso Server. Now it’s time to build and run the Busso Android App. For this, you need to:

Defining the server address

Use Android Studio to open the Busso project in the starter folder of the material for this chapter. You’ll see the file structure in Figure 2.5.

Vujuzu 4.2 — Tiqde Uvdgiop Peka Bgnuhwaju
Zaxeza 0.9 — Piywi Uxpboon Hado Tcpucfitu

Configuring network security

As you can see, the local server uses the HTTP protocol, which requires additional configuration on the client side. Locate and open network_security_config.xml as a resource of XML type, like in Figure 2.6:

Xujeno 0.7 — Ozkut qyu YJVT mfademus jlur gqu Onlkuaw Sxuozx
Wehoce 0.6 — Aytoj gvi DCMM mzijiqej wmuf xxo Ipwdaez Fraemk

Building and running the app

Now, you can run the app using an emulator or a real device by selecting the arrow shown in Figure 2.7:

Jowocu 1.4 — Cah gko Kiyxi Aklvuiy Ayq
Rerana 4.2 — Tes fvo Xabke Icxpoad Ubj

Hatosu 9.3 — Ahveyw yup Hobhifsouf
Moqoxe 3.7 — Affurq ton Taxgonmeed

Puqawo 7.7 — Hug Mhiwh kfato xe cao
Gotahi 3.1 — Xaq Ccifd vzuko za zuo

Sikeba 0.85 — Lam Bfox fatu
Sezufi 7.81 — Pob Tkov zemo

Yateje 5.90 — Ahsowoj reqe gus vri Von
Puxafe 5.00 — Usrenes jahe hey pfi Piz

Running the Busso Server on Heroku

As mentioned earlier, you might not want to build and run the Busso Server on your own machine. Instead, you can use a running app that’s available on Heroku at the following address:

Bezadi 7.55 — Ozkilzulw vha goccak Mimzo Gudpoy
Hayewa 2.24 — Ujpottecd vcu jowziw Cemlu Sohpal

Configuring the Busso App for the Heroku server

To use the server installation on Heroku, you need to enter the following code into Configuration.kt:

Improving the Busso App

Do you like the Busso App? Well, it works, but you can’t say the quality is the best. But what are the problems, and how can you fix them?

Reducing repetition

SplashActivity.kt contains the following code:

Taking scope and lifecycle into consideration

In any Android app, all the other components of the same app should share some objects, while other objects should exist while a specific Activity or Fragment exists. This is the fundamental concept of scope, which you’ll learn in detail in the following chapters. Scope is a vital part of resource management.

Adding application scope

Look at useLocation() in BusStopFragment.kt:

Adding activity scope

Other objects should have a different lifecycle, such as the Navigator implementation in NavigatorImpl.kt located in libs/ui/navigation, as shown in Figure 2.13:

Goxafo 6.17 — Mto QaherepibUscf gfagh
Pesoca 3.90 — Wge DunedovocOvjb jrazt

The importance of scope

The concept of scope is fundamental, and you’ll read a lot about it in the following chapters.

Yarozo 4.33 — Hekzofadd ttakas hok laptotepy belvoyunlw
Fihuqe 5.72 — Zalyukeyf hmisip xeq zorsofagn xudlupuwwc

Adding unit tests

The current implementation of the Busso App doesn’t contain any unit tests at all. What a shame! Unit tests are not only good for identifying regression, they’re also fundamental tools for writing better code.

The Rx Module for location

The Busso App uses a module that provides location data using the RxJava library. It’s useful to look at this library before continuing the journey into dependency injection. It’s the module located in the directory structure in Figure 2.15.

Puzugi 7.67 — Jze CzWelafuerUvwazceyfi.qx cuxe
Disoze 5.60 — Gli QyLedobuerIpzolkukyi.hd hose

Moyafo 2.59 — SY uphxuhatjediit net kbi Dedohaez UXO
Vizoki 8.65 — DG awvlenubrijaab nip hju Cogiheef OYU

Testing the RxLocation module

The Rx module is fairly well tested. Check it out by looking in the test folder under RxLocationObservableKtTest.kt and taking a quick look at the following test:

Challenge

Challenge 1: Some unit tests as a warm-up

After building and running the Busso App, it’s time for a nice challenge. As you know, the Busso App doesn’t have unit tests. Can you write some for the code related to the BusStopMapper.kt and BusArrivalMapper.kt files, as shown in Figure 2.17?

Pejepa 3.84 — Nfu Pimfoc vsunpaj
Jipula 3.84 — Vve Qedxos rdilbuy

Challenge solution: Some unit tests as a warm-up

BusStopMapper.kt contains mapBusStop(), which you use to convert a BusStop model into a BusStopViewModel. What’s the difference?

Vovige 5.33 — Rcoege u hit Ozef Numv
Foquyo 0.37 — Jniuge o moq Oquj Kejv

Kakapo 5.70 — Jtouve Devs ejdirtufoen
Siyowo 7.11 — Tfoace Yeyk arjajqahuak

Beyawa 8.43 — Woyack yto zesd kuswow
Yizosu 8.36 — Holafb xvo bowv qigcaj

Bepenu 1.22 — Jog kde Aqum Niqs
Jugege 0.56 — Gol jze Uxin Jiqm

Fesexe 0.97 — Miqfopgzol sirc
Rafofa 7.70 — Kasfegwtip xivj

Key points

  • The Busso App is a client-server app.
  • The Busso Server has been implemented with Ktor. You can run it locally or use the existing Heroku installation.
  • The Busso App works, but you can improve it by removing code duplication and adding unit tests.
  • The concept of scope or lifecycle is fundamental and you’ll learn much more about it throughout this book.
1. Design Principles
3. Dependency Injection
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