Układy kanoniczne

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.

Jeśli wiesz już, czym są kanoniczne układy aplikacji dostosowanych do urządzenia, ale nie wiesz, których interfejsów API Androida użyć, przejdź do sekcji Zastosowanie, aby dowiedzieć się, który układ jest odpowiedni do Twoich zastosowań aplikacji.

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

Układ listy z informacjami szczegółowymi można tworzyć za pomocą różnych technologii, w tym Compose, widoków i osadzania aktywności (w przypadku starszych aplikacji). Aby zdecydować, która technologia najlepiej sprawdzi się w Twojej aplikacji, zapoznaj się z sekcją Zastosowanie.

Biblioteka SlidingPaneLayout jest przeznaczona do implementacji układów szczegółów listy na podstawie widoków lub fragmentów.

Najpierw zadeklaruj element SlidingPaneLayout jako element główny układu XML. Następnie dodaj 2 elementy podrzędne – widoki lub fragmenty – które reprezentują listę i treści szczegółowe.

Zaimplementuj metodologię komunikacji, aby przekazywać dane między widokami lub fragmentami szczegółów listy. Zalecamy korzystanie z wersji ViewModel, ponieważ pozwala ona na przechowywanie logiki biznesowej i przetrwanie zmian konfiguracji.

SlidingPaneLayout automatycznie określa, czy wyświetlić listę i szczegóły razem czy osobno. W oknie, które ma wystarczającą ilość wolnego miejsca w poziomie, by pomieścić zarówno listę, jak i szczegóły, pojawią się obok siebie. W oknie, w którym brakuje miejsca, w zależności od interakcji użytkownika z aplikacją wyświetlana jest lista lub szczegóły.

Przykładową implementację znajdziesz w artykule Lista i szczegóły z przesuwnym panelem.

Umieszczanie aktywności

Dzięki osadzeniu aktywności starsze aplikacje obsługujące wiele aktywności mogą wyświetlać 2 aktywności obok siebie na tym samym ekranie lub skumulowane (jedna nakłada się na drugą). Jeśli Twoja aplikacja implementuje listę i szczegóły w ramach układu lista–szczegóły w oddzielnych aktywnościach, umieszczanie aktywności umożliwia tworzenie układu lista–szczegóły z minimalną ilością kodu lub bez niej.

Wdroż umieszczanie aktywności, określając podział okna zadania za pomocą pliku konfiguracji XML. Podział definiuje główną aktywność, która inicjuje podział, oraz aktywność dodatkową. Określ minimalną szerokość wyświetlania dla podziału, używając punktów granicznych klasy rozmiaru okna. Gdy szerokość wyświetlania spadnie poniżej minimalnego punktu przecięcia, aktywności będą się na siebie nakładać. Jeśli na przykład minimalna szerokość wyświetlacza wynosi 600 dp, aktywności są wyświetlane na wyświetlaczach kompaktowych nachodzące na siebie, a na wyświetlaczach średnich i rozszerzonych obok siebie.

Osadzanie aktywności jest obsługiwane w Androidzie 12L (API na poziomie 32) lub nowszym, ale może być też dostępne na niższych poziomach interfejsu API, jeśli zostanie zaimplementowane przez producentów urządzeń. Gdy umieszczanie aktywności nie jest dostępne na urządzeniu, działanie kreacji zastępczej powoduje, że działanie listy lub szczegółów zajmuje całe okno aplikacji zależnie od interakcji użytkownika z aplikacją.

Więcej informacji znajdziesz w artykule Otwieranie aktywności w ramach innych aplikacji.

Przykładową implementację znajdziesz w pliku List-detail with activity embedding.

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

RecyclerView efektywnie renderuje dużą liczbę elementów w jednej kolumnie. Element GridLayoutManager rozmieszcza elementy w siatce, umożliwiając konfigurowanie ich rozmiarów i zakresów.

Konfiguruj kolumny siatki na podstawie rozmiaru dostępnej powierzchni wyświetlania, aby ustawić minimalną dozwoloną szerokość elementów.

Domyślną strategię obejmującą GridLayoutManager, która obejmuje jeden element na element, możesz zastąpić, tworząc niestandardową SpanSizeLookup. Dostosuj rozpiętość, aby niektóre elementy były bardziej eksponowane.

Na wyświetlaczach o kompaktowej szerokości, które mają wystarczającą ilość miejsca na tylko jedną kolumnę, użyj LinearLayoutManager zamiast GridLayoutManager.

Przykładową implementację znajdziesz w przykładzie pliku danych z widokami.

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

Układ panelu pomocniczego jest implementowany za pomocą układu pomocniczego, takiego jak LinearLayout lub ConstraintLayout. Określ klasy rozmiaru okna dzielącą ilość dostępnego dla aplikacji miejsca w poziomie na 3 kategorie: kompaktowa (< 600 dp), średnia (>= 600 dp) i rozszerzona (>= 840 dp).

W przypadku każdej klasy rozmiaru okna zdefiniuj układy w ten sposób:

  • Kompaktowy: w folderze zasobów aplikacji layout umieść treść, która renderuje panel pomocniczy pod główną treścią lub wewnątrz planszy dolnej
  • Średnie: w folderze layout-w600dp umieść treści panelu pomocniczego, które będą renderowane obok treści głównych, dzieląc poziomą przestrzeń wyświetlania na równe części.
  • Rozwinięte: w folderze layout-w840dp umieść treści w panelu pomocniczym, które będą renderowane obok treści głównych. Panel pomocniczy zajmuje tylko 30% poziomej przestrzeni, a pozostałe 70% zostanie przeznaczone na treści główne.

Używaj ViewModel do komunikacji między główną treścią a stroną za pomocą widoków, fragmentów lub kombinacji.

Przykłady implementacji:

Zastosowanie

Układy kanoniczne umożliwiają tworzenie wieloaspektowych treści, które są łatwo dostępne i można je dokładnie poznać. Poniższy schemat blokowy pomoże Ci określić układ i strategię implementacji, które najlepiej sprawdzą się w przypadku Twojej aplikacji.

Przykłady kanonicznej wersji układu zaimplementowanej w różnych typach aplikacji znajdziesz w galerii dużych ekranów.

Rysunek 4. Schemat decyzyjny dotyczący kanonicznego układu na dużym ekranie.

Additional resources