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

Dzięki Wear OS by Google zegarek może komunikować się z siecią bezpośrednio, 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 z wytycznymi i instrukcjami podanymi w tym przewodniku.

Dostęp do sieci

Aplikacje na Wear OS mogą wysyłać żądania sieciowe. Gdy zegarek jest połączony z telefonem przez Bluetooth, ruch sieciowy zegarka jest zwykle przekazywany przez telefon.

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

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

W przypadku żądań asynchronicznych, w tym regularnego sprawdzania dostępności aktualizacji, używaj WorkManager.

Jeśli musisz połączyć się z określonymi typami sieci, zapoznaj się z artykułem Odczytywanie stanu sieci.

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

Platforma Wear OS zarządza łącznością sieciową, aby zapewnić użytkownikom jak najlepsze wrażenia. Platforma wybiera domyślną aktywną sieć, równoważąc 2 potrzeby: długi czas pracy na baterii i przepustowość sieci.

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

W tej sekcji znajdziesz wskazówki dotyczące korzystania z klasy ConnectivityManager, które pomogą Ci zapewnić aplikacji odpowiednią przepustowość sieci. Ogólne informacje o szczegółowej kontroli zasobów sieciowych znajdziesz w artykule Zarządzanie wykorzystaniem sieci.

Prośba o połączenie Wi-Fi

W przypadku zastosowań wymagających dostępu do sieci o dużej przepustowości, takich jak przesyłanie dużych plików lub strumieniowe przesyłanie multimediów, poproś o połączenie z siecią o dużej przepustowości, np. Wi-Fi. Ilustruje to poniższy przykład:

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

fun requestWifiNetwork() {
    connectivityManager.requestNetwork(
        NetworkRequest.Builder().addTransportType(NetworkCapabilities.TRANSPORT_WIFI).build(),
        callback
    )
}

Uzyskanie dostępu do sieci może nie być natychmiastowe, ponieważ radio Wi-Fi lub komórkowe zegarka może być wyłączone w celu oszczędzania baterii. Jeśli zegarek nie może połączyć się z siecią, metoda onAvailable() instancji NetworkCallback nie jest wywoływana.

Po wywołaniu funkcji onAvailable() urządzenie próbuje utrzymać połączenie z siecią Wi-Fi, dopóki nie zostanie zwolniona funkcja NetworkCallback. Aby oszczędzać baterię, zwolnij wywołanie zwrotne, jak pokazano w poniższym przykładzie, gdy nie będziesz już potrzebować sieci Wi-Fi.

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

Otwieranie ustawień Wi-Fi

Podczas wysyłania prośby o sieć Wi-Fi system próbuje połączyć się z zapisaną siecią, jeśli jest ona skonfigurowana i w zasięgu. Jeśli nie ma zapisanej sieci Wi-Fi, metoda wywołania zwrotnego instancji NetworkCallback nie jest wywoływana.onAvailable

Jeśli do określania czasu oczekiwania na żądanie sieciowe używasz Handler, możesz w przypadku przekroczenia limitu czasu poprosić użytkownika o dodanie sieci Wi-Fi. Przekieruj użytkownika bezpośrednio do aktywności dodawania sieci Wi-Fi za pomocą tego intencji:

val networkSettingsAction = "com.google.android.clockwork.settings.connectivity.wifi.ADD_NETWORK_SETTINGS"
val intent = Intent(networkSettingsAction).apply {
    addFlags(Intent.FLAG_ACTIVITY_NEW_TASK)
}
context.startActivity(intent)

Aby uruchomić aktywność ustawień, aplikacja musi mieć uprawnienie CHANGE_WIFI_STATE.

Wskazówki dotyczące interfejsu

Jeśli aplikacja wymaga połączenia z nową siecią Wi-Fi do wykonania operacji o dużej przepustowości, powinna bezproblemowo uzyskiwać to połączenie i zwalniać je w razie potrzeby. Jeśli nie ma dostępnej sieci Wi-Fi, wyjaśnij, że ta funkcja wymaga Wi-Fi, i udostępnij sposób uruchomienia aktywności ustawień Wi-Fi. Nie blokuj użytkownikowi dostępu do funkcji aplikacji, które nie wymagają sieci o dużej przepustowości.

Zużycie energii i danych

Aby oszczędzać baterię i minimalizować zużycie mobilnej transmisji danych, odłóż wszelkie nieistotne zadania sieciowe, takie jak raportowanie analityczne czy zbieranie logów, do czasu, aż urządzenie z Wear OS ponownie nawiąże połączenie Bluetooth lub Wi-Fi zamiast połączenia LTE lub połączenia z limitem danych.

Komunikacja w chmurze

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

Żadne interfejsy API do uzyskiwania dostępu do sieci ani FCM nie są specyficzne dla Wear OS. Zapoznaj się z dokumentacją dotyczącą nawiązywania połączenia z sieciąkomunikacji w chmurze.

FCM dobrze współpracuje z trybem uśpienia i jest zalecanym sposobem wysyłania powiadomień na zegarek.

Zapewnij obsługę wiadomości z FCM, zbierając token rejestracyjny urządzenia, gdy działa aplikacja na Wear OS. Następnie dołącz token do miejsca docelowego, gdy serwer wysyła wiadomości do punktu końcowego REST FCM. FCM wysyła wiadomości na urządzenie zidentyfikowane przez token.

Wiadomość FCM jest w formacie JSON (JavaScript Object Notation) i może zawierać 1 lub 2 z tych ładunków:

  • Ładunek powiadomienia: gdy zegarek otrzyma ładunek powiadomienia, dane są wyświetlane użytkownikowi bezpośrednio w strumieniu powiadomień. Gdy użytkownik kliknie powiadomienie, aplikacja zostanie uruchomiona.
  • Ładunek danych: gdy ładunek zawiera zestaw niestandardowych par klucz-wartość. Ładunek jest dostarczany do aplikacji na Wear OS w postaci danych.

Więcej informacji i przykłady ładunków znajdziesz w artykule Typy wiadomości.

Domyślnie powiadomienia są udostępniane z aplikacji na telefonie na zegarek. Jeśli masz samodzielną aplikację na Wear OS i odpowiadającą jej aplikację na telefon, mogą pojawiać się zduplikowane powiadomienia. Na przykład jedno powiadomienie z FCM odebrane przez telefon i zegarek może być wyświetlane przez oba urządzenia niezależnie. Możesz temu zapobiec, używając interfejsów API pomostowych.

Korzystanie z usług w tle

Aby mieć pewność, że zadania w tle są wykonywane prawidłowo, muszą one uwzględniać tryb uśpienia i stan gotowości aplikacji.

Gdy ekran wyłączy się lub przejdzie w tryb otoczenia na wystarczająco długi czas, może nastąpić częściowe przejście w tryb uśpienia, a zadania w tle mogą zostać odroczone na określony czas. Później, gdy urządzenie przez dłuższy czas pozostaje w bezruchu, włącza się zwykły tryb uśpienia. Planuj żądania za pomocą interfejsu WorkManager API, który umożliwia aplikacji rejestrowanie się w celu wykonywania kodu w trybie uśpienia.

Planowanie z ograniczeniami

Za pomocą ograniczeń możesz skonfigurować żądania w taki sposób, aby oszczędzać baterię. Wybierz co najmniej jedno z tych ograniczeń, które chcesz uwzględnić w swoich żądaniach:

  • Zaplanuj prośbę, która wymaga sieci.

    Określ, czy wartość NetworkType to CONNECTED czy UNMETERED. UNMETERED służy do przesyłania dużych ilości danych, a CONNECTED – małych.

  • Zaplanuj prośbę podczas ładowania.

  • Zaplanuj żądanie, gdy urządzenie jest bezczynne. Jest to przydatne w przypadku mniej ważnych zadań w tle lub synchronizacji, zwłaszcza gdy urządzenie jest ładowane.

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