Migrer des cartes vers les widgets

Bien que les tuiles et les widgets affichent votre contenu sur une surface de système à distance, leur création nécessite des approches distinctes. Migrer votre tuile existante vers un widget signifie passer d'une génération de mise en page rigide à une interface utilisateur dynamique et déclarative, ce qui vous permet de bénéficier de nouvelles fonctionnalités et d'un modèle de développement simplifié.

Choisir votre stratégie d'implémentation

Si vous migrez une application qui conserve une tuile héritée, vous devez décider comment votre application fournit du contenu au système. Alors que les tout nouveaux widgets doivent utiliser un seul service de widget, les applications avec des tuiles existantes doivent choisir entre conserver les deux services ou les regrouper dans un seul service de widget.

Recommandé : Double service (tuile + widget)

Conserver à la fois une tuile et un widget est la méthode recommandée pour toutes les applications qui disposent d'une tuile existante. Fournir deux services distincts offre la meilleure expérience utilisateur possible sur différents appareils.

Comportement du système pour la configuration à double service :

OS / Fonctionnalité de l'appareil Expérience résultante
Wear OS 3 La tuile est utilisée
Wear OS 4, 5, 6 La tuile est utilisée
Wear OS 7 (aucune prise en charge de la hauteur partielle, par exemple, Pixel Watch) La tuile est utilisée
Wear OS 7 (prise en charge de la hauteur partielle, par exemple, Galaxy Watch) Le widget est utilisé

Autre solution : Service unique (widget uniquement)

Un seul service gère les deux protocoles. Bien que cette approche soit plus rapide à implémenter, elle repose sur un mode de compatibilité pour "adapter" votre widget en tuile sur les appareils exécutant des versions antérieures de Wear OS.

Si vous choisissez cette approche :

  1. Spécifiez les deux filtres d'intent : votre service doit inclure des filtres d'intent pour androidx.wear.tiles.action.BIND_TILE_PROVIDER et androidx.glance.wear.action.BIND_WIDGET_PROVIDER. Cela garantit que votre widget s'affiche sur les surfaces de tuiles dans Wear 4, 5, 6 et 7 (le cas échéant).
  2. Conservez le nom de votre service existant (pour des mises à niveau fluides) : si vous remplacez une tuile active, conserver le même nom de classe de service permet de s'assurer que les utilisateurs qui ont votre tuile dans leur carrousel la verront se mettre à jour automatiquement vers le nouveau widget. Alors que Wear OS 7 utilise l'attribut group dans le XML de configuration du widget pour lier logiquement différents composants, les versions de Wear OS antérieures à la version 7 s'appuient sur le nom du service pour les identifier comme le "même" composant. Si vous préférez utiliser un nouveau nom de service, votre application fonctionnera toujours parfaitement. Toutefois, les utilisateurs d'appareils exécutant Wear OS version 6 ou antérieure devront ajouter manuellement le widget à leur carrousel.

Comportement du système pour la configuration à service unique :

OS / Fonctionnalité de l'appareil Expérience résultante
Wear OS 3 Non disponible
Wear OS 4, 5, 6 Le widget s'affiche sous forme de tuile en plein écran
Wear OS 7 (aucune prise en charge de la hauteur partielle) Le widget est converti en tuile
Wear OS 7 (prise en charge de la hauteur partielle) Le widget est utilisé

*Nécessite le moteur de rendu 1.6 ou version ultérieure.

Conseils de traduction de l'interface utilisateur

Lorsque vous traduisez votre interface utilisateur de ProtoLayout (tuiles) vers Remote Compose (widgets), le modèle mental passe de générateurs de mise en page impératifs à une architecture basée sur l'état et sur Compose, où les mises à jour de l'interface utilisateur sont gérées par recomposition. Gardez à l'esprit les principes suivants :

  • Adoptez une interface utilisateur déclarative : remplacez les générateurs ProtoLayout impératifs (LayoutElementBuilders) par des équivalents Remote Compose déclaratifs, tels que RemoteText, RemoteColumn et RemoteBox.
  • Concentrez-vous sur le contenu principal (mainSlot) : les widgets à hauteur partielle (par exemple, les types de conteneurs SMALL et LARGE) offrent une surface ciblée et consultable en un coup d'œil. Plutôt que de transférer une mise en page de tuile dense en plein écran, simplifiez votre conception pour mettre en avant les informations principales dans la zone de contenu principale.
  • Repensez les actions alignées sur les bords : dans l'architecture des tuiles, les composants qui s'adaptent à l'écran, comme EdgeButton, étaient ancrés à un bottomSlot dédié. Étant donné que les widgets à hauteur partielle s'intègrent directement dans une surface à défilement vertical, ce paradigme bottomSlot fixe n'existe plus. Comme les boutons alignés sur les bords servaient souvent d'actions principales très visibles, la migration nécessite une refonte délibérée de l'interface utilisateur plutôt qu'un échange direct de composants. Évaluez d'autres stratégies d'expérience utilisateur pour vos actions principales :
    • Actions intégrées : intégrez un RemoteButton intégré directement dans votre mise en page mainSlot.
    • Appuis sur le conteneur : consolidez l'interaction en rendant l'ensemble du conteneur de widget cliquable à l'aide d'un PendingIntentAction.
    • Pivot de contenu : réévaluez l'objectif du widget. Sans emplacement d'action dédié, envisagez de présenter des données plus riches et consultables en un coup d'œil, et de vous appuyer sur un seul appui pour ouvrir l'application complète plutôt que d'isoler des actions spécifiques sur la surface du widget.
  • Migrez la gestion des événements (actions par rapport aux lambdas) : les tuiles s'appuient sur des interactions (comme LoadAction) qui déclenchent des rappels de service complets pour actualiser l'interface utilisateur. Les widgets Wear sont gérés côté client. Les lambdas Compose standards ne peuvent pas être exécutés à distance. À la place, fournissez des actions déclaratives sérialisables (comme ValueChange ou PendingIntentAction). Combinez-les avec un état déclaratif (par exemple, rememberMutableRemoteInt) pour prendre en charge les mises à jour instantanées de l'interface utilisateur sans aller-retour dans l'application.
  • Adaptez les dimensions et les types : lorsque vous migrez des dimensions de mise en page, préférez la résolution de mise en page différée à l'aide de RemoteDp (par exemple, 10.rdp) plutôt que le Dp standard. Cela garantit que le moteur de rendu du système calcule correctement les valeurs de pixels au moment de l'affichage. De même, utilisez les fonctions d'extension Remote Compose (.rc pour Color, .rs pour String, .rdp pour Dp) pour convertir de manière transparente les types Kotlin standards et Remote Compose.
  • Consultez l'exemple de code : pour voir des exemples complets de création de mises en page, d'application de typographie sémantique et de gestion de l'état dans Remote Compose, explorez l'exemple de code officiel disponible dans le dépôt d'exemples Wear OS.