To learn more about what's new in Android, check out the Android Keynote at #GoogleIO → goo.gle/IO23_androidkey_pin

@Himachaliyan

8 ай бұрын

Hi @AndroidDevelopers , We are using compose for our application , we are group of 6 engineers working on the app, from all around the world, Our app is having very laggy behavior and need your help if you can so that we can follow the best practices, we have developed very big app on the compose and as we can see the laggy behavior, we are scratching our head, We have used good compose practice everything is in small set of composables, we using states, we are using coroutines, Can you please help us, is there any way we can get over a call, for some help

Manuel: I'm Manuel - same team, same title Manuel making use of state very well 😄

Thank you very much. That video was so important😊!! The new thing for me that I was searching for was the Saver for the rememberSaveable to survive configuration changes with my own non primitive type. I built a very buteful and customized calendar and needed that. Thank you!!!❤

This talk, hands down, had the best flow ever! Great job Stamato and Manuel!! 👏🏻👏🏻❤

Gracias gente! Me llevo algunos conceptos nuevos después de ver este video. Muy bien por mencionar España y Argentina durante el tutorial. 😄Existe algún otro video o CodeLab que explique como escribir tests para este tipo de implementación?

Great video. Good understanding of producestate,launchedeffect,coroutinescope

Muchas gracias por la informacion. Han dado el panorama completo de los efectos secundarios y estados avanzados, vi el codelab y me mareaba, viendo el video, fue como decimos aca en Peru, "directo a la vena", mucho mas didactico. Ya le toca a cad auno profundizar mas y ponerlos en practica. Muchas gracias!!!!

Great video!

Thanks for sharing, it was helpful.

"like so" sounds so cute )) Alejandra and Manuel thanks a lot for your work )

Thank you very much.

Great video! In the section about saving the input state you implemented a custom saver in the state object and use that in rememberSaveable. One way that I have approached this in the past is to make the state object parcelable using the kotlinx parcelize annotation. From that point I just have the initialization of this object wrapped in rememberSaveable and it is restored as expected through process death configuration changes. What are the benefits of creating a custom saver versus this other approach? Are they both valid or is the parcelable approach I described not as beneifical?

@AlejandraStamato

Жыл бұрын

For sure! That's actually the simplest way as per developer.android.com/jetpack/compose/state#ways-to-store In the video we show an alternative using listSaver if you can't add the plugin/annotate the class for any reason.

Hi! There is something that I can't quite get my head around. In step six, when talking about LaunchedEffect vs rememberCoroutineScope, it reads: "LaunchedEffect guarantees that the side-effect will be executed when the call to that composable makes it into the Composition. If you use rememberCoroutineScope and scope.launch in the body of the LandingScreen, the coroutine will be executed every time LandingScreen is called by Compose regardless of whether that call makes it into the Composition or not." - What would be the case for a Composable to be called but not "making it into the Composition"? Can a Composable function be called but not end up in the UI? How so? Thanks!

Awesome guys! That was really helpful! I have a question though regarding the section for the InputText and its State: What are the differences between creating and declaring the state for the composable the way you do in the video and providing the state through the viewmodel? Being more specific: - Having a screen state in the viewmodel (as a data class and then wrapped with StateFlow) composed of the input text and hint - Collecting that state in the screen with the collectAsStateWithLifecycle API and passing the corresponding arguments to the InputText composable - Using an event call to the viewmodel to update the input text (this will call _state.update and make a copy of the screen state updating the value for input text) Is it a better practice to do it the way you show in the video when the information of that composable isn't dependable on the domain/data layer? However, this option delegates more "thinking" work to the UI rather than keeping it "dumb". What are your views about this? Thanks in advance and keep up the good work!

@AlejandraStamato

Жыл бұрын

Hoisting to the VM is fine, if you need to apply business logic to the TextField state for sure. But be careful as currently we do not recommend using a reactive stream (such as StateFlow) to represent the textfield. consider using mutable state in the viewmodel and avoid async validations. The full explanation is described in this blog medium.com/androiddevelopers/effective-state-management-for-textfield-in-compose-d6e5b070fbe5

I wonder how people who's written this code didn't look at it and said "this is way too over engineered, we should step back and think it over".

I'm confused about this bit, in which scenario that 'onTimeout' would be changed? feel like in practice, this lambda function would barely be changed. so didn't get the point of using "val currentOnTimeout by rememberUpdatedState(onTimeout)", which makes it look like that onTimeout would be changed quite often. Just wondering the scenarios? Thanks.

In the ToDestinationUserInput composable I'm wondering why you chose to trigger a side effect to call the onToDestinationChanged lambda. Is there a reason why you can't simply use an if statement that invokes the lambda when the text is not the hint?

👋🏼🇨🇴🧔🏻👍🏻🤝🏻 Estupenda información

personal memo 4:03 viewModel as single source of truth 9:40 side-effect

Hi, 9:01, why composable functions run multiple times, please?

Not very clear why derived state is used. Does the composable function recomposes if there is a calculation that checks if X>0?

Was night light activated or what?

I would really love to see how it compares with a different approach and why we should really use these. Crane app si a bad example, too big, too much noise. Less code but more examples would work better. I am still not very sure why would I use most of these. 1. "Consuming a Flow safely..." what's the unsafe way? Why it is unsafe? What "safe" actually means in this context? 2. Side effects seem more like an after thought than something organic. I try to avoid them as much as I can but maybe I'm wrong. Nevertheless this didn't quite help clarifying it. 3. The language is very dogmatic: "better approach" but why? "safer" but why? Not very scientific. Sounds like an advertisement to me. Works for IO but if you really try learn things... go figure.

Disposable Effect??????

Too small for display on a mobile device

Very confusing as usual, Google's technologies looks like they are made on a contest of how to make things much more complex than they should. I don't need to show off how well I manage with complex technologies, I just need to be productive and make complex things simple, not otherwise. The probability of developers making mistakes are enormous using this APIs, unacceptable in my opinion.

@simbelarium

10 ай бұрын

Completely agree with you on this, as time passes, Google makes thing more and more complex, and it seems that they simply wont stop.

@kirwakelvinkering3122

6 ай бұрын

Ooooh no , just do more on jetpack compose first , this was really helpful😢

@SumriseHD

6 ай бұрын

​@@kirwakelvinkering3122I agree. Once you get started with this stuff you see how it's actually pretty helpful. And yes, I agree with OP that it seems like a lot of it is pretty useless, and some of it definitely is, but a lot of other stuff definitely makes sense after a while.

@ShivamVermaokdone

3 ай бұрын

okay then they tried to give you some value which can differentiate you from others who know only easy stuff!!!!!

@techocia

Ай бұрын

Bro just tap on anything that says “Advanced” a bit later 😊