anyone got opinion on this style of api? where ser...
# coroutines
anyone got opinion on this style of api? where service has its own scope so doSomething doesnt get canceled then callsite scope does
But why?
Vlastimil, correct me if I'm wrong: This code-snippet is to be expanded, adding actual network requests and keep them going so that they can be cached, even if there's no UI or other consumer listening any more.
­čĹŹ 1
@elizarov yes thats just dummy function, point is that Service has its own scope where callsite wont cancel it if they run out of their scope / get canceled -- example data sync, which writes to database for example; and callsite is viewModel, where it gets destroyed when user pressed back
you can just write
Copy code
suspend fun doSomething3(): String = scoped {
        Log.d("Default", "returning something")
        "Something" //<- no need return for closures
I think simple withContext(scope) { ... } will work for you as your scope variable contains new Job object which will be used to attach new job to, not on to callee's job (coroutine)
So by default withContext(scope) { ... } call will be detached from your callee's coroutine and be non cancellable by parent