Avec Wear OS by Google, une montre peut communiquer directement avec un réseau, sans accéder à un téléphone Android ou iOS. N'utilisez pas l'API Data Layer pour connecter une application Wear OS à un réseau. Suivez plutôt les consignes et les étapes de ce guide.
Accès au réseau
Les applications Wear OS peuvent effectuer des requêtes réseau. Lorsqu'une montre dispose d'une connexion Bluetooth avec 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 du 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 pour les requêtes et les réponses.
Nous vous recommandons également d'utiliser l'API WorkManager pour les requêtes asynchrones, y compris l'interrogation à intervalles réguliers.
Si vous devez vous connecter à des types de réseaux spécifiques, consultez Lire l'état du réseau.
Accès réseau à haut débit
La plate-forme Wear OS gère la connectivité réseau afin d'offrir la meilleure expérience utilisateur globale possible. La plate-forme choisit le réseau actif par défaut en équilibrant deux besoins :
- Autonomie de la batterie
- Bande passante réseau
Lorsque l'autonomie de la batterie est prioritaire, le réseau actif peut disposer d'une bande passante insuffisante pour effectuer certaines tâches, comme le transport de fichiers volumineux ou le streaming de contenus multimédias.
Cette section fournit des conseils sur l'utilisation de la classe ConnectivityManager pour que votre application dispose de la bande passante réseau dont elle a besoin. Pour obtenir des informations générales sur le contrôle précis des ressources réseau, consultez 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 de fichiers volumineux ou la lecture en streaming de contenus multimédias, demandez la connectivité via un transport à haut débit, tel que 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 le Wi-Fi ou la cellule GSM peuvent être éteints pour économiser la batterie. Si la montre ne parvient pas à se connecter à un réseau, la méthode onAvailable() de votre instance NetworkCallback n'est pas appelée.
Une fois la méthode onAvailable() appelée, l'appareil tente de rester connecté au réseau Wi-Fi jusqu'à ce que l'instance NetworkCallback soit libérée. Pour préserver l'autonomie de la batterie, libérez le rappel comme indiqué dans l'exemple suivant lorsqu'un réseau Wi-Fi n'est plus nécessaire.
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 celui-ci est configuré et à portée. Si aucun réseau Wi-Fi enregistré n'est disponible, 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 d'inactivité de la requête réseau, vous pouvez demander à l'utilisateur d'ajouter un réseau Wi-Fi lorsque le délai est expiré.
Renvoyez directement l'utilisateur à l'activité pour qu'il ajoute un réseau Wi-Fi avec 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ètres, votre application doit disposer de l'autorisation suivante : android.permission.CHANGE_WIFI_STATE.
Éléments à prendre en compte concernant l'interface utilisateur
Si votre application nécessite une connexion à un nouveau réseau Wi-Fi pour une opération à haut débit, assurez-vous que le motif de connexion est clairement indiqué à l'utilisateur avant de lancer les paramètres Wi-Fi. Demandez-lui d'ajouter un nouveau réseau Wi-Fi uniquement lorsqu'un réseau à haut débit est requis. N'empêchez pas l'utilisateur d'accéder à des fonctionnalités d'une application qui ne nécessitent pas de réseau à haut débit.
La figure 1 montre une application musicale. Cette application doit permettre à l'utilisateur de parcourir de la musique sur un réseau ayant une bande passante limitée et ne demande à cet utilisateur d'ajouter un réseau Wi-Fi que s'il souhaite 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 les tâches réseau non essentielles, telles que les rapports d'analyse ou la collecte de journaux, jusqu'à ce que l'appareil Wear OS ait rétabli une connexion Bluetooth ou Wi-Fi.
Messagerie via le cloud
Pour envoyer des notifications, les applications peuvent utiliser directement Firebase Cloud Messaging (FCM).
FCM et les API d'accès au réseau ne sont pas propres à Wear OS. Consultez la documentation existante sur la connexion à un réseau et la messagerie via le cloud.
FCM fonctionne bien avec le mode Sommeil. Il s'agit de la méthode recommandée pour envoyer des notifications à votre montre.
Fournissez les messages issus de FCM en collectant un jeton d'enregistrement pour un appareil lorsque votre application Wear OS s'exécute. Incluez ensuite le jeton dans la 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 utilisent le format JSON (JavaScript Object Notation) et peuvent inclure l'une des charges utiles suivantes, ou les deux :
- Charge utile de notification : lorsqu'une montre reçoit une charge utile de notification, les données sont directement présentées à un utilisateur dans le flux de notifications. Lorsque l'utilisateur appuie sur la notification, votre application se lance.
- Charge utile de données : la charge utile 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 de téléphone vers une montre. Si vous avez une application Wear OS autonome et l'application pour téléphone correspondante, des notifications en double peuvent être émises. Par exemple, une même notification issue de FCM, reçue à la fois par un téléphone et par une montre, peut être affichée indépendamment par les deux appareils. Pour éviter cela, utilisez des API de pontage.
Utiliser les services d'arrière-plan
Pour contribuer à s'assurer que les tâches en arrière-plan sont correctement exécutées, elles doivent prendre en compte les fonctionnalités Sommeil et Mise en veille des applications.
Lorsqu'un écran s'éteint ou passe en mode Veille pendant une période suffisamment longue, un sous-ensemble de la fonctionnalité Sommeil peut s'exécuter 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é. Planifiez les requêtes à l'aide de l'API WorkManager, qui permet à votre application d'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. Sélectionnez une ou plusieurs des contraintes suivantes à inclure dans vos requêtes :
- Planifiez une requête nécessitant une mise en réseau. Indiquez si
NetworkTypeestCONNECTEDouUNMETERED. Le typeUNMETEREDconcerne les transferts de données volumineux, tandis queCONNECTEDconcerne les transferts de petite taille. - Programmez une requête pendant la charge.
- Planifiez une requête lorsque l'appareil est inactif. Cette fonctionnalité est utile pour les tâches en arrière-plan ou les synchronisations de priorité inférieure, en particulier lorsque l'appareil est en charge.
Notez que certains réseaux à faible bande passante, tels que la technologie Bluetooth LE, sont considérés comme facturés à l'usage.
Pour plus d'informations, consultez le guide Effet des contraintes sur les tâches périodiques du WorkManager.