--- title: UiState is Too Big and Hard to Read — Now What? | daily.dev description: A practical rundown of seven techniques to tame bloated UiState classes in Android apps using Jetpack Compose and MVVM. Suggestions include modeling mutually... canonical: https://daily.dev/posts/uistate-is-too-big-and-hard-to-read-now-what--vutjdzhsk twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: UiState is Too Big and Hard to Read — Now What? | daily.dev og:description: A practical rundown of seven techniques to tame bloated UiState classes in Android apps using Jetpack Compose and MVVM. Suggestions include modeling mutually... og:url: https://daily.dev/posts/uistate-is-too-big-and-hard-to-read-now-what--vutjdzhsk og:image: https://api.daily.dev/og/posts/VUTJdzhsk.png og:image:alt: UiState is Too Big and Hard to Read — Now What? og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # UiState is Too Big and Hard to Read — Now What? **[ProAndroidDev](https://daily.dev/sources/pand)** · 5 min read · 3 upvotes · 1 comments ## Summary A practical rundown of seven techniques to tame bloated UiState classes in Android apps using Jetpack Compose and MVVM. Suggestions include modeling mutually exclusive states with sealed interfaces, breaking flat state into sub-states, keeping UI-local state inside Composables, deriving computable values instead of storing them, splitting oversized ViewModels, avoiding huge lists in UiState (using Paging instead), and splitting a single StateFlow into independent flows per screen section. The core takeaway is that a large UiState isn't inherently bad — the real issue is mixing unrelated kinds of state together. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### How do I keep my Android ViewModel UiState from becoming too large and hard to read? Use a combination of techniques: model mutually exclusive states with a sealed interface instead of nullable flags, group related properties into sub-states like HeaderState and FilterState, move UI-only state (like expansion or animation state) into the Composable with rememberSaveable, and derive computable values like filteredItems instead of storing them separately. _daily.dev surfaces practical Android architecture patterns for developers wrestling with sprawling ViewModel state._ ### Should large lists of items be stored directly inside a Jetpack Compose UiState data class? No, large datasets should not be embedded directly in a UiState class. Instead, keep UiState limited to things like search queries and filters, and stream the actual item list separately using a paging mechanism such as the Paging library combined with cachedIn(viewModelScope), keeping the monolithic state object lightweight. _Developers designing Compose screens with large datasets can find this kind of paging guidance on daily.dev._ ### When should I split one big StateFlow into multiple separate StateFlows in a ViewModel? Split into independent StateFlows, such as headerState, searchState, and contentState, when different sections of a screen have genuinely independent state and only need to observe their own slice. However, splitting every property into its own StateFlow can make the architecture harder to follow, so this should be applied selectively rather than universally. _daily.dev helps Android developers weigh state-splitting trade-offs before restructuring a ViewModel._ ## Community discussion Top comments from developers on daily.dev. **@mark\_kazakov** · 0 upvotes > Sealed classes and "sub states" can trivialize a large state management mess, can't recommend these approaches enough. ## Similar posts on daily.dev - [AppState in Jetpack Compose: The Missing Piece for Building Large-Scale Android Apps](https://daily.dev/posts/appstate-in-jetpack-compose-the-missing-piece-for-building-large-scale-android-apps-gsrhvyqeq) · Medium · 2 upvotes · 1 comments - [Android Architecture Is Quietly Moving Beyond ViewModel as a State Holder](https://daily.dev/posts/android-architecture-is-quietly-moving-beyond-viewmodel-as-a-state-holder-0e2pkua20) · ProAndroidDev · 12 upvotes · 0 comments - [Stop Passing ViewModels to Your Composables?](https://daily.dev/posts/stop-passing-viewmodels-to-your-composables--lshjhtw8a) · ProAndroidDev · 4 upvotes · 0 comments - [How to simplify State and Entity mappings with Kotlin interfaces, delegation and covariant generics](https://daily.dev/posts/how-to-simplify-state-and-entity-mappings-with-kotlin-interfaces-delegation-and-covariant-generics-74hv7oqbr) · Medium · 0 upvotes · 0 comments --- Tags: [#general-programming](https://daily.dev/tags/general-programming), [#android](https://daily.dev/tags/android), [#kotlin](https://daily.dev/tags/kotlin), [#jetpack-compose](https://daily.dev/tags/jetpack-compose) [View this post on daily.dev](https://daily.dev/posts/uistate-is-too-big-and-hard-to-read-now-what--vutjdzhsk) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"UiState is Too Big and Hard to Read — Now What?","url":"https://daily.dev/posts/uistate-is-too-big-and-hard-to-read-now-what--vutjdzhsk","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/uistate-is-too-big-and-hard-to-read-now-what--vutjdzhsk"},"datePublished":"2026-08-15T21:52:32.135Z","dateModified":"2026-09-14T07:05:30.331Z","description":"A practical rundown of seven techniques to tame bloated UiState classes in Android apps using Jetpack Compose and MVVM. Suggestions include modeling mutually...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/b36fd5f1370a6a57a32bcfdba8e7e7dd?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/b36fd5f1370a6a57a32bcfdba8e7e7dd?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"ProAndroidDev","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"ProAndroidDev","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/656c1eb1f1ef4f91936e86fc16545114","url":"https://daily.dev/sources/pand"},"commentCount":1,"discussionUrl":"https://daily.dev/posts/uistate-is-too-big-and-hard-to-read-now-what--vutjdzhsk","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":3},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":1}],"keywords":"general-programming,android,kotlin,jetpack-compose","timeRequired":"PT5M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"ProAndroidDev","item":"https://daily.dev/sources/pand"},{"@type":"ListItem","position":3,"name":"UiState is Too Big and Hard to Read — Now What?"}]} {"@context":"https://schema.org","@type":"WebPage","@id":"https://daily.dev/posts/uistate-is-too-big-and-hard-to-read-now-what--vutjdzhsk","comment":[{"@type":"Comment","text":"Sealed classes and “sub states” can trivialize a large state management mess, can’t recommend these approaches enough.","datePublished":"2026-08-25T15:23:41.973Z","url":"https://daily.dev/posts/VUTJdzhsk#c-GNrkAFYEq","author":{"@type":"Person","name":"Mark Kazakov","url":"https://daily.dev/mark_kazakov","image":"https://media.daily.dev/image/upload/s--xbUWQzIM--/f_auto/v1743106084/avatars/avatar_DXWhIjQxKsp3WABroh08k"}}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/uistate-is-too-big-and-hard-to-read-now-what--vutjdzhsk#faq","mainEntity":[{"@type":"Question","name":"How do I keep my Android ViewModel UiState from becoming too large and hard to read?","acceptedAnswer":{"@type":"Answer","text":"Use a combination of techniques: model mutually exclusive states with a sealed interface instead of nullable flags, group related properties into sub-states like HeaderState and FilterState, move UI-only state (like expansion or animation state) into the Composable with rememberSaveable, and derive computable values like filteredItems instead of storing them separately. daily.dev surfaces practical Android architecture patterns for developers wrestling with sprawling ViewModel state."}},{"@type":"Question","name":"Should large lists of items be stored directly inside a Jetpack Compose UiState data class?","acceptedAnswer":{"@type":"Answer","text":"No, large datasets should not be embedded directly in a UiState class. Instead, keep UiState limited to things like search queries and filters, and stream the actual item list separately using a paging mechanism such as the Paging library combined with cachedIn(viewModelScope), keeping the monolithic state object lightweight. Developers designing Compose screens with large datasets can find this kind of paging guidance on daily.dev."}},{"@type":"Question","name":"When should I split one big StateFlow into multiple separate StateFlows in a ViewModel?","acceptedAnswer":{"@type":"Answer","text":"Split into independent StateFlows, such as headerState, searchState, and contentState, when different sections of a screen have genuinely independent state and only need to observe their own slice. However, splitting every property into its own StateFlow can make the architecture harder to follow, so this should be applied selectively rather than universally. daily.dev helps Android developers weigh state-splitting trade-offs before restructuring a ViewModel."}}]} ```