The large screen canonical layouts are proven, versatile app layouts that provide an optimal user experience on large screen devices.
The canonical layouts are responsive and adaptive. They support small screen phones as well as tablets, foldables, and ChromeOS devices. Derived from Material Design guidance, the layouts are aesthetic as well as functional.
The Android framework includes specialized components that make implementation of the layouts straightforward and reliable using either views or Jetpack Compose.
The canonical layouts create engaging, productivity-enhancing UIs that form the foundation of great apps.
If you're already familiar with the large screen canonical layouts but aren't sure which Android APIs to use for your app, jump to Applicability below for help determining which layout is right for your app's use cases.
UX designs for large screens
Discover how much more your app can be on large screens.
Visit the large screen gallery to see a curated collection of large screen layouts.Take a tour
List-detail layout enables users to explore lists of items that have descriptive, explanatory, or other supplementary information—the item detail.
The layout divides the app window into two side-by-side panes: one for the list, one for the detail. Users select items from the list to display the item detail. Deep links in the detail reveal additional content in the detail pane.
Expanded-width displays (see window size classes) accommodate both the list and detail at the same time. Selection of a list item updates the detail pane to show the related content for the selected item.
Medium- and compact-width displays show either the list or the detail, depending on user interaction with the app. When just the list is visible, selection of a list item displays the detail in place of the list. When just the detail is visible, pressing the back button redisplays the list.
Configuration changes such as device orientation changes or app window size changes can change the display's window size class. A list-detail layout responds accordingly, preserving app state:
- If an expanded-width display showing both the list and detail panes narrows to medium or compact, the detail pane remains visible and the list pane is hidden
- If a medium- or compact-width display has just the detail pane visible and the window size class widens to expanded, the list and detail are shown together, and the list indicates that the item corresponding to the content in the detail pane is selected
- If a medium- or compact-width display has just the list pane visible and widens to expanded, the list and a placeholder detail pane are shown together
List-detail is ideal for messaging apps, contact managers, file browsers, or any app where the content can be organized as a list of items that reveal additional information.
A list-detail layout can be created with a variety of technologies, including Compose, views, and activity embedding (for legacy apps). See Applicability below for help deciding which technology is most suitable for your app.
The declarative paradigm of Compose supports window size class logic that determines whether to show the list and detail panes at the same time (when the width window size class is expanded) or just the list or detail pane (when the width window size class is medium or compact).
To ensure unidirectional data flow, hoist all state, including current window size class and detail of the currently selected item (if any), so all composables have access to the data and can render correctly.
When showing just the detail pane on small window sizes, add a
BackHandler to remove the detail pane and display just the list pane. The
BackHandler is not part of the overall app navigation since the handler is dependent on the window size class and selected detail state.
For an example implementation, see the List-detail with Compose sample.
Views and fragments
SlidingPaneLayout library is designed for easy implementation of list-detail layouts based on views or fragments.
First, declare a
SlidingPaneLayout as the root element of your XML layout. Next, add the two child elements—either views or fragments—that represent the list and detail content.
Implement a communication methodology to pass data between the list-detail views or fragments.
ViewModel is recommended because of its ability to store business logic and survive configuration changes.
SlidingPaneLayout automatically determines whether to display the list and detail together or individually. In a window that has enough horizontal space to accommodate both, the list and detail appear side by side. In a window that lacks sufficient space, either the list or detail is displayed depending on the user's interaction with the app.
For an example implementation, see the List-detail with views sample.
Use activity embedding to enable legacy, multiple-activity apps to display two activities side by side on the same screen or stacked one on top of another. If your app implements the list and detail of a list-detail layout in separate activities, activity embedding enables you to easily create a list-detail layout with minimal or no code refactoring.
Implement activity embedding by specifying a task window split using an XML configuration file. The split defines the primary activity, which initiates the split, and a secondary activity. Specify a minimum display width for the split using the window size class breakpoints. When the display width falls below the minimum breakpoint, the activities are displayed one on top of the other. For example, If the minimum display width is 600dp, the activities are displayed one on top of the other on compact displays, but side by side on medium and expanded displays.
Activity embedding is supported on Android 12L (API level 32) and higher, but may also be available on lower API levels if implemented by device manufacturers. When activity embedding is not available on a device, the fallback behavior results in the list activity or the detail activity occupying the entire app window based on user interaction with the app.
For more information, see Activity embedding.
For an example implementation, see the List-detail with activity embedding sample.
A feed layout arranges equivalent content elements in a configurable grid for quick, convenient viewing of a large amount of content.
Size and position establish relationships among the content elements.
Content groups are created by making elements the same size and positioning them together. Attention is drawn to elements by making them larger than nearby elements.
Cards and lists are common components of feed layouts.
A feed layout supports displays of almost any size because the grid can adapt from a single, scrolling column to a multi-column scrolling feed of content.
Feeds are especially well suited for news and social media apps.
A feed consists of a large number of content elements in a vertical scrolling container laid out in a grid. Lazy lists efficiently render a large number of items in columns or rows. Lazy grids render items in grids, supporting configuration of the item sizes and spans.
Configure the columns of the grid layout based on the available display area to set the minimum allowable width for grid items. When defining grid items, adjust column spans to emphasize some items over others.
For section headers, dividers, or other items designed to occupy the full width of the feed, use
maxLineSpan to take up the full width of the layout.
For an example implementation, see the Feed with Compose sample.
Views and fragments
Configure the grid columns based on the size of the available display area to set the minimum allowable width for items.
GridLayoutManager default spanning strategy, which is one span per item, can be overridden by creating a custom
SpanSizeLookup. Adjust the span to emphasize some items over others.
On compact-width displays that have enough space for only one column, use
LinearLayoutManager instead of
For an example implementation, see the Feed with views sample.
Supporting pane layout organizes app content into primary and secondary display areas.
The primary display area occupies the majority of the app window (typically about two thirds) and contains the main content. The secondary display area is a pane that takes up the remainder of the app window and presents content that supports the main content.
Supporting pane layouts work well on expanded-width displays (see window size classes) in landscape orientation. Medium- or compact-width displays support showing both the primary and secondary display areas if the content is adaptable to narrower display spaces, or if the additional content can be initially hidden in a bottom or side sheet accessible by means of a control such as a menu or button.
A supporting pane layout differs from a list-detail layout in the relationship of the primary and secondary content. Secondary pane content is meaningful only in relation to the primary content; for example, a supporting pane tool window is irrelevant by itself. The supplementary content in the detail pane of a list-detail layout, however, is meaningful even without the primary content, for example, the description of a product from a product listing.
Use cases for supporting pane include:
- Productivity apps: A document or spreadsheet accompanied by reviewer comments in a supporting pane
- Media apps: A streaming video complemented by a list of related videos in a supporting pane, or the depiction of an album of music supplemented with a playlist
- Search and reference apps: A query input form with results in a supporting pane
Compose supports window size class logic, which enables you to determine whether to show both the main content and the supporting content at the same time, or place the supporting content in an alternative location.
Hoist all state, including current window size class and information related to the data in the main content and supporting content.
For compact-width displays, place the supporting content below the main content or inside a bottom sheet. For medium and expanded widths, place the supporting content next to the main content, sized appropriately based on the content and space available. For medium width, split the display space equally between the main and supporting content. For expanded width, give 70% of the space to the main content, 30% to the supporting content.
For an example implementation, see the Supporting pane with Compose sample.
Views and fragments
A supporting pane layout is implemented using a helper layout such as
ConstraintLayout. Establish the window size classes that divide the amount of horizontal display space available for your app into three categories: compact (< 600dp), medium (>= 600dp), and expanded (>= 840dp).
For each window size class, define layouts as follows:
- Compact: In the app resources
layoutfolder, place content that renders the supporting pane below the main content or inside a bottom sheet
- Medium: In the
layout-w600dpfolder, provide supporting pane content that results in the main content and supporting pane rendering side by side, splitting the horizontal display space equally
- Expanded: In the
layout-w840dpfolder, include supporting pane content that results in the main content and supporting pane rendering side by side; however, the supporting pane takes up only 30% of the horizontal space, leaving the remaining 70% for the main content
ViewModel for communication between the main content and the supporting pane whether using views, fragments, or a combination.
For implementation examples, see the following samples:
The canonical layouts create multifaceted presentations of content for easy access and deep exploration. Use the following flowchart to determine which layout and implementation strategy is best for your app's use cases.
For examples of the canonical layouts implemented in different types of apps, see the large screen gallery.
- Supporting pane
- Material Design — Canonical layouts
- Migrate your UI to responsive layouts
- Navigation for responsive UIs