Comunicare direttamente su una rete su dispositivi autonomi

Con Wear OS by Google, un orologio può comunicare direttamente con una rete, senza l'accesso a un telefono Android o iOS. Non utilizzare l'API Data Layer per connettere un 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 un orologio dispone di un Bluetooth a uno smartphone, il traffico di rete dello smartwatch viene generalmente inviato tramite proxy il telefono.

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

Puoi utilizzare protocolli come HTTP, TCP e UDP. Tuttavia, Le API di android.webkit, incluso il corso CookieManager, non sono disponibili. Puoi utilizzare i cookie leggendo e scrivendo intestazioni sulle richieste diverse.

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

Se devi connetterti a tipi di rete specifici, consulta la sezione Rete di lettura. .

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 in generale. La piattaforma sceglie la rete attiva predefinita bilanciare due esigenze: batteria a lunga durata e larghezza di banda di 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 contenuti multimediali.

Questa sezione fornisce indicazioni sull'utilizzo del corso ConnectivityManager per per assicurarti che la tua app abbia la larghezza di banda di rete necessaria. Per informazioni generali informazioni sul controllo granulare sulle risorse di rete, consulta Gestire utilizzo della rete.

Richiedi connettività Wi-Fi

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

Dopo aver chiamato onAvailable(), il dispositivo tenta di rimanere connesso al Rete Wi-Fi fino al rilascio di NetworkCallback. Per preservare la durata della batteria, rilasciare il callback come mostrato nell'esempio seguente, quando non hai più bisogno di 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 una di queste è configurata e nel raggio d'azione. Se non è disponibile una 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 di aggiungere una rete Wi-Fi quando si verifica il timeout. Invia l'utente direttamente a l'attività per l'aggiunta di 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 l'CHANGE_WIFI_STATE autorizzazione.

Considerazioni sull'interfaccia utente

Se la tua app richiede una connessione a una nuova rete Wi-Fi per una larghezza di banda elevata assicurati che il motivo della connessione sia chiaro all'utente prima avvii le impostazioni Wi-Fi. Richiedi solo all'utente di aggiungere una nuova rete Wi-Fi quando è necessaria una rete a larghezza di banda elevata. Non impedire all'utente di accesso a funzionalità delle 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 ha una larghezza di banda inferiore e richiede all'utente di aggiungere una nuova rete Wi-Fi solo se che vogliono 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 qualsiasi attività di networking non essenziali, come la generazione di report di analisi o la raccolta di log, finché sul dispositivo Wear OS non viene ristabilita 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. Fai riferimento all'elenco documentazione 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 messaggi da FCM raccogliendo un token di registrazione per un dispositivo quando è in esecuzione l'app per Wear OS. Quindi includi il token come parte della destinazione quando il tuo server invia messaggi all'endpoint REST di FCM. FCM invia messaggi a 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 l'orologio, i dati vengono mostrati all'utente direttamente nello stream della notifica. Quando l'utente tocca la notifica e la tua app si avvia.
  • 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 disponi di un app per Wear OS autonoma e un'app per smartphone corrispondente, notifiche duplicate che possono verificarsi. Ad esempio, una singola notifica da FCM, ricevuta sia da un uno smartphone e uno smartwatch, possono essere visualizzati separatamente da entrambi i dispositivi. Puoi evitare che ciò accada utilizzando le API di bridging.

Utilizzare i servizi in background

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

Quando uno schermo si spegne o entra in modalità Ambient per un periodo di tempo sufficiente, 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 con protezione della sospensione.

Pianifica con vincoli

Puoi utilizzare i vincoli per configurare le richieste in modo da preservare la batteria vita privata. Seleziona uno o più dei seguenti vincoli da includere nel 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 piccoli trasferimenti trasferimenti.

  • Pianifica una richiesta durante la ricarica.

  • Programma una richiesta quando il dispositivo è inattivo. Questo è utile per lavori in background o sincronizzazione a bassa priorità, in particolare Il dispositivo è in carica.

Per ulteriori informazioni, esamina l'effetto dei vincoli su di lavoro periodico.