Moving forward with the Kodein Open Source Initiative
Back in the very early days of Kotlin Multiplatform, when the KODEIN Dependency Injection library was the very first community library ever being ported to this new promising technology, I dreamt of an integrated suite of components that, together, offered mobile developers tools to quickly and easily develop multi-platform mobile applications.
In essence, I wanted to create a framework providing DI, DB, Logging, MVI, and more, all integrated into a cohesive platform.
However, as time went on, I realised that Open Source development is quite long and difficult (who knew, right?), especially when you're a team of two, and that you also need to work for clients, in order to, you know, eat.
I also realised that I was promoting our work backwards. The message "This lib is part of a framework that does not really exist yet, but it is also its own independent library that you can totally use without any other of our libs" is actually very ambiguous.
Furthermore, full fledged frameworks are nowadays a lot less attractive to developers. As application craftsmen & craftswomen, we want to own our architecture, and make choices that reflect our very own business needs, opinions, and experience. It's not because you are using the Kodein Dependency Injection container that using SQLDelight (instead of Kodein-DB) should feel a mistake, or vice-versa.
I came to the realisation that when we advertise each library as part of a whole framework, we harm each individual library by preventing them to be evaluated only by their own merits.
We (Romain and I, founders of Kodein Koders) decided that it is time to sunset the Kodein-Framework. This by no means signifies that we will stop working on our Open-Source libs, but simply that each library will be given its very own independent identity.
We will be maintaining & advancing these libraries as the "Kodein Open Source Initiative", or KOSI for short. The biggest change that this decision will bring is the move & rename of our Github organisation & projects, which will happens in the next few weeks.
That's it for the big announcement.
In the rest of this article, I want to take the opportunity to describe our take on what's next for our libraries, and how we envision the future of Kotlin Multiplatform application development with KOSI.
Be advise, this is a multi-year vision.
Moving KODEIN-DI to the platforms
Our Dependency Injection library will revert back to being called KODEIN. Its previous new name "Kodein-DI" never really took anyway, and people still come to me today saying that they "enjoy using Kodein". Since KO-DE-IN initially meant KOtlin DEpendency INjection, calling it Kodein-DI never really made sense anyway.
1. Allow verification
We were always opposed to declaring dependencies as annotated class methods, which we find cumbersome and very complex to reason about. We are very attached to the ease & simplicity of our declarative DSL (which we are still improving). Furthermore, we believe that compile-time verification is way to restrictive and leads to a lot of complications, when we want to provide flexibility.
Yet, we believe that there still should be a way to verify for exhaustivity & correctness, if not at compile-time, at deployment time. In other words, we want to provide a way to write a 3-lines unit test that provides the absolute certainty that your DI code is correct.
This does mean changing the retrieval API, which we are less attached to.
When prototyping this feature, we realised that it would mean writing a Kotlin compiler plugin (or KSP generator), and that the context receiver feature (which is currently in beta in the Kotlin language) would help a lot.
2. Make binding & retrieval available to platform APIs
As KODEIN offers a Kotlin API, it can be used in the shared code as well as in the Android code. This means that, on Android, you can bind types & retrieve objects that only exist in the Android platform. As the shared code is only a library and not an application, the specific Android application code can also make use of KODEIN for its own dependencies (for example, binding platform services). This is not the case for the iOS specific code.
We want to make the iOS code, in Swift, able to provide its own specific modules to bind & retrieve its own types & objects. This means the creation of a "Swift-With-Kotlin deployment tool" (Intrigued? Keep reading!)
Taking Kodein-DB off the grid
The embedded NoSQL database Kodein-DB never really took off. I think there are multiple reasons for that : the name didn't help, the library is very experimental, its API is weakly typed, it lacked proper developer support (so sorry about that, life happened).
The project is far from abandoned, though! I am currently heavily working on it, and it will reborn under a new name (of course), and most importantly a better API.
On that note, if you have any idea for the name of a Kotlin/Multiplatform Embedded Document NoSQL Database, please share!
1. A better API with generated code
The goal of Kodein-DB has always been to allow you to store & query your own Kotlin structures and have your code be the single source of truth. We do not want to change that, but we do want to provide a strongly typed API that enforces correctness (for example, on index names, ID types, etc.). We are therefore working on a KSP generator that generates APIs according to your model classes, so that you can have the certainty that if it compiles, then it runs.
Oh, and we'll use coroutines by default. Jetpack Compose has demonstrated that it is not a problem anymore to depend on the KotlinX Coroutines library by default.
2. Full Text Search
I've worked for several weeks on this, so it is actually more advanced than you might think! The language processing bits are already implemented in Kotlin/Multiplatform. As it happens, the LevelDB native datastore (that we use as backend) is perfect for the kind of queries that FTS needs. We still need to connect a lot of moving parts, but I'm hopeful!
3. A true migration API
What happens if you move your classes from one package to another? Or if you simply rename a class? Or if you change the type of an ID? Or if you want to split or merge data classes?
We need to find answers and APIs for each of these scenarios.
4. Browser-based data viewer
We want to provide a data viewer that allows you to query & explore your data. This means forcing only one serialisation format, so we are only going to support KotlinX serializers with CBOR. This also means integrating with DB cryptography, so there's a lot to do on that front.
Of course, we would like this viewer to integrate with IntelliJ / Android Studio (How about you right click on a class, and you have the option to query your connected device for all objects of that type in the dattabase?).
Keeping MocKMP awesome
Not much to say about MocKMP, our compile-time mock generator. It already has a name that does not start with "Kodein-", is almost feature-complete, and sees great adoption from the community.
Changing the name of Kodein-Log
Our simple functional logging library needs a new name. You have an idea?
A way to distribute Swift sources with a KMP library.
Let's come back to the use case of using the KODEIN Dependency Injection container from Swift. We need a way to distribute Swift APIs alongside Kotlin APIs. The problem is that when an iOS application uses a Kotlin/Multiplatform shared framework (a "library" in the iOS language), the said framework is compiled specifically for that app under a generated package name. As that package name changes for each app, there is no possible way to distribute a Swift binary libray that uses code from a KMP library.
We therefore must distribute Swift source files with a template "import" at the top that must be automagically changed to the framework package name when included to a final application. I've started working on a Gradle package that does that.
…and then?
We have lots, lots, looooooots of other ideas.
Want to help us bring them to life?
Make sure to contact us. We are very welcoming, supportive, and definitely looking for contributors!
This article is brought to you by Kodein Koders, a European service & training provider focused on Kotlin & Kotlin/Multiplatform. You can visit our blog, or our Youtube channel for more content.
