State holders and state production in the UI Layer

The UI layer displays application data on the screen. But how is it done exactly? We dive deep into the UI state production pipeline and state holders that manage UI complexity. Get to know the differences between UI and business logic, a ViewModel and a plain state holder class, state and events, and more! What is all that, when to use which, and how to do it.
Resources:
Guide to app architecture → goo.gle/mad-architecture-guide
UI layer → goo.gle/architecture-ui-layer
State holders and UI State → goo.gle/architecture-state-ho...
UI State production → goo.gle/architecture-uistate-...
UI events → goo.gle/architecture-ui-events
ViewModel overview → goo.gle/architecture-viewmodel
Architecture recommendations → goo.gle/architecture-recomend...
0:00 - Introduction
1:37 - Types of UI state
2:24 - Types of logic
4:25 - How state and logic relate to each other
4:50 - Where to handle logic
5:10 - ViewModels
8:55 - Plain state holder classes
11:35 - Identifying state holders in the UI
13:08 - Should you use ViewModels?
14:20 - Producing screen UI state
15:03 - Local sources of state change
16:07 - External sources of state change
16:56 - Combining local and external sources
18:15 - Collect state in a lifecycle-aware manner
18:40 - Modelling screen UI state based on inputs
19:34 - Recap
Speaker: Manuel Vicente Vivo
Watch more:
Watch all the Android Dev Summit sessions → goo.gle/ADS-All
Watch all the Modern Android Development sessions → goo.gle/ADS-MAD
Subscribe to Android Developers → goo.gle/AndroidDevs
#Featured #AndroidDevSummit #Android

[@conorsmall1373]

This talk has answered so many of my questions thanks Manuel!

[@CharfaouiYounes]

I've been waiting for a detailed talk about States 🤩, Knowing the different options available for us will help a lot!

[@AndroidDevelopers]

We're very happy to hear this, Charfaoui! Thank you for the feedback, and we're glad the video was helpful 😁

[@radhakrishnan9662]

​@@AndroidDevelopers

[@amirhosseinghafoorian9985]

super important talk and issues to mention. thanks a lot

[@AndroidDevelopers]

You're very welcome! Don't forget to also check out the video description for even more on this topic 😊

[@MyFoenix]

hi, thank you! Please, give an example of managing viewmodel complexity with delegates as described, I want to see it in detail

[@kalidsherefuddin]

Thanks very

[@anasaltair8244]

I think numberOfRolls should be taken from roll object instead of user inside the combine function (18:07). Otherwise this state will get missing in case the screen went to the background more than 5 seconds. Unless you cache it after every roll. And I'd reduce user to StateFlow before passing it to combine to avoid showing loading after 5 sec in background.

[@zekininadresi]

Do external streams of data have to be exposed as a cold flow always? For example a state in the data layer that's fetched from a local database?

[@trevorcrawford3776]

@18:50 Any resources on pros and cons of StateFlow vs Compose State and reasons for that decision?

[@trevorcrawford3776]

@@manuelvicnt Sorry for the late reply, thank you so much. That makes perfect sense and this is a great article. (There are so many great new articles! 😁)

[@arkadymagomedov1700]

Dear Android colleagues from Google, current state management in compose is nuts. It feels like the API changed gazillion times just in the past 2 years, and today it feels like only you guys understand what the hack is going on in there.

[@richardmiklos]

What is that "Success" type in the stateless DiceRollUI composable function's when statement? Shouldn't that be DiceRollUiState.DiceRoll?

[@sanek1985t]

I am rewriting our java+kotlin+xml project to Compose. So, what I can say... despite I experienced developer it seems that modern recommended android development is very over complicated especially for beginners... All these: lifecycle APIs, flow, state flow, compose state, APIs for getting one from another , many helper wrappers around such APIs..., Hilt, viewmodels as holders for business, and UI logics .... Looks like some mess and need to be rewritten totally 😁. Just one example of bad arch IMHO. In fragment world recommended approach is to use navcontroller or plain supportfragmanager and *replacing* one fragment by another when we want to show new fragment. Viemodel here is for storing data from backstacked fragment. But instead of replacing previous fragment we could just hide it! (view is still live in container, just hidden) and show new fragment above (view add to container). That is use .add instead of .replace method with some tricks of hiding all previous. The same behavior was implemented for Activities before fragments! Why you changed this by suggesting replacing fragments? When we use add/hide approach we no need viewmodels at all;), because view is still live and when we go back we just see what was on a screen before without any new requests of data. Simple to use.

[@thecsciworker291]

Your idea/approach doesn't take into consideration how the Android System manages these view components., that is Application Lifecycle. When you add an activity over another, the system places the activity in a state where it no longer consumes resources. However fragments don't work that way. They will continue to use resources even if the user is not viewing the fragment. So if you don't "replace" instead of "add", the fragment is just sitting there consuming RAM when it doesn't need to. It's better to replace, and save your state (Viewmodel or onSavedInstance). However onSavedInstance should only save simple data. That is, data that can be QUICKLY serialized and deserialized. Otherwise you risk stuttering (like most badly designed apps where they don't consider lifecycle states). This is where the Viewmodel comes in. It survives configuration changes, can hold complex and bloated data types/objects, outlives your fragments and works with your app's lifecycle, and decouples data holding & management from Activities and Fragment (which they shouldn't. They should just present). They are also more entwined with your lifecycle if you use Kotlin StateFlows.

[@_plaha_]

True and real. My patience is running thin with all these bs

[@yewo.m]

You don't have to integrate every single one of those APIs. I'm also a beginner Android developer myself (though not a beginner with programming in general), and the simple apps I've created so far haven't used things like Viewmodels, Hilt, flow, or any of those you mentioned. You can start with the basic building blocks which Compose provides (like basic remember + mutableStateOf, or navigation compose with a navController). And then you can add the other features depending on the complexity of your app, current need, or as you go along So it's all about understanding the tools and why you use them, not just blindly throwing everything into your project

[@SiamakAshrafi]

Good talk! We only let our VM talk to our use cases in our clean Arch.

[@mortezamgh1347]

based on recommendation at 8:19, if we would have to pass `resources` to viewmodel, is it better to pass `applicationContext.resources` instead of Fragment resource?

[@jansmycka4338]

Well, this is hard to answer. On one hand, you should stay away from using anything context related as said. And I would advise against it. On the other - from R+ it is recommended to fetch resources via Activitys context because Applications context could report wrong values for multi-window and secondary displays. (Fragments resources just get one from the activity). What do you need it for?

[@aleksandrsmols8335]

Nice info but really hard for understanding by start class developers

[@PS-bv1zq]

Why not use mustableStateOf instead of MutableStateflow in ViewModel

[@manuelvicnt]

Hi! You definitely can use it if the UI state is the screen UI state is created using local sources of state change or one-shot APIs. See my reply in Trevor's question in this video for more information about this. Thank you!

[@sanek1985t]

@@manuelvicnt hello Manuel, just one question about fragments. Modern navcontroller and old plain supportfragmanager uses .replace method when we want to show new fragment. It's recommended approach. Previous view is destroyed, fragment is putting to backstack. Viewmodel for this fragment holds data and responsible for reattach data again to new view when we go back to this fragment. But there is another approach working with fragments which I saw in many big and popular apps. It's not destroying view , not replacing fragments, just hidding previous and showing new. That is you hide prev frag and show new one. Both view are in container. Benefits: views are not destroyed. When we go back to previous fragment we just show it and that's all! We no need to reattach data or request data again - fragment and view is still live and just showing... I saw some implementations on GitHub. They are not so complex. Also it gives you option to use fully custom animation based on views, also getting results from new fragment to previous using simple callback (like in iOS), because previous fragment and it's view is still live! What do you think about this approach? Ps: this behavior was implemented for Activities before fragments - one activity is opened just above previous.

[@barashkagornaya3826]

This is so complicated...

[@JuanTorres-lp2rc]

620

[@sanjaybhatikar]

Peace.

[@Dencell]

Sorry this doesn't feel intuitive at all. You should learn more from swiftui...

[@nima7605]

No offense (I am just trying to make a suggestion), Please Sir let others explain the stuff, your voice is not suitable for lecturing, every time I watch your videos I learn lots of stuff but at the same time I get headache. Plz let others do the speech part

[@burakcanduzcan]

his accent is thick

[@ivanh1821]

I feel the opposite, when others explain in perfect English I understand absolutely nothing, when Manuel explains it, I perfectly understand what he says.

[@UpToTheWhalesNow]

Tech is very international - you should be used to working with many different accents

[@Zhuinden]

No mention of SavedStateHandle.getStateFlow(), we're back in 2017 making people think ViewModel alone is enough for handling process death 🤦