Acceso a la red y sincronización en Wear OS

Organiza tus páginas con colecciones Guarda y categoriza el contenido según tus preferencias.

Con Wear OS by Google, un reloj se puede comunicar con una red directamente sin acceder a un teléfono con Android o iOS. No debes usar la API de Data Layer para conectarte a una red.

Acceso a la red

Las apps para Wear OS pueden realizar solicitudes de red. Cuando un reloj tiene una conexión Bluetooth a un teléfono, el tráfico de red del reloj en general se envía mediante proxy a través del teléfono.

Cuando un teléfono no está disponible, se usan las redes Wi-Fi y móviles, según el hardware del reloj. La plataforma de Wear OS controla las transiciones entre redes.

Puedes usar protocolos como HTTP, TCP y UDP. Sin embargo, las APIs de android.webkit (incluida la clase CookieManager) no están disponibles. Puedes usar cookies con la lectura y escritura de encabezados en solicitudes y respuestas.

También recomendamos usar la API de WorkManager para las solicitudes asíncronas, incluidos los sondeos a intervalos regulares.

Si necesitas conectarte a tipos de red específicos, consulta Cómo leer el estado de la red.

Acceso a redes de alto ancho de banda

La plataforma de Wear OS administra la conexión de red con el objetivo de proporcionar la mejor experiencia del usuario en general. Para elegir la red activa predeterminada, la plataforma evalúa los siguientes dos factores:

  • La necesidad de conservar batería
  • La necesidad de ancho de banda de red

Cuando se prioriza la conservación de la batería, la red activa podría no llegar a satisfacer la alta demanda de ancho de banda de ciertas tareas, como la transferencia de archivos grandes o la transmisión de contenido multimedia.

En esta sección, verás una guía para usar la clase ConnectivityManager y asegurarte de que tu app pueda usar el ancho de banda de red necesario. A fin de obtener información general sobre el control preciso de recursos de red, consulta Cómo administrar el uso de red.

Solicita la conectividad Wi-Fi

Para los casos prácticos que requieren acceso a redes de ancho de banda alto, como la transferencia de archivos grandes o la transmisión de contenido multimedia, solicita conectividad con una transmisión de ancho de banda alto, como Wi-Fi.

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)
        // The Wi-Fi network has been disconnected
    }
}
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);
        // The Wi-Fi network has been disconnected
    }
};
connectivityManager.requestNetwork(
        new NetworkRequest.Builder().addTransportType(NetworkCapabilities.TRANSPORT_WIFI).build(),
        callback
);

Es posible que adquirir una red no sea un proceso instantáneo porque la radio móvil o Wi-Fi de un reloj podría estar desactivada para conservar la batería. Además, si un reloj no se puede conectar a una red, no se llamará al método onAvailable() de tu instancia de NetworkCallback.

Una vez que se llame a onAvailable(), el dispositivo intentará permanecer conectado a la red Wi-Fi hasta que se libere NetworkCallback. Libera la devolución de llamada cuando ya no necesites una red Wi-Fi para conservar la duración de la batería.

Kotlin

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

Java

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

Inicia la actividad de configuración de Wi-Fi

Cuando se solicita una red Wi-Fi, el sistema intenta conectarse a una guardada si se configuró alguna y si está dentro del alcance. No obstante, si no hay una red Wi-Fi disponible, no se llama al método de devolución de llamada onAvailable() de tu instancia de NetworkCallback.

Si usas un Handler a los efectos de agotar el tiempo de espera de la solicitud de red, puedes indicarle al usuario que agregue una red Wi-Fi cuando haya transcurrido dicho tiempo. Envía al usuario directamente a la actividad para agregar una red Wi-Fi con el siguiente 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"));

Para iniciar la actividad de configuración, tu app debe tener el siguiente permiso: android.permission.CHANGE_WIFI_STATE.

Consideraciones sobre la interfaz de usuario

Si tu app requiere una conexión a una nueva red Wi-Fi para una operación de ancho de banda alto, asegúrate de que el motivo de la conexión sea claro para el usuario antes de que inicies la configuración de Wi-Fi. Solo debes solicitar que el usuario agregue una nueva red Wi-Fi cuando se requiera la red de ancho de banda alto. No bloquees el acceso de un usuario a las funciones de la app que no necesitan una red de ancho de banda alto.

En la figura 1, se muestra una app de música. Esta debería permitirle al usuario explorar música y solicitarle que agregue una nueva red Wi-Fi únicamente si quiere descargar o transmitir música.

Descarga de música

Figura 1: El flujo de una app de música para descargar contenido musical.

Envío de mensajes a través de la nube

Para enviar notificaciones, las apps pueden usar directamente Firebase Cloud Messaging (FCM).

No hay APIs para acceso a redes ni a FCM que sean específicas de Wear OS. Consulta la documentación existente para conectarse a una red y sobre el envío de mensajes a través de la nube.

FCM funciona bien con Descanso y es el método recomendado para enviar notificaciones a un reloj.

Permite los mensajes de FCM con la recopilación de un token de registro para un dispositivo cuando se ejecute tu app para Wear OS. Luego, incluye el token como parte del destino cuando tu servidor envíe mensajes al extremo REST de FCM. FCM envía mensajes al dispositivo que identificó el token.

Un mensaje de FCM está en formato JSON y puede incluir una de las siguientes cargas útiles o ambas:

  • Carga útil de la notificación: cuando un reloj recibe la carga útil de una notificación, los datos se muestran directamente al usuario en el flujo de notificaciones. Cuando el usuario presiona la notificación, se inicia tu app.
  • Carga útil de datos: La carga útil tiene un conjunto de pares clave-valor personalizados. La carga útil se entrega como datos a tu app para Wear OS.

Para obtener más información y ver ejemplos relacionados con cargas útiles, consulta Información sobre los mensajes de FCM.

De forma predeterminada, las notificaciones se comparten desde una app para teléfonos hacia un reloj. Si tienes una app independiente para Wear OS y la aplicación para teléfonos correspondiente, pueden generarse notificaciones duplicadas. Por ejemplo, un teléfono y un reloj que recibieron la misma notificación de FCM podrían mostrarla de forma independiente. Puedes evitarlo con las APIs de Bridging.

Usa servicios en segundo plano

Para garantizar que las tareas en segundo plano se ejecuten correctamente, deben tener en cuenta la función Descanso y App Standby.

Cuando una pantalla se apaga o ingresa al modo ambiente durante un tiempo suficientemente largo, puede producirse una instancia de Descanso y las tareas en segundo plano pueden posponerse algunos períodos. Más tarde, cuando un dispositivo permanece inactivo durante un tiempo prolongado, aparece la función Descanso normal. Debes programar solicitudes con la API de WorkManager, que permite que tu app se registre para ejecutar código a prueba de Descanso.

Programa tareas con restricciones

Puedes usar restricciones para configurar solicitudes de un modo que preserve la duración de la batería. Selecciona una o más de las siguientes restricciones para incluir en tus solicitudes:

  • Programa una solicitud que requiera herramientas de redes. Especifica si NetworkType es CONNECTED o UNMETERED. UNMETERED es para transferencias de datos grandes, mientras que CONNECTED es para transferencias pequeñas.
  • Programa una solicitud mientras se carga.
  • Programa una solicitud mientras el dispositivo está inactivo. Es útil para la sincronización o los trabajos en segundo plano con menor prioridad, en especial cuando el dispositivo se está cargando.

Ten en cuenta que algunas redes de ancho de banda bajo, como Bluetooth de bajo consumo, se consideran de uso medido.

Para obtener más información, consulta la guía sobre los efectos de las restricciones en trabajos periódicos de WorkManager.