HarmonyOS 7 Floating Tabs: Window-Width-Driven Layouts for Foldables & Tablets

Why Device-Type Branching Fails

Developers often write layout branches based on device names (phone, tablet, foldable). However, a tablet in split-screen may have only a few hundred vp of width, while a foldable can be folded, unfolded, split-screened, or rotated. Asking "is this a tablet?" no longer answers whether the page should show one, two, or three columns.

The author advocates keeping device names in test logs and letting layout logic depend solely on the currently available container space. HarmonyOS's multi-device design emphasizes that when window size, orientation, or split-screen state changes, the page should rearrange information; foldables must also preserve app state continuity while using new space for valuable content.

Large-Screen Adaptation ≠ Stretching Phone Layouts

Three cards stacked vertically on a phone work fine, but on an unfolded foldable or tablet, stretching each card to full width yields longer text lines, excessive whitespace, and distant touch targets. Better approaches include increasing column count, adding auxiliary areas, limiting max content width, or switching to multi-column layouts. HarmonyOS design examples use repositioning, duplication, and column splits rather than simple stretching.

Demo Approach: ContainerReader for Content, HdsTabs for Navigation

The demo uses ContainerReader at the page root to observe the actual available width and height. The content area adjusts column count and margins based on width, while HdsTabs independently manages its floating navigation width via smallWidth, mediumWidth, largeWidth. When the window changes, layout reflows but the current tab and business state persist.

Testing is done on the HarmonyOS 7 emulator; real-device validation is still needed for folding motion, true split-screen, touch distances, and final rendering.

Confirm Available Space Before Deciding Layout

On phones, device width ≈ window width. On tablets, foldables, and 2-in-1s, that relationship breaks: apps may occupy full screen, a portion, or be resized freely. Huawei's free-form window troubleshooting docs cite clipping, component squeezing, and stacking as typical issues — both window state and size changes must feed layout decisions.

The demo reads the page container directly via ContainerReader, which reports the component's own allocated space, not the physical screen. Placed at the page root, it yields the full page size; if moved into a Navigation content pane or a split column, it naturally reflects that local region. This is crucial for component reuse: a workspace component that fills a phone screen but sits in a tablet's right pane should not assume wide-screen layout just because the device is a tablet.

Breakpoints Derived from Content Needs

The demo defines four layout states via three width thresholds:

< 440 vp : single column, tighter margins — ensure cards and text remain intact.

440–600 vp : single column, increased margins — space grows but not enough for stable two columns.

600–840 vp : two columns — use added horizontal space to increase on-screen information density.

≥ 840 vp : three columns — increase content density in large windows, and cap overall width.

These numbers are observation breakpoints, not fixed device specs. In production, the author prefers deriving breakpoints from the card itself: determine the minimum card width for readable text and operable buttons, then decide when to add a second or third column. This ties breakpoints directly to content, so they remain valid across devices. ContainerReader 's size binding must stay one-way: the container writes the actual layout result, business reads it to decide arrangement; business must not modify size expecting the container to grow. Parent provides constraints, ContainerReader reports final allocated space — reversing this causes circular dependencies.

Two Independent Responsive Systems on One Page

The demo runs two separate responsive rule sets:

Business content : ContainerReader drives column count (1/2/3), page margins, and max content width.

HdsTabs : its own smallWidth / mediumWidth / largeWidth (228/300/328 vp) control floating bar width based on the tab bar's own size. HdsTabs works on Phone, PC/2-in-1, Tablet; TV has behavioral differences.

Merging them into a global small/medium/large state is tempting but discouraged. Content switches to two columns at 600 vp, but HdsTabs may still be in its small or medium tier depending on its own aspect-ratio logic. Letting each respond to its real size is simpler and more robust.

The content area actively uses extra space: phone shows six cards in one column; at 600–700 vp two columns let users see more tasks; wider windows shift to three columns, which feels better than a single card spanning the whole width. Beyond ~1120 vp the demo caps content width at 1120 vp, leaving side margins — stretching further only adds whitespace and separates titles from actions. This matches HarmonyOS large-screen patterns: card repetition, vertical-to-horizontal restructuring, master-detail side-by-side — all aiming to fill new space with new information or task relationships.

Preserving Business State Across Layout Changes

Layout reflow (1→2→3 columns) is straightforward; the real risk is losing user context. If a user is halfway through a form on the Tasks tab, then unfolds the foldable or drags a split-screen divider from 580 vp to 650 vp, the layout must reflow but the form input, current tab, filters, and scroll position must survive.

This is the continuity experience foldable design stresses: screen size and shape may change, the app must keep running and retain the user's task.

The demo retains a single HdsTabsController and currentIndex throughout. ContainerReader updates container size and layout tier; cards reflow per new width; the user's tab location (Home, Tasks, Mine) is separate state, not recreated when column count changes. In small demos this seems deliberate; in real projects it's critical.

The author splits state into two categories:

Layout state : window width, column count, margins — can update continuously with container changes.

Business state : form content, current task, playback progress, selected items — stored in stable locations.

Binding them together causes hard-to-debug issues: e.g., a developer swaps entire page structures at a breakpoint, destroying the old page and creating a new one. Visually it becomes two columns, but the user's input vanishes. Every code piece looks correct, yet the experience breaks.

Foldables amplify this because fold/unfold happens frequently. Users don't think they reopened the app; they just unfolded the device. If each fold triggers a full data refetch, homepage reset, or scroll loss, the app feels unstable.

Window size changes should only trigger layout rearrangement. Only business logic that truly depends on physical fold state (e.g., content spanning the hinge, hover interactions) needs to observe fold posture. Ordinary lists shouldn't refetch data just because the device unfolded.

This separation also future-proofs navigation changes: e.g., narrow window uses bottom HdsTabs, wide window switches to a left sidebar. If both share the same selected index and business data, only the navigation entry point moves; if each maintains its own page state, rapid window toggling leads to one side showing Tasks while the other thinks it's on Home.

Sidebar Navigation? Depends on Page, Not Device

Above ~800 vp the question arises: keep bottom tabs or switch to a sidebar? No need to pre-bind to device type.

Lightweight apps with three top-level entries may keep bottom floating tabs even on large foldables/tablets — users are used to frequent switching, the bar occupies little space, and forcing a sidebar yields little gain.

Apps with five or six primary entries, tree directories, file lists, tool panels, and mouse/keyboard usage on wide screens benefit from a persistent left sidebar showing navigation while the right side displays more content — a common wide-screen pattern. HdsTabs currently only supports horizontal bottom layouts ( vertical, barPosition, barOverlap, barFloatingStyle control tab direction, position, and floating). True sidebar navigation is a different paradigm; you can't just move the floating style to the left.

The demo deliberately avoids auto-switching to a sidebar at 840 vp to isolate variables: this page focuses on how the same HdsTabs behaves during continuous window changes — content reflow and navigation stability. Swapping the navigation container simultaneously would make debugging ambiguous (content breakpoint vs. navigation rebuild).

Real projects can decide based on information architecture: few entries, touch-heavy, shallow hierarchy → evaluate bottom floating; many entries, deeper hierarchy, clear wide-screen residency → evaluate sidebar. The decision hinges on page usage patterns, not whether the device is a tablet.

A tablet squeezed into split-screen may find its previously comfortable sidebar now cramping content; a 2-in-1 window can be resized to phone-like dimensions. Judging by window and business space yields far more stable logic.

Regression Testing: Continuous Window Drag, Not Static Screenshots

The author recommends testing by continuously dragging the window width while on a stateful page (e.g., Tasks tab), passing through 440, 600, 840, and the max-content-width vicinity. Observe: when do columns increase? Do margins jump? Does the current tab persist? Can the last action item still scroll above the floating bar?

Breakpoint boundaries deserve extra back-and-forth. If 599 vp and 601 vp show a drastic visual shift, the two tiers may be too different; if the layout flickers between states with tiny window movements, re-check the size source and threshold logic.

Emulators excel at continuous window experiments and repeated split-screen/free-form entry. Physical foldables, hinge positions, actual touch distances, mouse/keyboard, and hardware window behavior still require real-device validation. HarmonyOS's multi-device guidelines likewise evaluate phones, foldables, tablets under different window shapes and interaction conditions.

Summary

Reduce the habit of writing separate layouts for tablet vs. foldable. Instead, confirm the current content area's available space, then decide card, margin, and navigation arrangement. ContainerReader handles business content; HdsTabs follows its own component rules for floating tab width. Both react to real size, each owning its responsibility — no forced shared "large-screen state".

As windows grow, pages must consider how to truly use new space: add columns, add auxiliary areas, limit reading width, or go multi-column. Merely stretching the phone layout horizontally only makes the page bigger, not more suitable for large screens.

Guard task continuity above all. Fold, unfold, split-screen, free-form are normal user flows; layout may change constantly, but current tab, form content, filters, and scroll state must persist. Separating layout state from business state makes future navigation changes (bottom tabs ↔ sidebar) much easier.

Current validation uses HarmonyOS 7 emulator for window changes, content reflow, and basic interaction. Folding motion, real split-screen, input device differences, and final visual effects must be verified on actual devices.