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

Con Wear OS by Google, un reloj puede comunicarse con una red directamente, sin acceso a un teléfono Android o iOS. No uses la API de Data Layer para conectar un para Wear OS a una red. En su lugar, sigue los lineamientos y los pasos que se indican .

Acceso a la red

Las apps para Wear OS pueden realizar solicitudes de red. Cuando un reloj tiene conexión Bluetooth a un teléfono, el tráfico de red del reloj generalmente se envía mediante proxy el 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, el Las APIs de android.webkit, incluida la clase CookieManager, no están disponibles. Puedes usar cookies leyendo y escribiendo encabezados en solicitudes y de respuestas ante incidentes.

Usa WorkManager para solicitudes asíncronas, incluido el sondeo en la red normal. en intervalos de tiempo.

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

Acceso a redes de alto ancho de banda

La plataforma de Wear OS administra la conectividad de red con el objetivo de proporcionar la la mejor experiencia general del usuario. La plataforma elige la red activa predeterminada equilibrar dos necesidades: batería de larga duración y ancho de banda de red.

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

En esta sección, se proporciona orientación sobre el uso de la clase ConnectivityManager para lo siguiente: garantizar que tu app tenga el ancho de banda de red que necesita. En general información sobre el control detallado de los recursos de red, consulta Administrar el uso de la red.

Solicita conectividad Wi-Fi

Para casos de uso que requieren acceso a redes de ancho de banda alto, como archivos grandes o la transmisión de contenido multimedia, solicitan conectividad con un ancho de banda alto transporte, 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 conexión Wi-Fi o es posible que la radio móvil esté desactivada para ahorrar batería. Si el reloj no puede conectarse a un red, el método onAvailable() de tu instancia NetworkCallback no es llamado.

Una vez que se llama a onAvailable(), el dispositivo intenta permanecer conectado a la red Wi-Fi hasta que se libere NetworkCallback. Para preservar la duración de la batería, libera la devolución de llamada como se muestra en el siguiente ejemplo cuando ya no necesites un 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 red guardada. si hay uno configurado y dentro del rango. Si no hay ninguna red Wi-Fi disponible, el ícono No se llama al método de devolución de llamada onAvailable de tu instancia NetworkCallback.

Si estás usando un Handler para agotar el tiempo de espera de la solicitud de red, puedes indicarle al que el usuario agregue una red Wi-Fi cuando se agote el tiempo de espera. Enviar 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 la CHANGE_WIFI_STATE. permiso.

Consideraciones sobre la interfaz de usuario

Si tu app requiere una conexión a una nueva red Wi-Fi para un ancho de banda alto, haz lo siguiente: operación, asegúrate de que el motivo de la conexión sea claro para el usuario antes inicias la configuración de Wi-Fi. Solo solicítale al usuario que agregue una red Wi-Fi nueva cuando se necesita la red de alto ancho de banda. No bloquees al usuario acceder a 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 un red de menor ancho de banda y solo requiere que el usuario agregue una nueva red Wi-Fi si quieren 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 los tareas de red no esenciales, como los informes de análisis o la recopilación de registros, hasta que el dispositivo Wear OS vuelva a establecer 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 documentación sobre cómo conectarse a una red y Cloud Messaging.

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

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

Un mensaje de FCM está en formato de notación de objetos de JavaScript (JSON) y puede incluir una o ambas de las siguientes cargas útiles:

• Carga útil de la notificación: Cuando una carga útil de notificación recibe una notificación, mirar, los datos se muestran al usuario directamente en el flujo de notificaciones. Cuándo 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 un app para Wear OS independiente y una aplicación para teléfonos correspondiente, notificaciones duplicadas puede ocurrir. Por ejemplo, una sola notificación de FCM, recibida por un un teléfono y un reloj, podrían mostrarse de forma independiente en ambos dispositivos. Puedes y evitar esto con APIs de modo puente.

Usa servicios en segundo plano

Para ayudar a garantizar que las tareas en segundo plano se ejecuten correctamente, deben tener en cuenta para Descanso y App Standby.

Cuando una pantalla se apaga o entra en el modo ambiente durante un tiempo suficiente, un subconjunto puede ocurrir Descanso y las tareas en segundo plano pueden aplazarse durante 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 la ejecución de código a prueba de Descanso.

Programa tareas con restricciones

Puedes usar restricciones para configurar solicitudes de modo que se preserve la batería la vida. Selecciona una o más de las siguientes restricciones para incluir en tu 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 de datos.

• Programa una solicitud mientras se carga.

• Programa una solicitud mientras el dispositivo está inactivo. Esto es útil para trabajo en segundo plano o sincronización de menor prioridad, especialmente cuando la se está cargando el dispositivo.

Para obtener más información, consulta la sección sobre los efectos de las restricciones en WorkManager trabajo periódico.