Wysyłanie i synchronizowanie danych w Wear OS

Zegarek z Wear OS by Google umożliwia wysyłanie i synchronizowanie danych na kilka sposobów. Zalecamy wysyłanie i synchronizowanie danych bezpośrednio z sieci, ponieważ dzięki temu aplikację można uznać za samodzielną aplikację.

Wysyłanie i synchronizowanie danych bezpośrednio z sieci

Twórz aplikacje na Wear OS, aby komunikować się bezpośrednio z siecią. Możesz używać tych samych interfejsów API, których używasz do programowania aplikacji na urządzenia mobilne, ale pamiętaj o pewnych różnicach specyficznych dla Wear OS.

Wysyłanie i synchronizowanie danych za pomocą interfejsu Wearable Data Layer API

Interfejs Wearable Data Layer API, który jest częścią Usług Google Play, udostępnia opcjonalny kanał komunikacji aplikacji.

Ten interfejs API jest dostępny tylko na zegarkach z Wear OS i sparowanych urządzeniach z Androidem. Na zegarkach z Wear OS sparowanych z telefonami z iOS aplikacje mogą wysyłać zapytania do innych interfejsów API działających w chmurze, jeśli dostępne jest połączenie z internetem.

Interfejs API warstwy danych do noszenia zależy od tych zależności:

Dodaj tę zależność do pliku build.gradle modułu Wear:

  dependencies {
    ...
    implementation 'com.google.android.gms:play-services-wearable:18.1.0'
  }
  

Zalecamy, aby aplikacje na urządzenia do noszenia wysyłały i synchronizowały dane bezpośrednio z sieci lub połączonego telefonu. Jeśli jednak chcesz komunikować się bezpośrednio między urządzeniami w formacie typu RPC lub nie możesz połączyć się bezpośrednio z siecią, aby pobrać dane, możesz skorzystać z interfejsu Wearable Data Layer API w następujący sposób.

Reklamowanie i wysyłanie zapytań o możliwości zdalne
CapabilityClient zawiera informacje o tym, które węzły w sieci Wear OS obsługują dane niestandardowe funkcje. Węzły reprezentują zarówno urządzenia mobilne, jak i urządzenia do noszenia, które są połączone z siecią. Potencjał to funkcja definiowana przez aplikację w czasie kompilacji lub konfigurowana dynamicznie w czasie działania.
Na przykład aplikacja mobilna na Androida może informować, że obsługuje zdalne sterowanie odtwarzaniem filmów. Gdy aplikacja do noszenia jest zainstalowana, może użyć interfejsu CapabilityClient, aby sprawdzić, czy jest zainstalowana i obsługuje tę funkcję. Jeśli tak, aplikacja do noszenia może wyświetlać przycisk odtwarzania/wstrzymywania, aby za pomocą wiadomości sterować odtwarzaniem filmu na drugim urządzeniu.
Może to też przebiegać w przeciwnym kierunku, w zależności od obsługiwanych funkcji strony aplikacji do noszenia.
Wysyłanie wiadomości
MessageClient może wysyłać wiadomości i jest odpowiedni do zdalnych wywołań procedur (RPC), takich jak sterowanie odtwarzaczem multimedialnym na urządzeniu do noszenia lub uruchamianie intencji na tym urządzeniu. Wiadomości świetnie sprawdzają się też w przypadku żądań jednokierunkowych oraz modelu komunikacji związanego z żądaniami lub odpowiedziami.
Jeśli urządzenie przenośne i urządzenie do noszenia są połączone, system umieszcza wiadomość w kolejce do dostarczenia i zwraca kod wyniku udanego. Jeśli urządzenia nie będą połączone, pojawi się komunikat o błędzie. Pomyślny kod wyniku nie oznacza, że wiadomość została dostarczona, ponieważ po otrzymaniu kodu wyniku urządzenia mogą się rozłączyć.
Przenoszenie danych
ChannelClient może przenieść dane z urządzenia mobilnego na urządzenie do noszenia. Dzięki ChannelClient możesz:
  • Przenoś pliki danych między co najmniej 2 połączonymi urządzeniami, gdy połączenie z internetem jest niedostępne, i korzystaj z automatycznej synchronizacji, gdy używane są obiekty Asset dołączone do obiektów DataItem. Funkcja ChannelClient oszczędza miejsce na dysku w systemie DataClient, co powoduje, że przed synchronizacją z podłączonymi urządzeniami tworzona jest kopia zasobów na urządzeniu lokalnym.
  • Niezawodnie za pomocą MessageClient wyślij plik, który jest za duży.
  • Przenoszenie danych strumieniowanych, np. danych głosowych z mikrofonu.
Synchronizowanie danych
DataClient udostępnia interfejs API dla komponentów do odczytu lub zapisu w DataItem bądź Asset.
DataItem jest zsynchronizowane na wszystkich urządzeniach w sieci Wear OS. Można ustawiać elementy danych bez połączenia z żadnymi węzłami. Te elementy danych są synchronizowane po przejściu węzłów w tryb online.
Elementy danych są prywatne dla aplikacji, która je utworzyła, i są dostępne tylko dla tej aplikacji w innych węzłach. Są zwykle małe. Do przesyłania większych, bardziej trwałych obiektów danych, np. obrazów, używaj narzędzia Assets.
Wear OS obsługuje wiele urządzeń do noszenia połączonych z urządzeniem mobilnym. Jeśli na przykład użytkownik zapisze notatkę na urządzeniu mobilnym, zostanie ona automatycznie wyświetlona na wszystkich jego urządzeniach z Wear OS. Aby ułatwić synchronizację danych między urządzeniami, serwery Google hostują węzeł w chmurze w sieci urządzeń. System synchronizuje dane z bezpośrednio połączonymi urządzeniami, węzłem w chmurze oraz urządzeniami do noszenia połączonych z węzłem chmury przez Wi-Fi.

Ostrzeżenie: elementy są przenoszone na wszystkie dostępne urządzenia z Wear OS, nawet na te, które nie mają zainstalowanej Twojej aplikacji. Jeśli synchronizujesz dużą ilość danych, sprawdź, czy masz zainstalowaną aplikację „odbiornik” i czy jest ona online, aby uniknąć marnowania zasobów zarówno na urządzeniach mobilnych, jak i na urządzeniach z Wear OS.

Nasłuchiwanie ważnych zdarzeń warstwy danych (dotyczy usług)
Rozszerzanie zakresu WearableListenerService umożliwia nasłuchiwanie ważnych zdarzeń warstwy danych w usłudze. System zarządza cyklem życia obiektu WearableListenerService, wiążąc go z usługą, gdy musi wysłać elementy danych lub wiadomości, oraz usuwa powiązanie usługi, gdy nie jest potrzebna żadna praca.
Wykrywaj ważne zdarzenia warstwy danych (w przypadku działań na pierwszym planie)
Implementacja OnDataChangedListener w aktywności umożliwia wychwytywanie ważnych zdarzeń warstwy danych, gdy aktywność działa na pierwszym planie. Użycie tego parametru zamiast WearableListenerService umożliwia wychwytywanie zmian tylko wtedy, gdy użytkownik aktywnie korzysta z aplikacji.

Ostrzeżenie: interfejsy API zostały zaprojektowane do komunikacji między urządzeniami przenośnymi a urządzeniami do noszenia, dlatego to jedyne interfejsy API, których możesz użyć do skonfigurowania komunikacji między tymi urządzeniami. Na przykład nie otwieraj gniazdek niskiego poziomu, by utworzyć kanał komunikacyjny.

Porównanie z klientami

W tabeli poniżej znajdziesz różne wymagania i przypadki użycia poszczególnych klientów.

Klient danych Klient wiadomości Klient kanału
Rozmiar danych większy niż 100 KB Tak Nie Tak
Może wysyłać wiadomości do węzłów, które nie są obecnie połączone Tak Nie Nie
Wzorzec komunikacji Udostępniony zasób sieciowy Przekazywana wiadomość 1:1 (z odpowiedzią) transmisja 1:1

Połączenia

Warstwa danych udostępnia 2 opcje komunikacji:

  1. Wymieniaj dane bezpośrednio po nawiązaniu połączenia Bluetooth między zegarkiem a innym urządzeniem.
  2. Wymiana danych przez dostępną sieć, np. LTE lub Wi-Fi.
Rysunek 1. Przykładowa sieć węzłów z urządzeniami do noszenia na ręku.

Wszystkie klienty warstwy danych mogą wymieniać dane przez Bluetooth lub Google Cloud Sync, w zależności od dostępnych połączeń. Usługa synchronizacji Cloud to opracowany przez Google mechanizm komunikacji i wymiany danych między urządzeniami do noszenia a telefonami, gdy Bluetooth jest niedostępny.

Zabezpieczenia

Zarówno opcje komunikacji (Bluetooth, jak i usługa synchronizacji Cloud) są w pełni szyfrowane.

Usługi Google Play egzekwują poniższe ograniczenia, aby zapewnić bezpieczną komunikację między aplikacją a telefonem.

  • Nazwa pakietu musi być taka sama na wszystkich urządzeniach.
  • Podpis pakietu musi być taki sam na wszystkich urządzeniach.

Bluetooth

Gdy urządzenia są połączone przez Bluetooth, warstwa danych używa tego połączenia. Gdy używasz Bluetootha, między urządzeniami zarządzany jest jeden zaszyfrowany kanał korzystający ze standardowego szyfrowania Bluetooth, którym zarządza Usługi Google Play.

Google Cloud

Załóżmy, że dane przesyłane za pomocą warstwy danych mogą w pewnym momencie korzystać z serwerów należących do Google. Na przykład DataClient, MessageClient lub ChannelClient automatycznie kierują trasę przez Google Cloud, gdy Bluetooth jest niedostępny. Wszystkie dane przesyłane przez Google Cloud są w pełni szyfrowane.

Generowanie i przechowywanie kluczy

Klucze kompleksowe do komunikacji w chmurze są generowane przez telefon i wymieniane bezpośrednio z zegarkiem, gdy oba urządzenia są połączone przez Bluetooth. Dzieje się tak podczas konfigurowania urządzenia. Serwery należące do Google nie otrzymują takich kluczy.

Komunikacja przez serwery należące do Google nie może być realizowana, dopóki nie zakończy się cały proces generowania kluczy. Klucze są przechowywane w prywatnej pamięci plików Usług Google Play na wszystkich sparowanych urządzeniach.

Kopia zapasowa danych z urządzenia

Klucze nie mają kopii zapasowej i nie opuszczają urządzenia. Jeśli będą wymagane nowe klucze, np. do nowego telefonu, system wygeneruje nowe klucze i udostępni je urządzeniom, które wciąż ma użytkownik.