Colton Idle
10/11/2023, 2:38 AMvar scope = CoroutineScope(Job() + dispatcher)
and then calling scope.launch {delay(...) doFoo() }
.
Isn't the whole point with coroutines that the top level caller is the one providing the scope? I feel like it's "bad" but I don't know why. Sure I can "pass" a scope in, but I think in this case, what I really want is maybe to inject the dispatcher/coroutine context (so its testable) and the app class would have it's own scope and the app class would do appScope.launch { pollingService.startPolling() }Francesc
10/11/2023, 5:09 AMSam
10/11/2023, 5:28 AMFrancesc
10/11/2023, 6:03 AMDmitry Khalanskiy [JB]
10/11/2023, 6:35 AMPollingService
uses coroutines is an implementation detail. With an interface like fun startPolling { scope.launch { ... } }
, you could easily rewrite the class to use separate threads or executors, for example. In a sense, PollingService
is something like an Actor from the actor concurrency model, not a collection of functions, and startPolling
is a command for it to, well, start polling.PollingService
to continue doing its thing? For example, if it no longer makes sense to proceed inside PollingService
after some ViewModel
gets destroyed (and its viewModelScope
gets cancelled), then yes, PollingService
should execute its tasks as part of that scope.Colton Idle
10/11/2023, 12:49 PMDmitry Khalanskiy [JB]
10/11/2023, 1:49 PMColton Idle
10/12/2023, 1:28 AM