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

A. Appendix A: The Busso Server
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 this book, you learned everything you need to use Dagger and Hilt. You did this by working on several different apps, with Busso being the most complex of them. As mentioned in the first chapter, Busso needs a server: the BussoServer. This is a web application implemented using Ktor, which is the framework for implementing web services with Kotlin. In this last chapter, you’ll look at how:

  • The BussoServer works.
  • To implement dependency injection on the server using Koin.

Koin is a dependency injection framework implemented in Kotlin. A complete description of the Koin framework would require another book. In this case, you’ll just introduce dependency injection with Koin into the simple BussoServer app, to give you a look at a different approach.

The BussoServer app

As mentioned in the introduction, BussoServer is a Ktor app with the architecture in Figure 20.1:

Figure 20.1 — BussoServer’s High Level Architecture
Figure 20.1 — BussoServer’s High Level Architecture

To understand how this works, use IntelliJ and open the BussoServer project from the starter folder in the materials for this chapter. You’ll see the structure in Figure 20.2:

Figure 20.2 — BussoServer’s Project Structure
Figure 20.2 — BussoServer’s Project Structure

Now, open Application.kt in the main package and look at its content:

// 1
fun main(args: Array<String>): Unit = io.ktor.server.netty.EngineMain.main(args)

@KtorExperimentalLocationsAPI
@Suppress("unused") // Referenced in application.conf
fun Application.module() { // 2
  // 3
  install(Locations)
  // 4
  install(ContentNegotiation) {
    gson {
      setDateFormat("yyyy-MM-dd'T'HH:mm:ssZ")
    }
  }
  // 5
  routing {
    get("/") { // 6
      call.respondText("I'm working!!", contentType = ContentType.Text.Plain)
    }
    // Features // 7
    findBusStop()
    findBusArrivals()
    myLocation()
    weather()
  }
}

This simple code is quite standard for Ktor. Here:

  1. You define main() for the app by instantiating the engine that implements all the routing logic for the server. Here, you’re using Netty.
  2. The server engine needs some configuration that you put into a module. You usually provide this information using a module() extension function.
  3. Ktor allows you to install and use different plugins for different purposes. In this case, you install the Locations feature. Despite its name, that feature has nothing to do with locations on a map. Rather, it gives you a type-safe way to define routing. You’ll see this in action later. Locations is experimental and requires the @KtorExperimentalLocationsAPI annotation.
  4. You use the ContentNegotiation feature, which allows you to manage JSON as the transport protocol. In this case, you use Gson as the parser.
  5. The routing is the logic that maps a specific URI pattern to some logic. You define routings in a routing block.
  6. Just for testing, if the server is up and running, you usually define a very simple endpoint for the root path /. In this case, you just return a simple text. Note how you send back content using respondText() on a call you get by invoking get() for a given path.
  7. The remaining function allows you to install other endpoints for different paths. You’ll see how to do this soon.

To launch the server locally, you just need to click on the run icon, as shown in Figure 20.3:

Figure 20.3 — Run BussoServer locally
Figure 20.3 — Run BussoServer locally

You’ll get an output ending with a log message similar to this:

2021-01-08 00:43:20.647 [main] INFO  Application - No ktor.deployment.watch patterns specified, automatic reload is not active
2021-01-08 00:43:21.393 [main] INFO  Application - Responding at http://0.0.0.0:8080

Now, open the browser and access http://127.0.0.1:8080. You’ll get the testing message that tells you that everything works, as in Figure 20.4:

Figure 20.4 — BussoServer is working
Figure 20.4 — BussoServer is working

The routing is responsible for mapping a request path to some logic the server needs to execute to return a valid response. The /findBusStop endpoint is a good example of how this works.

How /findBusStop works

The /findBusStop endpoint is one of four endpoints BussoServer provides. It’s the one responsible for returning the bus stop nearest to a given location. To see how it works, open FindBusStop.kt in the api package and look at the following code:

Using Koin in BussoServer

Koin is a dependency injection framework completely implemented in Kotlin that doesn’t have any type of code generation. It defines a domain-specific language (DSL) for managing dependency injection in different kinds of applications: Kotlin, Android, Ktor and others.

Installing Koin dependencies

Open build.gradle in Figure 20.5:

Dejuve 02.5 — Rgipza zazo jar VappuRalvac
Kefoqu 39.9 — Vraqte moqo kot LecxeSudden

The repository implementations

BussoServer is a very simple app that uses the repository pattern. Look at the repository and repository.impl packages to see the definition in Figure 20.6:

Lehayi 88.1 — Jikifipitoem pekoqfappy hoonyiz
Nedora 16.6 — Rucifonokueg riqaybollm nioynen

Creating a Koin module

Think back to the definition of a Dagger @Module: a fundamental concept you use to tell Dagger how to create objects for a given type. Koin modules are similar.

Koin initialization in Ktor

Now, you need to tell Koin to use the bindings you just defined in repositoryModule. Open Application.kt and add the following definition:

Injecting the repository implementation

Earlier, you installed the module with the bindings for BusStopRepository and BusArrivalRepository. But how do you inject them? That’s simple. Open FindBusStop.kt in the apis package and apply the following change:

Kuqile 64.0 — Fagevr DogdoSoplox ew tavnotb
Roruqe 35.8 — Caxifb YusliZopfim in nogqelw

Adding other dependencies: Logger

In the previous section, you saw how to inject the implementation for two simple interfaces, BusStopRepository and BusArrivalRepository, which don’t have dependencies.

Adding the Logger abstraction

You just want to see how dependency injection works with Koin, so all you need is a simple abstraction for the Logger. Start by creating a new package named logging in the src folder for main and create a new file named Logger.kt in it with the following code:

Creating a module for the Logger

To create a module for the Logger, create a new file named LoggerModule.kt in di with the following code:

Installing the module for the Logger in Ktor

Defining loggerModule doesn’t install it in Ktor, but you already know how the installation works. Open Application.kt and add the following:

Creating dependencies

Suppose you now want to use the Logger in ResourceBusStopRepository and RandomBusArrivalRepository. To do this, you need to define the dependency by using — of course — constructor injection.

Providing dependencies in modules

To resolve the dependencies, open RepositoryModule.kt in di and apply the following changes:

Key points

  • BussoServer is Busso’s server app. It’s a Ktor app.
  • You can use dependency injection on a Ktor server using Koin, a fully Kotlin solution without code generation.
  • Like Dagger, Koin allows to install the definition of modules you need as a Ktor feature.
  • Using inject() as a property delegate, you can inject dependencies into a dependency target.
  • Using get(), you can manage transitive dependencies between different objects.
  • This chapter only scratches the surface of Koin as an example of an alternative framework for dependency injection in Kotlin.
C. Conclusion
B. Appendix B: Assisted 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