https://kotlinlang.org logo
#coroutines
Title
# coroutines
u

ursus

04/02/2020, 9:57 PM
maybe like this?
Copy code
suspend fun someAction() = coroutineScope {
   ...
}
s

streetsofboston

04/02/2020, 10:01 PM
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---------------------------
u

ursus

04/02/2020, 10:09 PM
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)
backend people' coroutines are all scoped by requests right? maybe thats why Roman has never talked about this
s

streetsofboston

04/02/2020, 10:27 PM
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.
u

ursus

04/02/2020, 10:29 PM
yeam im just wondering why this api is not cleaner
feels like a afterthought
s

streetsofboston

04/02/2020, 10:30 PM
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
This is not a common use-case… maybe therefore it is slightly more verbous…?
u

ursus

04/02/2020, 10:31 PM
well not common for backends, for clients this is super common
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
@elizarov maybe?
I'd argue any mutating action most likely does not want to get canceled, as opposed to reads
s

streetsofboston

04/02/2020, 11:03 PM
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.
Yup, a mutating action that is temporarily ‘queued’ (because threads are busy) is a good use-case 🙂
u

ursus

04/02/2020, 11:15 PM
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)
but with it its hard to reconnect with ongoing..okay im not sure anymore
isnt this actors? 😄
4 Views