Compose Business Logic and UI State Holder Guide

— Have you ever wondered, “Why does my screen state keep getting more and more complicated when building with Compose?”

When building Android apps, state multiplies quickly.

User input, server data, loading/error flags, temporary UI toggles, animation triggers… At first it feels convenient to throw everything into a single ViewModel, but soon you’ll hit unexpected recompositions, tangled dependencies, and increased testing complexity all at once. Compose makes this even trickier since its expressiveness allows complex formulas to sneak in so easily.

This post is a practical guide to reduce that complexity by clearly separating Business Logic State Holders and UI Logic State Holders. It’s based on the painful lessons I learned from both a coding test assignment at a tech company and the Woowacourse Android Mission, and the final approach I applied to a Card Registration Screen.

Here’s how the post is structured:

Concept → Decision Criteria → Code Patterns → Refactoring Steps → Testing Strategy → Checklist

---

0) TL;DR

• Business Logic State Holder: Independent of the screen lifecycle. Responsible for data source access/processing and business rules. Usually implemented as a ViewModel.
• UI Logic State Holder: Tied to the screen lifecycle. Handles pure UI concerns like checkboxes, input validation, scroll position, dialogs. Usually implemented with remember/rememberSaveable + small classes.

If you remember just one line, it’s this:

— “Business lives in the ViewModel, interactions live in the UI State Holder.”

---

1) Why Separate Them?

1. Clearer UDF (Unidirectional Data Flow)

• ViewModel → domain/data access + mapping to UI models
• UI Holder → input/interaction handling (formatting, validation, toggles)

→ Simpler event flow and easier debugging

2. Minimized Recomposition Cost

• Localize UI-only state with remember → reduces unnecessary observation and allows partial recomposition

3. Easier Testing and Substitution

• ViewModel tests = business rules
• UI Holder tests = “input → state” with small, pure logic

---

2) What Goes Where? (Decision Table)

Question	Example	Goes Into
Must persist after rotation/process death?	Login state, detail info	Business (ViewModel)
Needs external layer access/async work?	Repository/UseCase calls, caching	Business (ViewModel)
Purely temporary UI-only state?	Input validation, bottom sheet open flag	UI State Holder
Reusable UI pattern/logic?	TextField with local validation, scroll snapping	UI State Holder (small class)

---

3) Minimal Pattern: “ViewModel is Business, UI is Localized”

3.1 Card Wallet — UI State Holder

Input formatting, validation, sheet toggles —

pure UI logic.

@Stable
class NewCardUiStateHolder(
    isBankSheetOpenInit: Boolean = false
) {
    var isBankSheetOpen by mutableStateOf(isBankSheetOpenInit)
        private set

    fun updateBankSheet(open: Boolean) {
        isBankSheetOpen = open
    }

    val canSave: Boolean
        get() = /* Combine validation results here */
}

@Composable
fun rememberNewCardState(): NewCardUiStateHolder =
    rememberSaveable { NewCardUiStateHolder() }

• isBankSheetOpen → purely UI toggles should live here
• canSave → instant feedback calculations should live here
• Final saving, duplicate checks, business rules → ViewModel

---

3.2 Screen Composition (Card Wallet, minimal wiring)

@Composable
fun NewCardScreen(
    onSaved: (CardUiModel) -> Unit = {},
    onFinish: () -> Unit = {},
) {
    val holder = rememberNewCardState()
    val viewModel: NewCardViewModel = hiltViewModel()

    NewCardTopBar(
        onBackClick = onFinish,
        onSaveClick = {
            if (holder.canSave) {
                val model = holder.createCardUiModel()
                viewModel.save(model)   // delegate to business
                onSaved(model)          // optional callback
            }
        }
    )

    // Preview card click → holder.updateBankSheet(true)
    // TextFields bind only to holder.updateXXX(...)
    // Save button enabled/disabled via holder.canSave
}

Key Points:

• Source of truth / final saving → ViewModel
• Input formatting / sheet toggling / button enabling → UI State Holder
• The screen only loosely wires the two together

---

4) One Step Further: Where to Draw the Line?

• Needs instant UI feedback char limits, local formatting, toggles, focus changes, bottom sheet open flags → Belongs in UI Holder
  
• Requires policy enforcement, persistence, or server checks duplicate card checks, Luhn/BIN validation, saving to server, retries, logging → Belongs in ViewModel + domain/data layers
  

Rule of thumb:

“Instant response = UI, accountable business logic = ViewModel.”

---

5) Performance Tips

• Use derivedStateOf { ... } for caching computed values (e.g. button enabled state, summary text, counters)
  
• Use snapshotFlow { state } to minimize read points → clearer handling, avoids unnecessary loops
  
• Use rememberSaveable only for recoverable values → form inputs that must survive process death; otherwise remember is enough
  
• For lists: use LazyXxx + stable keys, and keep item state inside items
  

---

6) Refactoring Steps (When Everything is in ViewModel)

1. Make a split table
   • Needs server/cache/domain access? → ViewModel
   • Pure UI-only? → UI Holder
2. Start with UI State Holder design
   • Public API should reflect user actions (updateXxx, toggle())
3. Inject it via remember/rememberSaveable
   • Sync initial values from ViewModel’s StateFlow if needed
4. Verify ViewModel noise is gone
   • If input formats/focus/visibility are removed, success
5. Separate tests
   • ViewModel = business transitions
   • UI Holder = pure input → state

---

7) Testing Strategy

UI State Holder Unit Tests: Lightweight

• Test toggles, derived states, and simple validation
• No Compose runtime needed — pure Kotlin tests

@Test fun `card number accepts only 16 digits`() {
    val ui = NewCardUiStateHolder()
    ui.updateCardNumber("1234-5678-9012-3456-9999")
    assertEquals(16, ui.cardNumber.length)
}

---

ViewModel Tests: Focus on Business Transitions

• Test save success/failure, duplicate checks, retry logic, loading/error flags
• Should run fine without the UI Holder

@Test fun `saving succeeds and updates state to Saved`() = runTest {
    val viewModel = NewCardViewModel(fakeRepository)

    val model = CardUiModel("1234567812345678", "1225", "HOLDER", BankType.KB)
    viewModel.save(model)

    testDispatcher.scheduler.advanceUntilIdle()

    assertEquals(
        NewCardUiState.Saved(model),
        viewModel.uiState.value
    )
}

---

8) Pitfalls

• Shoving all inputs/toggles into ViewModel → triggers excessive observation + recomposition hell. Localize into UI.
  
• Storing mutable objects directly in remember → breaks referential equality checks. Use immutable + copy or mutableStateOf.
  
• Overusing derivedStateOf → only use for expensive computations; otherwise just compute directly.
  

---

9) Naming & Structure Guide

(Of course, conventions may vary)

• UI-only: XxxUiState, XxxController, etc.
  • Provide rememberXxxUiState() if Saver exists
• Business-only: XxxViewModel
  • Expose only UI models (UiModel/UiState), do domain → UI mapping internally
• Event naming: updateXxx, toggleXxx, etc. → action-oriented

---

10) Checklist

• Does your ViewModel hold UI-only values (focus, open flags, input formats)?
• Is the UI Holder API action-centered?
• Is derivedStateOf used only for expensive computations?
• Is rememberSaveable applied only where recovery is required?
• Are ViewModel and UI Holder tests separated?

---

11) Wrap-Up

“Business lives in the ViewModel, interactions live in the UI State Holder.”

Stick to this one line and your screens instantly become simpler:

• Clearer separation of responsibilities
• Lower recomposition cost
• Easier testing and maintenance

If you’re not sure where to start, ask yourself:

“What’s only needed in the UI?” Then encapsulate it into a small UI State Holder. Your code will feel instantly lighter.