Folks who inject CoroutineScope, as in App scope, ...
# coroutines
u
Folks who inject CoroutineScope, as in App scope, to keep the suspend functions running no matter the ui, Do you expose regular or suspend functions for such component?
Copy code
class Foo(coroutineScope) {
   fun bar() {
      coroutineScope.launch {
         ...
      }
   }
}
This however does not compose as its not s suspend function ­čśĹ What to do if a blocking function is needed for some legacy component? If it were a suspend function, that legacy component might call it from within a runBlocking block If however its a plain function, now I need to add a barBlocking as well to the api, which is ..ughh, not scaling well
s
Not sure why a CoroutineScope would need to be injected. Injection of a CoroutineContext (eg a Dispatcher) makes sense (especially for the benefit of writing unit tests), but why injecting a CoroutineScope?
u
to keep the suspend functions running no matter the ui
@streetsofboston I see, you are not questioning why a Scope, but why to inject it. ­čÖé
@ursus what do you mean by
This however does not compose
. What is your issue with the non-suspending approach?
u
for example when i need a to make it into a blocking function .. like in firebase messaging service; if it were suspending, i'd just call it in runBlocking
Copy code
fun FirebaseMessagingService.onMessageReceived() {
    runBlocking { thingThatWouldBeLaunchedInFoo() }
}
I also create it privately, but I've seen folks sharing/injecting the scope