Comunicare direttamente su una rete su dispositivi autonomi

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

Accesso di rete

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

Quando uno smartphone non è disponibile, vengono utilizzate le reti Wi-Fi e cellulare, 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 le intestazioni delle richieste e delle risposte.

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

Se devi connetterti a tipi di rete specifici, vedi 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 fornire la migliore esperienza utente complessiva. La piattaforma sceglie la rete attiva predefinita bilanciando due esigenze: lunga durata della batteria e larghezza di banda della rete.

Quando viene data la priorità al risparmio della batteria, la rete attiva potrebbe non avere una larghezza di banda sufficiente per attività di rete come il trasferimento 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 delle risorse di rete, consulta Gestire l'utilizzo della rete.

Richiedere la connettività Wi-Fi

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

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
    )
}Network.kt

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

Una volta chiamato onAvailable(), il dispositivo tenta di rimanere connesso alla rete Wi-Fi finché non viene rilasciato 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.

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

Avvia l'attività delle impostazioni Wi-Fi

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

Se utilizzi un Handler per impostare il timeout della richiesta di rete, puoi invitare l'utente ad 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:

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)Network.kt

Per avviare l'attività delle impostazioni, la tua app deve disporre dell'autorizzazione 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, devi acquisirla senza problemi e rilasciarla in base alle necessità. Se non è disponibile alcuna rete Wi-Fi, spiega che la funzionalità richiede il Wi-Fi e fornisci un modo per avviare l'attività delle impostazioni Wi-Fi. Non impedire all'utente di accedere alle funzionalità dell'app che non richiedono una rete a larghezza di banda elevata.

Considerazioni sull'utilizzo di energia e dati

Per preservare la durata della batteria e ridurre al minimo l'utilizzo dei dati mobili, rimanda qualsiasi attività di rete non essenziale, come la generazione di 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.

Cloud Messaging

Per l'invio di notifiche, utilizza direttamente Firebase Cloud Messaging (FCM).

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

FCM funziona bene con Doze ed è il modo consigliato per inviare notifiche a uno smartwatch.

Fornisci messaggi da FCM raccogliendo un token di registrazione per un dispositivo quando viene eseguita l'app Wear OS. Poi includi il token come parte della 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 di notifica:quando un payload di notifica viene ricevuto da uno smartwatch, i dati vengono visualizzati direttamente nel flusso di notifiche. Quando l'utente tocca la notifica, l'app viene avviata.
Payload di dati:quando il payload ha un insieme di coppie chiave-valore personalizzate. Il payload viene inviato come dati alla tua app Wear OS.

Per ulteriori informazioni ed esempi di payload, vedi Tipi di messaggi.

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

Utilizzare i servizi in background

Per garantire che le attività in background vengano eseguite correttamente, devono tenere conto di Doze e App Standby.

Quando uno schermo si spegne o entra in modalità Ambient per un periodo di tempo sufficientemente lungo, può verificarsi un sottoinsieme di Doze e le attività in background possono essere posticipate per determinati periodi. In seguito, quando il dispositivo rimane fermo per un periodo di tempo prolungato, si attiva la modalità Doze normale. Pianifica le richieste con l'API WorkManager, che consente alla tua app di registrarsi per l'esecuzione di codice compatibile con Doze.

Pianificare 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 tue richieste:

Pianifica una richiesta che richiede il networking.

Specifica se NetworkType è CONNECTED o UNMETERED. UNMETERED è per i trasferimenti di grandi quantità di dati, mentre CONNECTED è per i trasferimenti di piccole quantità.
Pianifica una richiesta durante la ricarica.
Pianifica una richiesta mentre il dispositivo è inattivo. Questa funzionalità è utile per lavori o sincronizzazioni in background a bassa priorità, soprattutto quando il dispositivo è in carica.

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

Comunicare direttamente su una rete su dispositivi autonomi Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.