Koin: [Team] Opening Koin `2.0.0`

[arnaudgiuliani]

Hello Koin users & contributors 🎉

version 1.0.2 has been published. Now I've just finished investigating about general performances of Koin and end up with a new version of Koin core. Same DSL but all with internals rewritten & redesigned. I have refactored Koin with the several notions. Here is now how the coffeeMaker app looks like:

fun main(vararg args: String) {

    koinApplication {
        useLogger()
        loadModules(coffeeAppModule)
    }.start()

    val coffeeShop = CoffeeApp()

    val appDuration = measureTimeMillis {
        coffeeShop.maker.brew()
    }
    println("executed in $appDuration ms")
}

val coffeeAppModule = module {
    single { CoffeeMaker(get(), lazy { get<Heater>() }) }
    single<Pump> { Thermosiphon(get()) }
    single<Heater> { ElectricHeater() }
}

• KoinApplication & Koin to allow clearly isolate several instances of Koin (SDK usage for example)
• KoinApplication starter DSL to allow better extensibility & optimization for building/starting Koin. No more startKoin() but now use the koinApplication { } builder
• Koin DSL stay same, but with some package naming changes -> need to reimport things
• No more inner module to allow clear & simple rules of visibility and resolution, and easy to understand
• new logging system
• Focused on performances

Why a Koin 2.0.0? To start again with a clear API and not been stuck with old ideas and API. This will be easy to port 1.0.x to 2.0.x because it represents on the surface mostly moved imports, but we have to give up with some API that have to be rewritten now.

Some items for Koin 2.0.x

• Koin v2 - test it!!!!
• follow Kotlin v1.3
• Better linting with Kotlin Klint & more closed CI processing
• begin to think about multiplatform -> but need feedback about the demand behind that
• review documentation & website
• feedbacks feedbacks feedbacks ...

Target Scheduling: 3 months / start of 2019

• Battle test the new version
• Open intermediate versions (Alpha, Beta ...) to help people test migration & new features

More opened to contributors
Interested in contributing to Koin? Ping me on the Kotlin slack to add you on the koin developers channel. We will discuss here about futur developments & ideas.

Cheers.

[erickok]

I think the proposed changes are sane, and some very welcome. (Only thing is the annotaiton processing... this better be very optional - we are moving to Koin because it is no AP-based.)

What about the scoping API? Simple use-cases are fine now but it lacks for us to use it more extensively and fine-grained. For example, we tried to write some cusotm scopes based on time and reference counting, but the available API is pretty limited now. Also, the scoping on a String is not great. It is easy to get into issues (#290, #260...) with duplicates creation and potential naming duplicates. Have you considered a scope register based on reference instead (objects can be used but also instances, such as activity instances on Android)?

[pakoito]

One of the possible next logical steps is providing dependencies coming from a suspended context. That way they can be generated lazily in a non-blocking way, and allow cancelling the generation to prevent scoped leaks.

[Buckstabue]

It would be nice if each module had to declare only one scope and it could be possible to do scope inheritance, like it's done in dagger submodules

[arnaudgiuliani]

@erickok scope API remains the same as 1.0.2 but with detachScope feature that allows you to create several scopes of the same id, and get it fully isolated. But I'm clearly opened to new ideas :)

I also introduced a more flexible declaration of scope group definitions:

module {
     withScope(SCOPE_ID) {
         scoped { Simple.ComponentA() }
         scoped { Simple.ComponentB(get()) }
     }
}

[fredy-mederos]

I think we can include support for the new FragmentFactory included in androidx-fragments 1.1.0-alpha01.
I love koin but I don't want to use the "inject" keyword if I can add the dependencies via constructor.

[arnaudgiuliani]

I love koin but I don't want to use the "inject" keyword if I can add the dependencies via constructor.

clearly my feelings too @fredy-mederos

[joreilly]

@arnaudgiuliani Was looking to adopt new FragmentScenario (https://medium.com/google-developer-experts/exploring-the-android-fragment-scenario-component-e369ec587419) in test and ran in to this as well. Seems like some level of FragmentFactory support would be needed here to allow for example constructor injection of say a mock ViewModel?