State hoisting pattern in Android Kotlin - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ ui_behavior

intermediate

Understanding State Hoisting in Compose

What will be the visible text on the screen after clicking the button once in this Compose UI code?

Android Kotlin

var text by remember { mutableStateOf("Hello") }
Button(onClick = { text = "Clicked" }) {
  Text(text)
}

A Clicked

B Button

C Error: Unresolved reference

D Hello

💡 Hint

Think about what happens when the button is clicked and how state changes update the UI.

The mutableStateOf holds the current text. Clicking the button changes the text to "Clicked", which updates the UI to show "Clicked".

🧠 Conceptual

intermediate

Why Use State Hoisting?

Why is state hoisting recommended in Jetpack Compose components?

A To allow state to be controlled from outside the component for better reusability

B To keep state inside the component for encapsulation

C To prevent any state changes in the UI

D To make the UI static and unchangeable

💡 Hint

Think about who should own the state for flexible UI components.

State hoisting moves state ownership outside the component, allowing the parent to control it and making the component reusable and testable.

❓ lifecycle

advanced

State Hoisting and Recomposition

Given a hoisted state passed as a parameter to a composable, what happens when the state changes?

A The app crashes due to state mismatch

B The state resets to its initial value

C The composable recomposes reflecting the new state value

D The composable does not recompose because state is external

💡 Hint

Consider how Compose reacts to state changes passed as parameters.

When the hoisted state changes, Compose triggers recomposition of the composable receiving it, updating the UI accordingly.

🔧 Debug

advanced

Identify the State Hoisting Bug

What is wrong with this Compose code that tries to hoist state but does not update the UI on button click?

Android Kotlin

var count = 0
@Composable
fun Counter(count: Int, onCountChange: (Int) -> Unit) {
  Button(onClick = { count++ }) {
    Text("Count: $count")
  }
}

A count is not a mutable state, so UI does not recompose

B Button onClick should not modify count directly

C onCountChange is not called to update the state

D All of the above

💡 Hint

Check how state should be updated and how Compose detects changes.

The count variable is a plain integer, not a mutable state. The onClick modifies count locally but does not notify Compose or call onCountChange. Proper state hoisting requires calling onCountChange to update the external state.

❓ navigation

expert

State Hoisting Across Navigation Destinations

In a multi-screen Compose app, where should you hoist state to preserve it across navigation between screens?

A Inside each composable screen individually

B In a shared ViewModel scoped to the navigation graph or activity

C In local variables inside the NavHost

D In a global singleton object

💡 Hint

Think about where state should live to survive screen changes and configuration changes.

A shared ViewModel scoped to the navigation graph or activity holds state that survives navigation and configuration changes, enabling state hoisting across screens.