Heh, I opened this chat to ask if there's a proper DI library for KMP which is not a Service Locator...

# multiplatform

[dimsuz]

Heh, I opened this chat to ask if there's a proper DI library for KMP which is not a Service Locator implementation, and here is the survey about missing libraries.

Still. Is there a non-SL DI library available for KMP?

[Kris Wong]

do you need it to support concurrency?

[kpgalligan]

Not that I’m aware of. What comparable libraries would you be looking for?

[Kris Wong]

here is the most "authoritative" list of libraries I have come across: https://github.com/AAkira/Kotlin-Multiplatform-Libraries

[dimsuz]

Not that I’m aware of. What comparable libraries would you be looking for?

I guess it would be Dagger/Toothpick. Maybe Guice, but it uses reflection which is slow on Android.

do you need it to support concurrency?

Not only that. To provide dependencies in general, this is crucial for large apps...

[Kris Wong]

none of the current DI/SL libraries support native concurrency last I checked

[Kris Wong]

i rolled my own barebones impl.

[kpgalligan]

So, no. I’m working with Koin lead on native, obviously with concurrency support, but that’s not “proper”, so no, there are no options as of now.

[kpgalligan]

We’re using the Koin version now for our stuff: https://github.com/touchlab/KaMPKit. Hopefully we’ll have a version out with 1.3.70, but we’ll see

[dimsuz]

Got it! I mentioned this in the survey posted above :)

[dimsuz]

I had an experience with Kodein, so I thought to try it, it seem to have KMP support already.

[dimsuz]

none of the current DI/SL libraries support native concurrency last I checked

You mean accessing dependencies from other threads? Issues with freezing?

[kpgalligan]

It does not really support native threading, unless the situation has changed.

[kpgalligan]

Yes

[kpgalligan]

He means that

[dimsuz]

I see. Can I work around that by creating classes on the main thread?

[kpgalligan]

The Koin version I’m working on would support that, although you’d need to explicitly let other threads inject. I want to avoid silently freezing if possible

[kpgalligan]

Yeah, that’s the goal of what I’m working on with the Koin version. All DI is main thread, and you can keep state mutable

[kpgalligan]

If you need to move it to another thread, it’s frozen

[kpgalligan]

Description in readme (not exactly a full description, but you get the idea): https://github.com/kpgalligan/koin/tree/kpg/kmp_update

[dimsuz]

Great, thank you!

[kpgalligan]

I’m guessing there will be a serious release soon. I want to push more of an experimental one in the next week or so (“experimental” in that we also want to allow JVM to work as it currently does, optionally, but the experimental one will just be main-thread only)

[Kris Wong]

I managed to get SL using by inject() without having in injected object frozen

[kpgalligan]

With Kodein? If yes, my issue is, as of last time I looked at it, if you happened to capture something from kodein or access it from another thread, it would (in theory) freeze the kodein config, which would silently cause issues. Maybe not a huge deal sometimes, but you’ll eventually have issues. I think it should be explicit, and I also want Android to behave the same. So, the Koin version I’m working on will throw the same exceptions if you try to access it from other threads.

[Kris Wong]

no, my own

[Kris Wong]

kodein just crashed

[kpgalligan]

Yeah, I mean people use it. Not trashing on it. I just think the thread awareness needs to be explicit

[kpgalligan]

However, I’m a little fixated on the concurrency topic

[dimsuz]

I support explicitness too. I've used Toothpick DI library (jvm) and they went with ConcurrentHashMaps internally, but I never needed this thread safety in my apps, so maybe I could avoid paying performance price for this. Although, of course, I didn't notice any slowdown, so it's not fair judgement, but I still think sometimes it could be lighter.