Komunikacja bezpośrednio przez sieć na samodzielnych urządzeniach

Dzięki Wear OS by Google zegarek może komunikować się bezpośrednio z siecią, bez dostępu do telefonu z Androidem lub 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 krokami w tym przewodniku.

Dostęp do sieci

Aplikacje na Wear OS mogą wysyłać żądania sieciowe. Jeśli zegarek połączy się z telefonem przez Bluetooth, ruch sieciowy jest zazwyczaj przekierowywany przez telefon.

Gdy telefon jest niedostępny, używane są sieci Wi-Fi i komórkowe w zależności od modelu zegarka. Platforma Wear OS obsługuje przejścia między sieciami.

Możesz używać takich protokołów jak HTTP, TCP i UDP. Interfejsy API android.webkit, w tym klasa CookieManager, są jednak niedostępne. Możesz używać plików cookie, odczytując i zapisując nagłówki w żądaniach i odpowiedziach.

Używaj WorkManager do żądań asynchronicznych, w tym do odpytywania w regularnych odstępach czasu.

Jeśli musisz się połączyć 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ć użytkownikom maksymalną wygodę. Platforma wybiera domyślną aktywną sieć, biorąc pod uwagę 2 potrzeby: długi czas pracy na baterii i przepustowość sieci.

Gdy priorytetem jest dbanie o baterię, aktywna sieć może nie mieć wystarczającej przepustowości do zadań sieciowych, takich jak przesyłanie dużych plików czy strumieniowe przesyłanie multimediów.

W tej sekcji znajdziesz wskazówki dotyczące używania klasy ConnectivityManager, które pomogą Ci upewnić się, że aplikacja ma wystarczającą przepustowość sieci. Ogólne informacje na temat szczegółowej kontroli nad zasobami sieciowymi znajdziesz w artykule Zarządzanie wykorzystaniem sieci.

Poproś o połączenie Wi-Fi

W przypadkach wymagających dostępu do sieci o dużej przepustowości, np. do przesyłania dużych plików lub strumieniowania multimediów, poproś o połączenie za pomocą transportu publicznego o 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
);

Połączenie z siecią może nie być natychmiastowe, ponieważ połączenie Wi-Fi lub komórkowe w zegarku może 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 próbuje utrzymać połączenie z siecią Wi-Fi do momentu zwolnienia urządzenia NetworkCallback. Gdy nie potrzebujesz już sieci Wi-Fi, aby wydłużyć czas pracy na baterii, zwolnij wywołanie zwrotne w sposób pokazany w poniższym przykładzie.

Kotlin

connectivityManager.bindProcessToNetwork(null)
connectivityManager.unregisterNetworkCallback(callback)

Java

connectivityManager.bindProcessToNetwork(null);
connectivityManager.unregisterNetworkCallback(callback);

Uruchom aktywność związaną z ustawieniami Wi-Fi

Zgłaszając żądanie sieci Wi-Fi, system próbuje połączyć się z zapisaną siecią, jeśli jest ona skonfigurowana i znajduje się w jej zasięgu. Jeśli nie ma dostępnej zapisanej sieci Wi-Fi, metoda wywołania zwrotnego onAvailable instancji NetworkCallback nie jest wywoływana.

Jeśli używasz Handler do ograniczania czasu oczekiwania na żądanie sieci, możesz pokierować użytkownika, aby dodał sieć Wi-Fi po upłynięciu limitu czasu. Kieruj użytkownika bezpośrednio do działania polegającego na dodaniu sieci Wi-Fi w tym 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, aplikacja musi mieć uprawnienie CHANGE_WIFI_STATE.

Uwagi na temat interfejsu

Jeśli Twoja aplikacja wymaga połączenia z nową siecią Wi-Fi do działania z dużą przepustowością, przed uruchomieniem ustawień Wi-Fi upewnij się, że powód nawiązania połączenia jest jasny dla użytkownika. Poproś użytkownika o dodanie nowej sieci Wi-Fi tylko wtedy, gdy sieć o dużej przepustowości jest wymagana. Nie blokuj użytkownikowi dostępu do funkcji aplikacji, które nie wymagają sieci o dużej przepustowości.

Ilustracja 1 przedstawia aplikację muzyczną. Aplikacja pozwala użytkownikowi przeglądać muzykę w sieci o mniejszej przepustowości. Użytkownik musi dodać nową sieć Wi-Fi tylko wtedy, gdy chce pobrać muzykę lub słuchać jej strumieniowo.

Pobieranie muzyki

Rysunek 1. Aplikacja do pobierania muzyki.

Uwagi na temat zasilania i użycia danych

Aby wydłużyć czas pracy na baterii i zminimalizować użycie mobilnej transmisji danych, odłóż obojętne zadania sieciowe, takie jak raporty analityczne czy zbieranie dzienników, do czasu, aż urządzenie z Wear OS ponownie nawiąże połączenie Bluetooth lub Wi-Fi zamiast korzystania z połączenia LTE lub z pomiarem użycia danych.

Komunikacja w chmurze

Do wysyłania powiadomień używaj bezpośrednio Komunikacji w chmurze Firebase (FCM).

Żadne interfejsy API do dostępu do sieci lub FCM nie są specyficzne dla Wear OS. Zapoznaj się z dotychczasową dokumentacją dotyczącą łączenia się z siecią i funkcji przesyłania wiadomości w chmurze.

FCM dobrze działa z Uśpieniem i jest zalecanym sposobem wysyłania powiadomień na zegarek.

Przekazuj komunikaty z FCM, zbierając token rejestracji urządzenia podczas uruchamiania aplikacji na Wear OS. Następnie umieść ten token w miejscu docelowym, gdy serwer wysyła wiadomości do punktu końcowego REST FCM. FCM wysyła wiadomości na urządzenie identyfikowane przez token.

Wiadomość FCM jest w formacie JSON (JavaScript Object Notation) i może zawierać jeden lub oba te ładunki:

  • Ładunek powiadomień: gdy zegarek odbiera ładunek powiadomień, dane są wyświetlane użytkownikowi bezpośrednio w strumieniu powiadomień. Gdy użytkownik kliknie powiadomienie, aplikacja się uruchomi.
  • Ładunek danych: gdy ładunek zawiera zbiór niestandardowych par klucz-wartość. Ł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 FCM.

Domyślnie powiadomienia są przenoszone z aplikacji na telefon do zegarka. Jeśli masz samodzielną aplikację na Wear OS i powiązaną z nią aplikację na telefon, mogą wystąpić zduplikowane powiadomienia. Na przykład pojedyncze powiadomienie z FCM odebrane zarówno na telefonie, jak i na zegarku może być wyświetlane osobno na obu urządzeniach. Możesz temu zapobiec, używając interfejsów API łączących.

Używaj usług w tle

Aby zadania w tle były prawidłowo wykonywane, aplikacje te 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 funkcji Uśpienie, a zadania w tle mogą zostać odroczone na określony czas. Później, gdy urządzenie pozostaje nieruchome przez dłuższy czas, następuje zwykłe uśpienie. Planowanie żądań za pomocą interfejsu API WorkManager, który umożliwia aplikacji zarejestrowanie się do wykonania kodu w trybie uśpienia.

Harmonogram z ograniczeniami

Możesz używać ograniczeń do konfigurowania żądań w sposób zapewniający oszczędzanie baterii. Wybierz co najmniej jedno z tych ograniczeń, które chcesz uwzględnić w żądaniach:

  • Zaplanuj żądanie, które wymaga sieci.

    Określ, czy NetworkType to CONNECTED czy UNMETERED. UNMETERED jest przeznaczona do dużych transferów danych, a CONNECTED do niewielkich transferów.

  • Zaplanuj żądanie podczas ładowania.

  • Zaplanuj żądanie, gdy urządzenie jest nieaktywne. Jest to przydatne podczas pracy w tle lub synchronizacji o niższym priorytecie, zwłaszcza podczas ładowania urządzenia.

Więcej informacji znajdziesz w przewodniku WorkManager Wpływ ograniczeń na pracę okresową.