@@debdutsaha4316 compose compiler tracks when the snapshot value is read so by passing it to lambda you actually read it in a layout stage not a composition stage and the compiler tracks it automatically. You just have to stop thinking of snapshot values as observable values but rather as values that report to the compiler at what stage they are accessed.
15:48 can you please clarify if the word "measure" on the slide at the timestamp provided is referring to the function MeasureScope.measure from interface LayoutModifier, the function measure from interface Measurable, or something else?
Don't mention it! Be sure to visit these resources to help you progress further. 😁 Compose → bit.ly/3OBebbl Jetpack Compose pathway → bit.ly/3QFlFfj Layouts in Jetpack Compose → bit.ly/3tSbjPq
It would be interesting to know how the LazyColumn works, I tried to create a custom Layout and not call the place method for those measurables that I didn't want to be displayed on the screen, but using the layout inspector there were the outlines of the measurables not placed. But I suspect it was a problem related to the animation that I had given to my component and to an inaccuracy of the inspector. So if I don't call the place method for a measurable it is actually not placed on the screen? Is there a saving of resources?
With navigation graph, you moved the fragment transaction logic from code to xml and told us that that is great. Now with compose, you are asking us to move the ui building from xml to code and telling us that this is great. I think google has so much money and resources that their teams don't know what to do and the teams there are like creating their own shiny libraries without any harmony.
You are partially right, but the point of compose is to give you a new option of building ui. You don't need to use it. You can still build with fragments and use xml but compose allows you to drop these since it's been widely known for years that the Fragment was probably the worst designed component in the system. You can just have one single activity, no fragments and perfectly usable, lightweight and fast ui.
Yes, things are changing very quickly, and this is bad :(. Developers need constantly to learn instruments instead of building features. Compose UI seems good for building *dynamic ui* when xml is only for static ui. But when you need connect all parts together (data +ui), compose is not so easy - now you should know mvvm(viewmodel), states, patterns to working with ui states (hoisting states etc), many remember* fuctions, helpers, extentions, idioms - really it's like bird language :). I think that entry level for beginners is up! I think that Google should think about good solid Android SDK, APIs, which are not quickly changing, not quickly deprecated. These APIs should be enough to develop good andtoid app from scratch (may be with little set of app external libs)
I'd rather to have an IDE to drag-and-drop UI components, then do some fine-tune by coding. Lambdas without auto-complete means we need to remember many things and hope them will remain undeprecated in the next few years...
And the point is, the gap between developers and designers is still huge. The developers need to find the balance between designers/Google's UI design/Google's UI tech. Some tools like Zeplin can generate some simple codes for developers, but I think the best way is to directly let designers be able to export UI components to the codebase, then developers can focus more on the behaviors and business logic.
HaHa， it will be too easy to develop if we can drag and drop, so more and more people can develop a app so then we can't get well paid!! Ha Ha, so it won't be better if it is so easy to develop , it need some thresholds
Why is it on your channel that the sound quality is always so terrible? :-\
5th time watching this video..every single concept blow my mind. and i think about it for hours and then watch this video again 😇😇
I looked the 3rd time :) It helps really
The part on the lambda-style animation progress value is really useful and non-obvious, thanks for that. And the rest of this great tutorial)
I am unable to figureout how this will work? After changing the state how it will change? Can you explain?
@@debdutsaha4316 compose compiler tracks when the snapshot value is read so by passing it to lambda you actually read it in a layout stage not a composition stage and the compiler tracks it automatically. You just have to stop thinking of snapshot values as observable values but rather as values that report to the compiler at what stage they are accessed.
15:48 can you please clarify if the word "measure" on the slide at the timestamp provided is referring to the function MeasureScope.measure from interface LayoutModifier, the function measure from interface Measurable, or something else?
Super great tutorial! 👍
Dear team, kindly make a functioality for smooth scrolling for two lazy column at same time
Congrats to 1 Million Subs✨✨✨
Best video of compose ever!
Great video!
thanks a lot for this deep dive!
Don't mention it! Be sure to visit these resources to help you progress further. 😁
Compose → bit.ly/3OBebbl
Jetpack Compose pathway → bit.ly/3QFlFfj
Layouts in Jetpack Compose → bit.ly/3tSbjPq
All looks and sounds great except 1 year later this is all going to end up being deprecated! 'now use this new amazing thing we just created'.
Thanks for material :)
thanks for the tutorial! now have better understading on the layout things.
Go Compose!
It would be interesting to know how the LazyColumn works, I tried to create a custom Layout and not call the place method for those measurables that I didn't want to be displayed on the screen, but using the layout inspector there were the outlines of the measurables not placed. But I suspect it was a problem related to the animation that I had given to my component and to an inaccuracy of the inspector. So if I don't call the place method for a measurable it is actually not placed on the screen? Is there a saving of resources?
why there is no doc about LazyLayout ? i need that
There is guide to Lists and Grids: developer.android.com/jetpack/compose/lists
We'll add more on building custom Lazy Layouts as support stabalizes.
A lot of engineering has gone into this framework
Thanks for the great tutorial
Thank you
Compiler Magic
With navigation graph, you moved the fragment transaction logic from code to xml and told us that that is great. Now with compose, you are asking us to move the ui building from xml to code and telling us that this is great.
I think google has so much money and resources that their teams don't know what to do and the teams there are like creating their own shiny libraries without any harmony.
You are partially right, but the point of compose is to give you a new option of building ui. You don't need to use it. You can still build with fragments and use xml but compose allows you to drop these since it's been widely known for years that the Fragment was probably the worst designed component in the system. You can just have one single activity, no fragments and perfectly usable, lightweight and fast ui.
What a fascinating & informative video! Learned a lot and it does seem very simple now.
Respectful
How to leave android development? fed up of this keep changing keep learning curve...
learn iOS development
Sooner or later they'll deprecate Android itself lol
Flutter?
Yes, things are changing very quickly, and this is bad :(. Developers need constantly to learn instruments instead of building features.
Compose UI seems good for building *dynamic ui* when xml is only for static ui. But when you need connect all parts together (data +ui), compose is not so easy - now you should know mvvm(viewmodel), states, patterns to working with ui states (hoisting states etc), many remember* fuctions, helpers, extentions, idioms - really it's like bird language :).
I think that entry level for beginners is up!
I think that Google should think about good solid Android SDK, APIs, which are not quickly changing, not quickly deprecated. These APIs should be enough to develop good andtoid app from scratch (may be with little set of app external libs)
@@visvajeet5609 iOS also moved to Swift UI so what's your point?
while creature are useful
I'd rather to have an IDE to drag-and-drop UI components, then do some fine-tune by coding. Lambdas without auto-complete means we need to remember many things and hope them will remain undeprecated in the next few years...
And the point is, the gap between developers and designers is still huge. The developers need to find the balance between designers/Google's UI design/Google's UI tech. Some tools like Zeplin can generate some simple codes for developers, but I think the best way is to directly let designers be able to export UI components to the codebase, then developers can focus more on the behaviors and business logic.
HaHa， it will be too easy to develop if we can drag and drop, so more and more people can develop a app so then we can't get well paid!! Ha Ha, so it won't be better if it is so easy to develop , it need some thresholds