Correct me if I am wrong, Koin in JS seem to be using

::class.getFullName()

as the qualifier. This seems to have a major drawback: if 2 classes are named the same they will count as the same one, even though they are different Why not use

::class.js

as the qualifier? This grants access to the actual JS implementation so even if 2 classes are named the same they will count as different. If you really want the Map.Key of the instances to be String you can also use

::class.js.name

. This will provide the actual name of the class which should be unique given a module at least. Maybe even use the

typeOf<T>()

as the key? This should also solve template collision.

Any chance of getting https://github.com/InsertKoinIO/koin/pull/1192 into a release at some point? I believe it's the last barrier to getting KaMPKit working with M1 targets.

Spent a bunch of time trying to setup Koin for instrumented tests. Started by trying to use

loadModules

and

unloadModules

, which worked…until I found out it that the module didn’t load before tests started. That yielded test failures that were difficult to debug. The solution, that doesn’t require test code in production code, was to: 1. Create a new class that extends the production

Application

class, let’s call the child

InstrumentedTestApplication

2. In

InstrumentedTestApplication

, override the list of modules provided in `startKoin`’s

modules

declaration to include a

testModule

3. Create a new class that extends

AndroidJunitRunner

, let’s call it

InstrumentedTestJunitRunner

that will instantiate

InstrumentedTestApplication

4. Point

testInstrumentationRunner

in the app-level build.gradle to

InstrumentedTestJunitRunner

Is this something that is in the Koin documentation, and I missed it? If not, is there interest in having it added?

Question: I see we can load properties from files or by manually adding it to Koin by using the DSL. However, from the DSL we can use the type system (it has a generic parameter) but from the file system it is always considered a String. However, when you load the properties you may run into runtime exceptions if you request a type from the file system property. (Please, see the print screen for the comparison). Is there a reason for this design? It feels really misleading and can cause runtime exceptions if you call the wrong combination. In my humble opinion, we should have 3 possible designs here: 1. All are properties typed (primitives). 2. All are untyped (Strings). 3. We separate the concepts of file system properties and normal properties - and each one of these have a different API (one typed and one untyped). What are your opinions?

Koin 3.2.0 in preparation for first betas

Hi All! I'm injecting a "presenter" object into my compose views and every time a recomposition happens the presenter is recreated, how could I preserve the first created object? I have read that viewModel{} should work that way but I'm using KMM, so I cannot relay on android VM

What is d/w by

inject()

and

viewModel()

? I used both in when injecting in viewmodel and both works fine. I didn't figure out what the d/w in both. Which one need to use for viewModel. Any suggestions? Thanks

I believe the same: • https://insert-koin.io/docs/3.2/reference/koin-core/dsl#withoptions---dsl-options • https://insert-koin.io/docs/3.2/reference/koin-core/dsl-update/ • https://insert-koin.io/docs/3.2/reference/koin-android/dsl-update/

this allow to have something coherent on both DSL 👍

Checking the

includes

contribution. Seeing some perf impact, trying to see if I can optimise it a bit before releasing first 3.2.0-beta-1

Hello everyone! I’ve created my first PR contributing with Koin. It’s very simple, fixing one typo in new doc rsrs. Issue -> https://github.com/InsertKoinIO/koin/issues/1294 Pull Request -> https://github.com/InsertKoinIO/koin/pull/1293

Hey folks, do you think it makes sense to add Kotlin’s Binary Compatibility Validator to Koin to try to reduce breaking changes? For that, we would need to add the library + include the checks to the CI to ensure PRs aren’t added by mistake. 🤔

Hi guys, this is regarding this PR. Want your suggestions. More info in the thread

Hi, guys. I am relatively new to koin and ktor but this looks like there is some mismatching between ktor 2.0 and koin 3.2.0-beta-1. Maybe there is some more new version of docs instead of https://insert-koin.io/docs/reference/koin-ktor/ktor/ ? while trying to create extension fn run into next error.

implementation("io.insert-koin:koin-ktor:$koin_version")
    implementation("io.insert-koin:koin-logger-slf4j:$koin_version")

```import io.ktor.server.application.*
import org.koin.ktor.ext.Koin

fun Application.configureDependancyInjection() {
    install(Koin) {
        slf4jLogger()
        modules(helloAppModule)
    }
}

```Type mismatch: inferred type is Koin.Feature but Plugin<TypeVariable(P), TypeVariable(B), TypeVariable(F)> was expected

Hey guys, I need advice here. Let’s imagine an android app with hundreds of features. Each feature has one or multiple activities with you N fragments. Each host activity has your Koin module with scope tied to activity. What approach is better? 1. load and unload these activity tied koin modules in each activity host; 2. load and unload these activity tied koin modules in Application class; I think the second option it’s easy to maintain because host activities didn’t care with Koin load/unload and the tied scope can solve this in runtime. But… I don’t know if this case will be less performatic then first option.

Hi Anyone could help with this issue?

Hi Arnaud, looks like people are waiting for this feature (including me!). If you are working on something else I would love to raise a pr for a quick fix for the time being. Please do let me know your thoughts 🙂

Cross posting: https://kotlinlang.slack.com/archives/C67HDJZ2N/p1663595941423569 . Looks like the latest releases were made with JDK 11 and that JVM-only modules forward that as a required JVM version but there's no real reason to require Java11 ?

Hi guys, I recently got very interested in experimenting with KSP. So that got me thinking, would you be open to having KSP processor that would verify that all injections are being defined (effectively adding build-time check)?

I’m upgrading koin library in an Android app from

3.1.6

to

3.3.0

. When I run app I’m getting this error.

java.lang.NoSuchMethodError: No static method binds(Lkotlin/Pair;[Lkotlin/reflect/KClass;)Lkotlin/Pair; in class Lorg/koin/dsl/DefinitionBindingKt; or its super classes (declaration of 'org.koin.dsl.DefinitionBindingKt' appears in /data/app/~~aqqlOmEpOuZRMkiV16sAeA==/XXX.YYY.MYPACKAGE.AAA.BBBB-Wnq8EpEHG1vbVsljdmNEow==/base.apk!classes24.dex)

I’ve already cleaned, rebuild, restarted etc and it isn’t working. Someone as getting this error too? How can I fix it?

koin-core -> 3.3.0 / koin-android -> 3.3.1

@arnaud.giuliani I specified correctly right now. But I still getting same error.

koin_android = '3.3.1'
koin_core = '3.3.0'

This can happen If any of my libraries are using a old Koin version (like 3.1.6)? 🤔

I use

fragmentFactory()

to inject Fragments into Activities and that works like a charm. I was wondering if I could use an

AppComponentFactory

to do the same for Activities and made a quick prototype:

val componentFactoryModule = module {
    single<AppComponentFactory> { KoinComponentFactory() }
}

fun KoinApplication.componentFactory() {
    koin.loadModules(listOf(componentFactoryModule))
}

class KoinComponentFactory : AppComponentFactory(), KoinComponent {

    override fun instantiateActivity(
        cl: ClassLoader, className: String, intent: Intent?
    ): Activity {
        val clazz = Class.forName(className).kotlin
        val instance: Activity? = getKoin().getOrNull(clazz)
        return instance ?: super.instantiateActivity(cl, className, intent)
    }

}

add to startKoin:

startKoin {
    componentFactory()
    ...

and register the factory in the manifest:

tools:replace="android:appComponentFactory"
   android:appComponentFactory="mypackage.KoinComponentFactory"

This also works like a charm and I would love this to be part of the library itself but I'm not sure if this is the way to go and how this needs to be changed to play nicely with scopes?

Scenario:

1 - Activity using a koin module scope tied

Let me help to know what happens with this scenario, please. Everything will runs OK or dependencies won’t be found because

scope<ActivityProfile>

was unloaded by

ActivityProfile#2

?

1 - A activity class to see users profile, like ActivityProfile
2 - ActivityProfile has a module tied to it and this activity load and unload this module
3 - Using the app, ActivityProfile is called twice with distinct parameters like userIDs (so it's a expected behaviour)
4 - ActivityProfile#1 is in navigation stack and ActivityProfile#2 is in top (user is looking for it)
5 - User destroy the activity using back button so ActivityProfile#2 calls onDestroy. When this activity is closed user start to look ActivityProfile#1
6 - ActivityProfile#1 try to access Koin dependencies and ??????

Please if anyone can help

Hi Arnaud, there are two bugs in the koin-android-compat library. 1.

SharedViewModelCompat

passed the wrong ViewModelStore (see bug issue) 2. The

ViewModelCompatgetViewModel

always sets

extras = CreationExtras.Empty

, which causes a missing

SAVED_STATE_REGISTRY_OWNER_KEY

I can fix both issues + writing some unit tests.

Has anyone used koin in production for kmm library?