Am I the only person who had to turn on captions? This guy has a lovely sounding voice, but I - me, personally! - had trouble with some of his pronunciation... e.g. I had never heard of Jetmuse (i.e. Jet News). NEVERTHELESS, it is a great video with a very clear explanation. Nice.
As someone who is trying to learn Android Development, this is too over my head. It needs to be broken down more. After watching this, I still do not know what a UIState is.
When did "consume" become a synonym for "reads"? (e.g. consumes the new UI state.) Or "observable" and "exposed" for "API"? (e.g. exposed in an observable data holder.) Man, programming "terminology" evolves quicker than new programming languages!
This is all well and fine with simple examples. But what if the UI state is more complex, for example with lists of objects containing other lists or even maps. Managing this with immutable data classes results in rather complex nested .copy() operations. What would be a best practice to break this up?
If you do the threading right, you won't have any negative impact on the performance. When you have a complex UI state, the complexity should be moved over to the domain layer (or even data layer) and you should be exposing multiple data sources to the ViewModel and just collect them as needed. However, you should be able to figure out the minor tweaks you need to do in order to match your own requirements and make your UI state more manageable. I would say that they just want to emphasize, through these simple examples, what is the best approach to make your app bulletproof and bug-free considering the platform limitations. If you ever encountered an Android app codebase that did not have an architectural rules and the state was managed everywhere across the codebase, you probably had lots of subtle issues that were not that easy to reproduce and that is something they are trying to help us with.
@@martinmihalic8612 Thanks, your response got me thinking. I may not yet fully embrace the role of my ViewModel classes. Perhaps I'm enforcing too much of the domain relations onto the ViewModel classes.
It's considered UI as its only purpose should be to display state accordingly, not manage it (which is a fundamental root cause to Android app performance, and state management issues [multiple source of truths]). Your "main function" in Android is actually your Application class, not Activities. Retrieving and transforming state for display should be delegated to state holders. Resist the temptation to operate on data in your Activities and Fragments. The most you should do, is use it as common source (if you hoist state), to pass down callbacks from your state holders. If you need Context, look to your Application Context. These updated series of videos and documentation explains it all very well. Adopting UDF principles has been the direction the Android team has been heading since they took a stance on Architecture back when they launched Architecture components.
I think the better practice is should replace StateFlow by LiveData, because the StateFlow doesn't keep the last value of state or IU data like LiveData
@@sysadm85 sorry, i think there is my mistake. When restart fragment, the state flow will be initialized again, it will not keep the previous data. Anyway, it will be re-updated when re-fetching data and being observed inside lifecycle scope block.
After watching about 2 hours of videos, yours is the one that finally makes me understand the purpose of ViewModel. Thanks!
Great video! Nice Kurzgesagt easter-egg by the way!
Rocking the kurzgesagt shirt :D
another fan of Kurzgesagt! ❤️😄😄👏👏👏
Nobody noticing the Kurzgesagt Merch? Ten points for Gryffindor, my friend! :D
what does Kurzgesagt have to do with Harry Potter?
I was confused by View and ViewModel and Model but now it's so nicely explained that I can say that I finally get it, thank you!
Tj's speaks so lovely. Thanks for this tip Cheers :D
Am I the only person who had to turn on captions? This guy has a lovely sounding voice, but I - me, personally! - had trouble with some of his pronunciation... e.g. I had never heard of Jetmuse (i.e. Jet News). NEVERTHELESS, it is a great video with a very clear explanation. Nice.
Great series. Will you guys cover the Domain layer?
Yes! It's coming soon :)
It's here :) ua-cam.com/video/gIhjCh3U88I/v-deo.html
Thanks for these series of videos. they are indeed very useful to understand all the concepts in App Architecture.
You should also talk about navigation at some point ...
As someone who is trying to learn Android Development, this is too over my head. It needs to be broken down more. After watching this, I still do not know what a UIState is.
Nice, I hope there will be a code lab for after this series
Oh!!!!! I Really Understand!!!
Those architecture videos are very interesting! Thanks!
Domain Layer. When?
When did "consume" become a synonym for "reads"? (e.g. consumes the new UI state.) Or "observable" and "exposed" for "API"? (e.g. exposed in an observable data holder.) Man, programming "terminology" evolves quicker than new programming languages!
This is all well and fine with simple examples. But what if the UI state is more complex, for example with lists of objects containing other lists or even maps. Managing this with immutable data classes results in rather complex nested .copy() operations. What would be a best practice to break this up?
If you do the threading right, you won't have any negative impact on the performance. When you have a complex UI state, the complexity should be moved over to the domain layer (or even data layer) and you should be exposing multiple data sources to the ViewModel and just collect them as needed. However, you should be able to figure out the minor tweaks you need to do in order to match your own requirements and make your UI state more manageable.
I would say that they just want to emphasize, through these simple examples, what is the best approach to make your app bulletproof and bug-free considering the platform limitations. If you ever encountered an Android app codebase that did not have an architectural rules and the state was managed everywhere across the codebase, you probably had lots of subtle issues that were not that easy to reproduce and that is something they are trying to help us with.
@@martinmihalic8612 Thanks, your response got me thinking. I may not yet fully embrace the role of my ViewModel classes. Perhaps I'm enforcing too much of the domain relations onto the ViewModel classes.
Wait, which Ed Sheeran song? 😂
U.N.I
Best lecturer so far, thank you!
Thx for the great explanation.
Would you please add subtitles in future videos?
Isn't it wrong to call an activity an UI object?isnt it a controller and more akin to a main function. It's more of a has UI than is UI.
It's considered UI as its only purpose should be to display state accordingly, not manage it (which is a fundamental root cause to Android app performance, and state management issues [multiple source of truths]).
Your "main function" in Android is actually your Application class, not Activities.
Retrieving and transforming state for display should be delegated to state holders. Resist the temptation to operate on data in your Activities and Fragments. The most you should do, is use it as common source (if you hoist state), to pass down callbacks from your state holders.
If you need Context, look to your Application Context.
These updated series of videos and documentation explains it all very well. Adopting UDF principles has been the direction the Android team has been heading since they took a stance on Architecture back when they launched Architecture components.
Ividiyo enolwazi kakhulu evela kusayithi lonjiniyela
great series , keep it up , follow you from Sudan
Very nice episode, short with all the important info.
Love the Edsheeran U.N.I part hehe 🥰
🇨🇴🙋🏻♂️👍🏼🤝🏼 Saludos desde Colombia
I see a Kurzgesagt fan here 😆
What others state holders exists, aside of viewModels?
mannn i keep focusing on the pyramid up there!!!
Is that a kurzgesagt shirt?
And a kurzgesagt duck
Haha, it is!
awesome
Just a quastion, why you're using FlowState instead of ComposeState??
FlowState can work as state in compose
Finally got this flow, thanks
Nice points. Thanks.
Nice Kurzgesagt shirt
Greeat!!! Thanks
Great TJ
nice
Who's Ed Sheeran?
singer
I think the better practice is should replace StateFlow by LiveData, because the StateFlow doesn't keep the last value of state or IU data like LiveData
You're wrong, StateFlow keep last value of data, StateFlow is very similar with SharedFlow(replies=1)
@@sysadm85 sorry, i think there is my mistake. When restart fragment, the state flow will be initialized again, it will not keep the previous data. Anyway, it will be re-updated when re-fetching data and being observed inside lifecycle scope block.
Great video! Looking forward to the next episode!
1 st comment
Borling
That's an achievement. Congrats.
Боольшое спасибо автору,классное видео)
Спасибо автору,классно видео
Боольшое спасибо автору,классное видео)
Awesome explanation waiting for the next episode.
Yes Sir..ok very good info