Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Les API Data Layer de Wear OS se composent de plusieurs types de clients, qui sont utiles pour différents types de données et dans différentes conditions de connectivité.
Cette page présente chaque type de client et inclut un tableau comparant les fonctionnalités des différents clients. Grâce à ces informations, vous pouvez sélectionner l'ensemble de types de clients qui convient le mieux à votre application.
Chaque DataItem est une unité d'informations diffusée et synchronisée sur tous les appareils à proximité appartenant à un utilisateur. Un DataItem est stocké de manière persistante, et votre appareil peut lire son contenu jusqu'à ce que l'élément de données soit supprimé.
Un Asset est destiné aux charges utiles de données plus volumineuses, telles que des images ou des fichiers multimédias.
Client de messagerie
Un objet MessageClient peut envoyer des messages et convient pour les appels de procédure à distance (RPC), tels que l'utilisation d'un appareil Wear OS pour contrôler la version de votre application installée sur un appareil portable.
Les messages conviennent parfaitement pour les requêtes unidirectionnelles à l'aide de sendMessage() ou pour un modèle de communication requête et réponse à l'aide de sendRequest(). Contrairement aux clients de données, les clients de messages ont besoin que les nœuds soient connectés au réseau pour pouvoir envoyer des messages.
La méthode sendMessage() est une tentative optimale de diffusion au nœud distant. Elle ne contient aucun mécanisme de nouvelle tentative intégré. Si l'appareil cible se déconnecte avant le début du transfert réseau, la méthode renvoie TARGET_NODE_NOT_CONNECTED.
Client de canaux
Un objet ChannelClient fournit une communication orientée flux entre les appareils. Un canal est un canal de communication bidirectionnel entre deux nœuds, ce qui est utile pour les cas d'utilisation suivants :
Transférer des fichiers de données entre plusieurs appareils connectés lorsque la connexion Internet n'est pas disponible. ChannelClient permet d'économiser de l'espace disque sur DataClient, ce qui crée une copie des composants sur l'appareil local avant la synchronisation avec les appareils connectés.
Envoyer de manière fiable un fichier trop volumineux pour l'envoi à l'aide d'un MessageClient.
Transférer des données diffusées, telles que des données vocales depuis le micro.
Une fois un canal ouvert, vous pouvez envoyer et recevoir des données dans un flux d'octets continu, plutôt que dans les unités DataItem discrètes requises par les clients de données.
Vous êtes responsable de la gestion du flux de données et de la cohérence des données.
Les clients canaux n'offrent pas le même niveau de synchronisation automatique des données que les clients données.
Comparaison des clients
Le tableau suivant compare les fonctionnalités des différents clients :
Bluetooth de préférence. Les données sont sauvegardées dans le cloud. Si le Bluetooth est disponible, cette sauvegarde est effectuée de manière asynchrone.
Oui, pour la lecture et l'écriture
Client de messages
Sans persistance ni nouvelle tentative
Non
Bluetooth de préférence, mais le Wi-Fi peut être utilisé s'il s'agit du seul type de connexion disponible
Non
Client de canaux
Sans persistance (orienté connexion)
Oui
Bluetooth de préférence, mais le Wi-Fi peut être utilisé s'il s'agit du seul type de connexion disponible
Non
Le contenu et les exemples de code de cette page sont soumis aux licences décrites dans la Licence de contenu. Java et OpenJDK sont des marques ou des marques déposées d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/09/05 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Il n'y a pas l'information dont j'ai besoin","missingTheInformationINeed","thumb-down"],["Trop compliqué/Trop d'étapes","tooComplicatedTooManySteps","thumb-down"],["Obsolète","outOfDate","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Mauvais exemple/Erreur de code","samplesCodeIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 2025/09/05 (UTC)."],[],[],null,["The Wear OS data layer APIs consist of several different types of clients, which\nare useful for different types of data and during different connectivity\nconditions.\n\nThis page introduces each client type, and it includes a table that compares the\ncapabilities of the different clients. Using this information, you can select\nthe set of client types that works best for your app.\n\nData client\n\nA [`DataClient`](https://developers.google.com/android/reference/com/google/android/gms/wearable/DataClient) object lets you read or write to a [`DataItem`](https://developers.google.com/android/reference/com/google/android/gms/wearable/DataItem) or\n[`Asset`](https://developers.google.com/android/reference/com/google/android/gms/wearable/Asset):\n\n- Each `DataItem` is a unit of information that's broadcast and synchronized\n across all nearby devices that a user owns. A `DataItem` is stored persistently,\n and your device can read its contents until the data item is deleted.\n\n- An `Asset` is meant for larger data payloads, such as images or media files.\n\nMessage client\n\nA [`MessageClient`](https://developers.google.com/android/reference/com/google/android/gms/wearable/MessageClient) object can send messages and is good for remote procedure\ncalls (RPC), such as using a Wear OS device to control the version of your app\nthat's installed on a handheld device.\n\nMessages are great for one-way requests using `sendMessage()`, or for a\nrequest-and-response communication model using `sendRequest()`. Unlike with data\nclients, message clients need the nodes to be connected to the network in order\nto send messages.\n\nThe `sendMessage()` method is a best effort to deliver to the remote node, and\nit doesn't contain any built-in retry mechanism. If the target device\ndisconnects before the network transfer starts, the method returns\n`TARGET_NODE_NOT_CONNECTED`.\n| **Note:** To help preserve power, consider sending messages only to nearby devices.\n\nChannel client\n\nA [`ChannelClient`](https://developers.google.com/android/reference/com/google/android/gms/wearable/ChannelClient) object provides stream-oriented communication between\ndevices. A *channel* is a bidirectional communication pipe between two nodes,\nwhich is useful for use cases such as the following:\n\n- Transfer data files between two or more connected devices when the internet isn't available. `ChannelClient` saves disk space over `DataClient`, which creates a copy of the assets on the local device before synchronizing with connected devices.\n- Reliably send a file that's too large to send using a `MessageClient`.\n- Transfer streamed data, such as voice data from the microphone.\n\nAfter you open a channel, you can send and receive data in a continuous byte\nstream, rather than the discrete `DataItem` units that data clients require.\n\nYou're responsible for managing the data flow and keeping data consistent.\nChannel clients don't offer the same level of automatic data synchronization\nthat data clients do.\n\nClient comparison\n\nThe following table compares the capabilities of the different clients:\n\n| Client type | Data persistence | Supports data larger than 100 KB? | Network to use | Works offline? |\n|--------------------|--------------------------------------|--------------------------------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------|------------------------------|\n| **Data client** | Data is persisted indefinitely | Yes (use [`Asset`](https://developers.google.com/android/reference/com/google/android/gms/wearable/Asset) objects) | Bluetooth preferred. Data is backed up to the cloud; if Bluetooth is available, this backup is done asynchronously | Yes, for both read and write |\n| **Message client** | No persistence and no retry | No | Bluetooth preferred, but can use Wi-Fi if it's the only type of connection available | No |\n| **Channel client** | No persistence (connection-oriented) | Yes | Bluetooth preferred, but can use Wi-Fi if it's the only type of connection available | No |"]]
