Zach Klippenstein (he/him) [MOD]
04/26/2021, 11:30 PMRobert Jaros
04/27/2021, 12:10 AMGlobalScope
usage is discouraged, but I think it's hard to avoid it when developing on Kotlin/JS. Most of the time there is just no better/easier way to launch coroutines. Of course I can create another singleton object instead, but for me it just doesn't make sense.baxter
04/27/2021, 4:04 AMGlobalScope
, while I agree that it should never be used, would it be better to use a new scope that is never canceled for tasks that need to run once in a coroutine, or run it in the global scope? For example, on an Android project, I have a specific job I want to run once, and don't need any result back. It can take the entire app process lifecycle (if it is short) or run until completion.Zach Klippenstein (he/him) [MOD]
04/27/2021, 4:28 AMGlobalScope
, you shouldn’t hard-code it – you should inject it and provide it from a module near the root of your DI graph. Then, it’s still not a bad idea to make your own scope, because you can set the dispatcher explicitly, instead of having to remember what dispatcher GlobalScope
happens to use.louiscad
04/27/2021, 6:10 AMAppScope
in real world projectsJan Skrasek
04/27/2021, 6:51 AMFirstly, even if you are usingWhy so? Isn't injecting a dispatcher sufficient?, you shouldn’t hard-code it – you should inject it and provide it from a module near the root of your DI graph.GlobalScope
baxter
04/27/2021, 6:56 AMlouiscad
04/27/2021, 7:58 AMAppScope
has a Job
inside, it's safer than GlobalScope
.Zach Klippenstein (he/him) [MOD]
04/27/2021, 12:48 PMWhy so? Isn’t injecting a dispatcher sufficient?It’s better than nothing, but injecting a context/scope also lets you customize other things at the root. Eg: • In a lot of the main production apps I work on, we actually keep the process alive across independent instrumentation tests and for that to work you need everything that is scoped to the “app” to actually be disposable/cancellable. • Adding logging or debug interceptors
andylamax
04/28/2021, 10:54 AMGlobalScope
at all, I just
CoroutineScope(window.asCoroutineDispatcher()).launch {
// do things here
}
I think there is a Kotlin/JS(node) way of getting a dispatcher scoped to the processRobert Jaros
04/28/2021, 11:27 AMGlobalScope
on JS?louiscad
04/28/2021, 11:28 AMJan Skrasek
04/28/2021, 11:28 AMlouiscad
04/28/2021, 11:29 AMRobert Jaros
04/28/2021, 11:40 AMlouiscad
04/28/2021, 11:41 AMRobert Jaros
04/28/2021, 11:42 AMCoroutineScope(window.asCoroutineDispatcher()).launch { }
) is still not safe enough?louiscad
04/28/2021, 11:44 AMCoroutineScope
or to the Job
returned by launch
or it will be garbage collected whenever there's no strong reference held and the coroutine is suspended.CoroutineScope
but don't put it in a property.Robert Jaros
04/28/2021, 11:54 AMlouiscad
04/28/2021, 11:54 AMRobert Jaros
04/28/2021, 11:59 AMGlobalScope
"gone" 😉 the documentation on creating custom scopes the right way (with all this important information) should be somewhere in the main docs here https://github.com/Kotlin/kotlinx.coroutinesandylamax
04/28/2021, 12:23 PMJS
something like
val scope = CoroutineScope(window.asCoroutineDispatcher())
scope.launch {
// do stuff here
}
works?baxter
04/28/2021, 5:59 PMGlobalScope
. Thanks @louiscad for the insight on the ticket and explanation in ensuring a strong reference to a job is kept.AppScope
object now.ursus
04/30/2021, 1:13 AM@AppScope
1. class MessageSender() : HasLifecycle {
private val scope = SuperviserScope(...)
fun sendMessage() {
scope.launch {
doSendMessage()
}
}
private suspend fun doSendMessage() {
...
}
override fun destroy() {
scope.cancel()
}
}
@AppScope
2. class MessageSender(scope: coroutineScope) {
fun sendMessage() {
scope.launch {
doSendMessage()
}
}
private suspend fun doSendMessage() {
...
}
}
any reasons for one over the other?louiscad
04/30/2021, 10:17 AM