Accesso alla rete e sincronizzazione su Wear OS

Grazie a Wear OS by Google, un orologio può comunicare direttamente con una rete senza accedere a un telefono Android o iOS. Non utilizzare l'API del livello dati per connettere un'app per Wear OS a una rete. Segui invece le linee guida e i passaggi riportati in questa guida.

Accesso alla rete

Le app per Wear OS possono effettuare richieste di rete. Quando uno smartwatch dispone di una connessione Bluetooth a uno smartphone, il traffico di rete dello smartwatch viene generalmente inviato tramite proxy al telefono.

Quando lo smartphone non è disponibile, vengono utilizzate le reti Wi-Fi e mobili, a seconda dell'hardware dell'orologio. 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 nelle richieste e nelle risposte.

Ti consigliamo inoltre di utilizzare l'API WorkManager per le richieste asincrone, incluso il polling a intervalli regolari.

Se hai bisogno di connetterti a tipi di rete specifici, consulta Lettura dello stato della rete.

Accesso alla rete ad alta larghezza di banda

La piattaforma Wear OS gestisce la connettività di rete con l'obiettivo di fornire la migliore esperienza utente complessiva. La piattaforma sceglie la rete attiva predefinita bilanciando due esigenze:

• Batteria a lunga durata
• Larghezza di banda della rete

Quando viene data la priorità alla conservazione della batteria, la rete attiva potrebbe non avere 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 garantire che la tua app abbia la larghezza di banda di rete necessaria. Per informazioni generali sul controllo granulare sulle risorse di rete, consulta Gestire l'utilizzo della rete.

Richiesta di connettività Wi-Fi

Per i casi d'uso che richiedono un accesso di rete a larghezza di banda elevata, come il trasporto di file di grandi dimensioni o lo streaming di contenuti multimediali, richiedi connettività con un trasporto a larghezza di banda elevata, ad esempio il 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é la rete Wi-Fi o la radio cellulare di uno smartwatch potrebbero essere disattivate per risparmiare batteria. Se lo smartwatch non riesce a connettersi a una rete, il metodo onAvailable() dell'istanza NetworkCallback non viene chiamato.

Dopo aver chiamato 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 richiedi una rete Wi-Fi, il sistema tenta di connettersi a una rete salvata, se configurata e nel raggio d'azione. Se non è disponibile alcuna rete Wi-Fi salvata, non viene chiamato il metodo di callback onAvailable() della tua istanza NetworkCallback.

Se utilizzi un Handler per eseguire il timeout della richiesta di rete, puoi indicare all'utente di aggiungere una rete Wi-Fi quando si verifica il timeout. Invia l'utente direttamente all'attività per aggiungere una rete Wi-Fi utilizzando il seguente intent:

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, l'app deve avere la seguente autorizzazione: android.permission.CHANGE_WIFI_STATE.

Considerazioni sull'interfaccia utente

Se la tua app richiede una connessione a una nuova rete Wi-Fi per un'operazione a larghezza di banda elevata, 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 è richiesta la rete a larghezza di banda elevata. 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 larghezza di banda inferiore e richiede all'utente di aggiungere una nuova rete Wi-Fi solo se vuole scaricare o riprodurre musica in streaming.

Figura 1. Flusso di un'app musicale per scaricare musica.

Considerazioni sull'alimentazione e sull'utilizzo dei dati

Per preservare la durata della batteria e ridurre al minimo l'utilizzo della rete dati, rinvia qualsiasi attività di rete non essenziale, come i report di analisi o la raccolta di log, finché il dispositivo Wear OS non avrà ripristinato una connessione Bluetooth o Wi-Fi.

Messaggistica cloud

Per l'invio di notifiche, le app possono utilizzare direttamente Firebase Cloud Messaging (FCM).

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

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

Fornisci i messaggi di FCM raccogliendo un token di registrazione per un dispositivo quando è in esecuzione la tua app per Wear OS. Quindi includi il token nella destinazione quando il server invia messaggi all'endpoint REST di FCM. FCM invia 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 mostrati all'utente direttamente nel flusso di notifiche. Quando l'utente tocca la notifica, l'app viene avviata.
• Payload dei dati: il payload ha un insieme di coppie chiave/valore personalizzate. Il payload viene inviato sotto forma di dati nella tua app per Wear OS.

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

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

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 spegne o entra in modalità Ambient per un tempo sufficiente, può verificarsi un sottoinsieme di Sospensione e le attività in background possono essere differite per determinati periodi. Successivamente, quando il dispositivo rimane fermo per un lungo periodo di tempo, viene attivata la 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 i trasferimenti di dati di grandi dimensioni, mentre CONNECTED è per i trasferimenti di piccole dimensioni.
• Pianifica una richiesta durante la ricarica.
• Pianifica una richiesta quando il dispositivo è inattivo. Questa funzionalità è utile per le attività in background o per la sincronizzazione con priorità più bassa, soprattutto quando il dispositivo è in carica.

Tieni presente che alcune reti con larghezza di banda ridotta, come Bluetooth LE, sono considerate a consumo.

Per saperne di più, consulta la guida Effetti dei vincoli sul lavoro periodico di WorkManager.