Adaptive Compose Layouts: Design for Windows, Not Device Labels

Adaptive Jetpack Compose interfaces on phone, foldable, and tablet

“Phone layout” and “tablet layout” are no longer reliable design targets. The same Android application can run in portrait, landscape, split screen, a foldable posture, or a resizable desktop window.

An adaptive Compose UI should respond to the available window, preserve user context, and keep navigation predictable.

Start from content relationships

Describe what the screen means before choosing an API. A message list and selected conversation form a list-detail relationship. An editor and its controls form a supporting-pane relationship.

On a compact window, these areas may appear one at a time. On a wider window, they can appear side by side.

Keep window decisions at the screen boundary

Choose the high-level layout near the route or screen boundary. Reusable content should receive ordinary data and events instead of making independent width decisions throughout the component tree.

Preserve user state

When a layout expands, users should not lose their selected item. When it contracts, the detail destination should remain reachable through Back.

Keep selected IDs in saveable or state-holder state. A window resize is a presentation change, not a reason to reload data or recreate the ViewModel.

Test transitions

Test resizing, orientation changes, fold and unfold events, large font scales, translated text, keyboard navigation, accessibility focus order, and Back behavior.

Sources: Adaptive apps, Material 3 Adaptive

About the Author

You may also like these