Acceso a la red y sincronización en Wear OS

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 uses la API de Data Layer para conectar una app de Wear OS a una red. En su lugar, sigue los lineamientos y los pasos en esta guía.

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 te recomendamos que uses 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:

  • Batería de larga duración
  • Ancho de banda de red

Cuando se prioriza la conservación de la batería, la red activa podría no tener el ancho de banda suficiente para realizar tareas de la red, 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 para garantizar que tu app tenga el ancho de banda de red que necesita. Para obtener información general sobre el control preciso de recursos de red, lee el artículo Cómo administrar el uso de red.

Solicita conectividad Wi-Fi

Para los casos de uso 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. Esto se muestra en el siguiente ejemplo:

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

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. Si el 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 intenta permanecer conectado a la red Wi-Fi hasta que se libere NetworkCallback. Para conservar la duración de batería, libera la devolución de llamada como se muestra en el siguiente ejemplo cuando ya no necesites una red Wi-Fi.

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. 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. La app le permite al usuario explorar la música en una red de menor ancho de banda y solo le requiere agregar una nueva red Wi-Fi en caso de que este desee descargar o transmitir música.

Descarga de música

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

Consideraciones sobre el uso de datos y energía

Para ayudar a preservar la duración de la batería y minimizar el uso de datos móviles, aplaza las tareas de red no esenciales, como los informes de estadísticas o la recopilación de registros, hasta que el dispositivo Wear OS haya restablecido una conexión Bluetooth o Wi-Fi.

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 sobre cómo 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 de notación de objetos de JavaScript (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 de clave o 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 aplicación 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 una única 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. Programa 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 el 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 bajo ancho de banda, como Bluetooth LE, 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.