Great presentation. I like the cristal clear workshop, common developer errors, and dynamism of the presentation. I am impatient to see another presentation like this, based on codelabs.
Happy to hear that the tutorial was helpful, Chti. You can also check out the codelab for Using state in Jetpack Compose, as seen in the video here: goo.gle/3ssNnBO
Happy to hear the tutorial was helpful, Jahangir. You can also check out the following link to follow along with our Jetpack Compose codelab: goo.gle/3ssNnBO
Great job! I've been getting even more out of the codelabs that have this type of presentation. It helps to draw attention to the important details in the step by step guide. Keep it up!
We're delighted to know you enjoyed this video from Alejandra and Manuel! We love hearing feedback from our community members 🙂 If you liked this, don't forget to check out more Google I/O 2022 Sessions linked below → goo.gle/IO22_AllSessions
We're happy to know this lesson from Alejandra and Manuel provided some helpful guidance. If you are interested in learning more check out these awesome guides: developer.android.com/jetpack/getting-started
Glad to hear you found the video helpful, Harsh 🙂 You can also check out the following link to follow along with our Jetpack Compose codelab: goo.gle/3ssNnBO
After working 6 months in compose. Today I Understand how to properly handle UI state in Compose . Thanks to the dev team 👍. Previously I violate the single source of truth by passing ViewModel down to composables.
Jetpack Compose is like a sponge. There are so many wonderful features that you can absorb just like water! Want to learn more? Check here: goo.gle/3rBdmWO 🧽
My big state-related question: What about remembering state across invocations of the application? Is there a clean way to do that? My reasoning: 1. `rememberSaveable` will persist the state across screen rotations 2. The way `rememberSaveable` works is to persist the data to a bundle 3. Persisting to a bundle should also work across application restarts - but the framework does not do this for us I know I could go all the way to using a full database which I store the state in... but this is more complex than you might initially think! For example, if I have a call to `mutableStateOf()` in a function which is called via two separate paths, Compose will correctly create two separate state vars, and I don't have to think about it. So if I wanted to store state in a database, I'd have to have some way to generate a sensible key for the state. But implementing that myself requires somehow knowing Compose internals, and I'm not even sure how to do that reliably. Also consider what happens if a new version of the application comes out, where the path to the state changes. :( _Ideally_, `rememberSaveable` would just do this for us without having to write anything else. But it doesn't, so what should we be doing?
Great question and we're happy to share some insight! Live templates allow you to enter code snippets for fast insertion and completion of small chunks of code. They're great for saving time when you have a lot of repeating code you're needing to write ⏰ You can learn more here: goo.gle/3MRH17L
We have so many amazing resources for Jetpack Compose, and we can't wait to share them with you all! Check out our course here: goo.gle/compose-pathway All aboard the learning train 🚂
@@AndroidDevelopers Yah, I've already completed the codelab and am using it as my reference for my new Android role in an eCommerce business. Looking forward to see more great features from Compose.
val count: MutableState = mutableStateOf(0) Here, mutableStateOf(0) was showing error, that is why used direct val count = remeber { mutableStateOf(0) } then it worked correctly
Thank you so much for your feedback, Tom! We appreciate it! And of course you can also check out our State in Jetpack Compose Codelab for a more hands-on tutorial, here 😄 → goo.gle/3JVtzOP
Thanks guys! One question: which one should we use from these two?: - LiveData in the ViewModel with `val state by viewModel.liveData.observeAsState()` in the Composable? - or a MutableState like `var state by mutableStateOf(value)` directly in the ViewModel?
Nice workshop! I am very eager to convert the existing codebase with composable functions, the only thing stopping is the backward compatibility, our app supports min SDK 16 and compose works from SDK 21 ☹
This is a great question! You should use rememberSaveable if that's what your UX requires, as it creates a persistent source of truth, it really does depend on your usecase. There might be cases where you might not want to restore the screen to what it used to be. Also, creating Savers for some objects might not be trivial and it becomes a bit boilerplate-y.
Lets assume we are building a bank managemnt system , a user logs in , and the login details should be made available to all the screens in the app, when a user sends the app yo the background , he/she is logged out due to the sensitivity of the app ,how can we acheive this ?
How about if we change the screen from portrait to landscape with some checked tasks and then try to check new tasks with landscape screen if we go back to portrait mode why we lose the checked tasks after screen rotation? N.B: I used the rememberSabeable lambda also.
Couldn't you explain please. Why remember api doesn't working as rememberSaveable by default? Is it really so possible to score memory critically that it is necessary to separate? Maybe yes and good practice to separate api, a know it. But i'm interested)
This is a great video, and much more informative and interesting than the code labs due to your recommendations, tips, key concepts etc. Also code labs are boring and you too are the opposite. Its fun to watch with a mega pint of coffee.
Hi, great video. I have a question for the codelab in migrating check state. Why we need to change data class to regular class? How about like this? Thanks! data class WellnessTask(val id: Int, val label: String, var initialChecked: Boolean = false) { var checked by mutableStateOf(initialChecked) }
Hi! The viewModel() documentation says that it: Returns an existing ViewModel or creates a new one in the given owner (usually, a fragment or an activity). So if my screens all live inside the same Activity would this mean that, after instantiating several screens, all those ViewModels are also instantiated and kept around while the Activity is still active? Is this efficient?
We are having a lot of problems syncronizing the dependencies ,can you help us come up with a way, just as in the spring boot initializer to create an app and include all dependecies without any conflicts ,thanks you so much .
@@saidooubella I came from Java mindset, what I confused is why not use it directly from "import" keyword. Companion is equivalent as static in Java, right?
Kind of, it's just up to you to make them either stateless or stateful. In Flutter it's forced through inheriting the StatelessWidget or StatefulWidget IMO.
In the documentation it mention that we will need to add this to the build.gradle "implementation "androidx.lifecycle:lifecycle-viewmodel-compose:2.6.1" but is not working. You will get the following error message "Duplicate class kotlin.internal.jdk7.JDK7PlatformImplementations$ReflectSdkVersion found in modules kotlin-stdlib-1.8.10"
8:34 its not a religion to believe ! add in Text() ", color= colorResource(getColorR()" and a function outside the scope: private fun getColorR():Int{ val color:Int = Random.nextInt(4) var result_:Int=0 when (color) { 0 -> result_=R.color.teal_700 1 -> result_=R.color.teal_200 2 -> result_=R.color.purple_200 3 -> result_=R.color.purple_500 } return result_ } And you gonna see how Text redraws itself by button click
What I have to do if i want to use the texfield value and want to change its state outside the function. I have done it by returning the String from the textfield that is initialized as the variable that stores the remember savable I have returned it but my app is crashing..🥲🥲
