Feature Request P3
Status Update
Comments
se...@google.com <se...@google.com> #2
There are suspend functions Lifecycle.whenResumed / Lifecycle.whenStarted / Lifecycle.whenCreated / Lifecycle.whenStateAtLeast and launchWhenResumed etc are simply shortcut methods. Do they cover your usecases?
ma...@gmail.com <ma...@gmail.com> #3
I didn't know that the extensions were exposed, thanks for pointing them out :) This basically answers my initial question, because it does provide a way to access a coroutine scope tied to a lifecycle state.
Any reason why this is exposed as a coroutine scope builder rather than as a coroutine scope provider on which builders could be called?
Any reason why this is exposed as a coroutine scope builder rather than as a coroutine scope provider on which builders could be called?
se...@google.com <se...@google.com> #5
Sorry for very late reply, could you please explain a bit more what do you mean by:
Any reason why this is exposed as a coroutine scope builder rather than as a coroutine scope provider on which builders could be called?
ma...@gmail.com <ma...@gmail.com> #6
I mean rather than having:
```
lifecycleOwner.lifecycle.coroutineScope.launchWhenCreated { /* ... */ }
```
Why not let the user do something like this:
```
lifecycleOwner.lifecycle.getCoroutineScope(Lifecycle.State.CREATED).launch { /* ... */ }
```
It's more flexible because it allows any of the coroutine builders (launch, async, actor) to be called from the scope, not just launch.
```
lifecycleOwner.lifecycle.coroutineScope.launchWhenCreated { /* ... */ }
```
Why not let the user do something like this:
```
lifecycleOwner.lifecycle.getCoroutineScope(Lifecycle.State.CREATED).launch { /* ... */ }
```
It's more flexible because it allows any of the coroutine builders (launch, async, actor) to be called from the scope, not just launch.
Description
I'm wondering why not simply create properties to retrieve the coroutine scope which is tied to each one of these lifecycle states? Something like [`coroutineScopeActiveWhenCreated` `coroutineScopeActiveWhenStarted` `coroutineScopeActiveWhenResumed`] (perhaps naming could be improved, or maybe a function `coroutineScopeActiveWhenStateAtLeast`), on which the regular `launch` could be called in order to produce the same effect as these methods.
This would be more flexible, because it would make it possible to also call other coroutine builders like `async` on these scopes, opening a range of other use cases.