This article is intended to demonstrate how to use JetBrains Fleet for the development of Swift/UI applications, including SwiftUI previews.

For those who may not know about JetBrains, it is an amazing company that builds tools for developers, such as IntelliJ IDEA or Kotlin. To me, JetBrains has always provided tools that exceeded my developer expectations, even when those tools are considered “not stable.”

A year ago, JetBrains announced Fleet, a brand new distributed and polyglot IDE. While many people saw it as just another VSCode IDE, I knew it would become more than that. Bringing collaborative work for remote developers and providing multiple language support out-of-the-box is a real game-changer. And if you’ve already tried a JetBrains IDE, you know that they are serious about developer productivity!

In the meantime, a year ago, they discontinued AppCode, an underrated IDE for working within the Apple ecosystem. AppCode was particularly helpful for developers who found it challenging to adjust to alternative IDE workflows, such as XCode.

With Fleet, you will experience easy code navigation, refactoring, collaboration, and support for a wide range of languages and project types, including SwiftUI applications.

Let’s be honest, you won’t completely escape from Xcode — there are still essential tasks like project configuration, signing, and package dependency management that require its user interface. However, for the majority of your coding sessions, you’ll find that you won’t need it anymore.

Edit and run your iOS app from Fleet

Let’s start by installing Fleet using the JetBrains Toolbox. This is the easiest way to manage and upgrade your JetBrains IDEs in one place.

Once Fleet installed, you can either use your own SwiftUI project or clone the following GitHub project created for this article’s purpose.

https://github.com/KodeinKoders/playground-fleet-swiftui

Now, you can try to run the application by hitting the run button in the top right corner, or just use the ^R shortcut.

At this point, it might work if you have recently opened XCode and/or built and run an iOS project. Otherwise, you will likely encounter an error, such as the following:

This is certainly because your project’s environment is not ready to use any XCode toolchain. This can happen if you have never opened XCode or if you have just booted your Mac. The simplest solution is to open your project in XCode and build it once using CMD+B. Then you can close it and come back to Fleet.

Afterwards, you will be able to edit and run your iOS app from Fleet, even if you reboot your Mac!

Add custom run configuration that works with Fleet

Fleet allows you to define your own configuration to build and run your code. With Fleet, you can create multiple run configurations to target different schemes/devices without leaving the Fleet interface or going through XCode.

We can can create a run.json file inside a .fleet/ directory at the root of our project, such as the following example:

In this case, we define that our application needs to use the Xcode toolchain, that it should run on a iPhone 15 simulator with iOS 17, using the debug configuration.

A nice thing here is, if your project’s environment is correctly detected via the XCode toolchain, the available destination devices will be auto-completable.

To find our different run configurations, simply click the run button or use the ^R shortcut.

Bonus: SwiftUI Preview with Fleet and InjectionIII

One of the major benefits of developing with declarative UI frameworks like Jetpack Compose or SwiftUI is the ability to use tooling to preview your UI without having to build your application every time.

For this purpose you can use InjectionIII. Combined with Fleet, this project can be used as a file watcher, to hot reload SwiftUI changes, directly in your iOS Simulator.

Install it, directly from the Mac App Store

Once installed, launch InjectionIII. You will find a small blue syringe icon in your menu bar. Click on it, then select “Open Project” to target the project you want to watch. This will allow it to inject changes into an iOS Simulator.

Before running your application in the simulator and hot reload UI modification, you need to add debug specific code to your project. At the initialisation phase of the project, add the following if block.

This code will include the InjectionIII binary in your iOS/MacOS app, but only for the debug configuration.

Likewise, in your SwiftUI preview code, you will need to make a slight change in order to define what you will be injecting into the Simulator.

Now you can run your application onto an iOS Simulator. And when you will change some SwiftUI files, they will be injected directly inside this simulator instance, like in the following demonstration:

JetBrains Fleet holds great promise for the future of IDEs. It is polyglot, collaborative, and expected to be much lighter than IntelliJ IDEA.

However, like any alpha product, there are some drawbacks. For instance, at the time of writing this article, you won’t be able to define breakpoints to debug your iOS application, and the fact that we depend on the Apple toolchain may break your workflow at some point.

However, the benefits are already evident. Even in its public preview, Fleet has excelled in every type of project I’ve worked on — whether it was Kotlin code, Android, backend, Kotlin Multiplatform projects, or platform-specific code such as pure Swift and SwiftUI projects. It has never failed me. This becomes even better when working with Kotlin Multiplatform code; being polyglot by essence, it allows us to seamlessly navigate between different technologies, from Kotlin to Swift in a glimpse. This is a real breeze.

This article is brought to you by Kodein Koders, a European service & training provider focused on Kotlin & Kotlin/Multiplatform. Do not hesitate to visit our reach out through our website.

iOS development with JetBrains Fleet was originally published in Kodein Koders on Medium, where people are continuing the conversation by highlighting and responding to this story.

In a previous tutorial, I showed you how to configure your Kotlin/Multiplatform libraries to be published on Maven Central. To go beyond a publication process we now need to automate things with a good CI/CD workflow. Let’s see how to do this with Github Actions.

As the Kodein Open Source Initiative libraries are hosted on Github, we felt that it was the best choice to use the Github Actions pipelines to test, build and deploy our libraries, as it is entirely integrated with every other part of Github.

Let’s start with the snapshot publication process, as it is fairly straightforward. Publishing snapshots on Maven Central has no more constraints than just being authenticated with your Sonatype account, and having your artifacts file names ending with the uppercased word SNAPSHOT. This means that you could literally upload anything in your staging repositories.

Here is a Github Actions script to upload a snapshot of a Kotlin/Multiplatform project:

In that example, we run the task publishAllPublicationToOss on Linux, Mac & Windows, literally saying to publish every available targets onto the oss repository, which is the name we gave to it in our maven-publish configuration in our Gradle build script. This is not optimal, as every platform could upload shared targets like JVM, JS or even the Kotlin Multiplatform Metadata, but it’s simple, and it works!

Let’s now see how to deploy stable releases.

We have to discuss how we will be managing the unique staging repository we need. In fact, this is quite simple, and it is resume by this image:

What we need is to create a staging repository, by using the sonatype API over HTTP. This step will generate a repository ID, that we use in later steps. In the build-upload matrix, we upload every artifact onto the same staging repository. Finally, In the drop-or-release job, depending on the success or failure of the build-upload matrix, we drop or release the staging repository.

Whatever happens in the build-matrix, we will always create a staging repository, and at the end drop or release that same repository, like in this failure scenario:

So, how do we manage consuming the sonatype HTTP API?

You could write Gradle tasks to create, drop or release the staging repositories. You could also use your favorite language / framework to automate everything. But, let me share our experience and choices.

We did consider using Gradle tasks, but Gradle would need to perform the full configuration of your project before being able to make only one or so HTTP requests. Sounds like we could do something more efficient. Our second thought was to use bash scripts, using curl to send HTTP requests, and JQ to parse JSON responses. Here is our very simple script that creates a staging repository with bash:

This script needs 3 informations to create and retrieve a staging repository ID. Your credentials, username and password from your sonatype account, and the profile ID you want to use to publish your library. Note that you can have multiple profiles if you are allowed to send artifacts over different group ID.

If you don’t know your profile ID, you can get it through the sonatype API, here: https://oss.sonatype.org/service/local/staging/profiles

The last command of our script will send our repository ID to the outputs of a Github Action job, to be consumed by future steps in our workflow. We have the same kind of script to drop or release the staging repository, in case of success or failure of our publication steps.

As nice and handy as these scripts are, using them in every project we have means downloading the proper .sh file, giving the system the right to execute it, and then run it with the right parameters, ending with numerous Github Actions jobs like this on every project:

This sounds cumbersome and hard to maintain at a larger scale, though.

Github provides a way to create automated tasks, called Actions. Those Actions can be written with JavaScript, or you can provide a Docker container configuration to be executed when you need. Therefore, we decided to create our own Action, with the help of our very good friend Martin Bonnin (Github). Our goal was to avoid the complexity of managing manual scripts in every project, and of course to share it with the community, giving the ability to anyone to handle their publication over Maven Central in an easy way.

Those Actions are available under the Github organisation nexus-actions, so you can browse the code, copy them, and use them at your own convenience. Here is how to implement your release workflow with them:

This job will be triggered only when a release is created on your Github repository. The first job will be to create the unique staging repository to upload all of our artifacts on, applying the action nexus-actions/create-nexus-staging-repo, with the proper parameters. We can now retrieve the output of the action, attach it to the outputs of our create-staging-repository job, and then use it in a later one.

Now, all we have to do is to publish our Kotlin/Multiplatform project with a simple job, that will grab the needed information from the Github secrets, and from the output of the job previously executed:

As you can see, this job will only be executed after the first one ends, as it needs it to finish. This job will run multiple times, once for every platform defined in the matrix. It is quite easy to consume outputs from an earlier job, we just need to invoke this job from our needed ones, and provide the correct name of the variable we want to use.

This example, is really simple, if you are looking for more advanced use cases, you can check our Kodein Open Source Initiative Github Actions, where we manage things like caching Gradle or Konan across builds, installing specific JDK or Android NDK, or even connected checks on the Android Emulator.

Now, whatever is the result of this job, whether it fails or passes, we need to finalise our publication process, by either discard the already uploaded artifacts, or release the new version of our library.

Therefore, we need one last job that will always be executed:

Depending on the result of the build-upload job, only one step will be executed, drop or release. Both of them are based on a different action: either drop-nexus-staging-repo or release-nexus-staging-repo, waiting for the same parameters : your credentials and the previously created repository ID.

The drop task will just ask to sonatype to delete the uploaded artifacts on that specific staging repository while the release task will close the staging repository and wait for the sonatype checks, checking all the requirements we had to comply with, and finally publish the brand new version to Maven Central, making it available for anyone to download.

This article is brought to you by Kodein Koders, a European service & training provider focused on Kotlin & Kotlin/Multiplatform. Do not hesitate to visit our blog, or our Youtube channel for more contents.

Building Kotlin/Multiplatform with Github Actions was originally published in Kodein Koders on Medium, where people are continuing the conversation by highlighting and responding to this story.

In our last tutorial, Salomon showed you how to create a Kotlin Multiplatform Mobile library. Now that we have some code ready to be used by the community, let me show you how to publish your future releases to Maven Central.

Before going into details about how to deploy your libs to Maven Central, I want to adress library developers who already have a library published on JCenter.

This tutorial is also for you!

Publishing on Bintray and JCenter was a choice most of us made, because it had less constraints and more flexibility. Now that they will be shutting down quite soon, we must migrate our publication workflow. Maven Central seems to be the right choice these days, but we need to deal with new requirements.

Where Bintray was giving us some latitude on what we could upload and publish, Maven Central has always been more restrictive. Indeed, every uploaded artifact needs to be accompanied at least by the following items:

• A bundle of the sources of the artifact
• The documentation that goes with the artifact, in the JVM world this is the Javadoc.
• A well formatted POM file. For those who are not familiar with Maven, this is the description of your project, with its name, its version, its dependencies, etc, in an XML format
• And finally, every item needs to be signed to be accepted.

Actually, these requirements are not that hard to fulfill, and Gradle provides almost everything we need to publish our artifacts smoothly, with 2 official plugins, maven-publish and signing.

But… I told you : almost!

When performing a publication, before being available on Maven Central, all your uploaded artifacts with maven-publish are generally stored and referenced in one staging repository that you need to validate as the final step of publishing. While this is true for standard JVM projects, this is not the case for Kotlin/Multiplatform ones.

As Kotlin/Multiplatform developers, you may know that you need two machines to build your project if you are targeting Windows and at least one other native platform. By doing so, each build will invoke the publish task that will implicitly create at least a different staging repository by platform. Why “at least’’? Because, while configuring our open source Kodein-Framework projects that often implies multiple modules or submodules, we found that a unique invocation of the plugin maven-publish, on a unique machine, ended up with a few 10ish implicit staging repositories created. That can become really cumbersome when managing multiple libraries.

This is why we need to control our publication workflow, by being able to publish one release from multiple builds on a single staging repository. We will see how in a minute, right after checking on some requirements.

Before diving into the configuration of your project, you will need to fulfil some requirements.

I won’t go into every detail, but I will give you some hints of what you need to publish on Maven Central.

If you already have a sonatype account, a verified repository and a GPG key pair, you can just move on to the next chapter.

As I just said, in regards to being able to publish your project to Maven Central, you will need to create a Jira account on sonatype and give them the possibility to verify the ownership of the group id you want to publish on. So, go to https://issues.sonatype.org and create your account.

After that, you should be able to open an issue, select "New Project" as the Issue Type, and let sonatype verify the ownership of your group id.

In my use case, I wanted the ownership of our group id org.kodein, where we will be publishing all the future versions of the Kodein-Framework.

After that, Sonatype will ask you to validate your ownership, either by adding a DNS record to your domain, or by creating a specific repository named after the ticket number if you own a Github organisation. Your repository should be ready to store and expose your artifacts within a few minutes. Verification is usually done automatically, but sometimes is manual and longer for security reasons.

Now you can upload whatever you want to your sonatype repository. But, if you want your artifacts to be available on Maven Central, they must pass through a validation process, which will check if these artifacts are correctly signed. In order to do so, you need to generate a GPG key pair.

While there are plenty of ways to generate your GPG keys, here is the quickest one. Note that on MacOS I use GPG Suite to handle my keys.

To create a new GPG key pair, run the command:

With this, you just have to enter your name and email, a strong passphrase, and you’ll end up with a RSA key pair.

You can list your keys with the command:

And, later on we will need to export our private key as “armored”, with the command:

This will print your GPG private key in an ASCII format, surrounded with these key block delimiters.

I must warn you! You should never share your private key with anyone, under no circumstances. You should keep it somewhere safe, and do not lose it!

Now comes the fun part, configuring your Kotlin/Multiplatform project with vanilla Gradle. Let’s start by adding the necessary plugins to your configuration. Along with the Kotlin Multiplatform plugin we will apply the maven-publish and signing plugins.

The maven-publish plugin will help us fulfill the sonatype publication requirements. Pointing the configuration to the sonatype OSS repository is quite simple. We can even put a condition onto the published version of our library, to upload them directly on the SNAPSHOT repository, which allows us to upload anything on your group ID, as long as its version ends with the uppercased word SNAPSHOT.

As I said earlier, we prefer to upload our releases onto a unique staging repository to maximize our control over the publication workflow. Thus, we need to replace the release repo URL deploy/maven2 deploy/maven2 by deployByRepositoryId/$repositoryId, where the variable repositoryId can be set upward into Gradle properties, or via environment variables like in the following snippet:

Note that, while doing so fixes the multiple repositories issue, this makes the deployment dependent on a specific environment variable.

What remains is to set up the credentials of your sonatype account, obviously not with hardcoded values, but as external resources. So here is a full snippet of the maven-publish plugin configuration:

Before singing every output item of our Kotlin/Multiplatform build, we need to add some extra configuration, so that the sonatype validation check passes. As I already said, Maven Central requirements are restrictive. In fact, along with our artifacts we also need to upload the related sources, docs and a POM file with a defined set of metadatas.

Sources are already packaged by maven-publish, but we will have to add the docs and the POM file. Here is an example of how to generate a POM file with the publication configuration:

This means that for each Maven Publication task of our Kotlin/Multiplatform project, thus accompanying each target’s artifact, we will add a POM file with the required metadatas.

To provide some documentation to go with your artifacts, you can choose the easy way, like most of the libraries published on Maven Central, and “cheat” by adding an empty javadoc, with the following configuration:

Or, you can configure Dokka, the documentation engine for Kotlin developed by JetBrains, and recently enabled for Kotlin/Multiplatform. Start by adding the dokka plugin to your configuration:

And now add the following snippet to your gradle configuration script:

This defines where the dokka task should put the generated documentation, and provides it to the javadocJar task, that will bundle it with a name like `artifact-javadoc.jar`. The delete Dokka Output Directory task will ensure that the documentation is up to date, by removing the old ones before regenerating it.

Now, like for the empty javadoc, just add the javadocJar task as an artifact of the MavenPublication tasks.

We are almost there, ready to publish to Maven Central! The final rule that we need to validate is that every uploaded item needs to be signed. This is really trivial once you have your GPG key pair generated. You need to export your private key in an ASCII armored format with the following command:

Save that output, and your GPG password, wherever it suits for your build process. In our case we put it in our Github’s secrets, being able to set them as environment variables in our Github Actions workflow.

So signing is now as simple as adding a few lines of gradle configuration:

This defines how to retrieve the signatory configuration, by reading environment variables, and what should be signed. Here, we will be signing every output of all the publications tasks. You can now test your configuration locally by running the task `publishToMavenLocal`, and do not forget to set your environment variables.

Here is an example of the output of a publication for one target of the Kodein-DI library, with the kilb artifact, the sources, the javadoc, the pom file, and everyone of them is signed:

You can now run the publish task on multiple machines to upload your artifacts, depending on your Kotlin/Multiplatform targets.

But, we are not done here. The next step would be to set up a CI/CD workflow to automate everything. We will cover that in a future tutorial, to see how to automate the publication of a Kotlin/Multiplatform project with Github Actions.

I really hope that you have learned something, and that this will be useful for you to share to the community your Kotlin/Multiplatform libraries on Maven Central.

Here is a playground project that contains everything you need to release your libraries on Maven Central. Link is also in the description.

https://github.com/KodeinKoders/playground-publish-kmp-to-mavencentral/

See you soon for more tutorials here or on our KodeinKoders Youtube channel.

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

Thanks to Louis CAD for reviewing this article.

Publish a Kotlin/Multiplatform library on Maven Central was originally published in Kodein Koders on Medium, where people are continuing the conversation by highlighting and responding to this story.

In this article, we will see how to use a dependency injection library in your Kotlin/Multiplatform projects. I will walk you through the basics of the dependency injection pattern, and the materials we have at our disposal in a Kotlin/Multiplatform context, using the Kodein-DI library.

First, let me remind you why you should consider using dependency injection, and what are the benefits of a DI library. In software development, using dependency injection is the most popular technique to address the principle of separation of concerns. Its goal is to free objects of any responsibility but their original purpose. Let’s take an example of an application working with users, that is capable of retrieving data from an HTTP API, and also works offline with a local database. Here is the code we could write to make such an application:

Here, the different classes are responsible for their functions’ behaviour, but they also are responsible for creating the objects they need to work properly.

A more idiomatic design would be to separate all the objects’ creation from their call site, by defining them as external resources, for instance as constructor parameters.

This removes the responsibility of creating dependencies, enables code reusability, and should help you mock and test your code easily.

Now, the simplest thing you could do is to manage your dependencies manually, to instantiate and inject them in a global context, accessible from anywhere in your application.

However, this comes with a cost. Testing the different units becomes a challenge, because our instances are tightly coupled with the Injector object. This means that we’ll have to know how to instantiate our objects and dependencies, and how they are used, before plugging everything manually. This is where a Dependency Injection library helps.

A DI library gives you the tools to define the dependency graph of your application, and will be able to dynamically inject the right dependency when needed. It also gives the ability to swap object’s instances, and replace them with different implementations in an easy and readable way, which removes a lot of pain points when testing your code.

So now, let’s see how to configure and use Kodein-DI, our favorite dependency injection library for Kotlin/Multiplatform.

Kodein-DI has never been easier to use and configure in KMPs. All you need to do is to define a dependency in the common source set of your Gradle build file, and you’re done. Thanks to the Gradle Metadata published along with all the Kodein-DI binaries, Gradle will be able to attach the right binaries for each target of your project.

NB: we highly recommend to use Gradle 6.0, or higher, which enables Gradle Metadata by default.

To see how to use Kodein-DI let’s take our last example, where every class receives its dependencies as constructor parameters.

In our common source set, we can define a DI container that will provide all the needed dependencies. Thus, we can bind straight instances, singletons or even constants.

There are some other use cases where Kodein-DI can shine. For example, let’s say that you want to handle multiple databases, you could use tags to bind multiple instances of the DB object, and use those tags to inject the proper instance when needed.

We are also able to bind more volatile objects through providers and factories. A factory will be executed every time the DI container asks for it. When using a factory you’ll have to pass arguments to the instance function to get its result.

If you don’t want to bother managing your dependencies via your constructors, maintaining an API, a certain order in the parameters, and so on, you can pass around the DI container while writing your bindings. Therefore, you should be able to call every binding from that container.

We can go further by using the `DIAware` interface. Every object that implements `DIAware` needs to override a `di` property as a `DI` container reference. This interface provides shortcuts to the container, like the `instance` delegate.

When declaring your bindings, all you have to do is to pass the DI container itself within your binding declaration.

When working on bigger projects, We recommend to split your DI container into modules, to organise your code, or even be able to swap an entire block of dependencies. For example we could define a module for the app utilities, and one for the user business code, before importing them in a DI container.

Now that we know how to bootstrap Kodein-DI in a Kotlin/Multiplatform project, let’s see how we can easily swap our bindings and test our code. With Kodein-DI, every dependency is resolved lazily when needed. This means that you don’t need to mock an entire module if its bindings aren’t useful for your test case.

For example, we can define a module “Mock/User”, that overrides our module “App/User” while importing them in a local DI container. Now our UserService object uses the mocks `MockUserRepository` and `MockUserApi` internally, meaning we can focus on unit testing the behaviours of UserService.

In this article we explained what is the DI pattern and how to solve it with Kodein-DI, in a Kotlin/Multiplatform context. Now what remains is to use our business shared code within your favorite platforms. We will cover this in further videos for both Android and iOS, with some architectural approaches.

That’s it folks! Thanks for reading, see you next time for more content on Kodein-DI.

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

Dependency Injection for Kotlin/Multiplatform was originally published in Kodein Koders on Medium, where people are continuing the conversation by highlighting and responding to this story.

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.

Dependency Injection on Kotlin/Multiplatform — Part 3: iOS and Android was originally published in Kodein Koders on Medium, where people are continuing the conversation by highlighting and responding to this story.

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

In the first part we saw how to configure our Kotlin/Multiplatform project with Kodein-DI, then we have defined our architecture and our common business code. Now we need to test our code, once, before building it and using it on both mobile platforms ; iOS and Android.

Before being able to run tests upon our Kotlin code, we will need to configure our Gradle project depending on the platform we are targeting. As we are making a Kotlin/Multiplatform project, we certainly need to define test dependencies for our common code:

You can see that in Kotlin/Multiplatform project test dependencies are like normal dependencies, as they match to specifics source sets.

The power of Kotlin/Multiplatform is to allow us write code once, and then test it once, in the commonTest source set. But, along the way, you will probably need to interact with some platform specific APIs, thus you would also need to include platform specific testing dependencies, like for the JVM:

For the Native source sets we do not need to define test dependencies, as they are built-in into kotlin-test, already added in the common source set.

This article is not about what you need to test and why, but how to use the dependency injection pattern, with Kodein-DI, to test your Kotlin/Multiplatform code, before building and using your library.

If you have read the first part, you nay have seen me coming, as I intentionally used interfaces and separate Kodein-DI modules to make my code independent, swappable and testable, without having to mock or fake the whole application for every test.

Let’s take the previous example from our first article. The login module is composed of four bindings:

Where TokenRepisotry, AuthApi and Login.Presenter are interfaces, and their implementation have the following relations:

• AuthApiImpl needs an instance of some TokenRepository
• LoginPresenterImpl needs an instance of some AuthApi

To test this architecture we will have to import the login module, and override some of the binding to fake their behaviour, in order to test each pieces of our code, independently. Let’’s see how we can do this.

As an example, we will be testing the LoginPresenterImpl. In order to do that, we have to fake the behaviour of the TokenRepository and AuthApi, to control their flow. Here are two implementations, for both of them, one considering that login in is a success and one considering it's not. We will also add, a fake view to check the right behaviour of the Presenter.

Now, we have to declare a DI container that will be carrying our fake implementations:

This code defines a container that is meant to be used just for our tests, with the smallest scope, to avoid unpredictable behaviours.

The following line imports the loginModule from our library. We specify that the current container can override existing dependencies of this module.

Now, we just need to override the existing bindings for AuthApi and TokenRepository:

And finally, this will allow us to instantiate a new TestLoginView every time we need one:

This DI container can be use in our test class by implementing the DIAware interface. It will help us to write our test, avoiding to call the DI container every time we need it, by calling by instance() instead of by loggedInContainer.instance(). This is possible because we will be overriding the di property, from DIAware.

Swapping our fake object is now really simple, for example here is another DI container that will help us testing when the user is not logged, or when the API calls are failing:

Now that we have our multi-platform code, tested, we can confidently build our Kotlin/Multiplatform library before using it on iOS and Android.

While building a library for Android is kind of straightforward, for iOS it hasn’t always been that simple.

Remember, to configure our Kotlin/Multiplatform project we need to define special cases for iOS, depending on the SDK we are targeting, either iOS ARM64 devices or the iOS x64 simulator. Even if we are able to build a fat universal .framework , this can lead us to managing intermediate source set, that was not trivial to use, until Kotlin 1.4-M2.

Back to the point, today there is two path for building Kotlin/Multiplatform library for iOS.

In the early versions of Kotlin/Multiplatform we had to specify a Gradle task to create a .framework file, that could be added to your Xcode configuration manually. Here is the task to add in your build.gradle.kts file.

For some convenience, here we also add the dependency on packForXcode, thus the framework would be built when building our entire project with:

However, iOS developer have tools too! CocoaPods is a dependency management tool for Swift and Objective-C projects, and JetBrains has been kind enough to develop a Gradle plugin, that gives us the ability to provide our Kotlin/Multiplatform library to iOS developers, without breaking their habits. To do so, add the plugin org.jetbrains.kotlin.native.cocapods to your gradle configuration:

Then, wee need to define the cocoapods configuration like below:

Then running the following Gradle task will make the library available for cocoapods:

(we will see what is the output and how to use it in the next article).

As I said before, building our app for Android is pretty straightforward, nowadays. For this example, we will just build a .jar. Nevertheless, you still can build an .aar with Kotlin/Multiplatform by including an Android SDK dependency into the project configuration.

To use our Kotlin/Multiplatform library on Android, we need to publish it on a package repository, like Maven or JCenter. We can use the Gradle pluginmaven-publish

And then call the corresponding task:

That all for this one! Next time, we see how to use our Kotlin/Multiplatform library on iOS and Android.

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

Dependency Injection on Kotlin/Multiplatform — Part 2 : Test and build was originally published in Kodein Koders on Medium, where people are continuing the conversation by highlighting and responding to this story.

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

Kotlin/Multiplatform is certainly on the 2020’s list of programming trends. For sure, it’s a very nice technology, and it is now pretty mature. However, when starting using something new, it’s also convenient to have a bunch of tools that make our day to day job easier. Kotlin/Multiplatform journey is at its beginning, when it comes to tooling, there are some few, but there are still some topics no covered yet, and we are excited to see what’s coming in the next few months.

Until then, this is the first article of a series, that will guide you through the use of our Kotlin/Multiplatform Dependency Injection library: Kodein-DI.

In this part, we will see what we’ll be building, how to configure your Kotlin/Multiplatform project, and how to use Kodein-DI in this particular use case.

As with my wife we are close to having our second child, I have decided to find some time to build an app for our friends and families to bet on the name, the date and some other data regarding the birth of the new kid 😃

Here the data classes of the app:

So the idea is quite simple. We need to provide an app to enter those prognostics information and send them to a server. But, among our friends and families, there is both Android and iOS devices… Let’s try to factorize and test our business code in one place before using it on native platforms.

I am moving fast over the configuration of our Kotlin/Multiplatform project, as many resources have already covered this part:

What will matter to us, is how do we manage dependencies for Kotlin/Multiplatform projects, and more precisely for Kodein-DI.

Thanks to the Gradle Metadata feature, we do not have so much to do while targetting different platforms, but just declaring the use of Kodein-DI in the common source set, as long as you are using Gradle 6+.

In fact, when we build Kodein-DI, on MacOS for example, Gradle will produce binaries for each targetted platform, like MacOS / iOS / JVM / JS. But, it will also produce some files that are carrying references on which binaries are needed depending on the target. So, in the case of androidMain , Gradle will get org.kodein.di:kodein-di-jvm .

Note: there are Android-specific Kodein-DI modules that we will cover in a future part.

As we do not want the entire earth to be able to vote, I put a simple PIN-based authentication. This auth is verified by the server and returns a token, stored on the device. Here is the definition:

What's important here is the fact that most of the classes have interfaces. That way, implementations will be swappable with fake objects for testing, by using Kodein-DI.

To interact with the UI, thus the native code, I’ve chosen to use the MVP pattern, as I find it simple to grasp and to use for my use case. Thus, I have 2 interfaces, one for the Presenter and one for the View, that should be implemented or used by my native code somehow.

The Login.Presenter can receive instruction to authenticate the user with a secret PIN or to check the current state of the authentication.

The Login.View can respond to the UI with a onLoginSuccess function, but also with a onError, available from its parent interface BaseView.

You may have noticed that LoginPresenterImpl is implementing the interface DIAware. This provides a global approach for the class to use the dependency injection. Because of the interface, we can smoothly retrieve our dependency bindings as delegated properties, using by instance(). Doing so, the AuthApi and TokenRepository should be retrieved seamlessly, without the need to know how to instantiate them, at call-site.

This article is all about managing our dependency injection while using Kotlin/Multiplatform, remember?. So, let’s see how to define our dependencies.

To be able to test efficiently my business code, I decided to split concerns in modules. Kodein-DI's modules provide a way to extract our bindings in separated objects, avoiding one big central DI container, containing every binding of our application. Those modules can be imported side by side in a global container.

With this approach, I should be able to test atomically my code, or even swap an entire module if needed. Here is my login module:

So you’ve read so far, cool! Here is another example, based on the Participant API, used to give to the users the ability to send prognostics, change them, and see what they already have sent.

And here is the corresponding Kodein-DI module definition:

Now that we have defined our APIs and our DI modules, we will need to set on a dependency injection container, that will carry every binding that we would be using in our application.

Note: We didn’t talk about the database layer, we will certainly do in some next articles ;)

So, every module is imported in a global container. Usable in any native code, almost…

At the moment, Kodein-DI (v7.0) is Kotlin/Multiplatform, but, as it will mainly be a dependency for another K/M project, the API would less usable from non-kotlin native code, like Swift. Indeed, Swift does not support things like delegation properties or reified parameters, making the use of instance<T>() function impossible. So, for now, the solution is to give the ability to swift to call out our dependencies through facades:

Don’t worry, we are working on something that will make Kodein-DI as easy to use from Swift than from Kotlin 🙂

Here we have defined how to bootstrap our Kotlin/Multiplatform project using Kodein-DI. Next time we will see how we can test our code and how to bundle .jar and .framework to be used on Android and iOS.

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

Dependency Injection on Kotlin/Multiplatform — Part 1: Factorize your code was originally published in Kodein Koders on Medium, where people are continuing the conversation by highlighting and responding to this story.