feat(ui): large-screen layout - adaptive nav, content max-width, unlock rotation - #47
Merged
Merged
Conversation
Replaces the fixed bottom NavigationBar with Material3's NavigationSuiteScaffold, which renders the top-level destinations as a bottom bar on compact widths (phones) and a navigation rail on wider ones (tablets, landscape, foldables, large/free-form windows). Non-top-level (full-screen) destinations show no nav chrome, as before. Breakpoint is the standard 600dp compact/medium width. First step of large-screen support: a tablet in portrait is already wide enough to get the rail, so the app stops looking like a stretched phone without any per-screen changes. Content max-width and list/detail two-pane layouts are follow-ups.
Wraps the NavHost content so a single pane doesn't stretch across a whole tablet: content is capped at 840dp and centred, with gutters beyond that. widthIn is a no-op below the cap, so phones and split-screen are unaffected. The relationship graph opts out (FULL_BLEED_ROUTES) since the pan/zoom canvas wants the whole area. Second step of large-screen support, on top of the adaptive navigation.
MainActivity was locked to portrait, so on a landscape tablet or foldable the system pillar-boxed the whole window - black bars either side of the app, including the navigation rail. Dropping the orientation lock lets the app fill the window and rotate, which the adaptive navigation and content max-width already handle. Android 16 forces this on large screens anyway once we bump targetSdk, so this gets us there ahead of the deadline.
4 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Large-screen / tablet support at the app-root chrome level (part of #65). Two related changes, both in
SheafApp.1. Adaptive top-level navigation
Swaps the fixed bottom
NavigationBarfor Material3'sNavigationSuiteScaffold, which adapts the top-level chrome to the window width:NavigationSuiteType.None), same as before.Breakpoint is the standard 600dp compact/medium split, read from the window width so it reacts live to resize / multi-window. Destinations, selection state, and back-stack-preserving navigation are unchanged; only the container drawing them changed.
New dependency:
androidx.compose.material3:material3-adaptive-navigation-suite, pinned to thematerial3version (1.5.0-alpha17).2. Content max-width on wide windows
Wraps the
NavHostcontent so a single pane doesn't stretch across a whole tablet: capped at 840dp and centred, with gutters beyond that.widthInis a no-op below the cap, so phones and split-screen are untouched. The relationship graph opts out (FULL_BLEED_ROUTES) because the pan/zoom canvas wants the whole area.3. Drop the portrait orientation lock
MainActivitywas locked toportrait, so on a landscape tablet or foldable the system pillar-boxed the whole window - black bars either side of the app, including the rail. Removing the lock lets the app fill the window and rotate; the adaptive nav + content cap above handle the resulting widths. Android 16 forces this on large screens once we bump targetSdk, so it's on the path anyway.Follow-ups (not here)
ListDetailPaneScaffold, and/or a multi-column card grid on Home - the real way to use the extra landscape width rather than leaving gutters.Testing
:app:assemblePlayRelease :app:testPlayReleaseUnitTestgreen. Device checklist: