Chapters
Chapters

Chapters

Hide chapters

Kotlin Multiplatform by Tutorials

Third Edition · Android 15, iOS 18, Desktop · Kotlin 2.1.20 · Android Studio Meerkat

Before You Begin

Section 0: 5 chapters
Show chapters Hide chapters

Section I: Beginning Kotlin Multiplatform

Section 1: 5 chapters
Show chapters Hide chapters

Section II: Kotlin Multiplatform: Intermediate

Section 2: 5 chapters
Show chapters Hide chapters

Section III: Kotlin Multiplatform: Advanced

Section 3: 5 chapters
Show chapters Hide chapters

Section IV: Appendices

Section 4: 3 chapters
Show chapters Hide chapters

9. Dependency Injection
Written by Saeed Taheri

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

Putting unicellular organisms aside, nearly everything in the world depends on other entities to function. Whether it’s something in nature or something mankind has created, it usually takes multiple things to create a working instance of anything.

Imagine an assembly line in a car factory. They don’t create the engines and the wheels on the assembly line. Car manufacturers outsource many of the parts to other companies. In the end, they bring them all to the assembly line, inject each part into the making-in-progress and a shiny new car appears. The car is dependent on other objects. The same applies to the software world.

If you were to model the Car into a class, one of its dependencies would be the Engine. The car object shouldn’t be responsible for creating the engine. You should inject the engine from outside into the assembly line — or in programming nomenclature, constructor, or initializer.

Advantages of Dependency Injection

Dependency injection, or DI, has many advantages.

  • Maintainability: DI makes your code maintainable. If your classes are loosely coupled, you can catch bugs more easily and address a possible issue faster than you would with a convoluted class that doesn’t adhere to the single-responsibility principle.
  • Reusability: Going back to the car factory example, you’re able to reuse the same model of wheels for many cars the factory manufactures. Loosely coupled code will let you reuse many parts of your code in different ways.
  • Ease of refactoring: There may come a time in the lifetime of your app when you need to apply a change to your codebase. The less coupled your classes are, the easier the process will be. Imagine you needed to change the engine if you wanted to have new headlights!
  • Testability: Everything comes back to the code being loosely coupled. If each object is self-contained, you can test its functionality independently of others. No one would like a car whose engine wouldn’t work when a windshield wiper is broken! This way, each team responsible for each module will test their product and hand it over to other teams.
  • Ease of working in teams: As implicitly mentioned in other points, DI will make the product manufacturable by different teams. This also makes the code more readable and easier to understand, since it’s straightforward and doesn’t have unnecessary extras.

Automated DI vs. Manual DI

Now that you’re on the same page with those who favor using dependency injection in their apps, you need to actually provide the dependencies where needed.

Wav. 1.5 — Se joqeo tohbar yoh geqahaxonv
Wow. 3.1 — Pe naloi codver poz movesajasz

Setting Up Koin

Setting up Koin is similar to how you’ve set up other multiplatform libraries in the previous chapters – a shared part and some specific libraries to use for each platform.

Declaring Your App Dependencies for Koin

Koin uses a special Kotlin Domain Specific Language — or DSL — to let you describe your application and its dependency graph.

Using Koin on Each Platform

Now that you’ve got all the pieces, it’s time to use Koin for real.

Android

Open OrganizeApp.kt in the androidApp module. Add the onCreate function below inside the class and start Koin there.

Gap. 5.3 — Zxi Urwzeey atd ijsiz usxibmeqitq Koig.
Geh. 3.1 — Yma Ulbqaan adl abzaf emkuzcevavf Yiib.

iOS

Koin is a Kotlin library. Lots of bridging occurs, should you want to use it with Swift and Objective-C files and classes. To make things easier, you’d better create some helper classes and functions.

Hun. 0.8 — Svu uAX ict ozned uzleqjadeyh Qait.
Vel. 1.2 — Bnu oOV otx otwen adzunsukent Ruaq.

Desktop

This is the easiest of all platforms. First, open Main.kt in desktopApp module and add a reference to the Koin object. Initialize it in the main function.

Dov. 7.8 — Fme Jalhsug ojm uzyij evxowxoraww Hael.
Wuj. 7.6 — Zca Cebrhib img expik ikreglekizz Boap.

Updating AboutViewModel

You’re now familiar with the process, it’s time to update AboutViewModel to use DI. Put the book down and see if you can do it all by yourself.

Android

Open AboutView.kt in the androidApp module and change the AboutView composable definition to this:

iOS

It’s pretty straightforward. Open AboutView.swift and change the definition of viewModel as follows:

Desktop

This is also a piece of cake. Open AboutView.kt in desktopApp module and change the AboutView composable function definition:

Testing

Because of the changes you made in this chapter, the tests you wrote in the previous chapter wouldn’t compile anymore. Fortunately, it will only take a couple of easy steps to make those tests pass. You’ll also learn a few more tricks for testing your code along the way.

Checking Koin Integration

As you already know, Koin resolves the dependency graph at runtime. It’s worth checking if it can resolve all the dependencies providing the modules you declared.

Mes. 3.4 — Neal ksunlTexabaq logg vuiwen
Jey. 3.9 — Jaab nkefzXogomah nobj dauyum

Updating RemindersViewModelTest

Open RemindersViewModelTest.kt. There’s a lateinit property that holds a reference to an instance of RemindersViewModel. In the setup method, you’re initializing this property like this:

Key Points

  • Classes should respect the single-responsibility principle and shouldn’t create their own dependencies.
  • Dependency Injection is a necessary step to take in order to have a maintainable, scalable and testable codebase.
  • You can inject dependencies into classes manually, or use a library to do all the boilerplate codes for you.
  • Koin is a popular and declarative library for DI, and it supports Kotlin Multiplatform.
  • You declare the dependencies as modules, and Koin resolves them at runtime when needed.
  • When testing your code, you can take advantage of Koin to do the injections.
  • By conforming to KoinTest, your test classes can obtain instances of objects from Koin using some statements, such as by inject().

Where to Go From Here?

In this chapter, you gained a basic understanding of Koin and Dependency Injection in general. In the upcoming chapter, you’ll once again come back to DI to learn a new way of injecting platform-specific dependencies into classes.

8. Testing
10. Data Persistence
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