Dostęp do sieci i synchronizacja na Wear OS

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ę.

Pobieranie muzyki

Rysunek 1. Proces aplikacji muzycznej do pobierania muzyki.

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 to CONNECTED czy UNMETERED. UNMETERED służy do przenoszenia dużych ilości danych, a CONNECTED – 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ą.