State hoisting pattern in Android Kotlin - UI Render Trace

Component - State hoisting pattern

This UI component demonstrates the state hoisting pattern in Android Kotlin using Jetpack Compose. State hoisting means moving the state up to a parent component so that it can control and share the state, while the child component only displays UI and triggers events.

Widget Tree

ParentComposable
├── ChildComposable
│   └── TextField
└── Text

The ParentComposable holds the state and passes it down to ChildComposable as parameters. ChildComposable shows a TextField for user input and calls back to ParentComposable on changes. ParentComposable also displays the current text below.

Render Trace - 4 Steps

Step 1: ParentComposable

Step 2: ChildComposable

Step 3: TextField

Step 4: ParentComposable

State Change - Re-render

Trigger:User types text in the TextField inside ChildComposable

Before

text = "" (empty)

→

After

text = "user typed text" (updated string)

Re-renders:ParentComposable and its children (ChildComposable and Text) recompose to reflect new state

UI Quiz - 3 Questions

Where is the state variable 'text' stored in the state hoisting pattern?

A Inside the TextField widget

B In the ParentComposable

C In the ChildComposable only

D In a global variable

Key Insight

State hoisting helps keep UI components simple and reusable by moving state management to a common parent. This makes the app easier to test and maintain, and allows multiple components to share and react to the same state.

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