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:
- Najnowszą wersję Usług Google Play.
- urządzenie z Wear OS lub emulator Wear OS.
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ękiChannelClient
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ówDataItem
. FunkcjaChannelClient
oszczędza miejsce na dysku w systemieDataClient
, 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.
- 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
- Synchronizowanie danych
DataClient
udostępnia interfejs API dla komponentów do odczytu lub zapisu wDataItem
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 obiektuWearableListenerService
, 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 zamiastWearableListenerService
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:
- Wymieniaj dane bezpośrednio po nawiązaniu połączenia Bluetooth między zegarkiem a innym urządzeniem.
- Wymiana danych przez dostępną sieć, np. LTE lub Wi-Fi.
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.