Migracja z kafelków na widżety

Zarówno kafelki, jak i widżety wyświetlają treści na powierzchni zdalnego systemu, ale ich tworzenie wymaga odmiennych podejść. Przeniesienie istniejącego kafelka do widżetu oznacza przejście z generowania sztywnego układu na dynamiczny, deklaratywny interfejs, co otwiera nowe możliwości i upraszcza model programowania.

Wybieranie strategii wdrażania

Jeśli przenosisz aplikację, która obsługuje starszy kafelek, musisz zdecydować, w jaki sposób będzie ona udostępniać treści systemowi. Nowe widżety powinny korzystać z jednej usługi widżetów, ale aplikacje z dotychczasowymi kafelkami muszą zdecydować, czy chcą zachować obie usługi, czy też połączyć je w jedną usługę widżetów.

Zalecane: usługa podwójna (kafelek + widżet)

Zalecamy, aby wszystkie aplikacje, które mają już kafelki, zachowały zarówno kafelki, jak i widżety. Dostarczanie dwóch odrębnych usług zapewnia najlepsze wrażenia użytkownika na różnych urządzeniach.

Działanie systemu w przypadku konfiguracji z 2 usługami:

System operacyjny / możliwości urządzenia Wynikowe wrażenia
Wear OS 3 Używana jest karta
Wear OS 4, 5, 6 Używana jest karta
Wear OS 7 (bez obsługi częściowej wysokości, np. Pixel Watch) Używana jest karta
Wear OS 7 (obsługa częściowej wysokości, np. Galaxy Watch) używany jest widżet.

Alternatywa: pojedyncza usługa (tylko widżet)

Jeden serwis obsługuje oba protokoły. Chociaż to podejście jest szybsze we wdrożeniu, opiera się na trybie zgodności, który „dostosowuje” widżet do kafelka na urządzeniach z starszymi wersjami Wear OS.

Jeśli wybierzesz tę metodę:

  1. Określ oba filtry intencji: usługa musi zawierać filtry intencji dla androidx.wear.tiles.action.BIND_TILE_PROVIDERandroidx.glance.wear.action.BIND_WIDGET_PROVIDER. Dzięki temu widżet będzie wyświetlany na kafelkach w Wear 4, 5, 6 i 7 (w razie potrzeby).
  2. Zachowaj dotychczasową nazwę usługi (aby zapewnić płynne przejście na nową wersję): jeśli zastępujesz aktywny kafel, zachowanie tej samej nazwy klasy usługi sprawi, że użytkownicy, którzy mają Twój kafel w karuzeli, zobaczą, że automatycznie zaktualizował się on do nowego widżetu. Wear OS 7 używa atrybutu group w pliku XML konfiguracji widżetu, aby logicznie połączyć różne komponenty, natomiast wersje Wear OS starsze niż 7 polegają na nazwie usługi, aby zidentyfikować je jako „ten sam” komponent. Jeśli wolisz używać nowej nazwy usługi, aplikacja nadal będzie działać prawidłowo. Jednak użytkownicy urządzeń z Wear OS w wersji 6 lub starszej będą musieli ręcznie ponownie dodać widżet do karuzeli.

Działanie systemu w przypadku konfiguracji pojedynczej usługi:

System operacyjny / możliwości urządzenia Wynikowe wrażenia
Wear OS 3 Nieobsługiwane
Wear OS 4, 5, 6 Widżet jest wyświetlany jako kafelek na pełnym ekranie
Wear OS 7 (bez obsługi częściowej wysokości) Widżet jest tłumaczony na kafelek
Wear OS 7 (obsługa częściowej wysokości) używany jest widżet.

*Wymaga renderera w wersji 1.6 lub nowszej.

Wskazówki dotyczące tłumaczenia interfejsu

Podczas tłumaczenia interfejsu z ProtoLayout (kafelki) na Remote Compose (widżety) model mentalny zmienia się z imperatywnych konstruktorów układu na architekturę opartą na stanie i Compose, w której aktualizacje interfejsu są obsługiwane przez rekompozycję. Pamiętaj o tych zasadach:

  • Wdróż deklaratywny interfejs: zastąp imperatywne konstruktory ProtoLayout (LayoutElementBuilders) deklaratywnymi odpowiednikami Remote Compose, takimi jak RemoteText, RemoteColumnRemoteBox.
  • Skup się na głównych treściach (mainSlot): widżety o częściowej wysokości (np. typy kontenerów SMALLLARGE) zapewniają skupioną, łatwą do przejrzenia powierzchnię. Zamiast przenosić gęsty układ kafelków na pełnym ekranie w stosunku 1:1, uprość projekt, aby podkreślić najważniejsze informacje w głównej części treści.
  • Przeprojektowanie działań wyrównanych do krawędzi: w architekturze kafelków komponenty przylegające do ekranu, takie jak EdgeButton, były przypisane do dedykowanego bottomSlot. Widżety o częściowej wysokości są zintegrowane bezpośrednio z powierzchnią przewijaną w pionie, więc ten stały paradygmat bottomSlot już nie istnieje. Przyciski wyrównane do krawędzi często służyły jako bardzo widoczne główne działania, więc migracja wymaga przemyślanego przeprojektowania interfejsu, a nie bezpośredniej zamiany komponentów. Ocena alternatywnych strategii UX dla głównych działań:
    • Działania wbudowane: zintegruj wbudowane RemoteButton bezpośrednio w układzie mainSlot.
    • Kliknięcia kontenera: skonsoliduj interakcję, umożliwiając kliknięcie całego kontenera widżetu za pomocą elementu PendingIntentAction.
    • Content Pivot:ponowna ocena głównego tematu widżetu. Jeśli nie masz dedykowanego miejsca na działanie, rozważ wyświetlanie bardziej szczegółowych danych, które można szybko sprawdzić, i polegaj na jednym kliknięciu, aby otworzyć pełną aplikację, zamiast wyodrębniać konkretne działania na powierzchni widżetu.
  • Przenoszenie obsługi zdarzeń (działania a funkcje Lambda): kafelki opierają się na interakcjach (np. LoadAction), które wywołują pełne wywołania zwrotne usługi w celu odświeżenia interfejsu. Widżety Wear są obsługiwane po stronie klienta. Standardowe lambdy Compose nie mogą być uruchamiane zdalnie. Zamiast tego podaj serializowane działania deklaratywne (np. ValueChange lub PendingIntentAction). Połącz je ze stanem deklaratywnym (np. rememberMutableRemoteInt), aby obsługiwać natychmiastowe aktualizacje interfejsu bez konieczności wykonywania przez aplikację operacji typu round-trip.
  • Dostosuj wymiary i typy: podczas przenoszenia wymiarów układu preferuj odroczone rozwiązanie układu za pomocą RemoteDp (np. 10.rdp) zamiast standardowego Dp. Dzięki temu moduł renderujący systemu prawidłowo oblicza wartości pikseli w czasie wyświetlania. Podobnie używaj funkcji rozszerzeń Remote Compose (.rc dla Color, .rs dla String, .rdp dla Dp), aby bezproblemowo konwertować standardowe typy Kotlina i Remote Compose.
  • Sprawdź przykładowy kod: aby zobaczyć kompleksowe przykłady tworzenia układów, stosowania typografii semantycznej i zarządzania stanem w Remote Compose, zapoznaj się z oficjalnym przykładowym kodem dostępnym w repozytorium z przykładami Wear OS.