Yes. Absolutely- and as usual, you've helped me enter "A Compose State Of Mind".... Thank You for walking me through, as running through important steps is always a waste of time.
parts of this are useful, but many more are not explained enough or with real examples. very convoluted. hopefully the codelab will make stuff clearer.
Passing parameters to remember() (see code around 14:00) means that JetsnackAppState will be reset whenever any of its dependencies changes, right? It also won't survive configuration change or process recreation. Can lead to bugs if JetsnackAppState contains its own (not derived from dependencies) state.
Hi! Yeah, that's the idea, generally, you want to recreate the state holder if the dependencies change. If you don't do that, you might be using old instances of certain types that could potentially lead to memory leaks. As mentioned in your other comment, use `rememberSaveable` to make state survive config changes or process recreation
When LazyList's scroll position and expanded items are stored in CartState (19:09), they will be cleared on navigating to another screen & back, correct? That won't look good from UX perspective.
Hello! `collectAsState` is remembered and it's not re-executed on every recomposition. New values emitted into the flow will cause recompositions though. Hope this clarifies few things!
The composable function will only be recomposed when the collectAsState() value changes, Compose is smart enough to skip recomposing parts of the UI where the states did not change.
This doesnt seemed to follow OOP principle at all with all those remember keywords. It is a function that magically store state somewhere you dont know using remember keyword. Flutter does this cleanly with widget as object instead of function.
Compose is comparable to using XML / Data binding, UI frameworks do not benefit at all from object-oriented programming. I'm glad Google realized this and made Compose fully declarative. You might have a point with the "magic" remember keyword, but you do not have to use it, just can also put your state in a view model, it is only a convenience feature to make things simpler.
The code passed in the lambda to the remember function is executed only on initial composition, and not in re-composition, unless the any of the optional key parameters to the remember function have changed, which will cause the lambda to be re-executed.
![[ENGSUB] UNPRODUCTIVE DAY ใช้ชีวิต (เปื่อยๆ) ด้วยกัน 1 วัน! | OUROAD CLOSEFRiEND SS2 EP.9](http://i.ytimg.com/vi/pyYKZ3kra9w/mqdefault.jpg)
Amazing video. He has a deep understanding of the subject and because of that he can transform his knowledge. Give him a raise ❤
Every important aspects of compose in one video, excellent work and clear explanations. Thank you so much ❤❤
Amazing presentation. one of the best I've seen from Android Developers channel. please make more videos like this.
Very good video. Docs on state hoisting in compose are lacking real life examples and this video clarify some concepts. Thanks!
Yes. Absolutely- and as usual, you've helped me enter "A Compose State Of Mind".... Thank You for walking me through, as running through important steps is always a waste of time.
parts of this are useful, but many more are not explained enough or with real examples. very convoluted. hopefully the codelab will make stuff clearer.
salamat ss palabas na ito ang ganda pakingan
awesome presentation, thanks a lot
Great stuff! These tutorials are essential for getting into this complete new way of doing things. So plz keep it up
Good job
17:58 He means the DI library Hilt not Field
“Simplicity is the soul of efficiency.” - Austin Freeman. It would be great if you show some coding tutorials to clearly understand the concepts.
Preview isn't drawn when viewModel has some params. Did anyone have this issue?
I 'm still confusing about UI-element state vs screen state
Hello, Nguyên! Take a look at the link below for more information about UI layers.
goo.gle/3uXxOTP
We hope this helps!
Passing parameters to remember() (see code around 14:00) means that JetsnackAppState will be reset whenever any of its dependencies changes, right? It also won't survive configuration change or process recreation. Can lead to bugs if JetsnackAppState contains its own (not derived from dependencies) state.
Hi! Yeah, that's the idea, generally, you want to recreate the state holder if the dependencies change. If you don't do that, you might be using old instances of certain types that could potentially lead to memory leaks. As mentioned in your other comment, use `rememberSaveable` to make state survive config changes or process recreation
If I want to tracked an image not a number, how do I do?
I'm excited to learn this framework so that I too can charge people $12.99 for an ice cream sandwich.
When LazyList's scroll position and expanded items are stored in CartState (19:09), they will be cleared on navigating to another screen & back, correct? That won't look good from UX perspective.
You can `rememberSaveable` CartState if there's data you want to preserve across process and activity recreation
@@manuelvicnt Thanks for clarification. But fragment's view is also destroyed while in the back stack, AFAIK. What about Compose & its state?
@@gmk57 Compose rememberSaveable states are saved on the Fragment/Activity saved instance bundle, on the same place where onSaveInstanceState is used
Is it a good idea to call collectAsState() inside a composable function (17:05)? This conversion function will be re-executed on every recomposition.
Hello! `collectAsState` is remembered and it's not re-executed on every recomposition. New values emitted into the flow will cause recompositions though. Hope this clarifies few things!
@@manuelvicnt por que
Kaon sc7210
The composable function will only be recomposed when the collectAsState() value changes, Compose is smart enough to skip recomposing parts of the UI where the states did not change.
All I want is the nav controller availability in vm :(
its ok
牛蛙牛蛙
This doesnt seemed to follow OOP principle at all with all those remember keywords. It is a function that magically store state somewhere you dont know using remember keyword. Flutter does this cleanly with widget as object instead of function.
Compose is not OO, it's declarative programming. OOP principles are irrelevant here.
Compose is comparable to using XML / Data binding, UI frameworks do not benefit at all from object-oriented programming. I'm glad Google realized this and made Compose fully declarative. You might have a point with the "magic" remember keyword, but you do not have to use it, just can also put your state in a view model, it is only a convenience feature to make things simpler.
The code passed in the lambda to the remember function is executed only on initial composition, and not in re-composition, unless the any of the optional key parameters to the remember function have changed, which will cause the lambda to be re-executed.
OOP is not a principal tho, it is a one type of paradigm in a programming languages