I hope Jetpack Compose dev team will bring more amazing features in near future. Android dev love Declarative UI as iOS dev love SwiftUI. Hope they will make us surprise .
Is an all brand new way to write UI, and we need "unlearn" the view way of thinking. This isn't so straightforward as seems to be, guys! You can't just jump on to it like "just a new feature that I can grab on 15 minutes". There is a learning curve. So let's do it.
I find compose intriguing - how does it handle different screen size buckets and configuration changes? The xml system had structured folder hierarchy system for choosing the right resources based on runtime layout/dimens/etc, I'm yet to see anything with compose that addresses this? Until I see how this is handled its just not viable for me .. plus copy/pasting entire chunks of code just to preview a view - you have keep copy/pasting code each time you make a change to the composable function? The IDE needs to be as rich design system as it does for xml layouts - if that happens I'm sold on compose, until then it seems a bit rough around the edges.
@Krzysztof Dróbek I have used Compose for a while now, I see how Previews should be used, but still this should be unnecessary boilerplate - hopefully the @Preview function requirement will be removed in future updates. As for your link - that specifically deals with dimens, which is only one facet of resources (I'm sure flutter devs already do something similar already). I was talking about where layouts change based on screen size - changing a bunch of dimens doesn't cut it in a lot of use cases and is simply a limitation. The XML system was organised and structured towards mobile and tablet devices giving the developer a lot of flexbility in an intuitive way. Compose lacks this out of the box, sure you can have a screen in compose with a bunch of if/elses to lay itself out differently - but this leads to difficult to read code that can be hard to reason about and more error prone. Compose looks great for a play around right now, but currently for me the traditional View system is superior. I'll see what updates come along.
Compose looks like SwiftUI, SwiftUI looks like Flutter, Flutter looks like QtQuick, and QtQuick looks like JavaFX script. There is nothing new under the sun, just another implementation of a good idea.
..... I'd wait until 1.0.20+ for production releases .. at least some bugs will be fixed by then .. doesn't stop you develpoing now though as the api is decided for the first major release
can I write a background @Composable, that does not produce a view, but just some value? Ideally, one that could be observed like LiveData or Flow. - it could be used for control flow (better than xml Navigation) by treating the composition as a monad, effects would be wrapped to run the "first" time, one could easily revert to older state, have access to all variables, as they are just defined previously... - it could handle the only issue I have with coroutines, that you cannot re-run back from a point in past, like a Gui monad. - only limit is, that sometimes the @Compose function would have to get 'suspended' and stop running, until that part of 'decision tree' is reached...
My best guess at the answer: it is done because Google can't get its developers to concentrate on a single framework until it is really done. Either that or Product Management is deliberately pushing the engineers to put things out before they are really done -- which explains why this happens with so many of their products, not just frameworks!
LOL, we are back to the 80's where user interfaces were developed in code. Modern? There is a reason for having something like xml, json or html define a UI. The UI can be created on the fly which is useful. Creating code on the fly is possible but much more difficult if the code needs to be compiled. Imo a step backward.
Exactly flutter like syntax on kotlin. I still remember people saying flutter 's syntax is garbage its not good. Well android just went the same route 😂. Though Kotlin has more features than dart.
Please add LazyColumn cell change animation like we have with diffUtils now
I hope Jetpack Compose dev team will bring more amazing features in near future. Android dev love Declarative UI as iOS dev love SwiftUI. Hope they will make us surprise .
Who's learning Compose right now? ✋
me, Florian!
Me )
Я
I am!
this is so cool. being on react + ts this is something i would love to take up
XML never again.
Hahahahah for sure
Maintaining radio button/ checkbox state explicitly across menus and settings was always a pain..no more😭
Is an all brand new way to write UI, and we need "unlearn" the view way of thinking.
This isn't so straightforward as seems to be, guys! You can't just jump on to it like "just a new feature that I can grab on 15 minutes".
There is a learning curve. So let's do it.
Wow it's life changing !
nice, its much easier when you know flutter, I really prefer this approach than xml views
it was made for people coming from Frontend, Flutter, etc
React Native or flutter developer will love this 🙌🏻
update terus sempurnakan ui
Finally!!! this is great step forward!
I find compose intriguing - how does it handle different screen size buckets and configuration changes? The xml system had structured folder hierarchy system for choosing the right resources based on runtime layout/dimens/etc, I'm yet to see anything with compose that addresses this? Until I see how this is handled its just not viable for me .. plus copy/pasting entire chunks of code just to preview a view - you have keep copy/pasting code each time you make a change to the composable function? The IDE needs to be as rich design system as it does for xml layouts - if that happens I'm sold on compose, until then it seems a bit rough around the edges.
@Krzysztof Dróbek I have used Compose for a while now, I see how Previews should be used, but still this should be unnecessary boilerplate - hopefully the @Preview function requirement will be removed in future updates. As for your link - that specifically deals with dimens, which is only one facet of resources (I'm sure flutter devs already do something similar already). I was talking about where layouts change based on screen size - changing a bunch of dimens doesn't cut it in a lot of use cases and is simply a limitation. The XML system was organised and structured towards mobile and tablet devices giving the developer a lot of flexbility in an intuitive way. Compose lacks this out of the box, sure you can have a screen in compose with a bunch of if/elses to lay itself out differently - but this leads to difficult to read code that can be hard to reason about and more error prone. Compose looks great for a play around right now, but currently for me the traditional View system is superior. I'll see what updates come along.
this is gorgeous!
Looking forward to it :)
Any fixes regarding multiple sheets within ModalBottomSheetLayout yet?
Can you suggest best source to learn jetpack compose
BottomSheetScaffold with composables with different states?
@@sahil-dq9cy They have pathway on site visit official site
@@hit_the_luddy No, ModalBottomSheetLayout :)
Большое спасибо автору, классное видео)
...wait! Is it Flutter? I can see "Column", "Text" widgets... My mind is spinning .....
Same developers, almost same product
Compose looks like SwiftUI, SwiftUI looks like Flutter, Flutter looks like QtQuick, and QtQuick looks like JavaFX script. There is nothing new under the sun, just another implementation of a good idea.
Effortless waiting for a Menu with options "Migrate Xml to Compose".. Press and wala.. all converted!!😁😁😁😁... Deja-Vu... like migrate to AndroidX
ต
finally! future is coming!) compose + kotlin multiplatform mobile = will be best multiplatform solution ever!
@Палмер Элдрич why? can you tell me why and what's good solution on it? i'm web developer trying to learn android right now so idk about that
How is composable compared to flutter's widget?
faster?? :))))) I hardly think so. Why did Android need a new UI toolkit? So that we can make developers busy
Nerver back to XML 😎
Was skeptical on Compose until I tried it, no Dev can resist compose.
@Палмер Элдрич Let's talk in an year's time ...
How does it make the xml and drag and drop method in the layout editor less good?
When will version 1 come to life?, and should I use Compose in a real production app now?
It's been out for 3 years as they mentioned, which means the library is stable to use in production now
July
..... I'd wait until 1.0.20+ for production releases .. at least some bugs will be fixed by then .. doesn't stop you develpoing now though as the api is decided for the first major release
@@MK-to4et I am also waiting for it. Next month
So does Jetpack Compose make MVVM obsolete already? Or can we count on Compose to go the way of JavaFX, which is/was also 'declarative'?
I think the only that deprecate is binding but MVVM remain useful as in some samples with compose it is still used
Thanks for sharing
Can this support RXJava?
wait ?? , just LazyColumn , one line of code to replace recyclerView 😭
can I write a background @Composable, that does not produce a view, but just some value? Ideally, one that could be observed like LiveData or Flow.
- it could be used for control flow (better than xml Navigation) by treating the composition as a monad, effects would be wrapped to run the "first" time, one could easily revert to older state, have access to all variables, as they are just defined previously...
- it could handle the only issue I have with coroutines, that you cannot re-run back from a point in past, like a Gui monad.
- only limit is, that sometimes the @Compose function would have to get 'suspended' and stop running, until that part of 'decision tree' is reached...
essentially: can it be used for generic backtracking?
Yes just create a function that return a value but still annotated with @Composable
@@OliverRhyme Awesome! Thanks for telling me. - I'm looking forward to explore it more, once I have some free time!
great feature, looking forward to dive
眼睛不知所措，不知道是该看代码还是该看翻译的汉字🤣
Inspired by flutter 😄
5:40
it's basically flutter widgets on android...
Why you make too many frameworks instead of concentrating on one framework? We have old way to create apps, flutter and now this.
My best guess at the answer: it is done because Google can't get its developers to concentrate on a single framework until it is really done. Either that or Product Management is deliberately pushing the engineers to put things out before they are really done -- which explains why this happens with so many of their products, not just frameworks!
LOL, we are back to the 80's where user interfaces were developed in code. Modern? There is a reason for having something like xml, json or html define a UI. The UI can be created on the fly which is useful. Creating code on the fly is possible but much more difficult if the code needs to be compiled. Imo a step backward.
So it's Flutter running on Kotlin.
Nice to have but Dart is still nicer.
Exactly flutter like syntax on kotlin.
I still remember people saying flutter 's syntax is garbage its not good.
Well android just went the same route 😂.
Though Kotlin has more features than dart.
does jetpack compose works with android TV ?
reminds me of react, worth a try a guess
👍👍❤❇
Row, Column and ... Box? Why not call it Stack/VStack?
They don't want to copy SwiftUI that much :D
Why call it Stack or ugly VStack? You're clearly influenced by something and try to pass it as a common sense.
Well maybe, it sounds interesting anyways and doesn’t make compose less exciting. Thanks for replies guys
kotlíìn
How many of you love XML over Compose ?
Thank f**k compose is here. It was an absolute torment to code in native android.
Its like we're going back to 2001. Ugh
Good bye XML