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

Z Wear OS by Google zegarek może komunikować się bezpośrednio z siecią, bez dostęp do telefonu z Androidem lub iOS. Nie używaj interfejsu Data Layer API do łączenia aplikacji Wear OS z siecią. Zamiast tego postępuj zgodnie ze wskazówkami i instrukcjami podanymi w tym Google.

Dostęp do sieci

Aplikacje na Wear OS mogą wysyłać żądania sieciowe. Gdy zegarek ma Bluetooth przez telefon, ruch sieciowy zegarka jest zazwyczaj przekierowywany przez serwer proxy przez telefon.

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

Możesz używać takich protokołów jak HTTP, TCP i UDP. Jednak Interfejsy API android.webkit, w tym klasa CookieManager, nie są i dostępności informacji. Można używać plików cookie, odczytując i zapisując nagłówki w żądaniach oraz odpowiedzi.

Używaj WorkManager do żądań asynchronicznych, w tym do regularnego odpytywania interwały.

Jeśli musisz się połączyć z określonym typem sieci, patrz Sieć odczytująca dane stanu.

Dostęp do sieci o dużej przepustowości

Platforma Wear OS zarządza połączeniami sieciowymi, aby zapewniać i zapewniają użytkownikom najlepsze wrażenia. Platforma wybiera domyślną aktywną sieć przez zrównoważenie dwóch potrzeb: długiej żywotności baterii i przepustowości sieci.

Gdy priorytetem jest dbanie o baterię, aktywna sieć może nie mieć Wystarczająca przepustowość do zadań sieciowych, takich jak transport dużych plików czy strumieniowanie multimediów.

Ta sekcja zawiera wskazówki dotyczące używania zajęć ConnectivityManager do: pomaga upewnić się, że aplikacja ma wystarczającą przepustowość sieci. Ogólne informacje na temat szczegółowej kontroli nad zasobami sieciowymi można znaleźć w sekcji Zarządzanie wykorzystanie danych w sieci.

Poproś o połączenie Wi-Fi

Na potrzeby zastosowań, które wymagają dostępu do sieci o dużej przepustowości, takiego jak transport dużych plików lub strumieniowych transmisji multimedialnych, należy żądać łącza o dużej przepustowości. transportu publicznego, na przykład 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 dostępu do sieci może nie być natychmiastowe, ponieważ na zegarku jest radio komórkowe może być wyłączone, by oszczędzać baterię. Jeśli zegarek nie może połączyć się z sieci, metoda onAvailable() instancji NetworkCallback nie jest .

Po wywołaniu onAvailable() urządzenie spróbuje utrzymać połączenie z Sieć Wi-Fi do chwili zwolnienia NetworkCallback. Aby wydłużyć czas pracy baterii: zwolnij wywołanie zwrotne w sposób pokazany w poniższym przykładzie, gdy nie potrzebujesz już wywołania Sieć Wi-Fi.

Kotlin

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

Java

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

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

Podczas żądania sieci Wi-Fi system próbuje połączyć się z zapisaną siecią. jeśli jest skonfigurowany i mieści się w zakresie. Jeśli nie ma dostępnej zapisanej sieci Wi-Fi, Metoda wywołania zwrotnego onAvailable instancji NetworkCallback nie jest wywoływana.

Jeśli do sygnalizowania końca żądania sieciowego używasz urządzenia Handler, możesz skierować dodawania sieci Wi-Fi po upłynięciu limitu czasu. Przekieruj użytkownika bezpośrednio do działanie związane z dodaniem sieci Wi-Fi w 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, aplikacja musi mieć CHANGE_WIFI_STATE uprawnienia.

Uwagi na temat interfejsu

Jeśli aplikacja wymaga połączenia z nową siecią Wi-Fi, by uzyskać wysoką przepustowość upewnij się, że powód połączenia jest jasny dla użytkownika, po uruchomieniu ustawień Wi-Fi. Poproś użytkownika tylko o dodanie nowej sieci Wi-Fi gdy potrzebna jest sieć o dużej przepustowości. Nie blokuj użytkownikowi dostępu uzyskać dostęp 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ę na ma mniejszą przepustowość i wymaga od użytkownika dodania nowej sieci Wi-Fi tylko wtedy, i chcą pobrać lub odtwarzać strumieniowo muzykę.

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ć wykorzystanie mobilnej transmisji danych, odłóż do pracochłonnej obsługi sieci, np. tworzenia raportów analitycznych lub zbierania dzienników, dopóki urządzenie z Wear OS nie ponownie nawiąże połączenia Bluetooth lub Wi-Fi zamiast z sieci LTE czy 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 dotychczasowymi dokumentacji na temat łączenia się z siecią i przesyłania wiadomości w chmurze.

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

Dostarczaj wiadomości z FCM przez zbieranie tokena rejestracji urządzenia po uruchomieniu aplikacji na Wear OS. Następnie umieść token w miejscu docelowym gdy serwer wysyła wiadomości do punktu końcowego REST FCM. FCM wysyła wiadomości do: urządzenie identyfikowane przez token.

Wiadomość FCM ma format JSON (JavaScript Object Notation) i może zawierać jeden lub oba z tych ładunków:

  • Ładunek powiadomienia: gdy ładunek powiadomienia otrzyma dane wyświetlają się użytkownikowi bezpośrednio w strumieniu powiadomień. Kiedy użytkownik kliknie powiadomienie, a 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 posiadasz samodzielna aplikacja na Wear OS i odpowiadająca jej aplikacja na telefon, zduplikowane powiadomienia może wystąpić. Na przykład pojedyncze powiadomienie z FCM odebrane przez telefonu i zegarka, mogą być wyświetlane przez oba urządzenia niezależnie. Dostępne opcje temu zapobiec za pomocą interfejsów API połączeń.

Używaj usług w tle

Aby zadania w tle były prawidłowo wykonywane, użytkownicy muszą uwzględniać dla funkcji Uśpienie i Czuwanie aplikacji.

Gdy ekran wyłączy się lub przejdzie w tryb nieaktywny na odpowiednio długi czas, podzbiór może powodować uśpienie, a zadania w tle mogą być 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 rejestrację aplikacji do uruchamiania kodu w trybie uśpienia.

Harmonogram z ograniczeniami

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

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

    Określ, czy NetworkType to CONNECTED czy UNMETERED. UNMETERED – do dużych transferów danych, a CONNECTED – do małych transfery danych.

  • Zaplanuj żądanie podczas ładowania.

  • Zaplanuj żądanie, gdy urządzenie jest nieaktywne. Przydaje się to w przypadku praca lub synchronizacja w tle o niższym priorytecie, zwłaszcza gdy urządzenie się ładuje.

Więcej informacji znajdziesz w artykule Wpływ ograniczeń na usługę WorkManager pracy okresowej.