maybe like this? ```suspend fun someAction() = coroutineScope { ... }```

# coroutines

[ursus]

maybe like this?

suspend fun someAction() = coroutineScope {
   ...
}

[streetsofboston]

I wrote a blog post about CoroutineScope and how to handle lifecycles with them.

Towards the end I write about how to handle communication of objects that have different lifecycles.

https://medium.com/swlh/how-can-we-use-coroutinescopes-in-kotlin-2210695f0e89?source=your_stories_page---------------------------

[ursus]

I see so
repoScope.async {}.await()
inside a suspend function

I've never seen this, is this idiomatic? (that its inside a suspend fun is what gets me)

[ursus]

backend people' coroutines are all scoped by requests right? maybe thats why Roman has never talked about this

[streetsofboston]

Yup. As soon as the requestor/client goes away, the entire request is cancelled, since no one would be interested in it anymore.

But in a few cases, even if the requestor/client goes away, the object handling the request may still be interested in it (e.g still caching a network-response even after the screen is closed by the user). There may be other use-cases.

[ursus]

yeam im just wondering why this api is not cleaner

[ursus]

feels like a afterthought

[streetsofboston]

I don’t know if it is idiomatic or not.
But in repoScope.async { doSomething() }.await() , the doSomething will not be cancelled even if the caller of repoScope.async has ended (the await() call, which will run in _caller_’s scope, will be cancelled asap).

You can hide the reposScope inside the Repo-class and make it somewhat invisible to the caller/client

[streetsofboston]

This is not a common use-case… maybe therefore it is slightly more verbous…?

[ursus]

well not common for backends, for clients this is super common

[ursus]

im wondering if its the right way to go, verzus a regular function returning Unit and executing stuff internally, and then exposing a Flow .. sort of like ViewModels already do

[ursus]

@elizarov maybe?

[ursus]

I'd argue any mutating action most likely does not want to get canceled, as opposed to reads

[streetsofboston]

Often, Repos (often ‘singletons’) don’t really have their ‘own’ lifecycle, and you could just use GlobalScope. Their lifecycle only ends when the app/process ends, not before that.

But if you have a, for example a User-Cache (that would behave like the cache with its own lifecyle that I described earlier), this user-cache’s lifecycle could end when the user logs out, zapping the cache and cancelling any related network-requests that are still queued/outstanding.

[streetsofboston]

Yup, a mutating action that is temporarily ‘queued’ (because threads are busy) is a good use-case 🙂

[ursus]

but I worry that if you remove the suspend modifier, then you lose a lot of power, like being able to handle some obscure android lifecycle where you need to block etc. (or a fcm push for example)

[ursus]

but with it its hard to reconnect with ongoing..okay im not sure anymore

[ursus]

isnt this actors? 😄