I want to have a typed solution to pass an application-wide scope, which I am doing by simply doing this

class ApplicationScope : CoroutineScope by MainScope()

And in the classes that need it I can inject it by using this type and I know which one it will get, since I am providing this as a singleton in my DI setup. I’d like to do the same with a background dispatcher, but I can’t quite delegate like this, as CoroutineDispatcher is an abstract class, and not an interface. So I figured this compiles just fine

class BackgroundDispatcher : CoroutineDispatcher() {
  override fun dispatch(context: CoroutineContext, block: Runnable) {
    Dispatchers.IO.dispatch(context, block)
  }
}

And then in the classes where I want to provide this, I can ask for a

BackgroundDispatcher

and it should be IO for prod (again providing as a singleton so it’s just one instance of this class), and for tests I can provide the alternative that I want to use per-test. So my question is does this look odd? Any obvious problems I may be oblivious to doing something like this?

If you’re using dagger, you should probably be using

@Qualifier

annotations instead.

CoroutineDispatcher

has a lot of open functions that you will not be delegating to

Dispatchers.IO.dispatch

, so it will probably not work the way you want. Also I would be confused by

BackgroudnDispatcher

being IO and not Default. Both are background, so the name doesn't make sense. And like mentioned above, by tightly coupling the type to the dispatcher, you are defeating the point of injecting a dispatcher to begin with. You might as well just hard code it.

Yeah yeah you’re totally right, I was just trying to avoid the qualifier as it results in a compilation error instead of getting a warning in the IDE immediately when you’re not providing the qualifier and can be a bit annoying. But I think I’ll just go with a qualifier after all. We’re using Koin btw, but that has qualfier support too, so shouldn’t be an issue. Thanks for saving me from this bad idea 😅

For dispatcher you’ll likely want to invert the dependency you inject upwards to

CoroutineContext

.

Why do you want to subclass. It's easier to just create them using the

CoroutinScope(...)

factory methods.... And if you want to be able to tell them apart when injecting them, use qualifier annotations. Subclassing CoroutineScopes and properly implementing them is asking for trouble 🙂

Yeap makes total sense to go with CoroutineContext for that one. I am in an Android codebase here, so I do still want to be able to provide an application-wide CoroutineScope which I give to some classes to perform some work that should outlive what they’re doing. I think I could just do

abstract class ApplicationScope(coroutineScope: CoroutineScope) : CoroutineScope by coroutineScope

And provide this as

single<ApplicationScope> { object : ApplicationScope(MainScope()) {} }

or something similar hmm

And inject these wrappers and use the

.scope

to get the actual scope.

A wrapper like that can work actually yeah, without inheriting from CoroutineScope at all, lemme try that

If you want to make it suitable for testing, add a constructor parameter that takes a CoroutineContext, which you then can use to pass the proper Dispatcher.

For those tests, could I not pass both at the same time by doin smth like:

ApplicationScope(CoroutineScope(<http://Dispatchers.IO|Dispatchers.IO>))

Since CoroutineScope constructor itself takes CoroutineContext where I can pass that dispatcher?

class ApplicationScope(context: CoroutineContext = EmptyCoroutineContext) : CoroutineScope by CoroutineScope(SupervisorJob() + Dispatchers.Main + context)

This will by default create a main-scope (https://github.com/Kotlin/kotlinx.coroutines/blob/master/kotlinx-coroutines-core/common/src/CoroutineScope.kt#L118) and allow you to override stuff through the

context

parameter

Then in tests if I want to opt-out of the SupervisorJob functionality and go with a normal Job I’d need to explicitly pass in, sounds like more trouble than worth compared to

class ApplicationScope(scope: CoroutineScope = MainScope()) : CoroutineScope by scope

no? Like I’m not sure what this last suggestion will help me with in terms of ease of use in my tests compared to passing an entire CoroutineScope? Passing the entire CoroutineScope will also allow me to pass backgroundScope from inside

TestScope

if that’s what I need to use. With your impl that would make it harder no?