Communiquer directement via un réseau sur des appareils autonomes

Avec Wear OS by Google, une montre peut communiquer directement avec un réseau l'accès à un téléphone Android ou iOS. N'utilisez pas l'API Data Layer pour connecter un l'application Wear OS sur un réseau. Suivez plutôt les consignes et les étapes décrites dans ce .

Accès au réseau

Les applications Wear OS peuvent effectuer des requêtes réseau. Lorsqu'une montre dispose d'une connexion Bluetooth connexion à un téléphone, le trafic réseau de la montre est généralement transmis par proxy via le téléphone.

Lorsqu'un téléphone n'est pas disponible, les réseaux Wi-Fi et mobiles sont utilisés, en fonction le matériel de la montre. La plate-forme Wear OS gère les transitions entre les réseaux.

Vous pouvez utiliser des protocoles tels que HTTP, TCP et UDP. Toutefois, Les API android.webkit, y compris la classe CookieManager, ne sont pas disponibles. Vous pouvez utiliser des cookies en lisant et en écrivant des en-têtes sur les requêtes et des réponses.

Utilisez WorkManager pour les requêtes asynchrones, y compris l'interrogation à intervalles réguliers à intervalles réguliers.

Si vous devez vous connecter à des types de réseaux spécifiques, consultez la section Lecture des réseaux l'état.

Accès réseau à haut débit

La plate-forme Wear OS gère la connectivité réseau dans le but de fournir la meilleure expérience utilisateur globale. La plate-forme choisit le réseau actif par défaut équilibre entre deux besoins: longue autonomie de la batterie et bande passante réseau.

Lorsque l'autonomie de la batterie est prioritaire, il est possible que le réseau actif n'ait pas une bande passante suffisante pour les tâches réseau telles que le transport de fichiers volumineux ou le streaming médias.

Cette section explique comment utiliser la classe ConnectivityManager pour : pour vous assurer que votre application dispose de la bande passante réseau dont elle a besoin. Généralités des informations sur le contrôle ultraprécis des ressources réseau, consultez la section Gérer l'utilisation du réseau.

Demander la connectivité Wi-Fi

Pour les cas d'utilisation nécessitant un accès réseau à haut débit, tels que le transport des fichiers volumineux ou des contenus multimédias en streaming, demandez une connectivité avec une bande passante élevée. transport, comme le Wi-Fi. Ce processus est illustré dans l'exemple suivant :

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'acquisition d'un réseau peut ne pas être instantanée, car la connexion Wi-Fi ou la radio cellulaire peut être désactivée pour préserver l'autonomie de la batterie. Si la montre ne parvient pas à se connecter réseau, la méthode onAvailable() de votre instance NetworkCallback n'est pas appelé.

Une fois la méthode onAvailable() appelée, l'appareil tente de rester connecté au réseau Wi-Fi jusqu'à ce que le NetworkCallback soit libéré. Pour préserver l'autonomie de la batterie, libérez le rappel, comme illustré dans l'exemple suivant, lorsque vous n'avez plus besoin Réseau Wi-Fi.

Kotlin

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

Java

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

Lancer l'activité liée aux paramètres Wi-Fi

Lorsque vous demandez un réseau Wi-Fi, le système tente de se connecter à un réseau enregistré si elle est configurée et à portée. Si aucun réseau Wi-Fi enregistré n'est disponible, le La méthode de rappel onAvailable de votre instance NetworkCallback n'est pas appelée.

Si vous utilisez un Handler pour dépasser le délai de la requête réseau, vous pouvez diriger à l'utilisateur d'ajouter un réseau Wi-Fi lorsque le délai d'inactivité se produit. Rediriger l'utilisateur directement vers l'activité pour ajouter un réseau Wi-Fi à l'aide de l'intent suivant:

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

Pour lancer l'activité de paramétrage, votre application doit disposer de l'CHANGE_WIFI_STATE l'autorisation.

Éléments à prendre en compte concernant l'interface utilisateur

Si votre application nécessite une connexion à un nouveau réseau Wi-Fi pour bénéficier d'une bande passante élevée opération, assurez-vous que le motif de la connexion est clairement indiqué à l'utilisateur avant vous lancez les paramètres Wi-Fi. Demandez uniquement à l'utilisateur d'ajouter un nouveau réseau Wi-Fi lorsqu'un réseau à haut débit est requis. Ne pas empêcher l'utilisateur accédant à des fonctionnalités d'application qui ne nécessitent pas de réseau à haut débit.

La figure 1 illustre une application musicale. L'application permet à l'utilisateur de parcourir de la musique sur un un réseau à bande passante plus faible et n'exige que l'utilisateur ajoute un nouveau réseau Wi-Fi si qu'ils veulent télécharger ou écouter de la musique en streaming.

Figure 1. Flux d'applications musicales pour télécharger de la musique.

Éléments à prendre en compte concernant la consommation d'énergie et de données

Pour préserver l'autonomie de la batterie et réduire la consommation des données mobiles, différez des tâches réseau non essentielles, comme la création de rapports d'analyse ou la collecte de journaux, jusqu'à ce que l'appareil Wear OS rétablisse une connexion Bluetooth ou Wi-Fi au lieu d'une connexion LTE ou limitée.

Messagerie via le cloud

Pour envoyer des notifications, utilisez directement Firebase Cloud Messaging (FCM).

FCM et les API d'accès au réseau ne sont pas propres à Wear OS. Reportez-vous aux documentation sur la connexion à un réseau et la messagerie via le cloud.

FCM fonctionne bien avec la fonctionnalité Sommeil. Il s'agit de la méthode recommandée pour envoyer des notifications. à une montre.

Fournissez les messages de FCM en collectant un jeton d'enregistrement pour un appareil. lorsque votre application Wear OS s'exécute. Incluez ensuite le jeton dans l'attribut de destination lorsque votre serveur envoie des messages au point de terminaison REST FCM. FCM envoie des messages à l'appareil identifié par le jeton.

Les messages FCM sont au format JSON (JavaScript Object Notation) et peuvent inclure les caractères suivants : l'une des charges utiles suivantes, ou les deux:

• Charge utile de notification:lorsqu'une charge utile de notification est reçue par un montre, les données sont présentées à un utilisateur directement dans le flux de notifications. Quand ? l'utilisateur appuie sur la notification, votre application se lance.
• Charge utile de données:lorsqu'elle comporte un ensemble de paires clé/valeur personnalisées. La charge utile est envoyée sous forme de données à votre application Wear OS.

Pour obtenir plus d'informations et des exemples de charges utiles, consultez À propos des messages FCM.

Par défaut, les notifications sont pontées depuis une application pour téléphone vers une montre. Si vous avez un application Wear OS autonome et l'application pour téléphone correspondante, notifications en double peut survenir. Par exemple, une seule notification de FCM, reçue à la fois par un un téléphone et une montre, peuvent s'afficher indépendamment sur les deux appareils. Vous pouvez pour éviter cela en utilisant des API de pontage.

Utiliser les services d'arrière-plan

Pour s'assurer que les tâches en arrière-plan sont correctement exécutées, elles doivent tenir compte pour les fonctionnalités Sommeil et Mise en veille des applications.

Lorsqu'un écran s'éteint ou passe en mode Veille pendant suffisamment longtemps, un sous-ensemble peut se produire et les tâches en arrière-plan peuvent être différées pour certaines périodes. Par la suite, lorsque l'appareil restera à l'arrêt pendant une période prolongée, le mode Sommeil standard sera utilisé. Planifier des requêtes avec l'API WorkManager, qui permet à votre application d'enregistrer pour exécuter du code compatible avec le mode Sommeil.

Planifier avec des contraintes

Vous pouvez utiliser des contraintes pour configurer les requêtes de manière à préserver l'autonomie de la batterie vie. Sélectionnez une ou plusieurs des contraintes suivantes à inclure dans votre requêtes:

• Planifiez une requête nécessitant une mise en réseau.

  Indiquez si NetworkType est CONNECTED ou UNMETERED. UNMETERED concerne les transferts de données volumineux, tandis que CONNECTED concerne les transferts de petite taille. transferts.

• Programmez une requête pendant la charge.

• Planifiez une requête lorsque l'appareil est inactif. Ceci est utile pour une tâche en arrière-plan ou une synchronisation de priorité inférieure, en particulier lorsque l'appareil est en charge.

Pour plus d'informations, consultez la section Effet des contraintes sur guide du travail périodique.