Folks who inject CoroutineScope, as in App scope, to keep the suspend functions running no matter th...

# coroutines

[ursus]

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?

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

[streetsofboston]

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?

[uli]

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. 🙂

[uli]

@ursus what do you mean by This however does not compose . What is your issue with the non-suspending approach?

[ursus]

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

fun FirebaseMessagingService.onMessageReceived() {
    runBlocking { thingThatWouldBeLaunchedInFoo() }
}

[ursus]

I also create it privately, but I've seen folks sharing/injecting the scope