Dependency Injection on Kotlin/Multiplatform — Part 3: iOS and Android

Photo by Karsten Würth

This article is part of a series about using dependency injection on Kotlin/Multiplatform:

• Part 1 : Factorize your code
• Part 2 : Test and build
• Part 3 : iOS and Android usage

In the first two parts, we saw how easy it is to use Kodein-DI to enhance your mobile app architecture in a Kotlin/Multiplatform project, and how to test all your business code once. Now it is time to write our mobile applications, for iOS and Android.

Continuing the previous example from part 2, we would have to implement a login form. So, we need to provide to the user a text field to enter a secret code, and a button to validate the form. On iOS, With UIKit, we would end with the following controller:

Before being able to use our Kotlin/Multiplatform library in Swift, we need to define its dependency on our project. We previously have defined the CocoaPods in our build script, thus we can import our Kotlin Pod by adding a Podfile to our iOS project:

It is now as simple as adding an import in our Swift code to use our Kotlin/Multiplatform library, and plug our MVP upon our view:

Here we:

• import NBVCommon package
• make the controller implement LoginView
• inject the LoginPresenter with InjectorCommon defined in part 1

By using the lifecycle behaviors of the controller we can attach/detach the view from the presenter.

To act on presenter interaction, when login is success or failure, we have to implement the functions from LoginView, as if it was a regular Swift protocol.

As Kotlin has been available for Android for a long time now, it is really smooth to use a Kotlin/Multiplatform library here. So we can go a little further with Kodein-DI, as it has some specific modules to empower Android development. Assuming that we have published the Kotlin/Multiplatform library on Maven, all we need is to declare the dependency inside the Gradle configuration of our Android project:

You can see, that we also have a Kodein-DI module that will provide specific extensions for Android.

In Android it is not mandatory to define an Application, but using the Kodein-DI module for AndroidX can enhance your development experience.

Now, let's get back to our login feature. For that, we write an Activity that implements DIAware , and by definition must override the di property. The delegate function di() comes from the AndroidX module of Kodein-DI. It looks for the nearest DI container, if there is one, in the application context, from Activity / Fragment hierarchy, until it find one.

This allows us to inject the right presenter directly inside the Activity, with no pain

Sounds familiar? We just did the same as for iOS, but for Android! You can see that the native code for both platform stays really simple, and easy to maintain.

Of course, this is a quite simple example, but even in real world applications, the native code remains as stupid as possible. Indeed, all the business complexity has been develop from the beginning inside our Kotlin/Multiplatform library.

Going Further

In this series we have seen how to set up a MVP architecture with Kodein-DI in a multiplatform project, using the historical APIs of both mobile platforms.

Next, it should be interesting to move forward by using more modern tools, like the MVI pattern, made easier with SwiftUI and Jetpack Compose. We might talk about it in a future article.

Final though

Kodein-DI is already a powerful library to use in Kotlin/Mutiplatform projects. However, there is still a lot to do to bring Kodein-DI as an ultimate tool for Kotlin/Mutiplatform, and we have plenty of ideas to do so.

The more urgent subject are:

• Support for Swift, to be able to bind Swift objects smoothly
• Support for coroutines, to inject asynchronous instances

We also plan to provide more libraries for Kotlin/Multiplatform in a near future, stay tuned ;)

This article is brought to you by Kodein Koders, a European service & training provider focused on Kotlin & Kotlin/Multiplatform.