Two modules with the same name, one is a demo shell
A generator wrote a feature into a template demo module sharing the real one's name. Resolve the target from disk and halt on ambiguity rather than picking.
kotlin
120 posts
An external display is a second window, not a bigger one
Android 16 makes external displays a mainstream concern. The layout work is mostly window size classes you already have; the new parts are density, input capability and deciding what belongs on which screen.
adb install -r doesn't kill your app, so your screenshot is a lie
Reinstalling over a running app can leave the old composition on screen. A screenshot taken without a force-stop cannot say which build drew it.
A hinge is a physical object, and your layout should know where it is
Foldables give two things a resize doesn't: a posture and a hinge with real coordinates. Handling them well means avoiding the seam and using tabletop mode, not just supporting a new width.
SupportingPaneScaffold is for content that is about other content
SupportingPaneScaffold docks secondary content beside a primary view on wide windows and collapses it to a sheet on narrow ones. Choosing it over list-detail is a question about what the second pane contains.
ListDetailPaneScaffold: the back button is the whole reason it exists
ListDetailPaneScaffold adapts a list and detail across window sizes, but its real value is the navigator — which makes back pop the detail on compact and exit the screen on expanded, from one implementation.
There are three adaptive layouts, and you probably don't need a fourth
Material's canonical layouts give three tested patterns for adapting across window sizes. Knowing which one a screen is saves designing an adaptive layout from scratch, and the library implements two of them directly.
Screen size is the wrong thing to branch on. Window size is the right one.
Window size classes replace device-type checks with a measure of the window your app actually occupies. Three buckets per axis, recomputed live, and the reason isTablet() has been wrong for years.
Porting FlexboxLayout: every flex property maps onto something, but not onto one thing
There is no FlexboxLayout in Compose because flex's properties split cleanly across Row/Column, Arrangement, Alignment and FlowRow. A direct property-by-property mapping for anyone porting a View layout.
Sometimes the right grid is a Column of Rows
Not every grid needs LazyVerticalGrid. For a small fixed set — a keypad, a colour picker, a dashboard — a Column of Rows is simpler, cheaper and easier to reason about. Knowing the cutoff matters.
FlowRow is the chip group you kept writing a custom Layout for
FlowRow and FlowColumn wrap children onto new lines when they run out of room. They replace the custom Layout most codebases wrote for chip groups, and the overflow API handles the 'and 4 more' case.
HorizontalPager is a lazy list that snaps — and PagerState is where the bugs live
HorizontalPager brings paging into Compose with no external dependency. The interesting surface is PagerState — currentPage versus settledPage, scroll versus animateScrollToPage, and how to sync tabs without a loop.