Opcje mostków dla powiadomień

Domyślnie powiadomienia są udostępniane z aplikacji na telefonie na wszystkie sparowane zegarki. Jeśli tworzysz aplikację na zegarek, która jest też dostępna na sparowanym telefonie, użytkownicy mogą otrzymywać zduplikowane powiadomienia – jedno wygenerowane i przesłane przez aplikację na telefon, a drugie wygenerowane przez aplikację na zegarek. Wear OS zawiera funkcje, które pozwalają kontrolować, jak i kiedy powiadomienia są przesyłane.

Unikanie duplikowania powiadomień

Gdy tworzysz powiadomienia ze źródła zewnętrznego, np. z Komunikacji w chmurze Firebase, aplikacja mobilna i aplikacja na urządzenie do noszenia mogą wyświetlać na zegarku własne powiadomienia. Aby uniknąć tego rodzaju duplikowania, programowo wyłącz udostępnianie w aplikacji na urządzenie do noszenia.

Używanie tagów pomostowych

Jeśli chcesz przekazywać niektóre powiadomienia utworzone w aplikacji mobilnej na zegarek po zainstalowaniu aplikacji na urządzeniu do noszenia, ustaw tagi przekazywania.

Ustaw tag pomostowy w powiadomieniu za pomocą metody setBridgeTag(String), jak pokazano w tym przykładowym kodzie:

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

Wyłącz udostępnianie powiadomień

Możesz wyłączyć łączenie w przypadku niektórych lub wszystkich powiadomień. Zalecamy selektywne wyłączanie łączenia.

Wyłączanie przekazywania niektórych powiadomień

Możesz dynamicznie wyłączać pomijanie i opcjonalnie zezwalać na niektóre powiadomienia na podstawie ich tagu. Aby na przykład wyłączyć łączenie wszystkich powiadomień z wyjątkiem tych, które są oznaczone tagami tagOne, tagTwo lub tagThree, użyj obiektu BridgingConfig w sposób pokazany w tym przykładzie: 

// In this example, bridging is only enabled for tagOne, tagTwo and tagThree.
BridgingManager.fromContext(context).setConfig(
    BridgingConfig.Builder(context, isBridgingEnabled = false)
        .addExcludedTags(listOf("tagOne", "tagTwo", "tagThree"))
        .build()
)
BridgingConfiguration.kt

Wyłączanie łączenia w przypadku wszystkich powiadomień (niezalecane)

Uwaga: nie zalecamy wyłączania przekazywania wszystkich powiadomień, ponieważ konfiguracja przekazywania ustawiona w pliku manifestu zaczyna obowiązywać natychmiast po zainstalowaniu aplikacji na zegarku. Może to spowodować utratę powiadomień, jeśli użytkownik musi otworzyć i skonfigurować aplikację na zegarku, zanim otrzyma powiadomienia.

Aby zapobiec przekazywaniu wszystkich powiadomień z aplikacji na telefon, użyj wpisu <meta-data> w pliku manifestu aplikacji na zegarek, jak pokazano w tym przykładzie: 

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

Uwaga: określenie konfiguracji pomostowej w czasie działania zastępuje ustawienie związane z pomostem w pliku manifestu Androida.

Ustawianie identyfikatora zamykania w celu synchronizowania podobnych powiadomień

Gdy zapobiegasz łączeniu za pomocą funkcji trybu łączenia, zamknięte powiadomienia nie są synchronizowane na urządzeniach użytkownika.

Jeśli jednak podobne powiadomienia są tworzone zarówno na urządzeniu mobilnym, jak i na zegarku, chcesz, aby oba powiadomienia zostały odrzucone, gdy użytkownik odrzuci jedno z nich.

W sekcji NotificationCompat.WearableExtender możesz ustawić globalny unikalny identyfikator, aby po zamknięciu powiadomienia inne powiadomienia z tym samym identyfikatorem na sparowanych zegarkach również zostały zamknięte.

Klasa NotificationCompat.WearableExtender ma metody, które umożliwiają używanie identyfikatorów odrzucenia, jak pokazano w tym przykładzie:

Gdy powiadomienie zostanie odrzucone, wszystkie inne powiadomienia z tym samym identyfikatorem odrzucenia zostaną odrzucone na zegarku i telefonie. Aby pobrać identyfikator odrzucenia, użyj getDismissalId()

W poniższym przykładzie dla nowego powiadomienia określono globalnie unikalny identyfikator, dzięki czemu zamknięcia są synchronizowane: 

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

Uwaga: identyfikatory odrzucenia działają, jeśli zegarek jest sparowany z telefonem z Androidem, ale nie działają, jeśli zegarek jest sparowany z iPhonem.

Gdy powiadomienia nie są przekazywane

Te typy powiadomień nie są przekazywane:

Sprawdzone metody dotyczące powiadomień pomostowych

Wypychanie lub usuwanie powiadomień z urządzenia do noszenia może trochę potrwać. Podczas projektowania powiadomień unikaj nieoczekiwanego działania spowodowanego tym opóźnieniem. Te wskazówki pomogą Ci zadbać o to, aby powiadomienia pomostowe działały z powiadomieniami asynchronicznymi:

  • Jeśli anulujesz powiadomienie na telefonie, anulowanie odpowiedniego powiadomienia na zegarku może trochę potrwać. W tym czasie użytkownik może wysłać jeden z oczekujących intencji w tym powiadomieniu. Z tego powodu aplikacja nadal będzie otrzymywać oczekujące intencje z anulowanych powiadomień: podczas anulowania powiadomień zachowaj ważność odbiorników oczekujących intencji tych powiadomień.
  • Nie anuluj i nie wywołuj ponownie wszystkich powiadomień naraz. Modyfikuj lub usuwaj tylko te powiadomienia, które zostały zmienione. Pozwala to uniknąć opóźnień w aktualizowaniu urządzenia do noszenia i zmniejsza wpływ aplikacji na czas pracy baterii.

Uwagi dotyczące projektu

Powiadomienia na Wear OS mają własne wytyczne dotyczące projektowania. Więcej informacji znajdziesz w wytycznych dotyczących projektowania na Wear OS.