https://kotlinlang.org logo
#compose
Title
# compose
a

Archie

07/22/2020, 1:35 PM
I was also wondering if it is possible to run
Coroutines
with compose?
👌 3
a

Adam Powell

07/22/2020, 1:40 PM
launchInComposition
will launch a coroutine into a scope managed by the composition. If the call leaves the composition the scope is cancelled for you. https://developer.android.com/reference/kotlin/androidx/compose/package-summary#launchincomposition
😍 1
a

Archie

07/22/2020, 1:41 PM
Wow thank you very much. I've been searching for quite a while but I didnt see this. Thanks!
👍 1
So ive tried out
launchInComposition
, now I was wondering how I could run my coroutines without it getting cancelled by device rotation similar to launching coroutines in
viewModelScope
. Is this possible?
a

Adam Powell

07/22/2020, 4:23 PM
Yes, you can still launch into a
viewModelScope
in the usual way
a

Archie

07/22/2020, 7:00 PM
That means I have to create a ViewModel luanch the coroutine inside that ViewModel with viewModelScope? correct?
a

Adam Powell

07/22/2020, 8:18 PM
For the moment anyway. I think we had a couple of compose extensions that behave similarly to the
by viewModels()
API for fragments/activities floating around but I'm not sure which things made it into the actual api just yet 🙂
😮 1
t

Timo Drick

07/22/2020, 11:27 PM
You could also just create a singleton (object) and launch your coroutine there. When you do not want to cancel it when the view gets disposed. But than you can not change the UI as an result of the execution. So it depends on what you want to do.
a

Adam Powell

07/23/2020, 12:30 AM
This is where a pattern of
launchInComposition
making suspending calls to a ViewModel makes a lot of sense
the suspend function on the viewmodel can do things like
viewModelScope.async { ... }
internally, store the
Deferred
, and return the
.await()
of that operation
then future calls can await the one that's already in progress
UI updates stay scoped to the UI, and the operation itself stays scoped elsewhere and can multiplex for multiple awaiters
t

Timo Drick

07/23/2020, 12:49 AM
In my opinion in practice often the viewmodel lifecycle is not appropriate for most operations that are not directly tied to a fragment or an activity. But yes of course now with compose we only need one activity. But than the viewmodel is at the end the same like an object?
a

Adam Powell

07/23/2020, 1:09 AM
Substitute your backing repository scope then; the key part is that you let the operation and awaiting its result happen in different scopes 🙂
tbh I find very little use for
viewModelScope
in my own code thanks to this 🤷‍♂️
a

Archie

07/23/2020, 2:43 AM
tbh I find very little use for 
viewModelScope
 in my own code thanks to this
I got confused with this. So do we need
viewModel
or not? 🤔
a

Adam Powell

07/23/2020, 3:18 AM
ViewModel itself as a transport for transformed data caches across configuration changes, sure, but the
viewModelScope
CoroutineScope I don't tend to use very often. It depends on what you want to scope and why
a

Archie

07/23/2020, 1:35 PM
For the moment anyway. I think we had a couple of compose extensions that behave similarly to the 
by viewModels()
 API for fragments/activities floating around but I'm not sure which things made it into the actual api just yet 🙂
I accidentally found this in compose:
Copy code
val mainViewModel: MainViewModel = viewModel()
where
viewModel()
is a
@Composable
function. (Thank for pointing out the existing api <3) Is it right to assume that the
ViewModel
created here is scope to the
Activity
/`Fragment` Hosting the
@Composable
function?
2 Views