Options de pontage des notifications

Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

Par défaut, les notifications sont pontées (partagées) entre une application sur un téléphone et toutes les montres associées. Si vous créez une application pour les montres connectées et que celle-ci existe également sur un téléphone associé, les utilisateurs peuvent recevoir des notifications en double, l'une générée par l'application de téléphone (pontée) et l'autre par l'application de la montre. Wear OS inclut des fonctionnalités permettant de contrôler quand et comment ponter les notifications.

Éviter les notifications en double

Lorsque vous créez des notifications à partir d'une source externe, telle que Firebase Cloud Messaging, votre application mobile et votre application connectée peuvent afficher chacune leurs propres notifications sur la montre. Pour éviter ce type de duplication, le pontage des notifications sur votre application connectée doit être désactivé par programmation.

1. Dans l'application mobile, utiliser des balises de pontage, le cas échéant

Si vous souhaitez associer certaines notifications créés sur votre application mobile à votre montre lorsque votre application connectée est installée, définissez des balises de pontage.

Définir une balise de pontage

Pour définir une balise de pontage au niveau d'une notification, utilisez la méthode setBridgeTag(String), comme indiqué dans l'exemple de code suivant :

val notification = NotificationCompat.Builder(context, channelId)
    // ... set other fields ...
    .extend(
        NotificationCompat.WearableExtender()
            .setBridgeTag("foo")
    )
    .build()

2. Désactiver le pontage dans l'application connectée

Désactiver le pontage pour certaines notifications

Vous pouvez désactiver le pontage de manière dynamique et éventuellement autoriser certaines notifications en fonction de leur balise. Par exemple, pour désactiver le pontage de toutes les notifications, à l'exception de celles marquées foo, bar ou baz, utilisez l'objet BridgingConfig comme indiqué dans cette section.

BridgingManager.fromContext(context).setConfig(
    BridgingConfig.Builder(context, false)
        .addExcludedTags(listOf("foo", "bar", "baz"))
        .build()
)

Désactiver le pontage pour toutes les notifications (non recommandé)

Remarque : Il est déconseillé de désactiver le pontage pour toutes les notifications, car la configuration de pontage définie dans le fichier manifeste prend effet dès qu'une application de montre est installée. Cela peut entraîner la perte des notifications si l'utilisateur doit ouvrir et configurer l'application de la montre avant de recevoir des notifications.

Pour éviter le pontage de toutes les notifications provenant d'une application de téléphone, utilisez l'entrée <meta-data> dans le fichier manifeste de l'application de la montre, comme illustré dans l'exemple suivant :

<application>
...
  <!-- Beware this can have unintended consqequences before the user is signed-in -->
  <meta-data
    android:name="com.google.android.wearable.notificationBridgeMode"
    android:value="NO_BRIDGING" />
...
</application>

Remarque : La spécification d'une configuration de pontage lors de l'exécution remplace un paramètre lié au pontage dans le fichier manifeste Android.

3. Définir un ID de refus pour synchroniser les notifications similaires sur Wear OS et les appareils mobiles

Lorsque vous empêchez le pontage avec la fonctionnalité correspondante, les notifications ignorées ne sont pas synchronisées sur les appareils de l'utilisateur.

Toutefois, si des notifications similaires sont créées à la fois sur le mobile et sur la montre, elles doivent toutes les deux être ignorées si l'utilisateur désactive l'une d'entre elles.

Dans NotificationCompat.WearableExtender, vous pouvez définir un ID unique global afin que, lorsqu'une notification est ignorée, les autres notifications ayant le même ID sur une ou plusieurs montres associées le soient également.

La classe NotificationCompat.WearableExtender comporte des méthodes permettant d'utiliser des ID de refus, comme illustré dans l'exemple suivant :

fun setDismissalId(dismissalId: String): WearableExtender
fun getDismissalId(): String

Pour synchroniser des notifications ignorées, utilisez la méthode setDismissalId(). Pour chaque notification, transmettez un ID global unique, sous la forme d'une chaîne, lorsque vous appelez la méthode setDismissalId().

Lorsque la notification est ignorée, toutes les autres notifications ayant le même ID de refus sont ignorées sur la ou les montres et sur le téléphone. Pour récupérer un ID de refus, utilisez getDismissalId().

Dans l'exemple suivant, la synchronisation des notifications ignorées est activée, car un ID unique est spécifié pour une nouvelle notification :

val notification = NotificationCompat.Builder(context, channelId)
    // ... set other fields ...
    .extend(
        NotificationCompat.WearableExtender()
            .setDismissalId("abc123")
    )
    .build()

Remarque : Les ID de refus fonctionnent si une montre est associée à un téléphone Android, mais pas si une montre est associée à un iPhone.

Cas où les notifications ne sont pas pontées

Les notifications ne sont pas pontées dans les cas suivants :

Bonnes pratiques concernant les notifications pontées

Le transfert ou la suppression des notifications pontées sur un accessoire connecté peut prendre du temps. Lorsque vous concevez vos notifications, veillez à éviter tout comportement inattendu causé par cette latence. Les consignes suivantes garantissent que les notifications pontées fonctionnent avec les notifications asynchrones :

  • Si vous annulez une notification sur le téléphone, l'annulation de la notification correspondante sur la montre peut prendre un certain temps. Pendant ce temps, un utilisateur pourrait envoyer l'un des intents en attente au niveau de cette notification. C'est pourquoi votre application doit recevoir les intents en attente à partir des notifications qu'elle a annulées. Ainsi, lorsque vous annulez des notifications, assurez-vous que les destinataires d'intent en attente de ces notifications sont valides.
  • N'annulez pas et ne redéclenchez pas l'ensemble de vos notifications en même temps. Ne modifiez ou ne supprimez que les notifications qui ont été réellement modifiées. Cette approche évite toute latence liée à la mise à jour de l'accessoire connecté et garantit un impact minimum de votre application sur l'autonomie de la batterie.

Considérations de conception

Les notifications Wear OS sont soumises à des consignes de conception spécifiques. Pour en savoir plus, consultez les consignes de conception Wear OS.