Von Kacheln zu Widgets migrieren

Sowohl Kacheln als auch Widgets zeigen Ihre Inhalte auf einer Remote-Systemoberfläche an. Für die Entwicklung sind jedoch unterschiedliche Ansätze erforderlich. Wenn Sie Ihre vorhandene Kachel zu einem Widget migrieren, wechseln Sie von einer starren Layoutgenerierung zu einer dynamischen, deklarativen Benutzeroberfläche. Dadurch werden neue Funktionen und ein vereinfachtes Entwicklungsmodell ermöglicht.

Implementierungsstrategie auswählen

Wenn Sie eine App migrieren, die eine alte Kachel enthält, müssen Sie entscheiden, wie Ihre App Inhalte für das System bereitstellt. Während für brandneue Widgets ein einzelner Widget-Dienst verwendet werden sollte, müssen Apps mit vorhandenen Kacheln zwischen der Beibehaltung beider Dienste oder der Konsolidierung in einem einzelnen Widget-Dienst wählen.

Empfohlen: Dualer Dienst (Kachel + Widget)

Für alle Apps, die bereits eine Kachel haben, wird empfohlen, sowohl eine Kachel als auch ein Widget zu pflegen. Durch die Bereitstellung von zwei separaten Diensten wird die bestmögliche Nutzererfahrung auf verschiedenen Geräten ermöglicht.

Systemverhalten bei Einrichtung von zwei Diensten:

Betriebssystem / Gerätefunktion Ergebnis
Wear OS 3 Kachel wird verwendet
Wear OS 4, 5, 6 Kachel wird verwendet
Wear OS 7 (keine Unterstützung für teilweise Höhe, z.B. Pixel Watch) Kachel wird verwendet
Wear OS 7 (Unterstützung für teilweise Höhe, z.B. Galaxy Watch) Widget wird verwendet

Alternative: Einzelner Dienst (nur Widget)

Ein einzelner Dienst verarbeitet beide Protokolle. Dieser Ansatz ist zwar schneller zu implementieren, erfordert aber einen Kompatibilitätsmodus, um Ihr Widget auf Geräten mit älteren Wear OS-Versionen in eine Kachel zu „adaptieren“.

Wenn Sie sich für diesen Ansatz entscheiden, gilt Folgendes:

  1. Beide Intent-Filter angeben:Ihr Dienst muss Intent-Filter für androidx.wear.tiles.action.BIND_TILE_PROVIDER und androidx.glance.wear.action.BIND_WIDGET_PROVIDER enthalten. So wird dafür gesorgt, dass Ihr Widget auf Kacheloberflächen in Wear 4, 5, 6 und 7 angezeigt wird (falls erforderlich).
  2. Vorhandenen Dienstnamen beibehalten (für nahtlose Upgrades): Wenn Sie eine aktive Kachel ersetzen, wird durch Beibehalten des Dienstklassennamens dafür gesorgt, dass Nutzer, die Ihre Kachel in ihrem Karussell haben, automatisch das neue Widget sehen. In Wear OS 7 wird das Attribut group in der XML-Datei der Widgetkonfiguration verwendet, um verschiedene Komponenten logisch zu verknüpfen. In Wear OS-Versionen unter 7 wird der Dienstname verwendet, um sie als „dieselbe“ Komponente zu identifizieren. Wenn Sie lieber einen neuen Dienstnamen verwenden möchten, funktioniert Ihre App weiterhin einwandfrei. Nutzer auf Geräten mit Wear OS Version 6 oder niedriger müssen das Widget jedoch manuell in ihr Karussell einfügen.

Systemverhalten bei Einrichtung eines einzelnen Dienstes:

Betriebssystem / Gerätefunktion Ergebnis
Wear OS 3 Nicht unterstützt
Wear OS 4, 5, 6 Das Widget wird als Vollbildkachel angezeigt.
Wear OS 7 (keine Unterstützung für Teilhöhe) Das Widget wird in eine Kachel übersetzt.
Wear OS 7 (Unterstützung für teilweise Höhe) Widget wird verwendet

*Erfordert Renderer 1.6 oder höher.

Tipps zur UI-Übersetzung

Bei der Übersetzung Ihrer Benutzeroberfläche von ProtoLayout (Kacheln) zu Remote Compose (Widgets) ändert sich das mentale Modell von imperativen Layout-Buildern zu einer zustandsorientierten, Compose-basierten Architektur, in der UI-Updates durch Recomposition verarbeitet werden. Beachten Sie die folgenden Grundsätze:

  • Deklarative Benutzeroberfläche verwenden:Ersetzen Sie imperative ProtoLayout-Builder (LayoutElementBuilders) durch deklarative Remote Compose-Entsprechungen wie RemoteText, RemoteColumn und RemoteBox.
  • Fokus auf die Kerninhalte (mainSlot): Widgets mit teilweiser Höhe (z.B. die Containertypen SMALL und LARGE) bieten eine fokussierte, übersichtliche Oberfläche. Anstatt ein dichtes Vollbild-Kachellayout eins zu eins zu portieren, solltest du dein Design optimieren, um primäre Informationen im Hauptinhaltsbereich hervorzuheben.
  • Neugestaltung von Edge-Aligned Actions:In der Kachelarchitektur wurden bildschirmfüllende Komponenten wie das EdgeButton in einem dedizierten bottomSlot verankert. Da Widgets mit teilweiser Höhe direkt in eine vertikal scrollende Oberfläche eingebunden werden, gibt es dieses feste bottomSlot-Paradigma nicht mehr. Da an den Rand ausgerichtete Schaltflächen oft als sehr wichtige primäre Aktionen dienten, erfordert die Migration eine bewusste Neugestaltung der Benutzeroberfläche und nicht nur einen direkten Komponententausch. Bewerten Sie alternative UX-Strategien für Ihre primären Aktionen:
    • Inline-Aktionen:Integrieren Sie eine Inline-RemoteButton direkt in Ihr mainSlot-Layout.
    • Container-Taps:Konsolidieren Sie die Interaktion, indem Sie den gesamten Widget-Container mit einem PendingIntentAction antippbar machen.
    • Inhaltsänderung:Überprüfen Sie den Fokus des Widgets noch einmal. Wenn Sie keinen dedizierten Aktions-Slot haben, sollten Sie mehr übersichtliche Daten präsentieren und sich darauf verlassen, dass Nutzer mit einem einzigen Tippen die vollständige Anwendung öffnen, anstatt bestimmte Aktionen auf der Widget-Oberfläche zu isolieren.
  • Ereignisverarbeitung migrieren (Aktionen im Vergleich zu Lambdas): Kacheln basieren auf Interaktionen (z. B. LoadAction), die vollständige Service-Callbacks auslösen, um die Benutzeroberfläche zu aktualisieren. Wear-Widgets werden clientseitig gesteuert. Standard-Compose-Lambdas können nicht remote ausgeführt werden. Verwenden Sie stattdessen serialisierbare deklarative Aktionen wie ValueChange oder PendingIntentAction. Kombinieren Sie diese mit deklarativem Status (z. B. rememberMutableRemoteInt), um sofortige UI-Aktualisierungen ohne App-Roundtrips zu ermöglichen.
  • Dimensionen und Typen anpassen:Bei der Migration von Layoutdimensionen sollten Sie die verzögerte Layoutauflösung mit RemoteDp (z.B. 10.rdp) dem Standard-Dp vorziehen. So wird sichergestellt, dass der System-Renderer Pixelwerte zur Anzeigezeit korrekt berechnet. Verwenden Sie auf ähnliche Weise Remote Compose-Erweiterungsfunktionen (.rc für Color, .rs für String, .rdp für Dp), um Standard-Kotlin- und Remote Compose-Typen nahtlos zu konvertieren.
  • Beispielcode ansehen:Im Wear OS-Beispiel-Repository finden Sie umfassende Beispiele für das Erstellen von Layouts, das Anwenden semantischer Typografie und das Verwalten des Status in Remote Compose.