Hello Koin users,
The rocket is on the launchpad! 馃殌 We are beginning the release candidates versions!
Below the last big changes for Koin 1.0:
module {
module("B") {
single { ComponentA() }
single { ComponentB(get()) }
}
module("C") {
single { ComponentA() }
single { ComponentC(get()) }
}
}
val a : ComponentA = get(name = "B.ComponentA")
koin-reflect project. The main purpose is to help build definition by calling your constructor and filling injecting dependencies:// without API builder
module {
single { ComponentA(get() ...) }
}
// with create builder
module {
single { create<ComponentA>() }
}
// compact declaration
module {
single<ComponentA>()
}
KoinComponentmodule {
scope("session") { Presenter() }
}
// create a scope
val session = getKoin().createScope("session")
// will return the same instance of Presenter until 'session' scope is closed
val presenter = get<Presenter>()
// close it when finished
session.close()
// instance of presenter has been dropped
here are some links to the documentation:
https://insert-koin.io/docs/1.0/quick-references/koin-dsl/#implicit-naming--namespaces
https://insert-koin.io/docs/1.0/quick-references/koin-core/#using-scopes-with-the-scope-api
https://insert-koin.io/docs/1.0/documentation/reference/index.html#_using_scopes
https://insert-koin.io/docs/1.0/documentation/reference/index.html#_scope_features_for_android
https://insert-koin.io/docs/1.0/documentation/reference/index.html#_koin_reflect
While fixing the last bugs, website & others are in migration 馃憤
Keep in touch!
Should be not so hard to further simplify usage of scope functions by removing intermediate getKoin() call (add extention functions to KoinComponent):
// create a scope
val session = createScope("session")
// or get scope if already created before
val session = getScope("session")
Great work. I love koin and i can麓t wait for the final release.
Regarding your new scope api. I think it is a little bit confuse to have two functions. because the user will not know what happens if he calls createScope twice. or maybe you have to check the getScope function first and if it returns null you createScope.
getKoin().createScope("session")
getKoin().getScope("session")
it think it is clearer if you have one function. this function should return an already existing scope or if the scope does not exist create a new one and return this.
getKoin().getOrCreateScope("session")
and like @Tapchicoma said you can create an extention function to name it directly
```kotlin
getOrCreateScope("session")
Currently, I believe that we need to differentiate those 3 functions: createScope, getScope or getOrCreate. If you try to create a previously created scope, it will throw an exception.
You need to understand how your scope is created and be sure to create/close when needed.
Should be ok to compact getKoin() directly with KoinComponent extensions. My first thought is that it's a non trivial access to the Koin context. We are not just getting dependencies, but handling scopes ... then why not let the getKoin() access appears for such case. But ... yeah, it's shorter to write :)
Just pushed aRC-2 with rollback on release() APi and better Scope API usage.
The DSL definition hold the "scope id": scope("session") { UserSession() }
Before resolving, just check that you have created a "session" scope. And then resolve as susual.
Just updated the sample above.
It would be nice to also have a way to provide some configuration to createScope() method. Can be a map of parameters or same approach like injection parameters.
I recommend to invert the order of types in singleBy function.
Also in the same function specify that one type R extends to the other type T.
singleBy<T:Any,R:T>
This way we can avoid some errors in compile time.
Best Regards!!
Thanks @fredy-mederos
I finally propose to avoid a new keyword singleBy, and keep named single from another extension.
single with one type : import org.koin.experimental.builder.*
single with two types : import org.koin.experimental.builder.extended.*
And we keep:
module {
single<Component>()
single<Target,Implementation>()
}
What do you prefer: single with another import or singleBy?
single that has different imports will lead to the problems when both variants wanted to be used.
One of this variants will have to use import with alias name: import ... as singleBy.
So personally I will vote to have both single and singleBy.
koin-reflect has been finally renamed to koin-core-ext, to gather all extended and experimental features of Koin core (better name than a technical one).
Scope API has been updated to fix visibility problem when resolving scopes with the same type (https://github.com/InsertKoinIO/koin/issues/228).
koin-android-viewmodel will embed the viewModel<>() automatic declaration, thanks to koin-core-ext. You will have to use org.koin.android.viewmodel.experimental.builder import.
Koin 1.0.0 is actually in currently in publishing. Must have to wait for koin-core-ext publishing on jcenter.
Most helpful comment
Currently, I believe that we need to differentiate those 3 functions: createScope, getScope or getOrCreate. If you try to create a previously created scope, it will throw an exception.
You need to understand how your scope is created and be sure to create/close when needed.
Should be ok to compact getKoin() directly with KoinComponent extensions. My first thought is that it's a non trivial access to the Koin context. We are not just getting dependencies, but handling scopes ... then why not let the
getKoin()access appears for such case. But ... yeah, it's shorter to write :)