Options de pont pour les notifications

Par défaut, les notifications sont pontées, ou 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 et pontée par l'application pour téléphone et l'autre générée 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, désactivez de manière programmatique le pont dans votre appli connectée.

Utiliser des balises de pont

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

Pour définir une balise de pont 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("tagOne")
    )
    .build()

Désactiver le pontage

Vous pouvez désactiver le pontage pour toutes les notifications ou seulement pour certaines d'entre elles. Nous vous recommandons de désactiver de manière sélective le pontage.

Désactiver le pontage pour certaines notifications

Vous pouvez désactiver dynamiquement le pontage 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 tagOne, tagTwo ou tagThree, utilisez l'objet BridgingConfig comme indiqué dans l'exemple suivant : 

BridgingManager.fromContext(context).setConfig(
    BridgingConfig.Builder(context, false)
        .addExcludedTags(listOf("tagOne", "tagTwo", "tagThree"))
        .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.

Définir un ID de refus pour synchroniser les notifications similaires

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 l'appareil mobile et sur la montre, elles doivent toutes les deux être ignorée lorsque l'utilisateur désactive l'une d'entre elles.

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

La classe NotificationCompat.WearableExtender comporte des méthodes qui vous permettent 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 montre et sur le téléphone. Pour récupérer un ID de refus, utilisez getDismissalId().

Dans l'exemple suivant, un ID unique global est spécifié pour une nouvelle notification de sorte que les refus soient synchronisés : 

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 types de notifications suivants ne sont pas pontés :

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 contribuent à s'assurer 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, l'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 : 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 la latence liée à la mise à jour de l'accessoire connecté et réduit l'impact de votre application sur l'autonomie de la batterie.

Considérations relatives à la conception

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