Hi all, sorry for the spam 😉 but I'd like to introduce my new lightweight and minimalistic dependency injection framework Katana, written in pure Kotlin and designed with Android in mind. It's lean, fast, doesn't use reflection or code generation and is inspired by Dagger, Koin and Kodein. I believe it fills a niche in the realm of dependency injection libraries and is as good as handwritten DI. Please have a look at https://github.com/rewe-digital-incubator/katana and read https://medium.com/@caffeine81/why-we-need-yet-another-dependency-injection-framework-for-kotlin-android-f8162174ea4 for a bit of background. Please try it out, spread the word and report bugs and feature requests. Also come by #katana if you have questions or feedback. Thank you all for your support ✌🏼🙂

Nice! Any reason you don't target JS / native?

No specific reason. The focus was Android/JVM for the project we developed Katana for. I believe we're using some Kotlin standard library functions that are not (yet) available for JS / Native. Maybe the community can help in porting Katana to other platforms 🙂

Looks like it is just too easy to implement DI in Kotlin.

@marcinmoskala Your point? 😉

In Java it was hard and DI were developed way less often. If someone had an idea what should be improved, he rather made PR to Dagger or Spring to propose better design instead of making everything from scratch. It is because rewriting whole Annotation Processing would be very hard and complicated.

Since when is choice (in open source) a bad thing? By the way I made a few suggestions and PRs for Koin before. However some of my work was discarded. Anyway, no one is forced to use Katana or any other DI library. But I believe that there is a use case for Katana so I released it publicly instead of just using it internally.

@svenjacobs Choice is not bad, but by the same token, choice is not good either. There are many pros and cons on both sides. Too much choice also means too much fragmentation and potentially less support of the library I’ve decided to use. Much choice means it’s more likely I can find a library that suits my needs very closely. But neither is inherently good, nor bad. Both require careful consideration. Everyone ‘hates’ everyone else’s design decisions, and thinks they can do a better job, right? I think Marcin is merely attempting to avoid the JS universe where I don’t think anyone would disagree there are too many choices, all the way down to leftPad.

@Mike I get your point but I think regarding Kotlin-specific dependency injection frameworks we are far away from a situation like with JavaScript. There are now a handful of DI libraries which is okay imho

My comments are more general, and not aimed at you in particular. You asked “since when is choice a bad thing?” so I was just providing an interpretation where it isn’t all good. That’s all. Glad to see contributions at this level, especially for something so heavily used/abused as DI. With luck, we’ll hit on a new Kotlin based solution that makes most people very happy, and we’ll see focus. Arrow is a good example. A few different approaches to a similar problem, and then a convergence so all resources focused on what great solution. I agree we aren’t at that point yet for DI. But someday? I think we can agree that a number of the Java implementations are quite heavy, and Kotlin allows us to do a number of things that can lighten the load on DI, or allow us to approach it from many angles.

@svenjacobs The article doesn't say why you ruled out kodein...? It doesn't have the downsides you mentioned for Koin, and although a bit bloated... but I suppose proguard or r8 could do a good job of unused things...

@dave08 Indeed Kodein was/is just too heavy for us. It's very powerful but we only needed like 10% of its features.

And did that make a much bigger apk footprint (even with r8/proguard)? Technically, one could just "ignore" unnecessary features... and you never know when you might need one...

At this level it was not about APK size / method count but about syntax, how Kodein is set up and used and basically how it "feels". Katana is by design very lean but also expects responsibility from the developer. There is no implicit "magic" going on here.

I know what you mean about magic... truth is, I was looking for a "lighter" DI for Microservices based on Ktor... I might give it a shot there 😉

Sounds great 🙂 If you need help or have questions join me at #katana