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.

Practice

1. What is the main purpose of state hoisting in Android Kotlin UI development?

easy

A. To avoid using ViewModel for state management

B. To keep all state inside UI components for faster rendering

C. To make UI components dependent on global variables

D. To move state out of UI components to make them simpler and reusable

Solution

1. Step 1: Understand state hoisting concept

   State hoisting means moving state out of UI components so they don't manage their own state internally.

2. Step 2: Identify the benefit of moving state out

   This makes UI components simpler, easier to reuse, and testable by passing state and events as parameters.

3. Final Answer:

   To move state out of UI components to make them simpler and reusable -> Option D

4. Quick Check:

   State hoisting = move state out [OK]

Hint: State hoisting means lifting state up from UI [OK]

Common Mistakes:

• Thinking state should stay inside UI components
• Confusing state hoisting with global variables
• Believing ViewModel is not related to state hoisting

2. Which of the following is the correct way to pass state to a composable function following the state hoisting pattern?

easy

A. fun Greeting() { var name = "John"; Text("Hello $name") }

B. fun Greeting() { val name = remember { mutableStateOf("John") }; Text("Hello ${name.value}") }

C. fun Greeting(name: String) { Text("Hello $name") }

D. fun Greeting() { Text("Hello") }

Solution

1. Step 1: Identify state hoisting signature

   State hoisting means the composable receives state as a parameter instead of owning it internally.

2. Step 2: Check which function receives state as parameter

   fun Greeting(name: String) { Text("Hello $name") } passes name: String as parameter, which is correct for hoisting state.

3. Final Answer:

   fun Greeting(name: String) { Text("Hello $name") } -> Option C

4. Quick Check:

   State passed as parameter = fun Greeting(name: String) { Text("Hello $name") } [OK]

Hint: State hoisted means passed as parameter, not created inside [OK]

Common Mistakes:

• Creating state inside composable instead of passing it
• Not passing state at all
• Using remember inside UI component for hoisted state

3. Given the following code, what will be the output when the button is clicked once?

var count by remember { mutableStateOf(0) }
Button(onClick = { count++ }) {
  Text("Clicked $count times")
}

medium

A. Clicked 1 times

B. Clicked 0 times

C. Clicked times

D. Runtime error

Solution

1. Step 1: Understand initial state value

   The variable count starts at 0 using remember and mutableStateOf.

2. Step 2: Analyze button click effect

   When the button is clicked once, count++ increments count to 1, triggering recomposition.

3. Final Answer:

   Clicked 1 times -> Option A

4. Quick Check:

   Initial 0 + 1 click = 1 [OK]

Hint: Increment state on click updates UI text [OK]

Common Mistakes:

• Thinking count stays 0 after click
• Ignoring recomposition after state change
• Expecting syntax or runtime error

4. Identify the error in this state hoisting example:

@Composable
fun Counter() {
  var count by remember { mutableStateOf(0) }
  CounterDisplay(count)
}

@Composable
fun CounterDisplay(count: Int) {
  Button(onClick = { count++ }) {
    Text("Count: $count")
  }
}

medium

A. count++ inside CounterDisplay does not update state in Counter

B. Button onClick should not modify count at all

C. remember should be used inside CounterDisplay instead

D. State should be mutable in CounterDisplay to increment

Solution

1. Step 1: Analyze state ownership and mutation

   State count is owned in Counter and passed as immutable Int to CounterDisplay.

2. Step 2: Understand why count++ in CounterDisplay fails

   Incrementing count inside CounterDisplay only changes local copy, not the original state in Counter.

3. Final Answer:

   count++ inside CounterDisplay does not update state in Counter -> Option A

4. Quick Check:

   Immutable parameter can't update hoisted state [OK]

Hint: Only owner can update hoisted state, not parameter [OK]

Common Mistakes:

• Trying to mutate immutable parameter
• Using remember in child composable incorrectly
• Not passing event callback to update state

5. How should you modify the following code to correctly implement state hoisting so that CounterDisplay can update the count?

@Composable
fun Counter() {
  var count by remember { mutableStateOf(0) }
  CounterDisplay(count)
}

@Composable
fun CounterDisplay(count: Int) {
  Button(onClick = { count++ }) {
    Text("Count: $count")
  }
}

hard

A. Make count a var inside CounterDisplay and increment it there

B. Pass a lambda to CounterDisplay to update count in Counter

C. Use remember { mutableStateOf(0) } inside CounterDisplay instead

D. Remove count parameter and manage state only in CounterDisplay

Solution

1. Step 1: Recognize state hoisting requires event callbacks

   To update hoisted state, child composable must receive a function to trigger state changes in the owner.

2. Step 2: Modify CounterDisplay to accept update lambda

   Pass a lambda like onCountChange: () -> Unit to CounterDisplay and call it inside onClick.

3. Final Answer:

   Pass a lambda to CounterDisplay to update count in Counter -> Option B

4. Quick Check:

   State hoisting needs event callback to update state [OK]

Hint: Pass update function down to child to change hoisted state [OK]

Common Mistakes:

• Trying to mutate parameter directly
• Creating new state inside child composable
• Removing state from owner composable