Comunicare direttamente su una rete su dispositivi autonomi

Con Wear OS by Google, un orologio può comunicare direttamente con una rete, senza accedere a uno smartphone Android o iOS. Non utilizzare l'API Data Layer per connettere un'app per Wear OS a una rete. Segui invece le linee guida e i passaggi in questa guida.

Accesso alla rete

Le app per Wear OS possono effettuare richieste di rete. Quando uno smartwatch è connesso al Bluetooth a uno smartphone, il traffico di rete dello smartwatch viene generalmente inviato tramite proxy attraverso lo smartphone.

Quando non è disponibile uno smartphone, vengono utilizzate le reti Wi-Fi e mobili, a seconda dell'hardware dello smartwatch. La piattaforma Wear OS gestisce le transizioni tra le reti.

Puoi utilizzare protocolli come HTTP, TCP e UDP. Tuttavia, le API android.webkit, inclusa la classe CookieManager, non sono disponibili. Puoi utilizzare i cookie leggendo e scrivendo intestazioni su richieste e risposte.

Utilizza WorkManager per le richieste asincrone, incluso il polling a intervalli regolari.

Se devi connetterti a tipi di rete specifici, consulta la sezione Lettura dello stato della rete.

Accesso alla rete a larghezza di banda elevata

La piattaforma Wear OS gestisce la connettività di rete con l'obiettivo di offrire la migliore esperienza utente in generale. La piattaforma sceglie la rete attiva predefinita bilanciando due esigenze: batteria a lunga durata e larghezza di banda della rete.

Quando viene assegnata la priorità alla conservazione della batteria, la rete attiva potrebbe non disporre di una larghezza di banda sufficiente per attività di rete come il trasporto di file di grandi dimensioni o lo streaming di contenuti multimediali.

Questa sezione fornisce indicazioni sull'utilizzo della classe ConnectivityManager per assicurarti che la tua app disponga della larghezza di banda di rete necessaria. Per informazioni generali sul controllo granulare sulle risorse di rete, consulta la pagina su come gestire l'utilizzo della rete.

Richiedi connettività Wi-Fi

Per i casi d'uso che richiedono l'accesso alla rete a elevata larghezza di banda, ad esempio il trasporto di file di grandi dimensioni o lo streaming di contenuti multimediali, richiedi la connettività con un trasporto a larghezza di banda elevata, ad esempio Wi-Fi. Ciò è mostrato nell'esempio seguente:

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
);

L'acquisizione di una rete potrebbe non essere istantanea, perché il Wi-Fi o la radio cellulare di uno smartwatch potrebbero essere disattivati per risparmiare batteria. Se lo smartwatch non riesce a connettersi a una rete, il metodo onAvailable() della tua istanza NetworkCallback non viene chiamato.

Dopo la chiamata a onAvailable(), il dispositivo tenta di rimanere connesso alla rete Wi-Fi fino al rilascio di NetworkCallback. Per preservare la durata della batteria, rilascia il callback come mostrato nell'esempio seguente quando non hai più bisogno di una rete Wi-Fi.

Kotlin

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

Java

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

Avvia l'attività relativa alle impostazioni Wi-Fi

Quando viene richiesta una rete Wi-Fi, il sistema tenta di connettersi a una rete salvata se configurata e nel raggio d'azione. Se non è disponibile nessuna rete Wi-Fi salvata, il metodo di callback onAvailable della tua istanza NetworkCallback non viene chiamato.

Se utilizzi un Handler per cronometrare la richiesta di rete, puoi indirizzare l'utente ad aggiungere una rete Wi-Fi quando si verifica il timeout. Invia l'utente direttamente all'attività per l'aggiunta di una rete Wi-Fi utilizzando il seguente intento:

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"));

Per avviare l'attività relativa alle impostazioni, la tua app deve avere l'autorizzazione CHANGE_WIFI_STATE.

Considerazioni sull'interfaccia utente

Se l'app richiede una connessione a una nuova rete Wi-Fi per un'operazione a banda larga, assicurati che il motivo della connessione sia chiaro all'utente prima di avviare le impostazioni Wi-Fi. Richiedi all'utente di aggiungere una nuova rete Wi-Fi solo quando è necessaria la rete ad alta larghezza di banda. Non impedire all'utente di accedere alle funzionalità dell'app che non richiedono una rete a larghezza di banda elevata.

La Figura 1 mostra un'app di musica. L'app consente all'utente di sfogliare la musica su una rete con una larghezza di banda inferiore e richiede all'utente di aggiungere una nuova rete Wi-Fi solo se vuole scaricare o riprodurre musica in streaming.

Download di musica in corso...

Figura 1. Un flusso di app di musica per scaricare musica.

Considerazioni sull'alimentazione e sull'utilizzo dei dati

Per contribuire a preservare la durata della batteria e ridurre al minimo l'utilizzo dei dati mobili, posticipa le attività di rete non essenziali, come i report di analisi o la raccolta di log, finché il dispositivo Wear OS non ha ristabilito una connessione Bluetooth o Wi-Fi anziché una connessione LTE o a consumo.

Messaggistica cloud

Per inviare le notifiche, utilizza direttamente Firebase Cloud Messaging (FCM).

Nessuna API per l'accesso alla rete o FCM è specifica di Wear OS. Consulta la documentazione esistente sulla connessione a una rete e sulla messaggistica cloud.

FCM funziona bene con Sospensione ed è il metodo consigliato per inviare notifiche a un orologio.

Fornisci i messaggi da FCM raccogliendo un token di registrazione per un dispositivo quando è in esecuzione l'app per Wear OS. Includi il token nella destinazione quando il server invia messaggi all'endpoint REST di FCM. FCM invia i messaggi al dispositivo identificato dal token.

Un messaggio FCM è in formato JSON (JavaScript Object Notation) e può includere uno o entrambi i seguenti payload:

  • Payload delle notifiche: quando un payload di notifica viene ricevuto da un orologio, i dati vengono visualizzati a un utente direttamente nel flusso di notifica. Quando l'utente tocca la notifica, viene avviata l'app.
  • Payload dei dati: quando il payload ha un set di coppie chiave o valore personalizzate. Il payload viene inviato sotto forma di dati alla tua app per Wear OS.

Per ulteriori informazioni ed esempi di payload, vedi Informazioni sui messaggi FCM.

Per impostazione predefinita, le notifiche vengono collegate da un'app per smartphone a uno smartwatch. Se hai un'app per Wear OS autonoma e un'app per smartphone corrispondente, potrebbero verificarsi notifiche duplicate. Ad esempio, una singola notifica da FCM, ricevuta sia da uno smartphone sia da un orologio, potrebbe essere visualizzata da entrambi i dispositivi separatamente. Puoi evitare questo problema utilizzando le API di collegamento.

Utilizzare i servizi in background

Per garantire che le attività in background vengano eseguite correttamente, devono tenere conto di Sospensione e Standby delle app.

Quando uno schermo si disattiva o entra in modalità Ambient per un periodo di tempo sufficientemente lungo, può verificarsi un sottoinsieme di Sospensione e le attività in background possono essere differite per determinati periodi. In seguito, quando il dispositivo rimane fermo per un periodo di tempo prolungato, si verifica una modalità di sospensione regolare. Pianifica le richieste con l'API WorkManager, che consente alla tua app di registrarsi per l'esecuzione di codice Doze-safe.

Pianifica con vincoli

Puoi utilizzare i vincoli per configurare le richieste in modo da preservare la durata della batteria. Seleziona uno o più dei seguenti vincoli da includere nelle richieste:

  • Pianifica una richiesta che richiede il networking.

    Specifica se NetworkType è CONNECTED o UNMETERED. UNMETERED è indicato per trasferimenti di dati di grandi dimensioni, mentre CONNECTED è indicato per trasferimenti di piccole dimensioni.

  • Pianifica una richiesta durante la ricarica.

  • Programma una richiesta quando il dispositivo è inattivo. Ciò è utile per il lavoro in background o la sincronizzazione con priorità più bassa, in particolare quando il dispositivo è in carica.

Per ulteriori informazioni, consulta la guida Effetto dei vincoli sul lavoro periodico di WorkManager.