Hi @AndroidDevelopers , We are using compose for our application , we are group of 6 engineers working on the app, from all around the world, Our app is having very laggy behavior and need your help if you can so that we can follow the best practices, we have developed very big app on the compose and as we can see the laggy behavior, we are scratching our head, We have used good compose practice everything is in small set of composables, we using states, we are using coroutines, Can you please help us, is there any way we can get over a call, for some help
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!!!❤
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?
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!
Hoisting to the VM is fine, if you need to apply business logic to the TextField state for sure. But be careful as currently we do not recommend using a reactive stream (such as StateFlow) to represent the textfield. consider using mutable state in the viewmodel and avoid async validations. The full explanation is described in this blog medium.com/androiddevelopers/effective-state-management-for-textfield-in-compose-d6e5b070fbe5
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!!!!
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?
For sure! That's actually the simplest way as per developer.android.com/jetpack/compose/state#ways-to-store In the video we show an alternative using listSaver if you can't add the plugin/annotate the class for any reason.
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!
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?
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.
Very confusing as usual, Google's technologies looks like they are made on a contest of how to make things much more complex than they should. I don't need to show off how well I manage with complex technologies, I just need to be productive and make complex things simple, not otherwise. The probability of developers making mistakes are enormous using this APIs, unacceptable in my opinion.
@@kirwakelvinkering3122I agree. Once you get started with this stuff you see how it's actually pretty helpful. And yes, I agree with OP that it seems like a lot of it is pretty useless, and some of it definitely is, but a lot of other stuff definitely makes sense after a while.
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.
To learn more about what's new in Android, check out the Android Keynote at #GoogleIO → goo.gle/IO23_androidkey_pin
Hi @AndroidDevelopers , We are using compose for our application , we are group of 6 engineers working on the app, from all around the world,
Our app is having very laggy behavior and need your help if you can so that we can follow the best practices, we have developed very big app on the compose and as we can see the laggy behavior, we are scratching our head,
We have used good compose practice everything is in small set of composables, we using states, we are using coroutines,
Can you please help us, is there any way we can get over a call, for some help
Manuel: I'm Manuel - same team, same title
Manuel making use of state very well 😄
14:39 - rememberCoroutineScope
17:16 - Creating a state holder
29:46 - produceState
35:10 - derivedStateOf
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".
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!!!❤
This talk, hands down, had the best flow ever! Great job Stamato and Manuel!! 👏🏻👏🏻❤
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?
"like so" sounds so cute ))
Alejandra and Manuel thanks a lot for your work )
Great video. Good understanding of producestate,launchedeffect,coroutinescope
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!
Hoisting to the VM is fine, if you need to apply business logic to the TextField state for sure.
But be careful as currently we do not recommend using a reactive stream (such as StateFlow) to represent the textfield. consider using mutable state in the viewmodel and avoid async validations. The full explanation is described in this blog medium.com/androiddevelopers/effective-state-management-for-textfield-in-compose-d6e5b070fbe5
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!!!!
Great video!
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?
For sure! That's actually the simplest way as per developer.android.com/jetpack/compose/state#ways-to-store
In the video we show an alternative using listSaver if you can't add the plugin/annotate the class for any reason.
Thanks for sharing, it was helpful.
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!
Thank you very much.
👋🏼🇨🇴🧔🏻👍🏻🤝🏻 Estupenda información
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?
personal memo
4:03 viewModel as single source of truth
9:40 side-effect
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?
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.
Was night light activated or what?
Not very clear why derived state is used. Does the composable function recomposes if there is a calculation that checks if X>0?
Hi, 9:01, why composable functions run multiple times, please?
Very confusing as usual, Google's technologies looks like they are made on a contest of how to make things much more complex than they should. I don't need to show off how well I manage with complex technologies, I just need to be productive and make complex things simple, not otherwise. The probability of developers making mistakes are enormous using this APIs, unacceptable in my opinion.
Completely agree with you on this, as time passes, Google makes thing more and more complex, and it seems that they simply wont stop.
Ooooh no , just do more on jetpack compose first , this was really helpful😢
@@kirwakelvinkering3122I agree. Once you get started with this stuff you see how it's actually pretty helpful.
And yes, I agree with OP that it seems like a lot of it is pretty useless, and some of it definitely is, but a lot of other stuff definitely makes sense after a while.
okay then they tried to give you some value which can differentiate you from others who know only easy stuff!!!!!
Bro just tap on anything that says “Advanced” a bit later 😊
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.
I agree with most of the content of this video, but I think it needs to be corrected, especially after the middle.
Disposable Effect??????
Too small for display on a mobile device