Advanced state and side effects in Jetpack Compose

In this workshop you will learn advanced concepts related to State and Side Effects APIs in Jetpack Compose. We'll see how to create a state holder for stateful composables whose logic isn't trivial and how to create coroutines and call suspend functions from Compose code. We'll learn what are side effects, and different APIs, like LaunchedEffect and rememberUpdatedState, to trigger them and accomplish different use cases.

Resources:

Speakers: Alejandra Stamato, Manuel Vicente Vivo

Watch more:

#GoogleIO#Featured #AndroidDevelopers #JetpackCompose

[AmitJayant]

Manuel: I'm Manuel - same team, same title
Manuel making use of state very well 😄

[frankensteingodzilla]

14:39 - rememberCoroutineScope
17:16 - Creating a state holder
29:46 - produceState
35:10 - derivedStateOf

[gorudonu]

I wonder how people who's written this code didn't look at it and said "this is way too over engineered, we should step back and think it over".

[technophile_]

This talk, hands down, had the best flow ever! Great job Stamato and Manuel!! 👏🏻👏🏻❤

[tch.]

Thank you very much.
That video was so important😊!!
The new thing for me that I was searching for was the Saver for the rememberSaveable to survive configuration changes with my own non primitive type.
I built a very buteful and customized calendar and needed that.
Thank you!!!❤

[abhijeetsingh]

Launched effect do get re-triggered when holding fragment is replaced. A to B and back to A. Is it still the best place to make network call?

[carlosdiestro]

Awesome guys! That was really helpful! I have a question though regarding the section for the InputText and its State:
What are the differences between creating and declaring the state for the composable the way you do in the video and providing the state through the viewmodel? Being more specific:
- Having a screen state in the viewmodel (as a data class and then wrapped with StateFlow) composed of the input text and hint
- Collecting that state in the screen with the collectAsStateWithLifecycle API and passing the corresponding arguments to the InputText composable
- Using an event call to the viewmodel to update the input text (this will call _state.update and make a copy of the screen state updating the value for input text)

Is it a better practice to do it the way you show in the video when the information of that composable isn't dependable on the domain/data layer? However, this option delegates more "thinking" work to the UI rather than keeping it "dumb". What are your views about this?

Thanks in advance and keep up the good work!

[ellasaro]

Hi! There is something that I can't quite get my head around. In step six, when talking about LaunchedEffect vs rememberCoroutineScope, it reads: "LaunchedEffect guarantees that the side-effect will be executed when the call to that composable makes it into the Composition. If you use rememberCoroutineScope and scope.launch in the body of the LandingScreen, the coroutine will be executed every time LandingScreen is called by Compose regardless of whether that call makes it into the Composition or not." - What would be the case for a Composable to be called but not "making it into the Composition"? Can a Composable function be called but not end up in the UI? How so? Thanks!

[McMouse]

"like so" sounds so cute ))
Alejandra and Manuel thanks a lot for your work )

[JerryStephenson-un]

Great video!
In the section about saving the input state you implemented a custom saver in the state object and use that in rememberSaveable. One way that I have approached this in the past is to make the state object parcelable using the kotlinx parcelize annotation. From that point I just have the initialization of this object wrapped in rememberSaveable and it is restored as expected through process death configuration changes. What are the benefits of creating a custom saver versus this other approach? Are they both valid or is the parcelable approach I described not as beneifical?

[nzdas]

In the ToDestinationUserInput composable I'm wondering why you chose to trigger a side effect to call the onToDestinationChanged lambda. Is there a reason why you can't simply use an if statement that invokes the lambda when the text is not the hint?

[dmorales]

Muchas gracias por la informacion. Han dado el panorama completo de los efectos secundarios y estados avanzados, vi el codelab y me mareaba, viendo el video, fue como decimos aca en Peru, "directo a la vena", mucho mas didactico. Ya le toca a cad auno profundizar mas y ponerlos en practica. Muchas gracias!!!!

[hansonhuang]

I'm confused about this bit, in which scenario that 'onTimeout' would be changed? feel like in practice, this lambda function would barely be changed. so didn't get the point of using "val currentOnTimeout by rememberUpdatedState(onTimeout)", which makes it look like that onTimeout would be changed quite often. Just wondering the scenarios? Thanks.

[frankensteingodzilla]

Hi, 9:01, why composable functions run multiple times, please?

[chandra_]

Great video. Good understanding of producestate, launchedeffect, coroutinescope

[leandroperalta]

Gracias gente! Me llevo algunos conceptos nuevos después de ver este video. Muy bien por mencionar España y Argentina durante el tutorial. 😄Existe algún otro video o CodeLab que explique como escribir tests para este tipo de implementación?

[frankpickerson]

Not very clear why derived state is used. Does the composable function recomposes if there is a calculation that checks if X>0?

[GTEK]

personal memo

4:03 viewModel as single source of truth

9:40 side-effect

[cetateanturmentat]

I would really love to see how it compares with a different approach and why we should really use these. Crane app si a bad example, too big, too much noise. Less code but more examples would work better. I am still not very sure why would I use most of these.
1. "Consuming a Flow safely..." what's the unsafe way? Why it is unsafe? What "safe" actually means in this context?
2. Side effects seem more like an after thought than something organic. I try to avoid them as much as I can but maybe I'm wrong. Nevertheless this didn't quite help clarifying it.
3. The language is very dogmatic: "better approach" but why? "safer" but why? Not very scientific. Sounds like an advertisement to me. Works for IO but if you really try learn things... go figure.

[skarloti]

I agree with most of the content of this video, but I think it needs to be corrected, especially after the middle.