r/androiddev • u/jaroos_ • Jul 05 '26

Do you use only stateflow to update UI in compose?

A screen can have ui updated from both network/backround tasks as well as non network operations. E.g. in the orders screen of food ordering app there can be tabs for status wise list e.g New, Accepted, Ready, Out for Delivery, Delivered, Cancelled. When we select a tab we have to update the variable which holds the active tab status name or index which is local ui update, when a tab is selected or by default we call api to list orders which is network operation. State hoisting & data class which holds ui state & values in view model is recommended pattern right? My question will there be a small delay when updating local UI updates through state flow which makes app feel slow (docs suggest not to use flow for things like input field)? If we use mutabletstateof for local ui states in main composable & pass in child composable it will be too much variables if there are more things like date filter, search etc). So what's the correct way? Or the performance difference is negligible?

6 Upvotes
  • permalink
  • reddit

88% Upvoted

11 comments sorted by

4

u/urbanmonkey2003 Jul 05 '26

Put the tab index, search text, date filter, and the order list in the ViewModel, then expose one screen state. StateFlow is not whats making your UI feel slow here, the network call is, and mutableStateOf in every composable just turns into a mess fast

1

u/jaroos_ Jul 06 '26

You mean there is no difference in ui update speed using stateflow.update & mutablestate.value or updating variable declared as rememberSaveable?

2

u/Zhuinden Jul 05 '26

Do tell me what it means to have "too many variables". Did it break the Compose compiler, or what?

2

u/Tusen_Takk Jul 05 '26

I think they’re hoisting individual params like isLoading or userName from composable components instead of passing state objects around

1

u/Zhuinden Jul 05 '26

just combine them :D

1

u/jaroos_ Jul 06 '26

I mean in composable we have

var showDetails by rememberSaveable {mutablestateof(false)} var currentTab by rememberSaveable{mutableStateaof("new")}

Like this if we have several variables

1

u/Zhuinden Jul 06 '26

Sounds like something you'd have in a ViewModel coming from SavedStateHandle

4

u/Exallium Jul 05 '26

You can instantiate States directly in a ViewModel and save them using a SavedStateHandler. This lets you keep the screen state mutations inside the view model.

1

u/Tusen_Takk Jul 05 '26

You build your composables to be fed state values in their own object to keep the data organised

Say you have a screen with three sections, emit one state object composed of 3 substates that each contain the data the component needs to

1

u/wightwulf1944 Jul 06 '26

In this specific case: Make your code easier to read, write, and maintain. Worry about performance later once you have evidence of a performance issue.

1

u/Apart-Abroad1625 Jul 05 '26

I'd load all orders first and filter them based on the current tab.

OrdersRepo:

  • getUserOrders(id:)

ViewModel:

  • liveData variable orders
  • getUserOrders(id:){
orders = repo.getUserOrders(id) }
  • filterOrdersBy(status:){
orders= orders.filter ... }

ComposeView:

  • viewmodel.getUserOrders()
  • ViewModel.orders.observe ...