Compose Focus Navigation

Compose: focus navigation

Core principle

Focus is stateful UI behavior. Make focus targets explicit, request focus after composition succeeds, and test navigation with the same input model users use: keyboard, D-pad, or remote keys.

When to use this skill

Use this when UI:

• Runs on TV, desktop, ChromeOS, keyboard-first Android, or remote-control devices.
• Uses FocusRequester, focusRequester, focusProperties, onFocusChanged, or key handlers.
• Needs initial focus, restored focus, directional navigation, or back/escape behavior.
• Has a carousel, grid, lazy list, menu, dialog, or modal with focus traps.
• Has tests asserting which item is focused.

Build focus targets deliberately

Start with components that already participate in focus, then add only the focus hooks the behavior needs:

For example, request and observe focus only when both behaviors are needed:

val requester = remember { FocusRequester() }

Button(
   
    modifier = Modifier
        .focusRequester(requester)
        .onFocusChanged { state -> isFocused = state.isFocused },
) {
    Text("Play")
}

Prefer focusable components (Button, TextField, clickable/selectable surfaces) over manually adding focusable() to passive layout. Add manual focus only when the element is truly interactive or participates in navigation.

Request focus after composition

Call focus requests from an effect, not from the composable body:

val initialFocus = remember { FocusRequester() }

LaunchedEffect(initialFocus) {
    initialFocus.requestFocus()
}

If the target appears after loading, key the request to the condition:

LaunchedEffect(items.isNotEmpty()) {
    if (items.isNotEmpty()) {
        firstItemRequester.requestFocus()
    }
}

For lazy content, request focus only after the item is actually composed. Keep requesters in stable item state keyed by item id, not by index alone if the list can reorder.

Directional navigation

Use focusProperties when default spatial search is wrong:

Modifier.focusProperties {
    up = headerRequester
    down = firstRowRequester
    left = FocusRequester.Cancel
}

Use this sparingly. Too many hard-coded links create stale focus graphs when layouts change. Prefer natural focus order unless the design requires a specific jump or trap.

Key events

Use key handlers for behavior that is not normal click/focus traversal:

Modifier.onPreviewKeyEvent { event ->
    if (event.type == KeyEventType.KeyUp && event.key == Key.Back) {
        onBack()
        true
    } else {
        false
    }
}

Return true only when consumed. Returning true too broadly breaks text entry, accessibility shortcuts, and parent navigation.

For rapid D-pad input, throttle at the boundary that owns the expensive behavior (for example row scrolling or paging), not globally across the whole screen.

Focus restoration

Preserve focus by semantic identity:

• Track selected/focused item id, not just index.
• Use stable key values in lazy lists and grids.
• When content refreshes, re-request focus for the same id if it still exists.
• If it no longer exists, choose a deterministic fallback: nearest neighbor, first item, or parent container.

Common mistakes

Testing

Test focus through user input:

composeTestRule.onNodeWithTag("screen").performKeyInput {
    pressKey(Key.DirectionDown)
}

composeTestRule.onNodeWithTag("play-button").assertIsFocused()

Prefer asserting focused semantics over visual styling. Use screenshot tests only for focus appearance, not for deterministic focus ownership.

Broader test-shape choices (plain UI vs integration, semantics-first): compose-ui-testing-patterns.

Red flags during review

• "It focuses correctly when I tap it" for a keyboard/TV UI.
• Initial focus works only with fixed data and fails after loading/refresh.
• Focus state is inferred from selected data state when focus and selection are different concepts.
• The focus graph is described in comments but not encoded or tested.