State holders and state production in the UI Layer

Подписаться 1,3 млн

Просмотров 44 тыс.

50% 1

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

Наука

Опубликовано:

8 июл 2024

Ссылка:

Скачать:

Готовим ссылку...

Добавить в:

Мой плейлист

Посмотреть позже

Комментарии : 35

@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

@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?

@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.

@kalidsherefuddin Год назад

Thanks very

@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! 😁)

@richardmiklos Год назад

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

@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.

@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 2 месяца назад

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

@mortezamgh1347 11 месяцев назад

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 11 месяцев назад

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?

@SiamakAshrafi Год назад

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

@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.

@JuanTorres-lp2rc Год назад

620

@barashkagornaya3826 Год назад

This is so complicated...

@sanjaybhatikar 11 месяцев назад

Peace.

@Dencell Год назад

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

@mrbmro3991 6 часов назад

The data layer should not contain ANY business logic IF we are using a Domain layer. The data layer should ONLY be concerned purely CRUD operations and ALL business logic should be in the Domain layer where Usecases hold all the business logic and the domain layer does not depend on any other app module. This is Clean Architecture which enforces a separation of concerns. I can't think of any reason why you would develop an application where you would mix concerns of data persistence with business logic ALL within the data layer. This is plain wrong.

@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.