Opcje mostków dla powiadomień

Domyślnie powiadomienia są połączone (udostępniane) z aplikacji na telefonie do dowolnych sparowanych zegarków. Jeśli Jeśli stworzysz aplikację na zegarek, a aplikacja jest również na sparowanym telefonie, użytkownicy mogą otrzymać jej duplikat powiadomienia – jedno wygenerowane i połączone przez aplikację Telefon, a drugie wygenerowane w aplikacji na zegarek. Wear OS zawiera funkcje pozwalające kontrolować, jak i kiedy powiadomienia są połączone.

Unikaj podwójnych powiadomień

Gdy tworzysz powiadomienia ze źródła zewnętrznego, np. Komunikacji w chmurze Firebase, aplikacja mobilna i aplikacja do noszenia mogą wyświetlać na zegarku własne powiadomienia. Aby unikać automatycznie wyłączyć połączenia w aplikacji do noszenia.

Używanie tagów mostków

Jeśli chcesz połączyć z zegarkiem niektóre powiadomienia utworzone w aplikacji mobilnej po zainstalowaniu aplikacji do noszenia, ustaw tagi mostka.

Ustaw tag mostu w powiadomieniu za pomocą setBridgeTag(String) zgodnie z tym przykładowym kodem: 

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

Wyłącz połączenie

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

Wyłącz połączenie w przypadku niektórych powiadomień

Możesz dynamicznie wyłączyć połączenie i opcjonalnie zezwolić na niektóre powiadomienia na podstawie tagu. Na przykład, aby wyłączyć połączenie dla wszystkich powiadomień oprócz tych oznaczonych jako tagOne, tagTwo lub tagThree, użyj BridgingConfig jak w tym przykładzie: 

BridgingManager.fromContext(context).setConfig(
    BridgingConfig.Builder(context, false)
        .addExcludedTags(listOf("tagOne", "tagTwo", "tagThree"))
        .build()
)

Wyłącz połączenie dla wszystkich powiadomień (niezalecane)

Uwaga: nie zalecamy wyłączania połączeń w przypadku wszystkich powiadomień, ponieważ konfiguracja połączeń ustawiona w pliku manifestu zaczyna obowiązywać od razu po zainstalowaniu aplikacji na zegarek. Może to spowodować utratę powiadomień, jeśli użytkownik będzie musiał otworzyć i skonfigurować aplikację na zegarek zanim zaczniesz otrzymywać powiadomienia.

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

<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>

Uwaga: określenie konfiguracji połączenia w czasie działania zastępuje konfigurację związaną z łączeniem. w pliku manifestu Androida.

Ustaw identyfikator odrzucenia, aby synchronizować podobne powiadomienia

Jeśli wyłączysz połączenie za pomocą funkcji trybu połączenia, odrzucenia powiadomień nie będą synchronizowane między urządzeniami użytkownika.

Jeśli jednak podobne powiadomienia są tworzone zarówno na urządzeniu mobilnym, jak i na zegarku, chcesz, aby oba te powiadomienia były tworzone powiadomienia, które mają być zamykane, gdy użytkownik odrzuci którąś z nich.

W NotificationCompat.WearableExtender, możesz ustawić globalny, unikalny identyfikator, aby po odrzuceniu powiadomienia inne powiadomienia z tym samym identyfikatorem na sparowanych zegarkach.

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

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

Aby zsynchronizować odrzucenie, użyj setDismissalId() . Dla każdego powiadomienia przekaż globalnie unikalny identyfikator w formie ciągu znaków podczas wywoływania Metoda setDismissalId().

Po zamknięciu powiadomienia wszystkie pozostałe powiadomienia z tym samym identyfikatorem odrzucenia zostaną na zegarku i telefonie. Aby pobrać identyfikator odrzucenia, użyj getDismissalId()

W poniższym przykładzie unikalny identyfikator globalny to: zostały określone dla nowego powiadomienia, więc odrzucenia są synchronizowane: 

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

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

Gdy powiadomienia nie są połączone

Te typy powiadomień nie są połączone:

Sprawdzone metody dotyczące powiadomień przejściowych

Wypchnięcie lub usunięcie połączonych powiadomień z urządzenia do noszenia może trochę potrwać urządzenia. Podczas projektowania powiadomień pamiętaj, aby unikać nieoczekiwanych i działalności w wyniku tego opóźnienia. Skorzystaj z tych wskazówek sprawdź, czy powiadomienia mostkowe działają z powiadomieniami asynchronicznymi:

  • Jeśli anulujesz powiadomienie na telefonie, może minąć trochę czasu, zanim zostanie ono anulowane odpowiednie powiadomienie na zegarku. W tym czasie użytkownik może wysłać jedną z oczekujących intencji w tym powiadomieniu. Do tego celu powodu, nadal otrzymuj w swojej aplikacji oczekujące intencje z powiadomień, które zostały anulowane: podczas anulowania powiadomień zachowaj oczekujących odbiorców intencji tych powiadomień prawidłowe.
  • Nie anuluj i nie uruchamiaj ponownie całego stosu powiadomień naraz. Zmodyfikuj lub usuń tylko te powiadomienia, które zostały rzeczywiście zmodyfikowane. Pozwala to uniknąć opóźnień przy aktualizacji urządzenia do noszenia i zmniejsza wpływ aplikacji na żywotność baterii.

Uwagi dotyczące projektu

Powiadomienia na Wear OS mają własne wytyczne dotyczące ich wyglądu. Aby dowiedzieć się więcej, zapoznaj się z wytycznymi dotyczącymi projektowania w Wear OS.