Folding and unfolding are a live change of size

What it is

Moving a foldable from the cover display to the inner display, or folding it shut again, is not a new device and not a cold start. A live size jump means the app is still alive, the task is mid-stream, and usable area, aspect ratio, and safe insets swap to another set in a second or two. The cover is often a tall strip; the inner display is closer to a small tablet. Some devices add a half-fold stand, where area barely changes but orientation and the way the hinge bisects the surface do. This is not a desktop user dragging a window: dragging is continuous, folding is a jump. How scroll and input are kept, and whether anything can sit on the hinge, are separate questions.

Why it happens

The layout tree is measured against the current window. Folding replaces those measures: width may double or halve, the aspect ratio flips from phone to tablet, and system bars, cutouts, and hinge exclusion zones all move. Treating the change as a fresh open walks the launch layout: the list jumps to the top, the keyboard dismisses, a dialog recenters—while the person is still on the last step, now greeted as a new visitor. The jump can also change pane count—one pane on the cover, two on the inner display—so information architecture jumps with it, not just a scaled picture. Half-fold splits one panel into two regions; the lower becomes a keyboard or a base, the upper is the actual window. If the app still lays out against the full inner display, key actions land on the half that is folded away or blocked by a tabletop. The jump is a physical event. Layout has to treat it as a legal window change, not as a special case of a rotate animation.

Studying it

On hardware or an emulator that can swap two window metrics, fold or unfold halfway through a task. Compare “reflow to the new size and leave the task in place” with “recreate the activity and return to home or a default pane.” Cover long reading, a form filled halfway, and media in playback.

Independent variables: fold direction (cover→inner / inner→cover / half-fold), whether the UI is destroyed and recreated, whether the route is restored after recreation. Dependent variables: whether work continues from the interruption point, false returns to root, layout onto regions that no longer exist, the sense of having been kicked out.

A lab in which the facilitator hits a button undercounts real timing—people fold when they walk through a door, set the device down, or want the inner display for a picture. Let participants choose when to fold, so the jump lands on unfinished states. Do not use a 90° rotation as a proxy: rotation almost keeps area, folding changes it.

Where it stops holding

If the process is killed at the fold (tighter memory on the cover, harsher background limits), that is process reclamation: persist for the next cold start, do not pretend this is a layout jump. Apps that only work on the inner display (a wide canvas, an inner camera) may say “this needs to be unfolded” on the cover, but they still need a cover-side fallback rather than a black screen. Dragging a desktop window onto another display is a continuous move, not this jump; folding can be handled as a discontinuous window change, but desktop animation and thresholds do not transfer. A finger still down during the fold can miss-hit near the hinge; wait until the fold completes before committing layout, rather than reacting to a half-folded intermediate.

Applying it

• Register fold, unfold, and half-fold as window-metric changes: reflow to the new width, height, and insets. Do not walk a launch page as if this were a new device.
• Keep one task object across cover and inner displays. Do not build two non-communicating UI trees.
• In half-fold, put content only in the region still facing the user and not blocked by the table. Do not assume the full inner display remains tappable.
• Verify by reading to mid-article or filling a form halfway, then folding or unfolding. The same item and the same field should remain; only the layout should change. A return to home, or a dead blank region, means the jump was treated as a restart.

Related

• Within the group: K3.03.2 A fold change has to keep scroll position and input state · K3.03.3 The hinge must not hold anything the user has to read or hit
• Adjacent: K3.01 Large-screen Two-pane Layout · K2.01 Window Management · K1.08 App Switching and Background Reclamation
• Search terms: fold-state transition · posture change · runtime resize