Why is Adaptive Layout a Nightmare?
summary
A conference app is reworked into an adaptive layout using WindowManager, WindowSizeClass and Google’s two-pane scaffolds (supporting pane and list-detail) to show lists and details side-by-side; a cyclic dependency is fixed by adding a dedicated pane module and compact/medium component variants are created for landscape height. Practical frictions: floating action buttons must be coordinated at the navigation layer (not yet supported by navigation scaffold), subcomponents cannot read window size class, XML/Compose mixed apps can’t adopt the scaffolds, and a padding bug was recently removed upstream.
AI-written summary · about
chapters (10)
- 0:00Adaptive layout challenges
- 1:29Android architecture limits
- 3:40Tools for adaptive layout
- 9:25Higher-level solutions
- 10:29Conference app case study
- 14:47Component architecture approach
- 20:48Navigation Suite Scaffold
- 23:43Supporting Pane and List Detail
- 28:33Material design conflicts
- 35:00Challenges and conclusion
related talks
42mWhy is adaptive layout a nightmare?
26mMaking Apps adaptive with Material and Compose
43mThe Nightmare of Adaptive Layouts
33mBuild adaptive apps with Jetpack Compose
35mAdaptive Layouts in Compose
21mBuilding an adaptive layout with SlidingPaneLayout
18mCanonical layouts and visual hierarchy: Designing for larger screens
01h 01mComposing large screens