With HILT being publicly endorsed by google as the...

# android

[Scott Kruse]

With HILT being publicly endorsed by google as the recommended DI framework, and dagger getting some key new features this year like assisted injection. Is there any reason to continue using Koin / Kodein for android? If you have multiplatform ambitions for your existing codebase, how might you approach DI?

[kevindmoore]

I'm not a big fan of Dagger. Koin (and I think Kodein) have been updated for multiplaform. I really like the simplicity of Koin

[Jeremy]

Not Kotlin but main reason is compile time. Dagger/Kapt destroys build times

[Scott Kruse]

Yeah i guess questions about Kotlin dependency injection in Android is 😶 🤷

[Scott Kruse]

thanks for the input tho @Jeremy 👍

[Jeremy]

DI vs service locator is a :canofworms. I think ppl should use whatever solution that helps them achieve their goals

[gildor]

Compile time validation is just an incredible huge advantage of dagger, even with all compile time issues

[gildor]

But if you have multiplatform, you out of luck, work on support of KSP is just started, and even this doesn’t mean that it will be automatically multiplatform

[Joost Klitsie]

I would say: If you have multiplatform ambitions for your codebase, then you should use a multiplatform DI framework. I worked a bit with Kodein and it is very nice, but indeed the compile time errors are a big (and obvious) miss. However, the lack of code generation makes the framework much more transparent and easier to understand. I found that scoping was much easier there, so it is harder to mess up scoping with Kodein than with Dagger. There are mentions of a compiler plugin DI framework (just the idea of it) as one of the many things we can use compiler plugins for, and I did get the notion that jetbrains was brainstorming about providing such a solution (or perhaps it was just an idea they want the community to work on) so we can be hopeful that one day we can have a multiplatform compile time dependency injection framework. 🙂
and a note: I do consider your question very Kotlin-worthy, in a Kotlin world with developing an Android app in Kotlin, should I use a Kotlin dependency injection framework with an eye on Kotlin Multiplatform or not 🙂

[Jeremy]

dagger works with multiplatform, you just reuse platform specific di

[Michal Klimczak]

@gildor why do you need KSP for multiplatform dagger? Kapt can generate code on jvm but this code can then be used on different platforms. Is there something more that dagger does which can't be achieved with kapt?

[gildor]

Kapt doesn't generate code (except stubs, which a hack to make Kotlin compatible with Java APT), Kapt allows you read declarations on compile time

You are right, you can generate some code and then use it in common code, but it always very limited solution, you cannot read any declarations in common code, only in JVM project

In case of dagger, first of all it doesn't generate Kotlin code, it generates java and it highly coupled with your code declarations to generate code, you just cannot run it on non-jvm project, so moving to ksp as first step has much better perspective: makes compilation faster for Kotlin projects and because it doesn't depend on Java APT, it can read any Kotlin code, and next step may be to generate multiplatform Kotlin

Though, all those steps require a lot of work on side of Dagger

[Michal Klimczak]

Makes sense, thanks for explaining :)

[Michal Klimczak]

No, wait, you said that you can't read declarations in common code with kapt, but you can. Unless I'm misunderstanding what declaration is. But you can read annotated code in shared module and then generate kotlin for any platform, right?

[gildor]

You can do this in shared module, but not all code is shared, you have platform specific code, so dagger just not able to generate providers or factories for it.

I do not say that it completely impossible, there is chance that you just apply java plugin to common/platofrm code and it will work, so kapt will work too, but I doubt that it practical solution, most of the time it will just fail on every non-jvm annotation (even kotlin stdlib is not the same for different platforms). And again, now for dagger it’s pointless, it’s anyway generates Java

[Jeremy]

time for kagger 😆?

[gildor]

There are a few experiments in this direction, one which I like the most is this:
https://github.com/evant/kotlin-inject

But it’s not MPP (but it may be, when KSP will support MPP)

[Jeremy]

kotlin-inject looks like it was def inspired by dagger. I think challenges is you lose some of the integrations like dagger-hilt

[Jeremy]

Is creating platform specific @Module really that big of a deal? I'd think you'd want to manage both cross platform and native dependencies as a single graph

[Jeremy]

and integrate with a native swift/ios di solution

[Michal Klimczak]

I use koin for my multiplatform and there's bunch of things which are platform specific. E.g. you have a common media player manager with some common logic but then you have a platform specific impl of the player and you inject different things on ios and on Android for that.

[Jeremy]

Does the rest of the iOS app utilize Koin as well?

[Michal Klimczak]

no, shared uses koin internally and then exposes a module which is consumed on ios with swinject