Guia de instruções: integração às Notificações do MS Graph (Windows UWP)

Com o SDK do lado do cliente das Notificações do Graph no Windows, o aplicativo UWP do Windows pode executar as etapas de registro necessárias para se tornar um ponto de extremidade de recebimento que recebe notificações publicadas do seu servidor de aplicativo direcionado a um usuário. O SDK, em seguida, é usado para gerenciar as notificações no lado do cliente, incluindo receber novos conteúdos de notificação que cheguem a esse cliente, gerenciando o estado das notificações e recuperando o histórico de notificações. Para obter mais informações sobre as Notificações do MS Graph e como elas permitem a entrega da notificação centrada em humanos, confira Visão geral de Notificações do Microsoft Graph

Confira a página Referência de API para obter links para os documentos de referência relevantes para cenários de notificação.

Configuração preliminar para acessar a Plataforma de Dispositivos Conectados a fim de usar as Notificações do Graph

Há algumas etapas necessárias para integração com as Notificações do Graph

• Registro de aplicativo na MSA ou no AAD
• Integração do Centro de Desenvolvimento para fornecer identidade do aplicativo multiplataforma e credenciais de notificação por push
• Adicionar o SDK e inicializar a Plataforma de Dispositivos Conectados
• Associar o serviço de notificação com a Plataforma de Dispositivos Conectados

Primeiro, você precisa concluir o registro do aplicativo no AAD e/ou na MSA. Se você tiver feito isso, vá para a próxima seção.

Registro de Autenticação no AAD e na MSA

O registro de autenticação na MSA (Conta Microsoft) ou no AAD (Azure Active Directory) é necessária para todos os recursos do SDK incluindo Notificações, exceto para as APIs de compartilhamento por proximidade.

Se você ainda não tiver uma conta Microsoft e quiser usar uma, registre-se em account.microsoft.com.

Em seguida, se está usando a MSA como a estrutura de identidade e autenticação para seus usuários, você deve registrar seu aplicativo com a Microsoft, seguindo as instruções o Portal de registro de aplicativo (se você não tem uma conta de desenvolvedor Microsoft, você precisa criar uma primeiro). Você deve receber uma cadeia de caracteres de ID do cliente para seu aplicativo. Lembre-se da localização dela ou salve-a. Posteriormente, isso será usado durante a integração das Notificações do Graph. Observe que um aplicativo usando a autenticação da MSA deve ser registrado como um aplicativo do Live SDK, conforme mostrado abaixo.

Se estiver escrevendo um aplicativo que use o AAD como estrutura de identidade e autenticação de conta corporativa ou de estudante, você deverá registrar o aplicativo por meio de bibliotecas de autenticação do Azure Active Directory para obter a ID do cliente, conforme mostrado abaixo. Ao criar um registro de aplicativo, existem algumas permissões necessárias para usar as Notificações do Graph e outros recursos da plataforma de dispositivos conectados. Veja abaixo.

• Adicione a permissão para entrada do usuário conforme mostrado abaixo.
• Adicione permissões do serviço de comando para obter informações de dispositivo, conforme mostrado abaixo.
• Adicione a permissão de Notificações do Graph nas APIs do Serviço de Feed de Atividades, conforme mostrado abaixo.
• No final, se você estiver escrevendo um aplicativo multiplataforma, incluindo um aplicativo UWP em execução no Windows, verifique se você adicionou a permissão do Serviço de Notificação do Windows, conforme mostrado abaixo.

Em seguida, deverá integrar com o Centro de Desenvolvimento do Microsoft Windows para obter acesso à Plataforma de Dispositivos Conectados, a fim de integrar com experiências entre dispositivos, incluindo o uso de Notificações do Graph. Se você tiver feito isso, vá para a próxima seção.

Registrar o aplicativo no Centro de Desenvolvimento do Microsoft Windows para experiências entre dispositivos

Em seguida, você precisará registrar o aplicativo para o recurso de experiências entre dispositivos do Painel do Desenvolvedor Microsoft. Este é um procedimento diferente do registro de aplicativo na MSA e no AAD, que foi abordado nas etapas acima. A meta principal desse processo é mapear as identidades de aplicativo específico da plataforma com uma identidade de aplicativo multiplataforma que seja reconhecida pela plataforma de dispositivos conectados e, simultaneamente, autorize as Notificações do Microsoft Graph a enviar notificações usando os serviços de notificação por push nativa correspondentes a cada plataforma de sistema operacional. Nesse caso, ele permite que as Notificações do Graph enviem notificações aos pontos de extremidade de aplicativo UWP do Windows por meio do WNS – Serviço de Notificação do Windows. Vá para o Painel do Centro de Desenvolvimento, navegue para Experiências entre Dispositivos no painel de navegação esquerdo e selecione configurar um novo aplicativo entre dispositivos, conforme mostrado abaixo.

O processo de integração do Centro de Desenvolvimento requer as seguintes etapas:

• Selecionar as plataformas compatíveis – selecione as plataformas em que o aplicativo terá uma presença e será habilitado para experiências entre dispositivos. No caso de integração de Notificações do Graph, você pode selecionar do Windows, do Android e do iOS. Conforme mostrado abaixo.

• Fornecer IDs do aplicativo – forneça IDs do aplicativo para cada plataforma em que seu aplicativo tem uma presença. Conforme mostrado abaixo.

Observação

Você pode adicionar IDs diferentes (até dez) por plataforma, caso você tenha várias versões do mesmo aplicativo ou até mesmo diferentes aplicativos que deseje que sejam capazes de receber as mesmas notificações enviadas pelo seu servidor de aplicativo, destinadas ao mesmo usuário.

• Forneça ou selecione as IDs do aplicativo dos registros de aplicativo na MSA e/ou no AAD. Essas IDs de cliente correspondentes ao registro do aplicativo na MSA ou no AAD foram obtidas nas etapas anteriores de registro do aplicativo no AAD ou na MSA acima. Conforme mostrado abaixo.
• As Notificações do Graph e outras funcionalidades da Plataforma de Dispositivos Conectados aproveitam cada das plataformas de notificação nativas em plataformas principais para enviar notificações para baixo até os pontos de extremidade de cliente do aplicativo, ou seja, WNS (para UWP do Windows), GCM (para Android) e APNS (para iOS). Forneça suas credenciais para essas plataformas de notificação para habilitar as Notificações do Graph a entregar as notificações para seu servidor de aplicativo quando você publicar notificações direcionadas ao usuário. Conforme mostrado abaixo.

Observação

Para aplicativos UWP do Windows, habilitar a notificação de envio por push do WNS é um pré-requisito para usar as Notificações do Microsoft Graph. Veja Visão geral do WNS para obter mais detalhes. Depois de concluir a integração, você pode, em seguida, fornecer as credenciais de push por meio do Centro de Desenvolvimento do Windows para a Plataforma de Dispositivos Conectados.

• A última etapa é verificar o domínio de aplicativo entre dispositivos, que serve como um processo de verificação para comprovar que seu aplicativo tem a propriedade desse domínio, que age como uma identidade do aplicativo entre dispositivos para o aplicativo registrado por você. Conforme mostrado abaixo.
  A integração está finalizada! Prossiga para a próxima seção.

Em seguida, você precisa adicionar o SDK do Project Rome ao seu projeto e inicializar a Plataforma de Dispositivos Conectados. Se você tiver feito isso, vá para a próxima seção.

Adicionar o SDK

Insira as referências de repositório a seguir no arquivo build.gradle na raiz do seu projeto.

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

Em seguida, insira a dependência a seguir para o arquivo build.gradle que está na pasta do projeto.

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

Se você quiser usar o ProGuard em seu aplicativo, adicione as regras ProGuard para essas novas APIs. Crie um arquivo chamado proguard-rules.txt na pasta Aplicativo do projeto e cole nele o conteúdo de ProGuard_Rules_for_Android_Rome_SDK.txt.

No arquivo AndroidManifest.xml do projeto, adicione as seguintes permissões dentro do elemento <manifest> (se eles ainda não estão presentes). Isso dá ao aplicativo permissão para se conectar à Internet e para habilitar a descoberta de Bluetooth no 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" />

Observação

As permissões de Bluetooth são necessárias apenas para usar a descoberta de Bluetooth; elas não são necessárias para os outros recursos da Plataforma de Dispositivos Conectados. Além disso, ACCESS_COARSE_LOCATION só é necessário nos SDKs do Android 21 e posterior. Nos SDKs do Android 23 e versões posteriores, o desenvolvedor também precisa solicitar ao usuário que permita acesso à localização em runtime.

Em seguida, vá para as classes de atividade em que você deseja adicionar a funcionalidade de dispositivos conectados. Importe os namespaces connecteddevices.

import com.microsoft.connecteddevices.*;

Dependendo de quais cenários implementar, você pode não precisar de todos os namespaces. Você também precisará adicionar outros namespaces nativos do Android conforme avança.

Inicializar a Plataforma de Dispositivos Conectados

Antes de quaisquer recursos de Dispositivos Conectados poderem ser usados, a plataforma deverá ser inicializada dentro do aplicativo. As etapas de inicialização devem ocorrer no método onCreate ou onResume de sua classe principal, porque eles são necessários antes que outros cenários de Dispositivos Conectados possam ocorrer.

Você deve criar uma instância da classe Platform. O construtor Platform usa três parâmetros: o Contexto para o aplicativo, um NotificationProvider e um UserAccountProvider.

O parâmetro NotificationProvider só é necessário para determinados cenários. Se você usar as Notificações do Microsoft Graph, ele será necessário. Deixe como null por enquanto e descubra como habilitar o SDK do cliente para lidar com as notificações de entrada centradas no usuário por meio de canais de envio por push nativo na próxima seção.

O UserAccountProvider é necessário para fornecer um token de acesso OAuth 2.0 para acesso do usuário atual à Plataforma de Dispositivos Conectados. Ele será chamado na primeira vez em que o aplicativo for executado e após a expiração de um token de atualização gerenciado por plataforma.

Para ajudar os desenvolvedores a integrarem com a plataforma mais facilmente, nós fornecemos implementações do provedor de contas para Android e iOS. Essas implementações, encontradas no exemplo de provedor de autenticação, podem ser usadas para obter o token de acesso OAuth 2.0 e atualizar o token para o aplicativo.

Configurar a autenticação e o gerenciamento de contas

A plataforma de dispositivos conectados exige que um token OAuth válido seja usado no processo de registro. Você pode usar seu método preferido para gerar e gerenciar os tokens OAuth. No entanto, para ajudar os desenvolvedores a começarem a usar a plataforma, incluímos um provedor de autenticação como parte do aplicativo de exemplo do Android que gera e gerencia os tokens de atualização para sua conveniência.

Caso queira você mesmo implementar a interface ConnectedDevicesAccountManager, anote as seguintes informações:

Se você estiver usando uma MSA, precisará incluir os seguintes escopos em sua solicitação de entrada: "wl.offline_access", "ccs.ReadWrite", "dds.read", "dds.register", "wns.connect", "asimovrome.telemetry" e "https://activity.windows.com/UserActivity.ReadWrite.CreatedByApp".

Se você estiver usando uma conta do AAD, precisará solicitar os seguintes públicos-alvo: "https://cdpcs.access.microsoft.com", "https://cs.dds.microsoft.com", "https://wns.windows.com/" e "https://activity.microsoft.com".

Observação

Não há suporte para contas do AAD (Azure Active Directory) com as APIs de retransmissão do dispositivo.

Não importa se você está usando a implementação ConnectedDevicesAccountManager fornecida ou não, se estiver usando o AAD, precisará especificar as seguintes permissões no registro do seu aplicativo no portal do Azure (portal.azure.com > Azure Active Directory > Registros de aplicativo):

• Serviço de Feed de Atividades da Microsoft
  • Entregar e modificar as notificações de usuário para este aplicativo
  • Ler e gravar atividade do aplicativo para o feed de atividades dos usuários
• Serviço de Notificação do Windows
  • Conecte seu dispositivo ao Serviço de Notificação do Windows
• Serviço de Diretório do Dispositivos da Microsoft
  • Veja sua lista de dispositivos
  • Ser adicionado à sua lista de dispositivos e aplicativos
• Serviço de Comando da Microsoft
  • Comunicar-se com dispositivos de usuário
  • Ler dispositivos de usuário

No código a seguir, mSignInHelper faz referência a um MSAAccountProvider, também inicializado abaixo. Essa classe fornecida implemente a interface 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.
        }
    }
});

Agora você pode construir uma instância de Plataforma. Talvez você queira colocar o código a seguir em uma classe auxiliar separada.

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

Em sua classe principal, em que mSignInHelper é inicializado, adicione o seguinte código.

private Platform mPlatform;

//...

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

Você deverá desligar a plataforma quando seu aplicativo sair do primeiro plano.

mPlatform.shutdownAsync();

Por fim, você precisa habilitar o aplicativo para receber notificações por push. Se você tiver feito isso, vá para a próxima seção.

Associe a Plataforma de Dispositivos Conectados com a notificação por push nativa para cada plataforma móvel.

Como mencionado anteriormente, os clientes do aplicativo precisam fornecer o conhecimento sobre o pipeline de notificação por push nativa que está sendo usado para cada plataforma móvel para o SDK do lado do cliente e a Plataforma de Dispositivos Conectados durante o processo de registro, para permitir que o serviço de Notificação do Graph espalhe as notificações para cada ponto de extremidade do cliente do aplicativo quando o servidor de aplicativo publica uma notificação direcionada ao usuário por meio de APIs do Microsoft Graph.

Nas etapas acima, você inicializou a plataforma com um parâmetro nullnotificationProvider. Aqui, você precisará construir e passar um objeto que implementa NotificationProvider. O mais importante é observar o método getNotificationRegistrationAsync, que deve retornar uma instância de NotificationRegistration. O NotificationRegistration é responsável por fornecer à Plataforma de Dispositivos Conectados um token de acesso (e informações relacionadas) para o serviço de notificação.

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

Entregue esse registro em sua implementação de NotificationProvider. Em seguida, a chamada de inicialização da Plataforma deve fornecer à Plataforma local acesso ao serviço de notificação por push, permitindo que o aplicativo receba dados do lado do servidor das Notificações do Microsoft Graph.

Passar as notificações por push de entrada para o SDK do cliente

Agora, estenda sua classe de serviço de ouvinte nativo (FirebaseMessagingService nesse caso, pois este tutorial usa o Firebase Cloud Messaging) com uma sobrecarga especial do método onMessageReceived (o método de manipulação de notificações).

Devido a segurança, conformidade e possíveis otimizações, a notificação do Google Cloud Messaging de entrada proveniente do lado do servidor das Notificações do Graph pode ser um toque shoulder, que não contém nenhum dado inicialmente publicado pelo servidor do aplicativo. A recuperação do conteúdo de notificação propriamente dito publicado pelo servidor de aplicativos está oculta atrás de APIs do SDK do lado do cliente. Por isso, o SDK pode fornecer um padrão de programação consistente em que o cliente do aplicativo sempre passa o conteúdo do Google Cloud Messaging de entrada para o SDK. Isso permite que o SDK determine se essa é uma notificação para cenários de plataforma de dispositivo conectado ou não (caso o canal do Google Cloud Messaging nativo do Android seja usado pelo cliente do aplicativo para outros fins) e a qual cenário/funcionalidade essa notificação de entrada corresponde (Notificações do Graph, Atividade do Usuário etc.). Então, depois disso, o aplicativo cliente pode executar lógicas específicas sobre o tratamento de diferentes tipos de cenários.

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

Seu aplicativo agora pode lidar com notificações da Plataforma de Dispositivos Conectados.

Inicializar um canal de Notificação do Graph

Em um alto nível, o SDK permite que seu aplicativo assine diferentes canais para receber e gerenciar diferentes tipos de dados do usuário – incluindo Notificações do Graph, Atividades do Usuário e muito mais. Todos eles são armazenados e sincronizados no UserDataFeed. UserNotification é o tipo de classe e de dados correspondente a uma notificação direcionada ao usuário enviada por meio das Notificações do Graph. Para integrar com o gráfico de notificação e começar a receber UserNotification publicada pelo seu servidor de aplicativo, você primeiro precisará inicializar o feed de dados do usuário criando um UserNotificationChannel. Você deve tratar isso como a etapa de inicialização da plataforma acima: ela deve ser verificada e possivelmente refeita sempre que o aplicativo vem ao primeiro plano (mas não antes da inicialização da plataforma).

Criar um UserNotificationReader para receber UserNotifications de entrada e acessar o histórico de UserNotification

Uma vez que você referencia um UserNotificationChannel, é necessário um UserNotificationReader para permitir que o SDK busque o conteúdo da notificação propriamente dita do servidor. Nesse caso, um UserNotificationReader permite o acesso do cliente do aplicativo a esse feed de dados – para receber o conteúdo da notificação mais recente por meio do ouvinte de eventos ou para acessar a coleção UserNotification completa que pode ser usada como modelo de exibição do histórico de notificações do usuário.

O código a seguir mostra as etapas para criar uma instância de um canal de notificação do usuário, criar um leitor de notificação do usuário e adicionar um manipulador de eventos no leitor de notificação do usuário que é disparado quando a Plataforma de Dispositivos Conectados conclui cada sincronização e tem novas alterações sobre as quais notificar você.

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

Receber UserNotifications

Na seção acima, podemos ver que um ouvinte de eventos é adicionado ao leitor de notificação do usuário. Você deve implementar esse ouvinte de eventos para ler todas as novas notificações e atualizações de notificação do leitor. Deve também implementar sua própria lógica de negócios para lidar com cada uma dessas novas alterações.

Dica

É nesse ouvinte de eventos que você pode manipular a lógica de negócios principal e "consumir" o conteúdo da sua notificação com base em seus cenários. Se você está usando notificação bruta do WNS para construir uma notificação do sistema local na central de ações no nível do sistema operacional ou se você usa o conteúdo da notificação para atualizar algumas interfaces do usuário no aplicativo, esse é o lugar para fazer isso.

O código a seguir mostra como o aplicativo de exemplo escolhe gerar uma notificação do sistema local para todas as UserNotification de entrada que estão ativas e remover a interface do usuário de notificação correspondente no modo de exibição no aplicativo se uma notificação é excluída.

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

Atualizar o estado de uma UserNotification existente

Na seção anterior, mencionamos que, às vezes, uma alteração de UserNotification recebida por meio do leitor poderia ser uma atualização de estado em uma UserNotification existente – independentemente de ela estar sendo marcada como ignorada ou como lida. Nesse caso, o cliente do aplicativo pode decidir o que fazer, assim como habilitar a dispensa universal, removendo a notificação visual correspondente nesse dispositivo específico. Dando um passo para trás, seu cliente de aplicativo costuma ser aquele primeiro que iniciou esta atualização de alteração UserNotification – de um dispositivo diferente. Você pode escolher a hora para atualizar o estado das UserNotifications, mas geralmente eles são atualizados quando a notificação visual correspondente é manipulada pelo usuário nesse dispositivo ou a notificação é subsequentemente manipulada pelo usuário em alguma experiência no aplicativo habilitada por você. Aqui está um exemplo de como seria o fluxo: o servidor de aplicativos publica uma notificação direcionada ao usuário A, o qual recebe essa notificação no computador e telefone nos quais os clientes do aplicativo estão instalados. O usuário clica na notificação no PC e busca no aplicativo para desempenhar a tarefa correspondente. O cliente do aplicativo neste PC, em seguida, chamará no SDK da Plataforma de Dispositivos Conectados para atualizar o estado da UserNotification correspondente para que essa atualização seja sincronizada em todos os dispositivos deste usuário. Os outros clientes de aplicativo, ao receber esse estado de atualização em tempo real, removerão em seguida o alerta visual/mensagem/notificação do sistema correspondente do centro de notificações/bandeja de notificação/central de ações do dispositivo. É assim que as notificações são ignoradas universalmente em todos os dispositivos do usuário.

Dica

A classe UserNotification atualmente fornece 2 tipos de atualizações de estado – você pode modificar o UserNotificationReadState ou o UserNotificationUserActionState e definir sua própria lógica para o que deve acontecer quando as notificações são atualizadas. Por exemplo, você pode marcar UserActionState como Ativado ou Ignorado dinamizar esse valor para implementar a dispensa universal. Como alternativa ou simultaneamente, você pode marcar ReadState como lido ou não lido e, com base nisso, determinar quais notificações devem aparecer na exibição de histórico de notificações no aplicativo. O snippet de código mostra como marcar o UserNotificationUserActionState de uma notificação como Ignorado.

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