Diseños canónicos

Canonical layouts are proven, versatile layouts that provide an optimal user experience on a variety of form factors.

Depiction of large screen devices showing the canonical layouts.

The canonical layouts 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.

The canonical layouts create engaging, productivity‑enhancing UIs that form the foundation of great apps.

Si ya conoces los diseños canónicos de apps adaptables, pero no sabes qué APIs de Android usar, consulta la sección Aplicabilidad para obtener ayuda y determinar cuál es el diseño correcto para los casos de uso de tu app.

List-detail

Wireframe of list-detail layout.

The 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 Use 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.

Figure 1. Messaging app showing a list of conversations and the details of a selected conversation.

Implementation

Se puede crear un diseño de lista-detalles con una variedad de tecnologías, como Compose, vistas y la incorporación de actividades (para apps heredadas). Consulta la sección Aplicabilidad para obtener ayuda y decidir qué tecnología se adapta mejor a tu app.

La biblioteca SlidingPaneLayout está diseñada para implementar diseños de lista-detalles basados en vistas o fragmentos.

Primero, declara un SlidingPaneLayout como elemento raíz de tu diseño XML. A continuación, agrega los dos elementos secundarios (vistas o fragmentos) que representen el contenido de la lista y los detalles.

Implementa una metodología de comunicación para pasar datos entre las vistas de lista-detalles o los fragmentos. Se recomienda ViewModel debido a su capacidad de almacenar la lógica empresarial y permanecer vigente ante los cambios de configuración.

SlidingPaneLayout determina automáticamente si se muestran la lista y los detalles juntos o de forma individual. En una ventana que tiene suficiente espacio horizontal para adaptarse a ambas, la lista y los detalles aparecen uno al lado del otro. En una ventana que no tiene suficiente espacio, se muestran la lista o los detalles según la interacción del usuario con la app.

Para ver una muestra de implementación, consulta el ejemplo de lista y detalles con panel deslizante.

Incorporación de actividades

Usa la incorporación de actividades para permitir que las apps heredadas de varias actividades muestren dos actividades una al lado de la otra en la misma pantalla o apiladas (una superpuesta a la otra). Si tu app implementa la lista y los detalles de un diseño de lista-detalles en actividades separadas, la incorporación de actividades te permite crear un diseño de lista-detalles con una refactorización de código mínima o nula.

Para implementar la incorporación de actividades, especifica una división de la ventana de tareas con un archivo de configuración XML. La división define la actividad principal, que inicia la división, y una actividad secundaria. Especifica un ancho de pantalla mínimo para la división usando los puntos de interrupción de clase de tamaño de ventana. Cuando el ancho de la pantalla es inferior al punto de interrupción mínimo, las actividades se muestran una superpuesta a la otra. Por ejemplo, si el ancho mínimo de la pantalla es de 600 dp, las actividades se mostrarán una superpuesta a la otra en pantallas compactas, pero en paralelo en pantallas medianas y expandidas.

La incorporación de actividades es compatible con Android 12L (nivel de API 32) y versiones posteriores, pero también puede estar disponible en niveles de API inferiores si los fabricantes de dispositivos la implementan. Cuando la incorporación de actividades no está disponible en un dispositivo, el comportamiento de resguardo causa que la actividad de lista o la actividad de detalles ocupe toda la ventana de la app según la interacción del usuario con ella.

Para obtener más información, consulta Incorporación de actividades.

Para ver una muestra de implementación, consulta el ejemplo de lista y detalles con incorporación de actividades.

Feed

Wireframe of feed layout.

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.

Figure 2. Social media app showing posts in cards of varying sizes.

Implementation

A RecyclerView efficiently renders a large number of items in a single column. A GridLayoutManager lays out items in a grid, allowing configuration of the item sizes and spans.

Configure the grid columns based on the size of the available display area to set the minimum allowable width for items.

The 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 GridLayoutManager.

For an example implementation, see the Feed with views sample.

Supporting pane

Wireframe of supporting pane layout.

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 Use 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
Figure 3. Shopping app with product descriptions in a supporting pane.

Implementation

Se implementa un diseño de panel complementario con un diseño de ayuda, como LinearLayout o ConstraintLayout. Establece las clases de tamaño de ventana que dividen la cantidad de espacio de visualización horizontal disponible para tu app en tres categorías: compacta (<600 dp), medio (>= 600 dp) y expandido (>= 840 dp).

Para cada clase de tamaño de ventana, define diseños de la siguiente manera:

  • Compacta: En la carpeta layout de recursos de la app, coloca el contenido que renderiza el panel complementario debajo del contenido principal o dentro de una hoja inferior.
  • Mediana: En la carpeta layout-w600dp, proporciona el contenido del panel complementario que genera el contenido principal y la renderización del panel complementario uno al lado del otro dividiendo el espacio horizontal de la pantalla en partes iguales
  • Expandida: En la carpeta layout-w840dp, incluye contenido del panel complementario que genere que el contenido principal y el panel complementario se rendericen en paralelo. Sin embargo, el panel complementario solo ocupa el 30% del espacio horizontal, lo que deja el 70% restante para el contenido principal.

Usa un objeto ViewModel para la comunicación entre el contenido principal y el panel complementario, ya sea con vistas, fragmentos o una combinación.

Para ver muestras de implementación, consulta los siguientes ejemplos:

Applicability

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.

Figure 4. Large screen canonical layout decision tree.

Additional resources