Dzięki Wear OS by Google zegarek może komunikować się bezpośrednio z siecią, bez dostępu do telefonu z Androidem czy iOS. Nie używaj interfejsu Data Layer API do łączenia aplikacji na Wear OS z siecią. Zamiast tego postępuj zgodnie ze wskazówkami i instrukcjami w tym przewodniku.
Dostęp do sieci
Aplikacje na Wear OS mogą wysyłać żądania sieciowe. Gdy zegarek ma połączenie Bluetooth z telefonem, ruch sieciowy zegarka jest zwykle przesyłany przez serwer proxy.
Gdy telefon jest niedostępny, używane są sieci Wi-Fi i komórkowe (w zależności od wyposażenia zegarka). Platforma Wear OS obsługuje przenoszenie między sieciami.
Możesz używać protokołów takich jak HTTP, TCP i UDP. Jednak interfejsy API
android.webkit
, w tym klasa
CookieManager
, są niedostępne. Możesz używać plików cookie, odczytując i zapisując nagłówki w żądaniach i odpowiedziach.
Zalecamy też używanie interfejsu API WorkManager do obsługi żądań asynchronicznych, w tym odpytywania w regularnych odstępach czasu.
Jeśli musisz połączyć się z określonymi typami sieci, zapoznaj się z sekcją Odczytywanie stanu sieci.
dostęp do sieci o dużej przepustowości.
Platforma Wear OS zarządza połączeniami sieciowymi, aby zapewnić jak największą wygodę użytkowników. Platforma wybiera domyślną aktywną sieć, równoważąc 2 potrzeby:
- Długa żywotność baterii
- Przepustowość sieci
Jeśli priorytetem jest oszczędzanie baterii, aktywna sieć może nie mieć wystarczającej przepustowości do wykonywania zadań sieciowych, takich jak transport dużych plików czy strumieniowanie multimediów.
W tej sekcji znajdziesz wskazówki dotyczące używania klasy
ConnectivityManager
, aby zapewnić aplikacji odpowiednią przepustowość sieci. Ogólne informacje o szczegółowej kontroli nad zasobami sieciowymi znajdziesz w artykule
Zarządzanie wykorzystaniem sieci.
Poproś o połączenie z siecią Wi-Fi
W przypadkach użycia wymagających dużej przepustowości dostępu sieciowego, takich jak przesyłanie dużych plików lub strumieniowanie multimediów, poproś o połączenie za pomocą dużej przepustowości, np. Wi-Fi. Widać to w tym przykładzie:
Kotlin
val callback = object : ConnectivityManager.NetworkCallback() { override fun onAvailable(network: Network) { super.onAvailable(network) // The Wi-Fi network has been acquired. Bind it to use this network by default. connectivityManager.bindProcessToNetwork(network) } override fun onLost(network: Network) { super.onLost(network) // Called when a network disconnects or otherwise no longer satisfies this request or callback. } } connectivityManager.requestNetwork( NetworkRequest.Builder().addTransportType(NetworkCapabilities.TRANSPORT_WIFI).build(), callback )
Java
ConnectivityManager.NetworkCallback callback = new ConnectivityManager.NetworkCallback() { public void onAvailable(Network network) { super.onAvailable(network); // The Wi-Fi network has been acquired. Bind it to use this network by default. connectivityManager.bindProcessToNetwork(network); } public void onLost(Network network) { super.onLost(network); // Called when a network disconnects or otherwise no longer satisfies this request or callback. } }; connectivityManager.requestNetwork( new NetworkRequest.Builder().addTransportType(NetworkCapabilities.TRANSPORT_WIFI).build(), callback );
Uzyskanie sieci może nie być natychmiastowe, ponieważ Wi-Fi lub radio komórkowe na zegarku mogą być wyłączone, aby oszczędzać baterię. Jeśli zegarek nie może połączyć się z siecią, metoda onAvailable()
instancji NetworkCallback
nie jest wywoływana.
Po wywołaniu onAvailable()
urządzenie spróbuje utrzymać połączenie z siecią Wi-Fi do czasu zwolnienia NetworkCallback
. Aby wydłużyć czas pracy na baterii, zwolnij wywołanie zwrotne w sposób opisany poniżej, gdy nie potrzebujesz już sieci Wi-Fi.
Kotlin
connectivityManager.bindProcessToNetwork(null) connectivityManager.unregisterNetworkCallback(callback)
Java
connectivityManager.bindProcessToNetwork(null); connectivityManager.unregisterNetworkCallback(callback);
Uruchom aktywność dotyczącą ustawień Wi-Fi
Gdy wysyłasz żądanie do sieci Wi-Fi, system próbuje połączyć się z zapisaną siecią, jeśli jest ona skonfigurowana i znajduje się w zasięgu. Jeśli nie jest dostępna żadna zapisana sieć Wi-Fi, metoda wywołania zwrotnego onAvailable()
instancji NetworkCallback
nie zostanie wywołana.
Jeśli używasz Handler
do wyciszania żądań sieciowych, możesz wskazać użytkownikowi, by po upływie limitu czasu dodał sieć Wi-Fi.
Przekieruj użytkownika bezpośrednio do działania polegającego na dodaniu sieci Wi-Fi, korzystając z tej intencji:
Kotlin
context.startActivity(Intent("com.google.android.clockwork.settings.connectivity.wifi.ADD_NETWORK_SETTINGS"))
Java
context.startActivity(new Intent("com.google.android.clockwork.settings.connectivity.wifi.ADD_NETWORK_SETTINGS"));
Aby uruchomić aktywność związaną z ustawieniami, Twoja aplikacja musi mieć te uprawnienia: android.permission.CHANGE_WIFI_STATE
.
Uwagi na temat interfejsu
Jeśli Twoja aplikacja do wykonywania operacji związanych z dużą przepustowością wymaga połączenia z nową siecią Wi-Fi, przed uruchomieniem ustawień Wi-Fi upewnij się, że powód jest jasny dla użytkownika. Poproś użytkownika o dodanie nowej sieci Wi-Fi tylko wtedy, gdy wymagana jest sieć o dużej przepustowości. Nie blokuj użytkownikowi dostępu do funkcji aplikacji, które nie wymagają dużej przepustowości sieci.
Rysunek 1 przedstawia aplikację muzyczną. Aplikacja umożliwia użytkownikowi przeglądanie muzyki w sieci o niższej przepustowości i wymaga od użytkownika dodania nowej sieci Wi-Fi tylko wtedy, gdy chce pobierać lub odtwarzać strumieniowo muzykę.
Zasilanie i użycie danych
Aby wydłużyć czas pracy na baterii i zminimalizować wykorzystanie komórkowej transmisji danych, odrocz wszystkie mniej ważne zadania sieciowe, takie jak tworzenie raportów analitycznych czy zbieranie dzienników, do czasu ponownego nawiązania połączenia Bluetooth lub Wi-Fi przez urządzenie z Wear OS.
Komunikacja w chmurze
Do wysyłania powiadomień aplikacje mogą bezpośrednio używać Komunikacji w chmurze Firebase (FCM).
Wear OS nie ma interfejsów API do obsługi dostępu do sieci ani FCM. Zapoznaj się z istniejącą dokumentacją na temat łączenia się z siecią i przesyłania wiadomości w chmurze.
FCM dobrze działa z funkcją Uśpienie i jest zalecanym sposobem wysyłania powiadomień na zegarek.
Aby udostępniać wiadomości z FCM, zbierz token rejestracji urządzenia, gdy uruchomi się aplikacja na Wear OS. Następnie dołącz token jako część miejsca docelowego, gdy serwer wysyła wiadomości do punktu końcowego REST FCM. FCM wysyła wiadomości na urządzenie identyfikowane przez token.
Wiadomość w FCM ma format JavaScript Object Notation (JSON) i może zawierać jeden lub oba z tych ładunków:
- Ładunek powiadomienia: gdy zegarek odbiera ładunek powiadomienia, dane są wyświetlane użytkownikowi bezpośrednio w strumieniu powiadomień. Gdy użytkownik kliknie powiadomienie, aplikacja się uruchomi.
- Ładunek danych: ładunek ma zestaw niestandardowych par klucz lub wartości. Ładunek jest dostarczany jako dane do aplikacji na Wear OS.
Więcej informacji i przykłady ładunków znajdziesz w artykule Informacje o wiadomościach w FCM.
Domyślnie powiadomienia są połączone między aplikacją na telefonie a zegarkiem. Jeśli masz samodzielną aplikację na Wear OS i odpowiadającą jej aplikację na telefon, mogą występować zduplikowane powiadomienia. Na przykład 1 powiadomienie z FCM, otrzymane zarówno przez telefon, jak i zegarek, może zostać wyświetlone niezależnie na obu urządzeniach. Możesz temu zapobiec, korzystając z interfejsów API łączących.
Korzystanie z usług w tle
Aby zadania w tle były wykonywane prawidłowo, muszą uwzględniać funkcje Uśpienie i Czuwanie aplikacji.
Gdy ekran wyłączy się lub przejdzie w tryb nieaktywny na wystarczająco długo, może wystąpić podzbiór Uśpienia, a zadania w tle mogą być odroczone na określony czas. Później, gdy urządzenie przez dłuższy czas się nie rusza, następuje regularne uśpienie. Planuj żądania za pomocą interfejsu API WorkManager, który umożliwia zarejestrowanie się w aplikacji pod kątem wykonywania kodu w trybie uśpienia.
Harmonogram z ograniczeniami
Za pomocą ograniczeń możesz konfigurować żądania w sposób, który pozwala wydłużyć czas pracy baterii. Wybierz co najmniej jedno z tych ograniczeń, które chcesz uwzględnić w żądaniach:
- Zaplanuj żądanie, które wymaga połączenia z siecią. Określ, czy
NetworkType
toCONNECTED
czyUNMETERED
.UNMETERED
służy do przenoszenia dużych ilości danych, aCONNECTED
– do małych transferów. - Zaplanuj żądanie podczas ładowania.
- Zaplanuj żądanie, gdy urządzenie jest nieaktywne. Przydaje się to do pracy w tle lub synchronizacji o niższym priorytecie, zwłaszcza podczas ładowania urządzenia.
Pamiętaj, że niektóre sieci o niskiej przepustowości, np. Bluetooth LE, są uznawane za sieci z pomiarem użycia danych.
Więcej informacji znajdziesz w przewodniku WorkManagera dotyczącym efektu ograniczeń na pracę okresową.