State

An observable that triggers recomposition when it changes.

remember

Stores states through composition and recomposition.

var name by remember { mutableStateOf("") }

rememberSavable

Retains state like remember, but also through configuration changes. The saved state must be data type that can be added to the Bundle, such as Parcelized data class or implemented with either MapSaver or ListSaver

var name by rememberSavable { mutableStateOf("") }

remember scope

Avoid modifying state outside remember scope.

State Hoisting

• Place state in the lowest common ancestor.
• Keep state as low as possible, and closer to where it is comsumed.
• pass only parameters that composable needs.

@Composable
fun HelloScreen() {
    var name by rememberSaveable { mutableStateOf("") }

    HelloContent(name = name, onNameChange = { name = it })
}

@Composable
fun HelloContent(name: String, onNameChange: (String) -> Unit) {
    Column(modifier = Modifier.padding(16.dp)) {
        Text(
            text = "Hello, $name",
            modifier = Modifier.padding(bottom = 8.dp),
            style = MaterialTheme.typography.bodyMedium
        )
        OutlinedTextField(value = name, onValueChange = onNameChange, label = { Text("Name") })
    }
}

Stateless : composable function without internal state.

ViewModel with State

Managing State

• UI-element state : hoisted state of UI elements ( e.g. ScaffoldState )
• Screen or UI state : what to display on the screen ( e.g. Text messages showing to the user )
• UI behavior logic : how to display state changes. should always live in the composition ( e.g. navigation logic or showing snackbars )
• Business logic : what to do with state changes. implement in business layer or data layer, never in UI layer ( e.g. storing user preferences )

If benefits of ViewModel does not apply to the use case, plain state holders can also take ViewModel's responsibility.

StateHolder

Plain class which holds states for the UI elements and contains UI-related logics.

ViewModel as StateHolder

ViewModel as state holder can hoist state out of the composition since it has longer lifespan.

• Access to business logic and what to display on the screen ( UI state )
• Depends on other layers of the hierarchy ( i.e. data and business layers )
• Recommended for screen-level composables ( composables closer to the navgraph, activity or fragment )

Use case for ViewModel

• Operations that needs to survive configuration changes
• Usage of other Jetpack libraries such as Navigation and Hilt
• Caching state in the Navigation backstack and clear when the destination pops off

Should not take state created in composables since ViewModel lives longer than UI elements.