Schrittanleitung: Integration in MS Graph-Benachrichtigungen (UWP von Windows)

Mit dem clientseitigen SDK für Graph-Benachrichtigungen unter Windows kann die UWP-App die erforderlichen Registrierungsschritte ausführen, um aus ihr einen Empfangsendpunkt zu machen, der vom App-Server veröffentlichte Benachrichtigungen an einen Benutzer empfängt. Mit dem SDK werden dann die Benachrichtigungen auf der Clientseite behandelt, einschließlich des Empfangs neuer Benachrichtigungsnutzlasten auf dem Client, des Verwaltens des Status der Benachrichtigungen und des Abrufens des Benachrichtigungsverlaufs. Weitere Informationen über MS Graph-Benachrichtigungen und die Übermittlung benutzerzentrierter Benachrichtigungen finden Sie unter Microsoft Graph-Benachrichtigungen

Auf der Seite API-Referenz finden Sie Links zur Referenzdokumentation für Benachrichtigungsszenarien.

Vorläufige Einrichtung für den Zugriff auf die Plattform für verbundene Geräte, um Graph-Benachrichtigungen zu verwenden

Für die Integration in Graph-Benachrichtigungen müssen Sie einige Schritte ausführen.

• MSA- oder AAD-App-Registrierung
• Dev Center-Onboarding für die Bereitstellung von plattformübergreifender App-Identität und Anmeldeinformationen für Pushbenachrichtigungen
• Hinzufügen des SDK und Initialisieren der Plattform für verbundene Geräte
• Zuordnen des Benachrichtigungsdiensts zur-Plattform für verbundene Geräte

Zunächst müssen Sie die MSA- und/oder AAD-App-Registrierung ausführen. Wenn Sie dies bereits getan haben, fahren Sie mit dem nächsten Abschnitt fort.

Registrierung für MSA- und AAD-Authentifizierung

Alle Features des SDK, einschließlich Benachrichtigungen, erfordern Registrierung für MSA-Authentifizierung (Microsoft Account) oder AAD-Authentifizierung (Azure Active Directory). Dies gilt jedoch nicht für die Umgebungsfreigabe-APIs.

Wenn Sie noch kein MSA haben, jedoch ein MSA verwenden möchten, registrieren Sie sich auf account.microsoft.com.

Wenn Sie MSA als Authentifizierungs- und Identitätsframework für die Benutzer verwenden, müssen Sie als Nächstes die App bei Microsoft registrieren, indem Sie die Anweisungen im Portal für die Anwendungsregistrierung befolgen (wenn Sie über kein Microsoft-Entwicklerkonto verfügen, müssen Sie eines erstellen). Sie erhalten eine Client-ID-Zeichenfolge für Ihre App. Merken Sie sich den Speicherort, oder speichern Sie die Angaben zum Speicherort. Diese Zeichenfolge wird später beim Integrieren von Graph-Benachrichtigungen verwendet. Beachten Sie, dass eine App, die MSA-Authentifizierung verwendet, als Live SDK-Anwendung registriert werden muss, wie unten dargestellt.

Wenn Sie eine App schreiben, die AAD als Authentifizierungs- und Identitätsframework für Arbeits- oder Schulkonten verwendet, müssen Sie die App über Active Directory-Authentifizierungsbibliotheken registrieren, um die Client-ID zu erhalten, wie unten dargestellt. Beim Erstellen einer neuen App-Registrierung sind einige Berechtigungen erforderlich, um Graph-Benachrichtigungen und andere Funktionen der Plattform für verbundene Geräte zu verwenden. Siehe die folgende Abbildung.

• Fügen Sie die Benutzeranmeldungsberechtigung hinzu, wie unten dargestellt.
• Fügen Sie die Befehlsdienst-Berechtigungen für Geräteinformationen hinzu, wie unten dargestellt.
• Fügen Sie unter der API für den Microsoft-Dienst für Aktivitätsfeeds Berechtigungen für Graph-Benachrichtigungen hinzu, wie unten dargestellt.
• Wenn Sie schließlich eine plattformübergreifende Anwendung schreiben, einschließlich einer unter Windows ausgeführten UWP-App, müssen Sie Berechtigungen für den Windows-Benachrichtigungsdienst hinzufügen, wie unten dargestellt.

Als Nächstes müssen Sie das Onboarding mit Microsoft Windows Dev Center durchführen, um Zugriff auf die Plattform für verbundene Geräte zu erhalten, damit Sie die geräteübegreifende Nutzung, einschließlich der Verwendung von Graph-Benachrichtigungen, integrieren können. Wenn Sie dies bereits getan haben, fahren Sie mit dem nächsten Abschnitt fort.

Registrieren der App im Microsoft Windows Dev Center für die geräteübergreifende Nutzung

Anschließend müssen Sie die App für das Feature für die geräteübergreifende Nutzung im Microsoft-Entwicklerdashboard registrieren. Dies ist ein anderes Verfahren als die in den obigen Schritten beschriebene Registrierung für MSA- oder ADD-Authentifizierung. Der Hauptzweck dieses Verfahrens ist es, die plattformspezifischen App-Identitäten einer plattformübergreifenden App-Identität zuzuordnen, die von der Plattform für verbundene Geräte erkannt wird. Gleichzeitig sollen auch Microsoft Graph-Benachrichtigungen autorisiert werden, mit den nativen Push-Benachrichtigungsdiensten für die jeweilige Betriebssystemplattform Benachrichtigungen zu senden. In diesem Fall wird Graph-Benachrichtigungen das Senden von Benachrichtigungen an UWP-App-Endpunkte über den Windows-Benachrichtigungsdienst (Windows Notification Service, WNS) ermöglicht. Wechseln Sie zum Dev Center-Dashboard, navigieren Sie im linken Navigationsbereich zu „Cross-Device Experiences“ (Geräteübergreifende Nutzung), und wählen Sie die Option zum Konfigurieren einer neuen geräteübergreifenden App aus, wie unten dargestellt.

Der Dev Center-Onboardingprozess erfordert die folgenden Schritte:

• „Select supported platforms“ (Unterstützte Plattformen auswählen): Wählen Sie die Plattformen aus, auf denen Ihre App präsent sein wird und die für die geräteübergreifende Nutzung aktiviert werden sollen. Im Falle der Integration von Graph-Benachrichtigungen können Sie Windows, Android und/oder iOS auswählen, wie unten dargestellt.

• „Provide app IDs“ (App-IDs angeben): Stellen Sie App-IDs für jede Plattform bereit, auf der Ihre App präsent ist, wie unten dargestellt.

Hinweis

Sie können verschiedene IDs (bis zu zehn) pro Plattform hinzufügen. Dies ist sinnvoll, wenn mehrere Versionen der App vorhanden sind oder wenn Sie über mehrere Apps verfügen, die dieselbe vom App-Server gesendete Benachrichtigung empfangen sollen, die für denselben Benutzer vorgesehen ist.

• Geben Sie die App-IDs von der MSA- und/oder AAD-App-Registrierung an, oder wählen Sie sie aus. Diese der MSA- oder AAD-App-Registrierung entsprechenden Client-IDs wurden in den oben beschriebenen Schritten für die MSA-/AAD-App-Registrierung erlangt. wie unten dargestellt.
• Graph-Benachrichtigungen und andere Funktionen der Plattform für verbundene Geräte nutzen die jeweiligen nativen Benachrichtigungsplattformen der wichtigsten Plattformen zum Senden von Benachrichtigungen an die App-Client-Endpunkte, d.h. WNS (für UWP von Windows), GCM (für Android) und APNs (für iOS). Geben Sie Ihre Anmeldeinformationen für diese Benachrichtigungsplattformen an, damit Graph-Benachrichtigungen Benachrichtigungen für den App-Server übermitteln kann, wenn Sie Benachrichtigungen für Benutzer veröffentlichen. wie unten dargestellt.

Hinweis

Für UWP-Apps (Windows) müssen WNS-Pushbenachrichtigungen aktiviert werden, damit Microsoft Graph-Benachrichtigungen verwendet werden kann. Weitere Informationen finden Sie unter Übersicht über Windows-Pushbenachrichtigungsdienste (Windows Push Notification Services, WNS). Nachdem Sie das Onboarding abgeschlossen haben, können Sie im Windows Dev Center die Pushanmeldeinformationen für die Plattform für verbundene Geräte angeben.

• Der letzte Schritt ist das Überprüfen der Domäne für die geräteübergreifende App. Dabei wird überprüft, ob Ihre App Besitzer der Domäne ist. Dies entspricht einer geräteübergreifenden App-Identität für die App, die Sie registriert haben. wie unten dargestellt.
  Sie haben das Onboarding jetzt abgeschlossen! Fahren Sie mit dem nächsten Abschnitt fort.

Dann müssen Sie dem Projekt das Project Rome-SDK hinzufügen und die Plattform für verbundene Geräte initialisieren. Wenn Sie dies bereits getan haben, fahren Sie mit dem nächsten Abschnitt fort.

Hinzufügen des SDK

Fügen Sie die folgenden Repositoryverweise in die build.gradle-Datei im Stammverzeichnis des Projekts ein.

allprojects {
    repositories {
        jcenter()
        maven { url 'https://maven.google.com' }
        maven { url 'https://projectrome.bintray.com/maven/' }
    }
}

Fügen Sie anschließend die folgende Abhängigkeit in die build.gradle-Datei ein, die sich im Projektordner befindet.

dependencies { 
    ...
    implementation 'com.microsoft.connecteddevices:connecteddevices-sdk:0.11.0'
}

Wenn Sie ProGuard in Ihrer App verwenden möchten, fügen Sie die ProGuard-Regeln für die neuen APIs hinzu. Erstellen Sie im Ordner App des Projekts eine Datei mit dem Namen proguard-rules.txt, und fügen Sie den Inhalt von „ProGuard_Rules_for_Android_Rome_SDK.txt“ ein.

Fügen Sie in der Datei AndroidManifest.xml des Projekts im <manifest>-Element die folgenden Berechtigungen hinzu (sofern sie nicht bereits vorhanden sind). Dadurch erhält die App die Berechtigung, eine Verbindung mit dem Internet herzustellen und die Bluetooth-Erkennung auf dem Gerät zu aktivieren.

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

Hinweis

Die Berechtigungen für Bluetooth sind nur für die Bluetooth-Erkennung und nicht für die anderen Features der Plattform für verbundene Geräte erforderlich. Zudem ist ACCESS_COARSE_LOCATION nur für Android-SDKs der API-Ebene 21 und höher erforderlich. Für Android-SDKs der API-Ebene 23 und höher muss der Entwickler auch implementieren, dass der Benutzer zur Laufzeit zum Gewähren der Ortung aufgefordert wird.

Als Nächstes wechseln Sie zu der/den Aktivitätsklasse(n), in der/denen die Funktionalität der Plattform für verbundene Geräte hinzugefügt werden soll. Importieren Sie die connecteddevices-Namespaces.

import com.microsoft.connecteddevices.*;

Je nachdem, welche Szenarien Sie implementieren, sind möglicherweise nicht alle Namespaces erforderlich. Sie müssen im weiteren Verlauf auch weitere native Android-Namespaces hinzuzufügen.

Initialisieren der Plattform für verbundene Geräte

Bevor Funktionen der Plattform für verbundene Geräte verwendet werden können, muss die Plattform in der App initialisiert werden. Die Initialisierungsschritte sollten in der onCreate- oder onResume-Methode der Hauptklasse erfolgen, da sie für andere Szenarien für verbundene Geräte erforderlich sind.

Sie müssen die Platform-Klasse instanziieren. Der Platform-Konstruktor akzeptiert drei Parameter: den Context für die App, einen NotificationProvider und einen UserAccountProvider.

Der NotificationProvider-Parameter ist nur für bestimmte Szenarien erforderlich. Bei Verwendung von Microsoft Graph-Benachrichtigungen ist er erforderlich. Belassen Sie ihn vorerst bei null. Im nächsten Abschnitt erfahren Sie, wie mit dem Client-SDK eingehende benutzerzentrierte Benachrichtigungen über native Pushkanäle behandelt werden.

Der UserAccountProvider ist erforderlich, um ein OAuth 2.0-Zugriffstoken für den Zugriff des aktuellen Benutzers auf die Plattform für verbundene Geräte bereitzustellen. Er wird beim erstmaligen Ausführen der App und bei Ablauf eines von der Plattform verwalteten Aktualisierungstokens aufgerufen.

Um Entwicklern das Integrieren der Plattform zu erleichtern, wurden AccountProvider-Implementierungen für Android und iOS bereitgestellt. Diese Implementierungen, die Sie im Beispiel für Authentifizierungsanbieter finden, können zum Abrufen des OAuth 2.0-Zugriffstokens und Aktualisierungstokens für die App verwendet werden.

Einrichten von Authentifizierung und Kontoverwaltung

Die Plattform für verbundene Geräte erfordert, dass bei der Registrierung ein gültiges OAuth-Token verwendet wird. Sie können Ihre bevorzugte Methode zum Generieren und Verwalten der OAuth-Token verwenden. Um jedoch Entwicklern die ersten Schritte mit der Plattform zu erleichtern, wird in der Beispiel-App für Android ein Authentifizierungsanbieter bereitgestellt, der Aktualisierungstoken generiert und verwaltet.

Wenn Sie die ConnectedDevicesAccountManager-Schnittstelle selbst implementieren möchten, beachten Sie die folgenden Informationen:

Wenn Sie ein MSA verwenden, müssen Sie die folgenden Bereiche in die Anmeldeanforderung einschließen: "wl.offline_access", "ccs.ReadWrite", "dds.read", "dds.register", "wns.connect", "asimovrome.telemetry" und "https://activity.windows.com/UserActivity.ReadWrite.CreatedByApp".

Wenn Sie ein AAD-Konto verwenden, müssen Sie die folgenden Zielgruppen anfordern: "https://cdpcs.access.microsoft.com", "https://cs.dds.microsoft.com", "https://wns.windows.com/" und "https://activity.microsoft.com".

Hinweis

AAD-Konten (Azure Active Directory) werden für Device Relay-APIs nicht unterstützt.

Bei Verwendung von AAD müssen Sie unabhängig davon, ob Sie die bereitgestellte ConnectedDevicesAccountManager-Implementierung verwenden, in der Registrierung der App im Azure-Portal (portal.azure.com > „Azure Active Directory“ > „App-Registrierungen“) die folgenden Berechtigungen angeben:

• Microsoft-Aktivitätsfeeddienst
  • Bereitstellen und Ändern von Benutzerbenachrichtigungen für diese App
  • Lesen und Schreiben von App-Aktivitäten in den/aus dem Aktivitätsfeed des Benutzers
• Windows-Benachrichtigungsdienst
  • Verbinden des Geräts mit dem Windows-Benachrichtigungsdienst
• Microsoft Device Directory Service
  • Siehe die Liste der Geräte
  • Muss der Liste der Geräte und Apps hinzugefügt
• Microsoft Command Service
  • Kommunizieren mit Benutzergeräten
  • Lesen von Benutzergeräten

Im folgenden Code verweist mSignInHelper auf einen MSAAccountProvider, der auch weiter unten initialisiert wird. Die bereitgestellte Klasse implementiert die UserAccountProvider-Schnittstelle.

private MSAAccountProvider mSignInHelper;

// ...

// Create sign-in helper from helper lib, which does user account and access token management for us
// Takes two parameters: a client id for msa, and the Context
mSignInHelper = new MSAAccountProvider(Secrets.MSA_CLIENT_ID, getContext());

// add an event listener, which changes the button text when account state changes
mSignInHelper.addUserAccountChangedListener(new EventListener<UserAccountProvider, Void>() {
    @Override
    public void onEvent(UserAccountProvider provider, Void aVoid){
        if (mSignInHelper.isSignedIn()) {
            // update the UI indicating a user is signed in.
        }
        else
        {
            // update the UI indicating a user is not signed in.
        }
    }
});

Jetzt können Sie eine Platform-Instanz erstellen. Es empfiehlt sich, den folgenden Code in eine eigene Hilfsklasse einzufügen.

// Platform helper class:

private static Platform sPlatform;

//...

// This is the main Platform-generating method
public static synchronized Platform getOrCreatePlatform(Context context, UserAccountProvider accountProvider, NotificationProvider notificationProvider) {
    // check whether the local platform variable is already initialized.
    Platform platform = getPlatform();

    if (platform == null) {
        // if it is not initialized, do so:
        platform = createPlatform(context, accountProvider, notificationProvider);
    }
    return platform;
}

// gets the local platform variable
public static synchronized Platform getPlatform() {
        return sPlatform;
}

// creates and returns a new Platform instance
public static synchronized Platform createPlatform(Context context, UserAccountProvider accountProvider, NotificationProvider notificationProvider) {
    sPlatform = new Platform(context, accountProvider, notificationProvider);
    return sPlatform;
}

Fügen Sie in der Hauptklasse, in der mSignInHelper initialisiert wird, folgenden Code hinzu.

private Platform mPlatform;

//...

mPlatform = PlatformHelperClass.getOrCreatePlatform(this, mSignInHelper, null);

Sie sollten die Plattform herunterfahren, wenn die App den Vordergrund verlässt.

mPlatform.shutdownAsync();

Schließlich müssen Sie Empfang von Pushbenachrichtigungen für die App aktivieren. Wenn Sie dies bereits getan haben, fahren Sie mit dem nächsten Abschnitt fort.

Ordnen Sie die Plattform für verbundene Geräte der nativen Push-Benachrichtigung für die jeweilige mobile Plattform zu.

Wie bereits erwähnt, müssen die App-Clients während der Registrierung dem Client-SDK und der Plattform für verbundene Geräte mitteilen, welche native Push-Benachrichtigungspipeline für die jeweilige mobile Plattform verwendet wird. Dies geschieht, damit der Graph-Benachrichtigungsdienst Benachrichtigungen an jeden App-Clientendpunkt übermitteln kann, wenn der App-Server über Microsoft Graph-APIs Benachrichtigungen für Benutzer veröffentlicht.

In den obigen Schritten haben Sie die Plattform mit dem null NotificationProvider-Parameter initialisiert. Hier müssen Sie ein Objekt erstellen und übergeben, das NotificationProvider implementiert. Beachten Sie vor allem die getNotificationRegistrationAsync-Methode, die eine NotificationRegistration-Instanz zurückgeben muss. Die NotificationRegistration muss der Plattform für verbundene Geräte ein Zugriffstoken (und zugehörige Informationen) für den Benachrichtigungsdienst bereitstellen.

private NotificationRegistration mNotificationRegistration;

// ...

/**
* NotificationRegistration is constructed with four parameters:
* Type: This is the notification platform type.
* Token: This is the string that GCM or FCM sends to your registration intent service.
* SenderId: This is the numeric Sender ID that you received when you registered your app for push notifications.
* DisplayName: This should be the name of the app that you used when you registered it on the Microsoft dev portal. 
*/
mNotificationRegistration = new NotificationRegistration(NotificationType.FCM, token, FCM_SENDER_ID, "MyAppName");

Stellen Sie diese Registrierung in Ihrer Implementierung von NotificationProvider bereit. Anschließend muss der Platform-Initialisierungsaufruf der lokalen Platform Zugriff auf den Pushbenachrichtigungsdienst ermöglichen, damit die App Daten vom Server für Microsoft Graph-Benachrichtigungen empfangen kann.

Übergeben eingehender Pushbenachrichtigungen an das Client-SDK

Erweitern Sie jetzt die native Listener-Dienstklasse (in diesem Fall FirebaseMessagingService, da in diesem Tutorial Firebase Cloud Messaging verwendet wird) mit einer speziellen Überladung der onMessageReceived-Methode (die Benachrichtigungsverarbeitungsmethode).

Aufgrund von Compliance, Sicherheit und potenziellen Optimierungen fungiert die eingehende Google Cloud Messaging-Benachrichtigung vom Server für Graph-Benachrichtigungen möglicherweise lediglich als Signal, das keine Daten enthält, die ursprünglich vom App-Server veröffentlicht wurden. Der Abruf des eigentlichen Benachrichtigungsinhalts, der vom App-Server veröffentlicht wurde, erfolgt verborgen hinter clientseitigen SDK-APIs. Aus diesem Grund kann das SDK ein konsistentes Programmierschema bereitstellen, in dem der App-Client immer die eingehende Google Cloud Messaging-Nutzlast an das SDK übergibt. Dadurch kann das SDK bestimmen, ob es sich um eine Benachrichtigung für Szenarien der Plattform für verbundene Geräte handelt (falls der App-Client den nativen Google Cloud Messaging-Kanal von Android für andere Zwecke verwendet) und welchem Szenario/welcher Funktion die eingehende Benachrichtigung entspricht (Graph-Benachrichtigungen, Benutzeraktivität usw.). Anschließend können vom App-Client spezielle Logiken für unterschiedliche Szenariotypen ausgeführt werden.

/**
* Check whether it's a Connected Devices Platform notification or not.
* If it is a Connected Devices Platform notification, it will notify the apps with the information in the notification.
* @param from describes message sender.
* @param data message data as String key/value pairs.
*/
@Override
public void onMessageReceived(String from, Bundle data) {
    Log.d(TAG, "From: " + from);

    // Ensure that the Platform is initialized here before going on
    // ...

    // This method passes the data to the Connected Devices Platform if is compatible.
    if (!NotificationReceiver.Receive(data)) {
        // a value of false indicates a non-Rome notification
        Log.d(TAG, "GCM client received a message that was not a Rome notification");
    }
}

Ihre App kann jetzt Benachrichtigungen von der Plattform für verbundene Geräte behandeln.

Initialisieren eines Kanals für Graph-Benachrichtigungen

Allgemein ausgedrückt, kann Ihre App mit dem Project Rome-SDK unterschiedliche Kanäle abonnieren, um verschiedene Typen von Benutzerdaten zu empfangen und zu verwalten – einschließlich Graph-Benachrichtigungen, Benutzeraktivitäten u.v.m. Diese werde alle in UserDataFeed gespeichert und synchronisiert. UserNotification ist die Klasse und der Datentyp, die einer über Graph-Benachrichtigungen gesendeten Benachrichtigung für Benutzer entsprechen. Für die Integration in Graph-Benachrichtigungen und den Empfang einer vom App-Server veröffentlichten UserNotification müssen Sie zunächst den Benutzerdatenfeed initialisieren, indem Sie einen UserNotificationChannel erstellen. Sie sollten dabei wie im obigen Schritt für die Plattforminitialisierung vorgehen: Immer wenn die App in den Vordergrund gelangt (jedoch nicht vor der Plattforminitialisierung) sollte dies überprüft und möglicherweise wiederholt werden.

Erstellen eines UserNotificationReader, um eingehende UserNotifications zu empfangen und auf den UserNotification-Verlauf zuzugreifen

Sobald Sie über einen UserNotificationChannel-Verweis, verfügen, benötigen Sie einen UserNotificationReader, damit das SDK den Benachrichtigungsinhalt vom Server abrufen kann. In diesem Fall ermöglicht der UserNotificationReader den Zugriff des App-Clients auf den Datenfeed – um über einen Ereignislistener die neueste Benachrichtigungsnutzlast zu empfangen oder auf die UserNotification-Sammlung zuzugreifen, die als Ansichtsmodell für den Benachrichtigungsverlauf des Benutzers verwendet werden kann.

Der folgende Code zeigt die Schritte zum Instanziieren eines Benutzerbenachrichtigungskanals, zum Erstellen eines Benutzerbenachrichtigungsreaders und zum Hinzufügen eines Ereignishandlers für den Benutzerbenachrichtigungsreader. Der Handler wird ausgelöst, wenn die Plattform für verbundene Geräte eine Synchronisierung durchführt und Sie über neue Änderungen zu benachrichtigen hat.

public async Task SetupChannel()
{
    var account = m_accoutProvider.SignedInAccount;

    if (m_feed == null)
    {
        await Task.Run(() =>
        {
            lock (this)
            {
                if (m_feed == null)
                {
                    m_platform = new ConnectedDevicesPlatform(m_accoutProvider, this);

                    Logger.Instance.LogMessage($"Create feed for {account.Id} {account.Type}");
                    m_feed = new UserDataFeed(account, m_platform, "graphnotifications.sample.windows.com");
                    m_feed.SyncStatusChanged += Feed_SyncStatusChanged;
                    m_feed.AddSyncScopes(new List<IUserDataFeedSyncScope>
                    {
                        UserNotificationChannel.SyncScope
                    });

                    m_channel = new UserNotificationChannel(m_feed);
                    m_reader = m_channel.CreateReader();
                    m_reader.DataChanged += Reader_DataChanged;
                }
            }
        });
    }
}

Empfangen von UserNotifications

Im obigen Abschnitt wurde dem Benutzerbenachrichtigungsreader ein Ereignislistener hinzugefügt. Sie sollten diesen Ereignislistener implementieren, um alle neuen Benachrichtigungen und Benachrichtigungsaktualisierungen vom Reader zu lesen, und eine eigene Geschäftslogik zum Behandeln der einzelnen neuen Änderungen implementieren.

Tipp

Im Ereignislistener behandeln Sie die Hauptgeschäftslogik und verwenden den Inhalt der Benachrichtigungsnutzlast auf Grundlage Ihrer Szenarien. Wenn Sie derzeit eine unformatierte WNS-Benachrichtigung verwenden, um eine lokale Pushbenachrichtigung in der Mitteilungszentrale auf Betriebssystemebene zu erstellen, oder wenn Sie mit dem Inhalt der Benachrichtigung Benutzeroberflächenelemente der App aktualisieren, führen Sie dies hier durch.

Der folgende Code zeigt, wie die Beispiel-App eine lokale Pushbenachrichtigung für alle eingehenden Benutzerbenachrichtigungen auslöst, die aktiv sind, und das entsprechende Benachrichtigungs-Benutzeroberflächenelement in der App-internen Ansicht entfernt, wenn eine Benachrichtigung gelöscht wird.

private void Reader_DataChanged(UserNotificationReader sender, object args)
{
    ReadNotifications(sender, true);
}

private async void ReadNotifications(UserNotificationReader reader, bool showToast)
{
    var notifications = await reader.ReadBatchAsync(UInt32.MaxValue);

    foreach (var notification in notifications)
    {

        if (notification.Status == UserNotificationStatus.Active)
        {
            m_newNotifications.RemoveAll((n) => { return (n.Id == notification.Id); });
            if (notification.UserActionState == UserNotificationUserActionState.NoInteraction)
            {
                // new notification, show this to user using the Windows local toast notification APIs
                m_newNotifications.Add(notification);
                if (!string.IsNullOrEmpty(notification.Content) && showToast)
                {
                    ShowToastNotification(BuildToastNotification(notification.Id, notification.Content));
                }
            }

            m_historicalNotifications.RemoveAll((n) => { return (n.Id == notification.Id); });
            m_historicalNotifications.Insert(0, notification);
        }
        else
        {
            // Existing notification is marked as deleted, remove from display
            m_newNotifications.RemoveAll((n) => { return (n.Id == notification.Id); });
            m_historicalNotifications.RemoveAll((n) => { return (n.Id == notification.Id); });
            RemoveToastNotification(notification.Id);
        }
    }
}

Aktualisieren des Status einer vorhandenen UserNotification

Im vorherigen Abschnitt wurde erwähnt, dass manchmal eine über den Reader empfangene UserNotification-Änderung eine Statusaktualisierung einer vorhandenen UserNotification sein kann, die als verworfen oder gelesen markiert ist. In diesem Fall kann der App-Client auswählen, wie vorzugehen ist, z.B. Aktivieren von universellem Schließen, indem die entsprechende visuelle Benachrichtigung auf dem betreffenden Gerät entfernt wird. Häufig wurde die UserNotification-Änderung zuvor von Ihrem App-Client initiiert – von einem anderen Gerät aus. Sie können die Zeit der Statusaktualisierung der UserNotifications wählen. In der Regel erfolgt diese jedoch, wenn die entsprechende visuelle Benachrichtigung durch den Benutzer des Geräts behandelt wird. Oder die Benachrichtigung wird vom Benutzer in einer von Ihnen aktivierten In-App-Erfahrung behandelt. Ein Beispiel für diesen Flow wäre etwa: Der App-Server veröffentlicht eine Benachrichtigung an Benutzer A. Benutzer A empfängt diese Benachrichtigung auf seinem PC und seinem Smartphone, auf denen die App-Clients installiert sind. Der Benutzer klickt auf dem PC auf die Benachrichtigung und öffnet die App, um die entsprechende Aufgabe zu behandeln. Der App-Client auf dem PC ruft dann das SDK der Plattform für verbundene Geräte auf, um den Status der entsprechenden Benutzerbenachrichtigung zu aktualisieren, damit diese Aktualisierung auf allen Geräten des Benutzers synchronisiert wird. Die anderen App-Clients, entfernen dann bei Empfang dieser Statusaktualisierung in Echtzeit die entsprechende visuelle Warnung/Nachricht/Popupbenachrichtigung aus der Mitteilungszentrale/dem Infobereich/dem Info-Center des Geräts. So werden Benachrichtigungen auf den Geräten eines Benutzers universell geschlossen.

Tipp

Die UserNotification-Klasse bietet derzeit 2 Typen von Statusaktualisierungen – Sie können den UserNotificationReadState oder den UserNotificationUserActionState ändern und eine eigene Logik für die Vorgehensweise definieren, die beim Aktualisieren von Benachrichtigungen angewendet werden soll. Sie können z.B. den UserActionState als „Activated“ oder „Dismissed“ markieren und dann anhand dieses Werts universelles Verfwerfen implementieren. Alternativ oder gleichzeitig können Sie den ReadState als „Read“ oder „Unread“ markieren und auf dieser Grundlage bestimmen, welche Benachrichtigungen im App-internen Benachrichtigungsverlauf angezeigt werden sollen. Im folgenden Codeausschnitt wird gezeigt, wie der UserNotificationUserActionState einer Benachrichtigung als „Dismissed“ markiert wird.

public async void Dismiss(string id)
{
    var notification = m_newNotifications.Find((n) => { return (n.Id == id); });
    if (notification != null)
    {
        notification.UserActionState = UserNotificationUserActionState.Dismissed;
        await notification.SaveAsync();
    }
}