Comunícate directamente a través de una red en dispositivos independientes

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 para Wear OS a una red. En su lugar, sigue los lineamientos y los pasos que se indican 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 generalmente se envía mediante proxy a través del teléfono.

Cuando un teléfono no está disponible, se usan las redes móviles y Wi-Fi, 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 mediante la lectura y escritura de encabezados en las solicitudes y las respuestas.

Usa WorkManager para 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 conectividad de red con el objetivo de proporcionar la mejor experiencia del usuario en general. Para elegir la red activa predeterminada, la plataforma equilibra dos necesidades: una batería de larga duración y un ancho de banda de red.

Cuando se prioriza la conservación de la batería, es posible que la red activa no tenga suficiente ancho de banda para las tareas de red, como la transporte de archivos grandes o la transmisión de contenido multimedia.

En esta sección, se proporciona orientación sobre el uso de 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 detallado de los recursos de red, consulta Administra el uso de la 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 un transporte de ancho de banda alto, como Wi-Fi. Esto se muestra en el siguiente ejemplo:

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
)

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 puede conectarse a una red, no se llama al método onAvailable() de la 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. Para preservar 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.

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

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ó una y 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 para agotar el tiempo de espera de la solicitud de red, puedes indicarle al usuario que agregue una red Wi-Fi cuando se agote el tiempo de espera. Envía al usuario directamente a la actividad para agregar una red Wi-Fi con el siguiente intent:

context.startActivity(Intent("com.google.android.clockwork.settings.connectivity.wifi.ADD_NETWORK_SETTINGS"))

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 permiso 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 iniciar la configuración de Wi-Fi. Solo solicita que el usuario agregue una nueva red Wi-Fi cuando se requiera la red de alto ancho de banda. No bloquees el acceso del usuario a las funciones de la app que no requieren una red de alto ancho de banda.

En la figura 1, se muestra una app de música. La app le permite al usuario explorar música en una red de menor ancho de banda y solo requiere que agregue una nueva red Wi-Fi si desea descargar o transmitir 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 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 en lugar de una conexión LTE o de uso medido.

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

Para enviar notificaciones, usa Firebase Cloud Messaging (FCM) directamente.

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 Cloud Messaging.

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

Proporciona mensajes de FCM mediante 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 una carga útil de notificación, los datos se muestran al usuario directamente en el flujo de notificaciones. Cuando el usuario presiona la notificación, se inicia tu app.
• Carga útil de datos: Cuando 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 la app para teléfonos al reloj. Si tienes una app para Wear OS independiente y la aplicación para teléfonos correspondiente, pueden generarse notificaciones duplicadas. Por ejemplo, ambos dispositivos podrían mostrar de forma independiente una sola notificación de FCM, recibida en un teléfono y en un reloj. Para evitarlo, usa las APIs de puente.

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 entra en el modo ambiente durante un tiempo suficientemente largo, puede producirse una instancia de Descanso y las tareas en segundo plano pueden posponerse ciertos períodos. Más tarde, cuando el dispositivo permanece quieto 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 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. Esto es útil para la sincronización o los trabajos en segundo plano de menor prioridad, en especial cuando el dispositivo se está cargando.

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