Kanonische Layouts

Kanonische Layouts sind bewährte, vielseitige Layouts, die auf einer Vielzahl von Formfaktoren eine optimale Nutzerfreundlichkeit bieten.

Abbildung von Geräten mit großem Display mit den kanonischen Layouts.

Die kanonischen Layouts unterstützen Smartphones mit kleinen Bildschirmen sowie Tablets, faltbare Geräte und ChromeOS-Geräte. Die Layouts basieren auf den Material Design-Richtlinien und sind sowohl ästhetisch als auch funktional.

Das Android-Framework enthält spezielle Komponenten, die die Implementierung der Layouts einfach und zuverlässig machen.

Die kanonischen Layouts ermöglichen ansprechende, produktivitätssteigernde Benutzeroberflächen, die die Grundlage für großartige Apps bilden.

Wenn Sie bereits mit den kanonischen adaptiven App-Layouts vertraut sind, aber noch nicht welche Android-APIs Sie verwenden sollen, erfahren Sie hier .

Listen-Detailansicht

Wireframe des Listen-/Detail-Layouts.

Mit dem Layout „Liste – Details“ können Nutzer Listen mit Elementen aufrufen, die beschreibende, erklärende oder andere zusätzliche Informationen enthalten – die Elementdetails.

Bei diesem Layout wird das App-Fenster in zwei nebeneinanderliegende Bereiche unterteilt: einen für die Liste und einen für die Details. Nutzer wählen Elemente aus der Liste aus, um die zugehörigen Details aufzurufen. Über Deeplinks in den Details werden zusätzliche Inhalte im Detailbereich angezeigt.

Auf Displays mit erweiterter Breite (siehe Fenstergrößenklassen verwenden) können sowohl die Liste als auch die Details gleichzeitig angezeigt werden. Wenn Sie ein Listenelement auswählen, wird der Detailbereich aktualisiert und es werden die zugehörigen Inhalte für das ausgewählte Element angezeigt.

Auf Displays mit mittlerer und kompakter Breite wird je nach Nutzerinteraktion mit der App entweder die Liste oder die Detailansicht angezeigt. Wenn nur die Liste sichtbar ist, wird durch Auswahl eines Listenelements die Detailansicht anstelle der Liste angezeigt. Wenn nur die Detailansicht sichtbar ist, wird durch Drücken der Zurück-Schaltfläche die Liste wieder angezeigt.

Konfigurationsänderungen wie Änderungen der Geräteausrichtung oder der App-Fenstergröße können die Fenstergrößenklasse des Displays ändern. Ein Layout mit Liste und Detailansicht reagiert entsprechend und behält den App-Status bei:

  • Wenn ein Display mit erweiterter Breite, auf dem sowohl die Liste als auch der Detailbereich angezeigt werden, auf eine mittlere oder kompakte Breite verkleinert wird, bleibt der Detailbereich sichtbar und der Listenbereich wird ausgeblendet.
  • Wenn auf einem Display mit mittlerer oder kompakter Breite nur der Detailbereich sichtbar ist und sich die Fenstergrößenklasse auf „Erweitert“ ändert, werden Liste und Details zusammen angezeigt. In der Liste wird angegeben, dass das Element, das dem Inhalt im Detailbereich entspricht, ausgewählt ist.
  • Wenn auf einem Display mit mittlerer oder kompakter Breite nur der Listenbereich sichtbar ist und es auf die erweiterte Breite vergrößert wird, werden die Liste und ein Platzhalter-Detailbereich zusammen angezeigt.

Die Listen-/Detailansicht eignet sich ideal für Messaging-Apps, Kontaktmanager, interaktive Media-Browser oder Apps, in denen Inhalte als Liste von Elementen organisiert werden können, die zusätzliche Informationen enthalten.

Abbildung 1. Messaging-App mit einer Liste von Unterhaltungen und den Details einer ausgewählten Unterhaltung.

Implementierung

A list-detail layout can be created with a variety of technologies, including Compose, views, and activity embedding (for legacy apps). See the Applicability section for help deciding which technology is most suitable for your app.

The SlidingPaneLayout library is designed for 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 sliding pane sample.

Activity embedding

Use activity embedding to enable legacy, multiple-activity apps to display two activities side by side on the same screen or stacked (one overlaying the other). If your app implements the list and detail of a list‑detail layout in separate activities, activity embedding enables you to 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 overlaying the other. For example, if the minimum display width is 600dp, the activities are displayed one overlaying 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.

Feed

Wireframe des Feedlayouts.

Bei einem Feed-Layout werden gleichwertige Inhaltselemente in einem konfigurierbaren Raster angeordnet, damit sich eine große Menge an Inhalten schnell und bequem ansehen lässt.

Größe und Position stellen Beziehungen zwischen den Inhaltselementen her.

Contentgruppen werden erstellt, indem Elemente die gleiche Größe erhalten und zusammen positioniert werden. Elemente werden hervorgehoben, indem sie größer als die benachbarten Elemente dargestellt werden.

Karten und Listen sind gängige Komponenten von Feedlayouts.

Ein Feedlayout unterstützt Displays fast jeder Größe, da sich das Raster von einer einzelnen scrollenden Spalte zu einem mehrspaltigen scrollenden Feed mit Inhalten anpassen kann.

Feeds eignen sich besonders gut für Nachrichten- und Social-Media-Apps.

Abbildung 2. Social-Media-App mit Beiträgen in unterschiedlich großen Karten

Implementierung

Ein RecyclerView rendert effizient eine große Anzahl von Elementen in einer einzelnen Spalte. Mit GridLayoutManager werden Elemente in einem Raster angeordnet, sodass die Elementgrößen und -spannen konfiguriert werden können.

Konfigurieren Sie die Rasterspalten anhand der Größe des verfügbaren Anzeigebereichs, um die minimal zulässige Breite für Elemente festzulegen.

Die Standard-Spannungsstrategie von GridLayoutManager, also eine Spanne pro Element, kann überschrieben werden, indem eine benutzerdefinierte SpanSizeLookup erstellt wird. Passen Sie die Spannweite an, um bestimmte Elemente stärker hervorzuheben.

Auf Displays mit kompakter Breite, die nur Platz für eine Spalte bieten, verwenden Sie anstelle von GridLayoutManager den Befehl LinearLayoutManager.

Eine Beispielimplementierung findest du im Beispiel Feed mit Aufrufen.

Unterstützender Bereich

Wireframe des Layouts des unterstützenden Bereichs.

Das Layout mit Unterstützung für Bereiche unterteilt App-Inhalte in primäre und sekundäre Anzeigebereiche.

Der primäre Anzeigebereich nimmt den Großteil des App-Fensters ein (in der Regel etwa zwei Drittel) und enthält die Hauptinhalte. Der sekundäre Anzeigebereich ist ein Bereich, der den Rest des App-Fensters einnimmt und Inhalte präsentiert, die den Hauptinhalt unterstützen.

Unterstützende Bereichslayouts eignen sich gut für Displays mit erweiterter Breite (siehe Fenstergrößenklassen verwenden) im Querformat. Auf Displays mit mittlerer oder kompakter Breite können sowohl der primäre als auch der sekundäre Anzeigebereich angezeigt werden, wenn der Inhalt an schmalere Anzeigebereiche angepasst werden kann oder wenn der zusätzliche Inhalt anfangs in einem Bottom Sheet oder Side Sheet verborgen werden kann, auf das über ein Steuerelement wie ein Menü oder eine Schaltfläche zugegriffen werden kann.

Das Layout eines unterstützenden Bereichs unterscheidet sich vom Listen-/Detail-Layout in der Beziehung zwischen primärem und sekundärem Inhalt. Inhalte im sekundären Bereich sind nur in Bezug auf die primären Inhalte sinnvoll. Ein unterstützendes Toolfenster im sekundären Bereich ist beispielsweise für sich genommen irrelevant. Die zusätzlichen Inhalte im Detailbereich eines Listen-/Detail-Layouts sind jedoch auch ohne die primären Inhalte sinnvoll, z. B. die Beschreibung eines Produkts aus einer Produktliste.

Anwendungsfälle für das Unterstützungspanel:

Abbildung 3: Shopping-App mit Produktbeschreibungen in einem unterstützenden Bereich.

Implementierung

Ein unterstützendes Steuerfeld-Layout wird mit einem Hilfslayout wie LinearLayout oder ConstraintLayout implementiert. Fenstergrößenklassen festlegen die die für Ihre App verfügbare horizontale Anzeigefläche in drei Kategorien: „Kompakt“ (< 600 dp), „mittel“ (>= 600 dp) und „Erweitert“ (≥ 840 dp).

Definieren Sie die Layouts für jede Fenstergrößenklasse wie folgt:

  • Kompakt:Platzieren Sie im Ordner layout der App-Ressourcen Inhalte, die Rendert den unterstützenden Bereich unter dem Hauptinhalt oder in einem Tabellenblatt am unteren Rand
  • Mittel: Geben Sie im Ordner layout-w600dp unterstützende Inhalte des Bereichs an. sodass der Hauptinhalt und der unterstützende Bereich nebeneinander gerendert werden, gleichmäßige Aufteilung der horizontalen Anzeigefläche
  • Maximiert: Fügen Sie im Ordner layout-w840dp Inhalte für den Infobereich hinzu, sodass sich der Hauptinhalt und der Infobereich nebeneinander darstellen. Der Infobereich nimmt jedoch nur 30 % des horizontalen Bereichs ein, sodass die restlichen 70 % für den Hauptinhalt übrig bleiben.

Verwenden Sie ein ViewModel für die Kommunikation zwischen dem Hauptinhalt und dem unterstützenden Scheiben, ob mit Ansichten, Fragmenten oder einer Kombination.

Implementierungsbeispiele finden Sie in den folgenden Beispielen:

Geltungsbereich

Die kanonischen Layouts ermöglichen eine vielseitige Präsentation von Inhalten für einfachen Zugriff und detaillierte explorative Datenanalysen. Anhand des folgenden Flussdiagramms können Sie ermitteln, welche Layout- und Implementierungsstrategie für die Anwendungsfälle Ihrer App am besten geeignet ist.

Beispiele für die kanonischen Layouts, die in verschiedenen Arten von Apps implementiert sind, finden Sie in der Galerie für große Bildschirme.

Abbildung 4: Entscheidungsbaum für das kanonische Layout auf großen Bildschirmen

Zusätzliche Ressourcen