anyone got opinion on this style of api? where service has its own scope so doSomething doesnt get c...

# coroutines

[ursus]

anyone got opinion on this style of api? where service has its own scope so doSomething doesnt get canceled then callsite scope does

[elizarov]

But why?

[streetsofboston]

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.

[ursus]

@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

[Antanas A.]

you can just write

suspend fun doSomething3(): String = scoped {
        delay(2000)
        Log.d("Default", "returning something")
        "Something" //<- no need return for closures
    }

[Antanas A.]

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)

[Antanas A.]

So by default withContext(scope) { ... } call will be detached from your callee's coroutine and be non cancellable by parent