Guida pratica: Integrazione con le notifiche di MS Graph (Windows UWP)

Con l'SDK di Graph Notifications sul lato client in Windows la tua app UWP di Windows può eseguire la procedura di registrazione necessaria per diventare un endpoint di destinazione che riceve le notifiche pubblicate dal tuo server applicazioni destinate a un utente. L'SDK viene quindi usato per gestire le notifiche sul lato client, tra cui ricezione dei payload delle nuove notifiche in arrivo nel client, gestione dello stato delle notifiche e recupero della cronologia di notifica. Per altre informazioni su Microsoft Graph Notifications e su come consente il recapito delle notifiche incentrato sull'utente, vedi la panoramica su Microsoft Graph Notifications.

Visita la pagina Riferimento API per collegamenti alla documentazione di riferimento pertinente per gli scenari di notifica.

Configurazione preliminare per l'accesso alla piattaforma dispositivi connessi per l'uso di Graph Notifications

Per consentire l'integrazione con Graph Notifications ci sono alcune operazioni da eseguire

• Registrazione dell'app per MSA o AAD
• Onboarding in Dev Center per fornire l'identità dell'app multipiattaforma e le credenziali di notifica push
• Aggiunta dell'SDK e inizializzazione della piattaforma dispositivi connessi
• Associazione del servizio di notifica alla piattaforma dispositivi connessi

Per prima cosa, devi completare la registrazione dell'app per MSA e/o AAD. Se hai già eseguito questa operazione, passa alla sezione successiva.

Registrazione per l'autenticazione MSA e AAD

È richiesta la registrazione per l'autenticazione con account Microsoft (MSA) o di Azure Active Directory (AAD) per tutte le funzionalità dell'SDK, tra cui Notifications, ad eccezione delle API di condivisione in prossimità.

Se non hai già un account Microsoft e vuoi usarne uno, registrati in account.microsoft.com.

Se usi MSA come framework di autenticazione e identità per i tuoi utenti, devi poi registrare l'app in Microsoft seguendo le istruzioni nel portale di registrazione delle applicazioni. (Se non hai un account per sviluppatore Microsoft, devi prima di tutto crearne uno). Dovresti ricevere una stringa di ID client per l'app. Assicurati di ricordare il percorso o salvala. Dovrai usarla in seguito durante l'onboarding di Graph Notifications. Tieni presente che un'app che usa l'autenticazione MSA deve essere registrata come applicazione Live SDK, come illustrato di seguito.

Se stai scrivendo un'app che usa AAD come framework di autenticazione e identità per l'account aziendale o dell'istituto di istruzione, devi registrare l'app tramite le Librerie di autenticazione di Azure Active Directory per ottenere l'ID client, come illustrato di seguito. Quando si crea una nuova registrazione dell'app, sono necessarie alcune autorizzazioni per usare Graph Notifications e altre funzionalità della piattaforma del dispositivo connessa. Troverai altre informazioni più avanti.

• Aggiungi l'autorizzazione per l'accesso utente come indicato di seguito.
• Aggiungi le autorizzazioni per Command Service per le informazioni sul dispositivo, come indicato di seguito.
• Aggiungi l'autorizzazione per Graph Notifications nelle API Activity Feed Service, come indicato di seguito.
• Al termine, se stai scrivendo un'applicazione multipiattaforma che include un'app UWP in esecuzione in Windows, assicurati di aggiungere l'autorizzazione per il servizio di notifica Windows, come indicato di seguito.

Devi quindi eseguire l'onboarding in Microsoft Windows Dev Center per ottenere l'accesso alla piattaforma dispositivi connessi per l'integrazione con le esperienze tra dispositivi, incluso l'uso di Graph Notifications. Se hai già eseguito questa operazione, passa alla sezione successiva.

Registrare l'app in Microsoft Windows Dev Center per le esperienze tra dispositivi

Devi poi registrare l'app per la funzionalità per le esperienze tra dispositivi del dashboard per sviluppatori Microsoft. Si tratta di una procedura diversa dalla registrazione dell'app per MSA e AAD, descritta nei passaggi precedenti. L'obiettivo principale di questo processo è eseguire il mapping delle identità di app specifiche della piattaforma con un'identità di app multipiattaforma riconosciuta dalla piattaforma dispositivi connessi e allo stesso tempo autorizzare Microsoft Graph Notifications all'invio delle notifiche usando i servizi di notifica push nativi corrispondenti a ogni piattaforma del sistema operativo. In questo caso, consente a Graph Notifications di inviare notifiche agli endpoint delle app UWP di Windows tramite il servizio di notifica Windows (WNS). Vai al dashboard di Dev Center, passa a Esperienze tra dispositivi dal riquadro di spostamento a sinistra e seleziona la configurazione di una nuova app per più dispositivi, come indicato di seguito.

Il processo di onboarding di Dev Center richiede la procedura seguente:

• Seleziona le piattaforme supportate: seleziona le piattaforme in cui la tua app sarà presente e sarà abilitata per le esperienze tra dispositivi. Nel caso dell'integrazione con Graph Notifications, puoi selezionare Windows, Android e/o iOS, come indicato di seguito.

• Fornisci gli ID app: fornisci gli ID app per ogni piattaforma in cui la tua app è presente, come indicato di seguito.

Nota

Puoi aggiungere ID diversi (fino a dieci) per ogni piattaforma, ad esempio nel caso in cui ci siano più versioni della stessa app o addirittura app differenti, che devono essere in grado di ricevere le stesse notifiche inviate dal server applicazioni destinate allo stesso utente.

• Specifica o seleziona gli ID app dalle registrazioni delle app per MSA e/o AAD. Questi ID client corrispondenti alla registrazione dell'app in MSA o AAD sono stati ottenuti nei passaggi precedenti di registrazione delle app per MSA/AAD. come indicato di seguito.
• Le funzionalità di Graph Notifications e le altre funzionalità della piattaforma dispositivi connessi sfruttano tutte le piattaforme di notifica native sulle piattaforme principali per inviare notifiche agli endpoint dei client dell'app, nello specifico WNS (per la piattaforma UWP di Windows), GCM (per Android) e il servizio APNS (per iOS). Specifica le credenziali per queste piattaforme di notifica per abilitare Graph Notifications per il recapito delle notifiche per il tuo server applicazioni, al momento della pubblicazione di notifiche mirate agli utenti. come indicato di seguito.

Nota

Per le app UWP di Windows, l'abilitazione della notifica push WNS è un prerequisito per l'uso di Microsoft Graph Notifications. Vedi Panoramica di Servizi notifica Push Windows (WNS) per altri dettagli. Dopo aver completato il processo di onboarding, puoi quindi fornire le credenziali di push tramite Windows Dev Center alla piattaforma dispositivi connessi.

• L'ultimo passaggio consiste nel verificare il dominio dell'app tra dispositivi, che funge da processo di verifica per confermare che l'app abbia la proprietà di questo dominio che agisce come identità di app tra dispositivi per l'app registrata. come indicato di seguito.
  Ora si è tutti impostati con l'onboarding. Passa alla sezione successiva.

Devi quindi aggiungere Project Rome SDK al progetto e inizializzare la piattaforma dispositivi connessi. Se hai già eseguito questa operazione, passa alla sezione successiva.

Aggiungere l'SDK

Inserisci i riferimenti al repository seguenti nel file build.gradle nella radice del progetto.

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

Inserisci quindi la dipendenza seguente nel file build.gradle nella tua cartella del progetto.

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

Se vuoi usare ProGuard nell'app, aggiungi le regole ProGuard per queste nuove API. Creare un file denominato proguard-rules.txt nella cartella App del progetto e incollare il contenuto di ProGuard_Rules_for_Android_Rome_SDK.txt.

Nel file AndroidManifest.xml del progetto aggiungi le autorizzazioni seguenti all'interno dell'elemento <manifest> (se non sono già presenti). In questo modo l'app viene autorizzata a connettersi a Internet e ad abilitare l'individuabilità Bluetooth nel dispositivo.

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

Nota

Le autorizzazioni correlate a Bluetooth sono necessarie solo per usare l'individuabilità Bluetooth e non sono richieste per le altre funzionalità nella piattaforma dispositivi connessi. Inoltre, ACCESS_COARSE_LOCATION è richiesto solo per Android SDK 21 e versioni successive. Per Android SDK 23 e versioni successive, lo sviluppatore deve anche richiedere all'utente di concedere l'accesso alla posizione in fase di esecuzione.

Passa quindi alle classi di attività in cui vuoi aggiungere la funzionalità dispositivi connessi. Importa gli spazi dei nomi connecteddevices.

import com.microsoft.connecteddevices.*;

A seconda degli scenari implementati, potrebbero non essere necessari tutti gli spazi dei nomi. Potresti dover anche aggiungere altri spazi dei nomi Android nativi man mano che procedi.

Inizializzare la piattaforma dispositivi connessi

Prima di poter usare le funzionalità dei dispositivi connessi, la piattaforma deve essere inizializzata all'interno dell'app. I passaggi di inizializzazione devono essere eseguiti nel metodo onCreate o onResume della classe principale, perché sono necessari prima che possano essere messi in atto altri scenari di dispositivi connessi.

Devi creare un'istanza della classe Platform. Il costruttore Platform accetta tre parametri: Context per l'app, NotificationProvider e UserAccountProvider.

Il parametro NotificationProvider serve solo per determinati scenari. Se usi Microsoft Graph Notifications, è necessario. Per il momento lascialo impostato su null e scopri come abilitare l'SDK client per gestire le notifiche in ingresso incentrate sull'utente tramite i canali push nativi nella sezione successiva.

UserAccountProvider è necessario per fornire un token di accesso OAuth 2.0 per l'accesso dell'utente corrente alla piattaforma dispositivi connessi. Verrà chiamato alla prima esecuzione dell'app e alla scadenza di un token di aggiornamento gestito dalla piattaforma.

Per facilitare l'onboarding con la piattaforma per gli sviluppatori, sono disponibili implementazioni dei provider di account per Android e iOS. Queste implementazioni, incluse nell'esempio di provider di autenticazione, possono essere usate per ottenere il token di accesso di OAuth 2.0 e il token di aggiornamento per l'app.

Configurazione dell'autenticazione e della gestione degli account

La piattaforma dispositivi connessi richiede un token OAuth valido da usare durante il processo di registrazione. Puoi usare il tuo metodo preferito per generare e gestire i token OAuth. Tuttavia, per consentire agli sviluppatori di iniziare a usare la piattaforma, è stato incluso un provider di autenticazione come parte dell'app di esempio per Android, che genera e gestisce i token di aggiornamento per maggiore comodità.

Se preferisci implementare l'interfaccia ConnectedDevicesAccountManager manualmente, prendi nota delle informazioni seguenti:

Se usi un account Microsoft, dovrai includere gli ambiti seguenti nella richiesta di accesso: "wl.offline_access", "ccs.ReadWrite", "dds.read", "dds.register", "wns.connect", "asimovrome.telemetry" e "https://activity.windows.com/UserActivity.ReadWrite.CreatedByApp".

Se usi un account AAD, sarà necessario richiedere i seguenti destinatari: "https://cdpcs.access.microsoft.com", "https://cs.dds.microsoft.com", "https://wns.windows.com/" e "https://activity.microsoft.com".

Nota

Gli account Azure Active Directory (AAD) non sono supportati con le API Device Relay.

Se usi o meno l'implementazione connectedDevicesAccountManager fornita, se usi AAD devi specificare le autorizzazioni seguenti nella registrazione dell'app nel portale di Azure (portal.azure.com > azure Active Directory > Registrazioni app):

• Servizio feed attività Microsoft
  • Distribuire e modificare le notifiche utente per questa app
  • Leggere e scrivere attività dell'app nel feed attività degli utenti
• Servizio di notifica di Windows
  • Connettere il dispositivo al servizio di notifica Windows
• Servizio Microsoft Device Directory
  • Visualizzare l'elenco dei dispositivi
  • Essere aggiunto all'elenco di app e dispositivi
• Servizio comandi Microsoft
  • Comunicare con i dispositivi utente
  • Leggere i dispositivi utente

Nel codice seguente mSignInHelper fa riferimento a un MSAAccountProvider anch'esso inizializzato di seguito. Questa classe implementa l'interfaccia UserAccountProvider.

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.
        }
    }
});

A questo punto è possibile costruire un'istanza di Platform. Puoi inserire il codice seguente in una classe helper distinta.

// 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;
}

Nella classe principale, in cui viene inizializzato mSignInHelper, aggiungi il codice seguente.

private Platform mPlatform;

//...

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

Dovrai arrestare la piattaforma quando l'app non è più in primo piano.

mPlatform.shutdownAsync();

Infine, devi abilitare la tua app per ricevere le notifiche push. Se hai già eseguito questa operazione, passa alla sezione successiva.

Associare la piattaforma dispositivi connessi alla notifica push nativo per ogni piattaforma per dispositivi mobili

Come accennato in precedenza, i client dell'app devono fornire informazioni sulla pipeline di notifica push nativa usata per ogni piattaforma per dispositivi mobili all'SDK sul lato client e alla piattaforma dispositivi connessi durante il processo di registrazione, per consentire al servizio di notifica Graph di trasmettere notifiche a ogni endpoint dei client dell'app quando il server applicazioni pubblica una notifica destinata agli utenti tramite le API Microsoft Graph.

Nei passaggi precedenti hai inizializzato la piattaforma con un parametro null notificationProvider. In questo caso, devi costruire e passare un oggetto che implementa NotificationProvider. L'aspetto principale da notare è il metodo getNotificationRegistrationAsync, che deve restituire un'istanza di NotificationRegistration. NotificationRegistration ha la responsabilità di fornire alla piattaforma dispositivi connessi un token di accesso (e le informazioni correlate) per il servizio di notifica.

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");

Specifica questa registrazione nell'implementazione di NotificationProvider. La chiamata di inizializzazione di Platform deve quindi fornire alla piattaforma locale l'accesso al servizio di notifica push, consentendo alla tua app di ricevere dati da Microsoft Graph Notifications sul lato server.

Passare notifiche push in ingresso all'SDK client

A questo punto estendi la classe del servizio listener nativo (FirebaseMessagingService in questo caso, perché questa esercitazione usa Firebase Cloud Messaging) con un overload speciale del metodo onMessageReceived (il metodo di gestione delle notifiche).

Per motivi di conformità, sicurezza e ottimizzazioni potenziali, la notifica di Google Cloud Messaging in ingresso proveniente da Graph Notifications sul lato server potrebbe essere semplicemente un avviso che non contiene dati pubblicati inizialmente dal server applicazioni. Il recupero del contenuto effettivo della notifica pubblicato dal server applicazioni è nascosto dietro le API dell'SDK sul lato client. Per questo motivo, l'SDK può fornire un modello di programmazione coerente in cui il client dell'app passa sempre il payload in ingresso di Google Cloud Messaging all'SDK. Ciò consente all'SDK di determinare se si tratta o meno di una notifica per gli scenari della piattaforma dispositivi connessi (nel caso il client dell'app usi il canale nativo Google Cloud Messaging di Android per altri scopi) e a quale scenario/funzionalità corrisponde questa notifica in ingresso (Graph Notifications, Attività utente e così via). La logica specifica per la gestione dei diversi tipi di scenari può quindi essere eseguita dal client dell'app in seguito.

/**
* 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");
    }
}

La tua app è ora in grado di gestire le notifiche dalla piattaforma dispositivi connessi.

Inizializzare un canale di Graph Notifications

In generale, l'SDK consente alla tua app di sottoscrivere diversi canali per ricevere e gestire diversi tipi di dati utente, incluse notifiche di Graph Notifications, attività utente e altro ancora. Tutti questi dati sono archiviati e sincronizzati in UserDataFeed. UserNotification costituisce la classe e il tipo di dati corrispondenti a una notifica mirata all'utente inviata tramite Graph Notifications. Per consentire l'integrazione con Graph Notifications e iniziare a ricevere notifiche di tipo UserNotification pubblicate dal server applicazioni, per prima cosa dovrai inizializzare il feed dei dati utente creando uno UserNotificationChannel. Questa operazione deve essere gestita come il passaggio di inizializzazione della piattaforma descritto in precedenza: deve essere verificata e possibilmente rieseguita ogni volta che l'app passa in primo piano (ma non prima dell'inizializzazione della piattaforma).

Creare uno UserNotificationReader per ricevere notifiche di tipo UserNotification in ingresso e accedere alla cronologia di UserNotification

Dopo aver creato un riferimento a UserNotificationChannel, è necessario uno UserNotificationReader per consentire all'SDK di recuperare il contenuto effettivo della notifica dal server. Uno UserNotificationReader in questo caso consente al client dell'app di accedere a questo feed di dati, per ricevere il payload della notifica più recente tramite il listener di eventi o per accedere alla raccolta UserNotification completa utilizzabile come modello di visualizzazione della cronologia delle notifiche dell'utente.

Il codice seguente descrive i passaggi per creare un'istanza di un canale di notifica all'utente, creare un lettore di notifica all'utente e aggiungere un gestore eventi nel lettore di notifica all'utente che viene attivato quando la piattaforma dispositivi connessi completa ogni sincronizzazione e ha nuove modifiche da notificare.

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;
                }
            }
        });
    }
}

Ricezione di notifiche UserNotification

Nella sezione precedente è stato aggiunto un listener di eventi al lettore di notifica all'utente. Devi implementare questo listener di eventi per leggere tutte le nuove notifiche e gli aggiornamenti delle notifiche dal lettore e implementare la tua logica di business per gestire ognuna di queste nuove modifiche.

Suggerimento

Questo listener di eventi è il punto dove puoi gestire la logica di business principale e "utilizzare" il contenuto del payload delle notifiche basato sugli scenari in uso. Se usi la notifica non elaborata di WNS per costruire una notifica di tipo avviso popup locale nel centro notifiche a livello del sistema operativo o se usi il contenuto della notifica per aggiornare parte dell'interfaccia utente in-app, questo è il posto giusto per farlo.

Il codice seguente illustra come l'app di esempio sceglie di generare una notifica di tipo avviso popup locale per tutte le notifiche di tipo UserNotification in ingresso che sono Active e di rimuovere l'interfaccia utente della notifica corrispondente nella visualizzazione in-app se viene eliminata una notifica.

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);
        }
    }
}

Aggiornare lo stato di una notifica UserNotification esistente

Nella sezione precedente si è accennato al fatto che a volte una modifica di una notifica UserNotification ricevuta tramite il lettore potrebbe essere un aggiornamento dello stato di una notifica UserNotification esistente, indipendentemente dal fatto che sia contrassegnata come ignorata o come letta. In questo caso il client dell'app può scegliere come procedere, ad esempio abilitando Universal Dismiss tramite la rimozione della notifica visiva corrispondente in questo specifico dispositivo. Facciamo un passo indietro: il client dell'app spesso è quello che ha avviato questo aggiornamento della modifica di UserNotification, da un dispositivo diverso. Puoi scegliere quando aggiornare lo stato delle tue notifiche UserNotification, ma in genere vengono aggiornate quando la notifica visiva corrispondente viene gestita dall'utente in quel dispositivo o quando viene ulteriormente gestita dall'utente nel corso di un'esperienza in-app. Di seguito è riportato un esempio dell'aspetto del flusso: il server app pubblica una notifica destinata all'utente A. L'utente A riceve questa notifica sia sul PC che sul telefono in cui sono installati i client dell'app. L'utente fa clic sulla notifica nel PC e passa all'app per la gestione dell'attività corrispondente. Il client dell'app in questo PC chiamerà quindi l'SDK della piattaforma dispositivi connessi per aggiornare lo stato della notifica UserNotification corrispondente, in modo da sincronizzare questo aggiornamento tra tutti i dispositivi dell'utente. Gli altri client dell'app, dopo aver ricevuto questo aggiornamento dello stato in tempo reale, rimuoveranno quindi il messaggio, la notifica di tipo avviso popup o l'avviso visivo corrispondente dal centro notifiche o dall'area di notifica del dispositivo. Ecco come le notifiche vengono universalmente ignorate tra i dispositivi di un utente.

Suggerimento

La classe UserNotification fornisce attualmente due tipi di aggiornamenti di stato: puoi modificare UserNotificationReadState o UserNotificationUserActionState e definire la tua logica personalizzata riguardo a cosa deve accadere quando le notifiche vengono aggiornate. Ad esempio, puoi contrassegnare UserActionState come Activated o Dismissed e basarti su questo valore per implementare Universal Dismiss. In alternativa, o contemporaneamente, puoi contrassegnare ReadState come Read o Unread e in base a ciò determinare quali notifiche dovranno comparire nella visualizzazione della cronologia delle notifiche in-app. Il frammento di codice seguente illustra come contrassegnare UserNotificationUserActionState come Dismissed per una notifica.

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();
    }
}