hi! how can i, in a jvm desktop application, provi...

# koin

[abbic]

hi! how can i, in a jvm desktop application, provide a coroutineScope scoped to the lifecycle of the app via koin?

[abbic]

just found something, might this

factory { SupervisiorJob() }
single { CoroutineScope(<http://Dispatchers.IO|Dispatchers.IO> + get<SupervisorJob>()) }

do the trick for me?

[abbic]

or maybe rather just single { CoroutineScope(<http://Dispatchers.IO|Dispatchers.IO> + SupervisorJob()) }

[Pedro Alberto]

both should be Factory

[Pedro Alberto]

and I did a my own Scope Type and you might want to have a supervisor job accessible

[Pedro Alberto]

i.e.

factoryOf(::MainScope)

class MainScope: CoroutineScope {
    val supervisorJob: CompletableJob = SupervisorJob()
    override val coroutineContext: CoroutineContext
        get() = supervisorJob + Dispatchers.MAIN

}

[Pedro Alberto]

you might need to also create abstraction on scheduler so when you go to unit test this is easier

[Pedro Alberto]

not sure if @arnaud.giuliani has better way of achieving this

[arnaud.giuliani]

you can have the default dispatchers referenced in Koin, and request it when you need

[arnaud.giuliani]

for example here https://github.com/InsertKoinIO/nowinandroid, we can inject the default dispatchers from Koin

[arnaud.giuliani]

I would suggest to not use DI for Coroutines Scope configuration. or at least use injection by constructor if possible

[Pedro Alberto]

@arnaud.giuliani can you refer the class so I can see a sample ? we use constructor injection but then when we need to test the class we need also mock the CorutineScope

[arnaud.giuliani]

https://github.com/InsertKoinIO/nowinandroid/blob/refacto_koin/end/core/common/src[…]ples/apps/nowinandroid/core/network/di/DispatchersKoinModule.kt

[arnaud.giuliani]

after that, it’s used in cosntructor everywhere

[arnaud.giuliani]

just need to override the Dispatcher definition in test

[abbic]

thanks!

[Pedro Alberto]

@arnaud.giuliani Why you don't recommend to have?

factory {
     MainScope()
}

The thing why we went this way is that don't need to define every time where use the CoroutineScope. It becomes easier to use but if there is any side effect I would like to know.

[arnaud.giuliani]

I would avoid mixing Concurrency with DI as you are coupling them. In a unit test, it becomes less “unit” then, as you need DI container. But it’s ok to have default dispatchers in DI for constructor injection

[Pedro Alberto]

ok seems we have to refactor 🙂

[Pedro Alberto]

how can I explain this to my boss

[arnaud.giuliani]

better testability, else assume some kind of coupling 🤷