Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Wichtig
Die Microsoft Graph-Benachrichtigungs-API ist veraltet und gibt seit Januar 2022 keine Daten mehr zurück. Eine alternative Benachrichtigungsoberfläche finden Sie unter Microsoft Azure-Benachrichtigungshubs. Weitere Informationen finden Sie im Blogbeitrag Außerbetriebnahme der Microsoft Graph Benachrichtigungs-API (Beta).
Nachdem Sie Ihre App im Microsoft Entra Admin Center registriert und ihre geräteübergreifenden Erfahrungen im Partner Dev Center integriert haben, besteht der nächste Schritt darin, Ihre Client-App in das clientseitige SDK für Android-Apps zu integrieren.
Mit dem clientseitigen SDK kann Ihre App die nötigen Registrierungsschritte ausführen, um Benachrichtigungen von Ihrem App-Server zu empfangen, die an den Benutzer gerichtet sind, der aktuell angemeldet ist. Das SDK verwaltet die Benachrichtigungen clientseitig, einschließlich des Empfangs neuer Benachrichtigungen und der Verwaltung des Status von Benachrichtigungen, um Szenarien wie geräteübergreifendes Schließen und den Abruf des vollständigen Benachrichtigungsverlaufes zu realisieren.
Fluss neuer eingehender Benachrichtigungen
Für den Empfang neuer eingehender Benachrichtigungen wird der Datenfluss im folgenden Diagramm gezeigt.
Der Prozess umfasst einige Komponenten:
- App-Server – das Back-End Ihrer Anwendung
- App-Client – das Frontend Ihrer Anwendung (eine UWP-App, eine Android-App oder eine App für iOS)
- Microsoft Graph-Benachrichtigungen – Diejenige Dienstkomponente, die es ermöglicht, Benutzerbenachrichtigungen zu veröffentlichen, zu speichern und zwischen verschiedenen Instanzen der App auf mehreren Geräten und Plattformen zu synchronisieren.
- FCM – Firebase Cloud Messaging, der Pushbenachrichtigungsdienst von Android, der im Rahmen der Google Play-Dienste bereitgestellt wird. Microsoft Graph-Benachrichtigungen verwenden diesen Dienst, um Android-App-Clients Datenänderungen bei Benutzerbenachrichtigungen zu signalisieren.
Das Diagramm zeigt die folgenden Schritte:
- Anwendungslogik. Dieser Schritt erfasst, was den Versand der Benachrichtigung an den Benutzer auslösen soll. Dies ist App-spezifische Logik, die auch eine Ereignis- oder Datenaktualisierung zu etwas anderem in Microsoft Graph sein kann, beispielsweise ein neuer Kalendereintrag oder die Zuweisung einer Aufgabe, oder etwas anderes, worüber Ihr App-Dienst den Benutzer informieren möchte.
- Der App-Server sendet mittels der Microsoft Graph Benachrichtigungs-API eine Benachrichtigung an den entsprechenden Benutzer. Weitere Informationen hierzu finden Sie unter Serverseitige Integration.
- Bei Empfang der Webanforderung, welche die neue Benachrichtigung enthält, speichert Microsoft Graph Benachrichtigungen den Inhalt der Benachrichtigung für diese App und diesen Benutzer sicher in der Cloud.
- Für jede Instanz der Client-App, die für den Empfang von Benachrichtigungen für diesen Benutzer angemeldet ist, sendet Microsoft Graph Benachrichtigungen mittels des jeweils systemeigenen Push-Dienstes ein Signal aus, um den App-Client zu benachrichtigen. In diesem Fall ist die Anwendung eine Android-App und verwendet FCM-Datennachricht, um das Signal zu senden.
- Nachdem die Anwendung das Signal mittels eingehender Pushbenachrichtigung empfangen hat, fordert sie das SDK dazu auf, die Änderungen im Benachrichtigungsspeicher des Benutzers abzurufen.
- Das SDK baut eine sichere und konforme Verbindung mit dem Benachrichtigungsspeicher des Benutzers in Microsoft Graph auf.
- Das SDK empfängt die Datenänderungen – in diesem Fall handelt es sich um die neuen Benachrichtigungsinhalte.
- Das SDK sendet Ereignisrückrufe, um die App zu benachrichtigen, nachdem die Änderungen erfolgreich abgerufen wurden.
- Anwendungslogik. Dieser Schritt umfasst, was die App innerhalb des Ereignisrückrufes entscheidet, zu tun. In der Regel führt dies zur Änderung lokaler Anwendungsdaten und zu lokalen Benutzeroberflächen-Updates. In diesem Fall erstellt die App in der Regel ein Popupbenachrichtigungs-Popup, um den Benutzer über den Benachrichtigungsinhalt zu benachrichtigen.
Benachrichtigungs-Updatefluss
Einer der Hauptvorteile bei der Verwendung von Microsoft Graph Benachrichtigungen ist, dass Benachrichtigungen sicher in der Cloud gespeichert und in einen zustandsbehafteten Ressourcentyp gewandelt werden. Daher kann es Ihrer Anwendung dabei helfen, in einem plattformübergreifenden Szenario den korrekten Benachrichtigungsstatus über verschiedene Geräte hinweg für denselben angemeldeten Benutzer zu verwalten und zu synchronisieren. Wenn eine Benachrichtigung als geschlossen oder auf einem Gerät als gelesen markiert wird, können die anderen Geräte darüber in Echtzeit benachrichtigt werden. „Einmal behandelt, überall geschlossen“ kann für Ihre benachrichtigten Nutzer zu einem echten Versprechen werden.
Das folgende Diagramm zeigt den Datenfluss für die Änderung des Status einer Benachrichtigung oder für das Löschen der Benachrichtigung auf einem Gerät und den Erhalt/die Verarbeitung der Statusänderung oder der Löschung auf einem anderen Gerät.
Beachten Sie, dass der zweite Teil des Flussdiagramms ähnlich dem Ablauf für die Verarbeitung eingehender neuer Benachrichtigungen ist. Dies ist beabsichtigt: Das Programmiermuster des SDK ist so konzipiert, dass der Anwendungsclient alle Arten von Änderungen an Benutzerbenachrichtigungsdaten (neue eingehende Benachrichtigungen, Änderungen des Benachrichtigungszustands, gelöschte Benachrichtigungen) auf ähnliche Weise verarbeiten kann.
Das Diagramm zeigt die folgenden Schritte:
- Anwendungslogik. Etwas löst die Änderung oder Löschung der Benachrichtigung aus. Im Allgemeinen kann jedes Ereignis eine Änderung der Benachrichtigung auslösen.
- Die App kontaktiert das Client-SDK, um eine Benachrichtigung zu aktualisieren oder zu löschen. Derzeit bieten wir zwei Eigenschaften bezüglich Statusänderungen: userActionState und readState. Ihre Anwendung kann diese Status definieren und auch festlegen, wann diese aktualisiert werden müssen. Wenn ein Benutzer das Benachrichtigungs-Popup beispielsweise schließt, können Sie die Eigenschaft userActionState auf geschlossen setzen. Wenn ein Benutzer auf das Benachrichtigungs-Popup klickt und die App öffnet, um den entsprechenden App-Inhalt zu konsumieren, können Sie userActionState auf aktiviert und readState auf gelesen setzen.
- Nachdem die entsprechende API aufgerufen wird, um eine Benachrichtigung zu aktualisieren oder zu löschen, kontaktiert das SDK den Benachrichtigungsspeicher des Benutzers in der Cloud, um diese Änderung an die restlichen App-Client-Instanzen aufzufächern, in denen derselbe Benutzer angemeldet ist.
- Nach Erhalt der Aktualisierungs-/Löschanfrage von einem Client aktualisiert Microsoft Graph Benachrichtigungen den Benachrichtigungsspeicher und identifiziert die anderen App-Client-Instanzen, die sich für diese Änderung angemeldet haben.
- Für jede Client-App-Anmeldung sendet Microsoft Graph Benachrichtigungen mittels des jeweils systemeigenen Push-Dienstes ein Signal aus, um den App-Client zu benachrichtigen. In diesem Fall handelt es ich um eine Android-App und sie verwendet FCM-Datennachricht, um das Signal zu senden.
- Nachdem die Anwendung das Signal mittels eingehender Pushbenachrichtigung empfangen hat, fordert sie das SDK dazu auf, die Änderungen im Benachrichtigungsspeicher des Benutzers abzurufen.
- Das SDK baut eine sichere und konforme Verbindung mit dem Benachrichtigungsspeicher des Benutzers in Microsoft Graph auf.
- Das SDK empfängt die Datenänderungen – in diesem Fall handelt es sich um Benachrichtigungs-Statusaktualisierungen oder Benachrichtigungs-Löschungen.
- Das SDK sendet Ereignisrückrufe, um die App zu benachrichtigen, nachdem die Änderungen erfolgreich abgerufen wurden.
- Anwendungslogik. Dieser Schritt umfasst, was die App innerhalb des Ereignisrückrufes entscheidet, zu tun. In der Regel führt dies zur Änderung lokaler Anwendungsdaten und zu lokalen Benutzeroberflächen-Updates. Da Benachrichtigungsaktualisierungen vorliegen, sollte die App in diesem Fall die Benutzeroberfläche lokal aktualisieren, um die Zustandsänderung darzustellen. Wenn eine Benachrichtigung z.B. als aktiviert markiert wird, können Sie die zugehörige Benachrichtigung aus Androids Benachrichtigungsablage entfernen, um nach dem Prinzip „einmal behandelt, überall geschlossen“ zu arbeiten.
Weitere Informationen zu Microsoft Graph Benachrichtigungen finden Sie unter Microsoft Graph Benachrichtigungen Überblick. Für zusätzliche Informationen über die Schritte, die erforderlich sind, um Microsoft Graph-Benachrichtigungen von Ende zu Ende zu integrieren, lesen Sie die Microsoft Graph-Benachrichtigungsübersicht.
Entwicklungsumgebung und Anforderungen
Um Microsoft Graph-Benachrichtigungen verwenden zu können, benötigen Sie eine Android-App-Entwicklungs-IDE und ein Android-Gerät mit einer der unterstützten Architekturen (armeabi-v7a, arm64-v8a, x86 oder x86_64) oder einen Emulator. Auf dem System muss Android (4.4.2) oder höher ausgeführt werden.
Ihrem Projekt das SDK hinzufügen
Fügen Sie die folgenden Repository-Referenzen in die build.gradle-Datei am Stamm Ihres Projekts ein.
allprojects {
repositories {
jcenter()
maven { url 'https://maven.google.com' }
maven { url 'https://projectrome.bintray.com/maven/' }
}
}
Fügen Sie dann die folgende Abhängigkeit in die build.gradle-Datei ein, die sich in Ihrem Projektordner befindet.
dependencies {
...
implementation 'com.microsoft.connecteddevices:connecteddevices-sdk:+'
}
Wenn Sie in Ihrer App ProGuard verwenden möchten, fügen Sie die ProGuard-Regeln für diese neuen APIs hinzu. Erstellen Sie eine Datei namens proguard-rules.txt im Ordner App Ihres Projekts, und fügen Sie den Inhalt von ein ProGuard_Rules_for_Android_Rome_SDK.txt.
Fügen Sie in der AndroidManifest.xml-Datei Ihres Projekts folgende Berechtigungen innerhalb des manifest-Elements hinzu (sofern sie nicht bereits vorhanden sind). Dadurch erhält Ihre App die Berechtigung zum Herstellen einer Verbindung mit dem Internet und zum Aktivieren der Bluetooth-Erkennung auf Ihrem Gerät.
Beachten Sie, dass die Bluetooth-bezogenen Berechtigungen nur für die Verwendung der Bluetooth-Erkennung erforderlich sind. Sie sind für die anderen Features auf der Plattform für verbundene Geräte nicht erforderlich. Des Weiteren ist ACCESS_COARSE_LOCATION nur auf Android-SDKs ab 21 und höher erforderlich. Auf Android-SDKs 23 und höher müssen Sie den Benutzer außerdem auffordern, zur Laufzeit Standortzugriff zu gewähren.
<uses-permission android:name="android.permission.INTERNET" />
<uses-permission android:name="android.permission.BLUETOOTH" />
<uses-permission android:name="android.permission.BLUETOOTH_ADMIN" />
<uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" />
<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />
Wechseln Sie als nächstes zu den Aktivitätsklassen, in denen Sie die Funktion für verbundene Geräte platzieren wollen. Importieren Sie die folgenden Namespaces.
import com.microsoft.connecteddevices;
import com.microsoft.connecteddevices.userdata;
import com.microsoft.connecteddevices.userdata.usernotifications;
Initialisieren der Plattform für verbundene Geräte
Das clientseitige SDK basiert auf einer Infrastruktur namens Plattform für verbundene Geräte. Bevor eine der Funktionen verwendet werden kann, muss die Plattform innerhalb Ihrer App initialisiert werden. Die Initialisierungsschritte sollten in der Hauptklasse Ihrer OnCreate-Methode erfolgen, da sie benötigt werden, bevor die Benachrichtigungsszenarien erfolgen können.
Sie müssen die Plattform konstruieren und initialisieren, indem Sie die Klasse ConnectedDevicesPlatforminstanziieren. Vorher müssen Sie sicherstellen, dass Ereignishandler verknüpft sind, denn die Ereignisse können eintreten, sobald die Plattform gestartet wird.
ConnectedDevicesPlatform platform = new ConnectedDevicesPlatform(context);
platform.getAccountManager().accessTokenRequested().subscribe((accountManager, args) -> onAccessTokenRequested(accountManager, args));
platform.getAccountManager().accessTokenInvalidated().subscribe((accountManager, args) -> onAccessTokenInvalidated(accountManager, args));
platform.getNotificationRegistrationManager().notificationRegistrationStateChanged().subscribe((notificationRegistrationManager, args) -> onNotificationRegistrationStateChanged(notificationRegistrationManager, args));
platform.start();
Handhabung von Konto-Zugriffstoken
Alle Webaufrufe, die das SDK durchführt, einschließlich des Abrufens des Inhalts einer neuen eingehenden Benachrichtigung, das Aktualisierung von Benachrichtigungsstatus usw., lesen aus oder schreiben in die Benutzerdaten und benötigen daher stets ein gültiges Zugriffstoken. Das SDK erfordert, dass Sie die folgenden Ereignisse verarbeiten. Diese treten ein, sobald ein Zugriffstoken angefordert oder ungültig gemacht wird, um sicherzustellen, dass Ihr Zugriffstoken nach der Initialisierung der Plattform korrekt verarbeitet wird.
accessTokenRequested
Eine vollständige Implementierung finden Sie in der Beispiel-App für Android.
private void onAccessTokenRequested(ConnectedDevicesAccountManager sender, ConnectedDevicesAccessTokenRequestedEventArgs args) {
ConnectedDevicesAccessTokenRequest request = args.getRequest();
List<String> scopes = request.getScopes();
// We always need to complete the request, even if a matching account is not found
if (account == null) {
request.completeWithErrorMessage("The app could not find a matching ConnectedDevicesAccount to get a token");
return;
}
// Complete the request with a token
account.getAccessTokenAsync(scopes)
.thenAcceptAsync((String token) -> {
request.completeWithAccessToken(token);
}).exceptionally(throwable -> {
request.completeWithErrorMessage("The Account could not return a token with those scopes");
return null;
});
}
accessTokenInvalidated
Eine vollständige Implementierung finden Sie in der Beispiel-App für Android.
private void onAccessTokenInvalidated(ConnectedDevicesAccountManager sender, ConnectedDevicesAccessTokenInvalidatedEventArgs args, List<Account> accounts) {
Log.i(TAG, "Token invalidated for account: " + args.getAccount().getId());
}
Verarbeitung des Ablaufs von Push-Registrierungen
Microsoft Graph Benachrichtigungen verwenden FCM, die native Push-Plattform unter Android, um der Clientanwendung Änderungen der Benachrichtigungsdaten des Benutzers zu signalisieren. Dies geschieht, wenn neue eingehende Benachrichtigungen von Ihrem App-Server veröffentlicht werden oder wenn der Status einer Benachrichtigung auf einem anderen Gerät aktualisiert wird, falls es sich um denselben Nutzer in einem geräteübergreifenden Szenario handelt.
Deshalb ist ein gültiges FCM-Token erforderlich, das es ermöglicht, dass Datenbenachrichtigungen erfolgreich übermittelt werden. Der folgende Ereignisrückruf verarbeitet die Ablaufzeit von FCM-Push-Token.
notificationRegistrationStateChanged
Eine vollständige Implementierung finden Sie in der Beispiel-App für Android.
Ihren Benutzer anmelden
Microsoft Graph Benachrichtigungen, wie viele andere Ressourcentypen in Microsoft Graph, sind um einen zentralen Nutzer herum konstruiert. Um Ihre App für Benachrichtigungen für den angemeldeten Benutzer anzumelden und diese zu empfangen, müssen Sie zuerst ein gültiges OAuth-Token beschaffen, das im Registrierungsprozess verwendet wird. Sie können Ihre bevorzugte Methode zum Generieren und Verwalten der OAuth-Token verwenden. Die Beispielapp verwendet ADAL.
Wenn Sie ein Microsoft-Konto verwenden, müssen Sie die folgenden Berechtigungen in Ihre Anmeldeanfrage inkludieren: wl.offline_access", ccs.ReadWrite, wns.connect, asimovrome.telemetry und https://activity.windows.com/UserActivity.ReadWrite.CreatedByApp.
Wenn Sie ein Microsoft Entra-Konto verwenden, müssen Sie die folgende Zielgruppe anfordern: https://cdpcs.access.microsoft.com.
Der Plattform das Benutzerkonto hinzufügen
Sie müssen das angemeldete Benutzerkonto beim SDK registrieren. Dazu gehört das Hinzufügen des Kontos und die Registrierung eines Pushkanals, um die anfänglichen Pushbenachrichtigungen über FCM zu erhalten.
public AsyncOperation<Boolean> prepareAccountAsync(final Context context) {
// Accounts can be in 3 different scenarios:
// 1: cached account in good standing (initialized in the SDK and our token cache).
// 2: account missing from the SDK but present in our cache: Add and initialize account.
// 3: account missing from our cache but present in the SDK. Log the account out async
// Subcomponents (e.g. UserDataFeed) can only be initialized when an account is in both the app cache
// and the SDK cache.
// For scenario 1, initialize our subcomponents.
// For scenario 2, subcomponents will be initialized after InitializeAccountAsync registers the account with the SDK.
// For scenario 3, InitializeAccountAsync will unregister the account and subcomponents will never be initialized.
switch (mState) {
// Scenario 1
case IN_APP_CACHE_AND_SDK_CACHE:
mUserNotificationsManager = new UserNotificationsManager(context, mAccount, mPlatform);
return registerAccountWithSdkAsync();
// Scenario 2
case IN_APP_CACHE_ONLY: {
// Add the this account to the ConnectedDevicesPlatform.AccountManager
return mPlatform.getAccountManager().addAccountAsync(mAccount).thenComposeAsync((ConnectedDevicesAddAccountResult result) -> {
// We failed to add the account, so exit with a failure to prepare bool
if (result.getStatus() != ConnectedDevicesAccountAddedStatus.SUCCESS) {
result.getStatus());
return AsyncOperation.completedFuture(false);
}
// Set the registration state of this account as in both app and sdk cache
mState = AccountRegistrationState.IN_APP_CACHE_AND_SDK_CACHE;
mUserNotificationsManager = new UserNotificationsManager(context, mAccount, mPlatform);
return registerAccountWithSdkAsync();
});
}
// Scenario 3
case IN_SDK_CACHE_ONLY:
// Remove the account from the SDK since the app has no knowledge of it
mPlatform.getAccountManager().removeAccountAsync(mAccount);
// This account could not be prepared
return AsyncOperation.completedFuture(false);
default:
// This account could not be prepared
Log.e(TAG, "Failed to prepare account " + mAccount.getId() + " due to unknown state!");
return AsyncOperation.completedFuture(false);
}
}
public AsyncOperation<Boolean> registerAccountWithSdkAsync() {
if (mState != AccountRegistrationState.IN_APP_CACHE_AND_SDK_CACHE) {
AsyncOperation<Boolean> toReturn = new AsyncOperation<>();
toReturn.completeExceptionally(new IllegalStateException("Cannot register this account due to bad state: " + mAccount.getId()));
return toReturn;
}
// Grab the shared GCM/FCM notification token from this app's BroadcastReceiver
return RomeNotificationReceiver.getNotificationRegistrationAsync().thenComposeAsync((ConnectedDevicesNotificationRegistration notificationRegistration) -> {
// Perform the registration using the NotificationRegistration
return mPlatform.getNotificationRegistrationManager().registerAsync(mAccount, notificationRegistration)
.thenComposeAsync((result) -> {
if (result.getStatus() == ConnectedDevicesNotificationRegistrationStatus.SUCCESS) {
Log.i(TAG, "Successfully registered account " + mAccount.getId() + " for cloud notifications");
} else {
// It would be a good idea for apps to take a look at the different statuses here and perhaps attempt some sort of remediation.
// For example, token request failed could mean that the user needs to sign in again. An app could prompt the user for this action
// and retry the operation afterwards.
Log.e(TAG, "Failed to register account " + mAccount.getId() + " for cloud notifications!");
return AsyncOperation.completedFuture(false);
}
return mUserNotificationsManager.registerForAccountAsync();
});
});
}
Empfang von Benutzerbenachrichtigungen anmelden
Sie müssen ein UserDataFeed-Objekt für Ihre Anwendung für den angemeldeten Benutzer instanziieren. Ihre Anwendung wird durch die plattformübergreifende App-ID identifiziert, die Sie während des geräteübergreifenden Onboardings vergeben haben.
public UserNotificationsManager(@NonNull Context context, @NonNull ConnectedDevicesAccount account, @NonNull ConnectedDevicesPlatform platform)
{
Context context = new Context;
UserDataFeed feed = UserDataFeed.getForAccount(account, platform, Secrets.APP_HOST_NAME);
UserNotificationChannel channel = new UserNotificationChannel(feed);
UserNotificationReader reader = channel.createReader();
reader.dataChanged().subscribe((reader, aVoid) -> readFromCache(reader));
}
}
Empfangen und Verwalten von Benutzerbenachrichtigungen
Das Flussdiagramm weiter oben in diesem Artikel zeigt, dass die Programmierungsmuster zur Verarbeitung neu ankommender Benachrichtigungen von einem App-Server und ein Benachrichtigungs-Update oder eine -Löschung, die von einer anderen Client-Instanz initiiert werden, ähnlich sind. Die folgenden Schritte beschreiben die Verarbeitung dieser Datenänderungen.
Verarbeitung eingehender Pushbenachrichtigungs-Signale
Alle Typen von Datenänderungen an Benutzerbenachrichtigungen generieren ein Signal, welches als Pushbenachrichtigung zu den App-Clients gesendet wird. Bei Android-Apps wird das Signal als FCM-Pushdatennachricht bereitgestellt. Sobald das Daten-Nachrichtensignal empfangen wird, sollte die App TryParse aufrufen, um das SDK zu veranlassen, die tatsächlichen Datenänderungen vom Microsoft Graph Benachrichtigungsdienst abzurufen.
public void onMessageReceived(RemoteMessage message) {
Map data = message.getData();
ConnectedDevicesNotification notification = ConnectedDevicesNotification.tryParse(data);
if (notification != null) {
try {
ConnectedDevicesPlatform platform = ConnectedDevicesManager.getConnectedDevicesManager(getApplicationContext()).getPlatform();
// NOTE: it may be useful to attach completion to this async in order to know when the notification is done being processed.
// This would be a good time to stop a background service or otherwise cleanup.
platform.processNotificationAsync(notification);
} catch (Exception e) {
Log.e(TAG, "Failed to process FCM notification" + e.getMessage());
}
}
}
Verarbeitung von Änderungen an Benutzer-Benachrichtigungsdaten
Nachdem das SDK das Abrufen der Datenänderungen erfolgreich abgeschlossen hat, wird ein Ereignisrückruf ausgelöst und vom App-Client wird erwartet, dass er die Erstellung, Löschung oder Änderung einer Benachrichtigung übernimmt.
private void readFromCache(final UserNotificationReader reader)
{
reader.readBatchAsync(Long.MAX_VALUE).thenAccept(notifications -> {
synchronized (this) {
for (final UserNotification notification : notifications) {
if (notification.getStatus() == UserNotificationStatus.ACTIVE) {
removeIf(mNewNotifications, item -> notification.getId().equals(item.getId()));
if (notification.getUserActionState() == UserNotificationUserActionState.NO_INTERACTION) {
mNewNotifications.add(notification);
if (notification.getReadState() != UserNotificationReadState.READ) {
clearNotification(mContext.getApplicationContext(), notification.getId());
addNotification(mContext.getApplicationContext(), notification.getContent(), notification.getId());
}
} else {
clearNotification(mContext.getApplicationContext(), notification.getId());
}
removeIf(mHistoricalNotifications, item -> notification.getId().equals(item.getId()));
mHistoricalNotifications.add(0, notification);
} else {
removeIf(mNewNotifications, item -> notification.getId().equals(item.getId()));
removeIf(mHistoricalNotifications, item -> notification.getId().equals(item.getId()));
clearNotification(mContext.getApplicationContext(), notification.getId());
}
}
}
});
}
Aktualisierung des Zustands einer Benachrichtigung
Wenn diese App-Client-Instanz eine Statusänderung für eine Benachrichtigung initiiert (beispielsweise, wenn die Popupbenachrichtigung auf diesem Gerät vom Benutzer aktiviert wird), so muss die App das SDK aufrufen, um den Benachrichtigungsstatus zu aktualisieren, damit dieser Status geräteübergreifend für diesen Nutzer auf all seinen Geräten synchronisiert wird.
notification.setUserActionState(UserNotificationUserActionState.ACTIVATED);
notification.saveAsync().whenCompleteAsync((userNotificationUpdateResult, throwable) -> {
if (throwable == null && userNotificationUpdateResult != null && userNotificationUpdateResult.getSucceeded()) {
Log.d(TAG, "Successfully activated the notification");
}
});
Zeitliches Steuern einer Benachrichtigung
Wenn von dieser App-Client-Instanz aus die Löschung einer Benachrichtigung initiiert wird (z.B. falls der Task, der dieser Benachrichtigung zugehörig ist, als abgeschlossen gekennzeichnet wird und aus der Datenbank Ihrer App entfernt wird), so muss die App das SDK aufrufen, um die Benachrichtigung zu löschen, damit dieser Löschvorgang über alle Geräte dieses Benutzers hinweg synchronisiert wird.
Eine Benachrichtigung wird erst dann aus dem Benachrichtigungsspeicher eines Nutzers entfernt, wenn sie abgelaufen ist oder ausdrücklich gelöscht wurde. Eine Benutzerbenachrichtigung wird nicht gelöscht, wenn Sie den UserActionState auf geschlossen setzen, denn die semantische Definition von UserActionState wird durch die Anwendung selbst definiert.
channel.deleteUserNotificationAsync(notification.getId()).whenCompleteAsync((userNotificationUpdateResult, throwable) -> {
if (throwable == null && userNotificationUpdateResult != null && userNotificationUpdateResult.getSucceeded()) {
Log.d(TAG, "Successfully deleted the notification");
}
});
Verwandte Inhalte
- API-Referenz für alle APIs, die mit Benachrichtigungsfunktionen im SDK zusammenhängen.
- Clientseitiges Beispiel für Android-Apps.
- App-Server-Beispiel für die Veröffentlichung von Benachrichtigungen.