Summary: Emphasise on 'what' rather 'how'. Declarative way of building the UI. The UI element state is defined by the argument we pass them. We can create UI entirely in Kotlin. Avoids errors that were coming in xml Ui due to conflicting view updates. In compose, the creation of UI happens in same fashion as in xml. UI elements are functions and not objects. Recomposition - the process of regenerating the UI when state changes.
This is a very well written episode, like there's a lot of quite complicated terminology here esp. for noobs but you have made it very easy to understand, so thanks!
One of our goals with these videos is to make it easy for everyone to understand, so this is awesome feedback to get! Everyone has to start somewhere, and we are here to help with the journey 🙌🏼 You can check out all our other MAD Skills episodes here: goo.gle/madskills
@@AndroidDevelopersI got to say, i tried reading UIKIT documentation, and it was complicated. Android team, on the other hand gives examples, so that we can better understand what is going on. For example, when you explained what a Scheduler for background task is, such as invoking email screen inside another app, you gave an example, and not just a technical text. For that alone, I switched to developing for Android. THank you Android team. Continue explaining stuff like this, and never assume that your readers are familiars with concepts. Always give examples, this makes it for us, developers much easier to understand how to do certain things
Seconding @SoulRepaerDan1 here. I've fallen into a black hole of views bugs. I wish Android Studio interface presented descriptions and explanation this clearly.
Thanks Google devs! Watching this to supplement my learning of the Android with Kotlin Nanodegree at Udacity! Nice to learn about Jetpack Compose! Hope the Nanodegree gets updated at some point (or rather soon as I am doing it now 😉).
I would like to know when you guys plan to support better: - Webviews. - Fingerprint. - Permissions. Web views with accompanist is incomplete and full of issues
No xml, great. No internal state to worry about, great. Some things that sound a little off though: stating that there is no need for findViewById seems a little weird. No one uses that anymore. Also, with the Views framework, when a radio button is selected, you would notify the ViewModel about a new selected choice, who would then emit an observable value indicating that the Next button should be enabled. Presenting that scenario as problematic sounds like those fake ads where people are trying to open a milk carton and they suddenly rip it in half cause they don't have the right tool. For the most part, Compose looks good so far.
Delighted to hear this tutorial was helpful, Manshal. To get started with Jetpack Compose, check out the Compose Learning Pathways here: goo.gle/compose-pathway or the Jetpack Compose tutorial: goo.gle/3S2IUzT 👍
You're purposely misrepresenting *your own* standard practices. No one uses find view by id. Viewbinding or data binding what does all what compose do but with way better preview options. Compose is actively encouraging high coupling of UI and business logic. Not a good option 👎
Why Android sucks? Because they first invented XML UI to separate UI from coding. And now they are putting UI into code? Why they often change the way of coding. Tomorrow they will again say, no no the XML UI way is good. And there will be no end. Well, as I understood by stepping into Android Developoment, I find basically the whole Android Development system is a mess. Problem is in Android the Learning Curve is not fixed. Today you devote your time of learning some tool or way of coding and tomorrow you come to know that the stuff you were learning is now obsolete or deprecated. There is no fixed way. Again learn new way. And again after some time the current new way will become obsolete or deprecated. And so Android sucks. Simply put, there is no fixed way to learn. For example, can you simply tell me if MVVM architecture is good or MVI? No fixed answer, right? That's Android.
Let me tell you coming from Unity Game Dev its the same. I also dabbled in web dev and its the same. And with Android it does seem like its on another level which I contribute to simple fact; you gotta keep the many many devs they have employed... well employed. This is why keep inventing things since they have really not much to do once the whole framework has been done. I dont mind them adding new ways as long as the old way is still supported. Funny enough Unity added css style UI toolkit but I find their first one actually much better even compared to Android Layouts Xml. Its really easy to use and understand and to dock an UI element wherever you want and it scales up with screen size without fault.
![Build a TikTok Clone in React Native and AWS Backend [Tutorial for Beginners] 🔴](http://i.ytimg.com/vi/7okW52MQgSE/mqdefault.jpg)
Thanks to Google devs team 😘 for making Android development easier.
Thank you for the kind feedback, Mikhail! If you're interested in learning more, check out the Compose Learning Pathways here: goo.gle/compose-pathway
@@AndroidDevelopers 你是哪个现实来的官方🤔
Summary:
Emphasise on 'what' rather 'how'.
Declarative way of building the UI.
The UI element state is defined by the argument we pass them.
We can create UI entirely in Kotlin.
Avoids errors that were coming in xml Ui due to conflicting view updates.
In compose, the creation of UI happens in same fashion as in xml.
UI elements are functions and not objects.
Recomposition - the process of regenerating the UI when state changes.
This is a very well written episode, like there's a lot of quite complicated terminology here esp. for noobs but you have made it very easy to understand, so thanks!
One of our goals with these videos is to make it easy for everyone to understand, so this is awesome feedback to get! Everyone has to start somewhere, and we are here to help with the journey 🙌🏼
You can check out all our other MAD Skills episodes here: goo.gle/madskills
@@AndroidDevelopersI got to say, i tried reading UIKIT documentation, and it was complicated. Android team, on the other hand gives examples, so that we can better understand what is going on. For example, when you explained what a Scheduler for background task is, such as invoking email screen inside another app, you gave an example, and not just a technical text. For that alone, I switched to developing for Android. THank you Android team. Continue explaining stuff like this, and never assume that your readers are familiars with concepts. Always give examples, this makes it for us, developers much easier to understand how to do certain things
Seconding @SoulRepaerDan1 here. I've fallen into a black hole of views bugs. I wish Android Studio interface presented descriptions and explanation this clearly.
Thanks Google devs! Watching this to supplement my learning of the Android with Kotlin Nanodegree at Udacity! Nice to learn about Jetpack Compose! Hope the Nanodegree gets updated at some point (or rather soon as I am doing it now 😉).
I'm glad I can hear because following these videos without sound is horrific.
You need to create a room code lab in compose, that would help a huge lot. For the nubes like myself.
room has nothing to do with ui
³
I would like to know when you guys plan to support better:
- Webviews.
- Fingerprint.
- Permissions.
Web views with accompanist is incomplete and full of issues
No xml, great. No internal state to worry about, great. Some things that sound a little off though: stating that there is no need for findViewById seems a little weird. No one uses that anymore. Also, with the Views framework, when a radio button is selected, you would notify the ViewModel about a new selected choice, who would then emit an observable value indicating that the Next button should be enabled. Presenting that scenario as problematic sounds like those fake ads where people are trying to open a milk carton and they suddenly rip it in half cause they don't have the right tool. For the most part, Compose looks good so far.
😮 😢 BB 😮b😮 k😢😢57😢m c c torxdd😢😢😢😢😅😅😅😅😅😅😅
Why are composable functions not in lowerCamelCase? Should i use this pattern on my own composable functions?
Please make video on dagger hilt library
Can't wait for the next video. 😁
How to write custom controls UI in jetpack compose in exoplayer.??? Reply please
Compose es maravilloso!
Mulakan
0
Who decided that white text on a light blue background was a good idea?
INTUITIVE : THINKING IN COMPOSE - MAD SKILLS
Tankyou so much
Helpful
Delighted to hear this tutorial was helpful, Manshal. To get started with Jetpack Compose, check out the Compose Learning Pathways here: goo.gle/compose-pathway or the Jetpack Compose tutorial: goo.gle/3S2IUzT 👍
Declarative GUI only work for simple ui
React has been doing declarative UI for ages and it definitely scales
It's almost like flatter.
Compose gives me headaches😩
🎉 ok thanks
492nd...Thanks Chris
😎😎😎
感谢(🙏ˊᗜˋ*)
ترجم عربي كي نفهم
You're purposely misrepresenting *your own* standard practices. No one uses find view by id. Viewbinding or data binding what does all what compose do but with way better preview options. Compose is actively encouraging high coupling of UI and business logic. Not a good option 👎
ViewBindings and Data Bindings work by writing findViewById at compile time. You can also see code generated by viewBindings in the build folder.
いｊ
was monetized, so that company could aim for Nice tutorials channel to make money
but google owns yt. why would they monetise it to get money...
Why Android sucks? Because they first invented XML UI to separate UI from coding. And now they are putting UI into code? Why they often change the way of coding. Tomorrow they will again say, no no the XML UI way is good. And there will be no end.
Well, as I understood by stepping into Android Developoment, I find basically the whole Android Development system is a mess.
Problem is in Android the Learning Curve is not fixed. Today you devote your time of learning some tool or way of coding and tomorrow you come to know that the stuff you were learning is now obsolete or deprecated. There is no fixed way. Again learn new way. And again after some time the current new way will become obsolete or deprecated. And so Android sucks.
Simply put, there is no fixed way to learn. For example, can you simply tell me if MVVM architecture is good or MVI? No fixed answer, right? That's Android.
Let me tell you coming from Unity Game Dev its the same. I also dabbled in web dev and its the same. And with Android it does seem like its on another level which I contribute to simple fact; you gotta keep the many many devs they have employed... well employed. This is why keep inventing things since they have really not much to do once the whole framework has been done. I dont mind them adding new ways as long as the old way is still supported. Funny enough Unity added css style UI toolkit but I find their first one actually much better even compared to Android Layouts Xml. Its really easy to use and understand and to dock an UI element wherever you want and it scales up with screen size without fault.
That is the problem within Google too