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.
- Usługa kafelków: rozszerz
TileServicei zadeklaruj filtr intencji dlaandroidx.wear.tiles.action.BIND_TILE_PROVIDER. - Usługa widżetu: rozszerz
GlanceWearWidgetServicei zadeklaruj filtr intencji dlaandroidx.glance.wear.action.BIND_WIDGET_PROVIDER. - Logiczne grupowanie: użyj atrybutu
groupw konfiguracji widżetu, aby połączyć nową implementację z dotychczasową usługąTileService. Dzięki temu system może rozpoznać je jako jeden logiczny komponent i automatycznie przenieść istniejące miejsce na karuzelę użytkownika do nowego widżetu na zegarku z Wear OS 7 lub nowszym.
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ę:
- Określ oba filtry intencji: usługa musi zawierać filtry intencji dla
androidx.wear.tiles.action.BIND_TILE_PROVIDERiandroidx.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). - 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
groupw 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 jakRemoteText,RemoteColumniRemoteBox. - Skup się na głównych treściach (
mainSlot): widżety o częściowej wysokości (np. typy kontenerówSMALLiLARGE) 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 dedykowanegobottomSlot. Widżety o częściowej wysokości są zintegrowane bezpośrednio z powierzchnią przewijaną w pionie, więc ten stały paradygmatbottomSlotjuż 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
RemoteButtonbezpośrednio w układziemainSlot. - 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.
- Działania wbudowane: zintegruj wbudowane
- 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.ValueChangelubPendingIntentAction). 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 standardowegoDp. Dzięki temu moduł renderujący systemu prawidłowo oblicza wartości pikseli w czasie wyświetlania. Podobnie używaj funkcji rozszerzeń Remote Compose (.rcdlaColor,.rsdlaString,.rdpdlaDp), 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.