Guest post: Gestire le notifiche push di una Universal Windows app con i Notification Hub di Azure


Questo post è stato scritto da Matteo Pagani, Support Engineer in Microsoft per il programma AppConsult

Le notifiche push sono uno dei sistemi più diffusi per gestire la comunicazione asincrona tra un client e un server. Con questo meccanismo il controllo sulla presenza di nuovi dati o informazioni viene spostato dal client (che dovrebbe mantenere una comunicazione continua verso il server, con conseguente impatto sulla batteria e sul consumo di dati) al server (che, invece, si limita a notificare il client quando c’è qualche novità).

L’importanza delle notifiche push, inoltre, assume maggiore rilevanza in ambito mobile, in quanto permettono di comunicare con un’applicazione anche quando questa non è in esecuzione, andando a sopperire al fatto che quasi tutte le principali piattaforme non consentono alle applicazioni di girare indiscriminatamente in background, con lo scopo di preservare la durata della batteria e le performance del sistema operativo. Certo, esistono dei meccanismi per gestire queste situazioni anche senza le notifiche push (pensiamo, ad esempio, ai background task della Universal Windows Platform, citati nel precedente post), ma non sono adatti a soddisfare qualsiasi scenario.

Prendiamo, come esempio, un’applicazione dedicata al calcio. Se volessimo comunicare all’utente, in maniera tempestiva, ogni qualvolta la sua squadra del cuore ha segnato, le notifiche push sarebbero l’unico meccanismo che ci permetterebbe di implementare questo scenario, in quanto:

  1. L’evento (in questo caso, il gol) viene scatenato dall’esterno e non gestito localmente all’interno dell’applicazione.
  2. Si tratta di un evento asincrono e “imprevedibile”: nessuno dei trigger supportati dai background task ci permetterebbe di gestire questo scenario, dato che la maggior parte sono legati ad eventi di sistema (presenza di connettività, blocco del telefono, ecc.) o a vincoli temporali (ad esempio, controlli periodici).

Le notifiche push permettono di soddisfare al meglio scenari di questo tipo, proprio perché vengono generate lato server (e quindi possono gestire eventi indipendenti dall’applicazione) e non hanno vincoli temporali (il canale di comunicazione rimane sempre attivo, quindi fintanto che non ci sono problemi di connettività le notifiche vengono spedite e ricevute senza problemi).

L’architettura delle notifiche push

Nel corso di questo post parleremo, in dettaglio, del funzionamento delle notifiche push nel mondo Windows, ma l’architettura generale è molto simile per tutte le principali piattaforme mobile. Tale architettura prevede il coinvolgimento di tre attori:

  1. Il client, ovvero l’applicazione mobile: si tratta dell’app che riceverà le notifiche push.
  2. Il server, ovvero l’applicazione che si farà carico di generare la notifica push.
  3. Un servizio cloud, che si fa carico di fare da tramite tra il client e il server e che viene fornito e gestito, solitamente, dal produttore della piattaforma mobile. Nel caso di Windows, questo servizio si chiama Windows Push Notification Service (WNS). Ogni qualvolta un’applicazione Windows o Windows Phone vuole sfruttare le notifiche push, questa si registra presso il WNS, il quale genererà un canale di comunicazione, rappresentato da un url. Dall’altro lato del canale si trova il server: ogni qualvolta vuole inviare una notifica push verso il device, dovrà inviare un pacchetto con una struttura ben precisa a tale url, sfruttando il comando POST del protocollo HTTP. Il WNS si farà carico di ricevere il pacchetto e inoltrarlo al device corretto e di restituire al server i dettagli dell’esito dell’operazione (notifica ricevuta, notifica non ricevuta per problemi di connettività, ecc.)

Tale architettura fa sì che l’invio di una notifica push da parte del server sia un’operazione molto semplice da implementare e, soprattutto, agnostica rispetto a qualsiasi piattaforma o tecnologia: trattandosi di un normale pacchetto HTTP inviato tramite una POST, è possibile aggiungere il supporto alle notifiche push in qualsiasi applicazione server, indipendentemente dalla tipologia (web, desktop, servizio, ecc.) e dalla tecnologia sottostante (.NET, Java, PHP, Ruby, etc.)

I Notification Hub di Azure

Nonostante l’architettura base di invio delle notifiche push sia molto semplice, richiede comunque un certo lavoro da parte dello sviluppatore per realizzare l’infrastruttura server necessaria. Nello specifico, è importante gestire una serie di requisiti fondamentali:

  1. Tutti i principali servizi cloud (incluso il WNS) implementano un meccanismo di sicurezza, per evitare che chiunque possa inviare notifiche push ai device semplicemente conoscendo l’URL del canale. Di conseguenza, lato server occorre gestire l’autenticazione a tali servizi. Il WNS, ad esempio, sfrutta il protocollo oAuth: nel momento in cui l’applicazione viene registrata sullo Store, vengono fornite una serie di credenziali per l’autenticazione. Se le credenziali vengono validate dal WNS si riceve in ritorno un token , da includere in tutte le chiamate successive al WNS: senza tale token, le chiamate non andranno a buon fine.
  2. Il server deve gestire l’elenco di tutti i dispositivi che si sono registrati per ricevere le notifiche push, con il relativo canale, memorizzandoli ad esempio in un database. Tale elenco, infatti, è indispensabile nel momento in cui il server vuole inviare una notifica a tutti i dispositivi che hanno installato e avviato l’applicazione. Opzionalmente, inoltre, potreste avere la necessità di memorizzare, oltre al canale, informazioni addizionali che vi permettano di identificare un singolo device o un gruppo di device. Ritornando all’esempio dell’applicazione calcistica di prima, probabilmente la notifica push relativa al gol segnato da una squadra dovrà essere inviata solamente agli utenti che hanno aggiunto tale squadra tra le preferite.
  3. L’applicazione server deve farsi di carico di gestire la logica di registrazione dei dispositivi ed evitare, ad esempio, che vengano registrati due dispositivi con lo stesso canale o che rimangano memorizzati dei dispositivi “orfani” (ovvero per i quali il canale non è più valido).

I Notification Hub sono uno dei tanti servizi di tipo PaaS (Platform as a Service) disponibili su Azure: con questo termine, si indicano tutti quei servizi cloud già “pronti” per essere utilizzati dagli sviluppatori, senza che si debbano preoccupare di gestire l’infrastruttura sottostante (manutenzione dell’hardware, aggiornamento del sistema operativo e del software, ecc.).

I Notification Hub sono un prezioso alleato per risolvere in un colpo solo tutte le complessità elencate poco fa:

  1. L’autenticazione viene gestita direttamente dal servizio: è sufficiente, nella configurazione, specificare le credenziali di autenticazione fornite dal servizio di notifiche push.
  2. Il servizio si fa carico di gestire l’elenco di tutti i dispositivi che si sono registrati per ricevere notifiche push. Inoltre, i device possono essere associati ad uno o più tag, ovvero delle parole chiave che possono essere utilizzate per raggrupparli in categorie. Ad esempio, l’applicazione sportiva potrebbe gestire un tag per ogni squadra di calcio e associarlo ad ogni device nel quale l’utente ha scelto tale squadra come preferita.
  3. Il servizio gestisce, in automatico, la logica necessaria per una corretta gestione dei dispositivi: ad esempio, in caso di canale già esistente, si farà carico di aggiornare la registrazione già esistente invece che crearne una nuova.

I Notification Hub, inoltre, hanno una caratteristica che li rende particolarmente adatti per scenari complessi: sono cross-platform, ovvero consentono di gestire dispositivi (e il relativo invio di notifiche) Windows, iOS, Android, ecc. Riprendendo l’esempio precedente, la vostra applicazione calcistica potrebbe essere disponibile per tutte le principali piattaforme: nel momento in cui una squadra ha segnato, sarete in grado, lato server, di inviare un’unica notifica a tutti gli utenti che hanno indicato tale squadra come preferite, indipendentemente dal fatto che stiano usando uno smartphone Windows Phone o un iPhone.

Per questo motivo, Microsoft mette a disposizione un SDK per interagire con i Notification Hub compatibile con le principali piattaforme e tecnologie, così da poterli facilmente integrare in qualsiasi scenario.

Nel corso di questo post, vedremo come farlo all’interno di un’applicazione Windows 10.

Creare un Notification Hub

I Notification Hub fanno parte dei servizi offerti dalla tecnologia Service Bus di Azure, che include, tra le altre, strumenti come Queue, Event Hub e Topic: si tratta, semplificando, di canali di comunicazione altamente scalabili che consentono di inviare e ricevere messaggi, anche ad una frequenza molto elevata.

Il punto di partenza per creare un Notification Hub, perciò, è accedere alla sezione del portale di Azure dedicata a Service Bus: ovviamente, vi servirà un account Azure valido, anche in modalità trial. Per il momento, Service Bus è gestibile solamente dal vecchio portale: non è ancora presente, infatti, nel nuovo portale in preview. Di conseguenza, dovrete fare login con il vostro account all’indirizzo http://manage.windowsazure.com.

All’interno della sezione chiamata Service Bus, premete il pulsante Create: ciò vi permetterà di creare un namespace, ovvero un “contenitore” all’interno del quale creare uno o più servizi. In realtà, i servizi di messaggistica e di Notification Hub sono mantenuti separati: una delle cose che vi sarà richiesta, infatti, è proprio la tipologia di servizio. Se scegliete Notification Hub, creerete un namespace all’interno del quale potrete aggiungere solamente servizi per le notifiche. La categoria Messaging, invece, vi consente di aggiungere uno qualsiasi dei servizi di messaggistica offerti da Service Bus.

Nel nostro caso, ovviamente, scegliamo Notification Hub: le altre informazioni richieste sono il nome del namespace (che costituirà la prima parte dell’indirizzo che verrà associato, ad esempio MyNotificationHub.servicebus.windows.net) e la regione di Azure in cui ospitarlo.

A questo punto abbiamo creato il namespace, che però sarà vuoto: dobbiamo creare il nostro primo Notification Hub, tramite il pulsante New posizionato in fondo alla pagina. Dovremo specificare il nome che vogliamo dare all’hub che, insieme all’indirizzo del namespace, lo identificherà in maniera univoca. Come impostazione predefinita, il Notification Hub viene creato sfruttando il piano gratuito, che offre 1 milione di notifiche push gratuite al mese e un massimo di 500 device registrati contemporaneamente. Esistono poi due piani a pagamento (Basic e Standard), nei quali questi limiti vengono progressivamente alzati (si arriva fino a 10 milioni di notifiche al mese e un numero illimitato di device registrati), e che offrono una serie di funzionalità più avanzate (come la possibilità di schedulare l’invio di notifiche o strumenti avanzati di telemetria). Troviamo un resoconto dettagliato delle caratteristiche dei vari piani all’indirizzo http://azure.microsoft.com/en-us/pricing/details/notification-hubs/

 

Il passo successivo è configurare il Notification Hub, così da poterlo usare con il servizio di notifiche push più adatto per la nostra applicazione. Nel nostro caso, andremo ad interagire con un’applicazione Windows 10, di conseguenza ci occuperemo di completare la configurazione relativa al supporto alle Universal Windows app.

Il primo passo è quello di recuperare le credenziali di accesso al WNS ed è indipendente dai Notification Hub: dovremmo seguire questa procedura anche se volessimo appoggiarci ad un’altra soluzione o farci carico noi di realizzarla. Per farlo, dobbiamo prima riservare un nome per la nostra applicazione Windows e associarlo: facciamo clic con il tasto destro sul nostro progetto in Visual Studio e, alla voce Store, scegliamo Associate app with Store. Dopo aver inserito le credenziali del nostro Microsoft Account legate al Dev Center, comparirà la lista di nomi che abbiamo già riservato: scegliamone uno o, in alternativa, riserviamone uno nuovo usando l’opzione in basso.

Dopo aver completato la procedura, dobbiamo portarci sul Dev Center, aprendo il browser all’indirizzo http://dev.windows.com. Entrando nella dashboard, troveremo tra le applicazioni recenti quella per cui abbiamo riservato il nome. Clicchiamoci sopra per accedere ai dettagli e, dal menu di sinistra, scegliamo la voce Push notifications dalla sezione Services.

Nella schermata che comparirà ci saranno descritte le varie opzioni disponibili per interagire con i servizi di notifica offerti da Microsoft. La sezione che interessa a noi è quella intitolata Windows Push Notification Services (WNS) and Microsoft Azure Mobile Services. La sezione sottostante, chiamata Microsoft Push Notification Service (MPNS), è infatti relativa al vecchio servizio di notifiche che veniva utilizzato nelle applicazioni Windows Phone 7.x e 8.0, il quale è ancora disponibile per retro compatibilità con le applicazioni già esistenti ma, a tutti gli effetti, da considerarsi deprecato in quanto sostituito dal WNS.

All’interno della pagina troveremo un link chiamato Live Services Site, evidenziato nella figura sottostante:

Clicchiamoci sopra per andare alla pagina dei servizi Live, in cui avremo accesso alle credenziali utilizzate per l’autenticazione. Nello specifico, quelle che servono a noi sono Package SID e Client secret.

Dopo che abbiamo preso nota di questi due valori, possiamo tornare sul portale di Azure e accedere alla sezione Configure del Notification Hub che abbiamo creato in precedenza. Tale sezione, tra le altre informazioni, offre la possibilità di indicare le credenziali di accesso per i principali servizi di notifiche push: oltre a quelli di Microsoft (WNS e MPSN), troviamo quelli di Google, Apple, Amazon e Baidu.

Nel nostro caso, ci interessa configurare la sezione chiamata Windows Notification Settings, all’interno della quale andare a specificare i Package SID e Client secret precedentemente recuperati, come nell’immagine seguente.

Gestire l’accesso al servizio da parte delle applicazioni

Abbiamo visto come un Notification Hub sia identificato dal namespace che lo contiene e da un nome univoco. Queste due informazioni, però, non sono sufficienti per consentire ad un’applicazione (sia essa client o server) di interagire con il servizio: per questi di sicurezza, infatti, le chiamate verso le API devono essere autenticate.

A questo scopo, i Notification Hub (ma, più generale, tutte le tipologie di servizi offerte da Service Bus) si basano sul concetto di Shared Access Signature, ovvero una chiave di accesso a cui possono essere legate differenti tipologie di permessi. Lo scopo di questo meccanismo è quello di consentire la distribuzione di tali chiavi a terze parti (ad esempio, se l’applicazione client e quella server sono sviluppate da due società differenti) senza, per questo, compromettere la sicurezza del servizio.

Una signature può avere tre tipologie di permessi (i quali possono anche essere combinati):

  • Manage: consente la gestione completa del servizio, garantendo l’accesso all’elenco dei dispositivi registrati, alla loro configurazione, ecc.
  • Send: consente il solo invio di notifiche push. E’ utilizzata tipicamente dall’applicazione server.
  • Listen: consente la sola sottoscrizione al Notification Hub. E’ utilizzata tipicamente dall’applicazione client.

Ogni signature è associata ad un nome univoco e le possiamo gestire all’interno della sezione Configure del servizio. Come impostazione predefinita, quando creiamo un Notification Hub vengono generate due chiavi:

  • Una con accesso completo (manage, send, listen) di nome DefaultFullSharedAccessSignature
  • Una per i client (con il solo permesso di listen) di nome DefaultListenSharedAccessSignature

Ogni signature è collegata a due chiavi di accesso (una primaria e una secondaria), che devono essere condivise con lo sviluppatore dell’applicazione. Il modo più semplice per condividere tali chiavi è tramite la relativa stringa di connessione. Analogamente a quando dobbiamo collegarci un database possiamo usare una stringa di connessione (ovvero una stringa che contiene tutte le informazioni necessarie per il collegamento, come l’indirizzo del server, la username, la password, ecc.), anche i Notification Hub mettono a disposizione una stringa di connessione per ogni signature, con tutte le informazioni che serviranno all’applicazione per effettuare il collegamento.

Possiamo trovarle nella dashboard del servizio, premendo il pulsante View connection strings, evidenziato nell’immagine seguente.

Ecco un esempio di stringa di connessione ad un Notification Hub:

Endpoint=sb://windows10samples.servicebus.windows.net/;SharedAccessKeyName=DefaultFullSharedAccessSignature;SharedAccessKey=DlbQZoLHpq49BNJbP9YmkRVPoN4jqCfnJZwt+vAHU24=

Il client: l’applicazione Windows 10

Ora che abbiamo configurato il Notification Hub, possiamo iniziare a integrarlo nell’applicazione Windows, che sarà il destinatario delle nostre notifiche. Per interagire con i Notification Hub abbiamo a disposizione un’apposita libreria, disponibile su NuGet, dal nome WindowsAzure.Messaging.Managed. Si tratta di una versione dell’SDK per Azure Service Bus semplificata e specifica per i client: non offre, infatti, alcuna API per la gestione di scenari server (come l’invio di notifiche o la gestione dei device registrati). Esiste una libreria più completa, che vedremo più avanti nel corso del post, che però non possiamo usare in questo scenario perché richiede la versione full del framework .NET e, di conseguenza, non è compatibile con la Universal Windows Platform.

Il primo passo per integrare il Notification Hub è quello di registrare il canale per le notifiche push: in realtà, si tratta di un’azione indipendente dal servizio di Azure. Si tratta, infatti, della procedura standard da utilizzare quando vogliamo registrare un’applicazione Windows a ricevere notifiche push:

private async void OnRegisterForNotificationsClicked(object sender, RoutedEventArgs e)

{

PushNotificationChannel channel = await PushNotificationChannelManager.CreatePushNotificationChannelForApplicationAsync();

if (channel != null)

{

    //gestisco il canale

}

}

La creazione del canale viene eseguita tramite il metodo CreatePushNotificationChannelForApplicationAsync() della classe PushNotificationChannelManager. Se la registrazione va a buon fine, ci viene restituito un oggetto di tipo PushNotificationChannel, che contiene tutte le informazioni sul canale appena creato.

Anche il secondo passaggio è parzialmente indipendente dai Notification Hub: una volta registrato il canale, infatti, dobbiamo comunicarne l’url alla nostra applicazione server, così che lo possa usare. In caso non ci appoggiassimo ai Notification Hub, la gestione di tale attività sarebbe a nostro carico: ad esempio, potremmo decidere di esporre un servizio REST che la nostra applicazione Windows 10 potrebbe contattare per comunicare le informazioni sul canale. Dato che, in questo caso, stiamo invece sfruttando i Notification Hub di Azure, possiamo utilizzare le API offerte dalla libreria appena installata.

Ecco come appare il flusso completo:

private async void OnRegisterForNotificationsClicked(object sender, RoutedEventArgs e)

{

PushNotificationChannel channel = await PushNotificationChannelManager.CreatePushNotificationChannelForApplicationAsync();

if (channel != null)

{

NotificationHub hub = new NotificationHub(“uwpsample”, ConnectionString);

await hub.RegisterNativeAsync(channel.Uri);

}

}

Semplice no? Abbiamo creato un oggetto di tipo NotificationHub che, nel costruttore, richiede il nome del servizio e la stringa di connessione (di cui abbiamo parlato nel paragrafo precedente). Dopodichè, è sufficiente chiamare il metodo RegisterNativeAsync() passando, come parametro, l’url del canale, contenuto all’interno della proprietà Uri dell’oggetto di tipo PushNotificationChannel.

Esiste, inoltre, un overload del metodo RegisterNativeAsync() che accetta un secondo parametro, ovvero una collezione di tag, che ci permettono di categorizzare il device e, di conseguenza, inviare notifiche push ad un sottoinsieme dei dispositivi registrati.

private async void OnRegisterForNotificationsClicked(object sender, RoutedEventArgs e)

{

PushNotificationChannel channel = await PushNotificationChannelManager.CreatePushNotificationChannelForApplicationAsync();

if (channel != null)

{

NotificationHub hub = new NotificationHub(“uwpsample”, ConnectionString);

await hub.RegisterNativeAsync(channel.Uri, new[] { “milan”, “juventus” });

}

}

Riprendendo l’esempio dell’applicazione sportiva, questo esempio di codice potrebbe essere utilizzato per gestire un dispositivo nel quale l’utente, all’interno dell’applicazione, abbia indicato Milan e Juventus come squadre preferite.

Il punto di forza di queste API è che si fanno carico di gestire, in automatico, l’eventuale aggiornamento del canale. Tra le best practice nell’utilizzo delle notifiche push, infatti, troviamo il fatto che l’applicazione dovrebbe, ad ogni avvio, richiedere l’apertura del canale: questo perché gli URL non sono immutabili, ma possono scadere e cambiare nel tempo. Di conseguenza, dovremmo farci carico di memorizzare (ad esempio, nello storage locale) l’url del canale e andare a registrarlo nuovamente sul server solo se questo è cambiato. Sfruttando l’SDK dei Notification Hub ciò non è necessario: il metodo RegisterNativeAsync() si farà carico, in automatico, di registrare un nuovo dispositivo o di aggiornare quello esistente, in base allo scenario.

Volendo, ancora prima di realizzare l’architettura lato server, i Notification Hub ci danno la possibilità di testare che il lavoro svolto fin qui sia corretto. Nel portale su Azure, infatti, troverete una voce chiamata Debug, che vi permetterà di inviare una notifica di test a tutti i device registrati (o ad un sottoinsieme, specificando uno o più tag).

.

In base alla piattaforma scelta e al tipo di notifica, la sezione body si popolerà con il contenuto standard del pacchetto relativo. Nel caso di notifiche per le piattaforme Windows, il pacchetto è rappresentato da un file XML, che contiene al suo interno le varie informazioni. Nell’immagine, possiamo vedere il template per l’invio di una notifica toast. Se abbiamo seguito i passaggi precedenti nel modo corretto, premendo il pulsante Send la nostra applicazione per Windows 10 dovrebbe ricevere una notifica toast, con all’interno il messaggio che abbiamo definito nel nodo text.

Il server: gestire i device e inviare le notifiche

Vediamo ora come implementare l’applicazione server, ovvero quello che interagirà con il Notification Hub per gestire i dispositivi registrati e per inviare le notifiche. Al momento, il requisito che abbiamo per sfruttare l’SDK apposita è che l’applicazione deve essere basata sulla versione full del framework .NET: per questo esempio, sfrutterò un’applicazione WPF, dato che ho maggiore famigliarità con lo sviluppo client e con lo XAML. Nulla vieta, ad esempio, di realizzare un’applicazione web basata su ASP.NET.

Il primo passo è di installare nell’applicazione la libreria NuGet dedicata, che si chiama WindowsAzure.ServiceBus. Rispetto a quella client trattata in precedenza, offre metodi aggiuntivi per inviare notifiche, gestire i dispositivi registrati, ecc.

Partiamo dall’operazione principale, ovvero inviare le notifiche.

private async void OnSendNotificationsClicked(object sender, RoutedEventArgs e)

{

string xml = @”<toast>

<visual>

<binding template=””ToastGeneric””>

<text>Hello insiders!</text>

<text>This is a notification from Notification Hub</text>

</binding>

</visual>

</toast>”;

 

NotificationHubClient client = NotificationHubClient.CreateClientFromConnectionString(ConnectionString, “uwpsample”);

await client.SendWindowsNativeNotificationAsync(xml);

}

Anche se con qualche differenza nel codice, il concetto base è lo stesso: le interazioni con il Notification Hub sono rese possibili dalla classe NotificationHubClient. Il modo più semplice per istanziarla è usare il metodo statico CreateClientFromConnectionString(), che accetta come parametri la stringa di connessione e il nome del Notification Hub.

Dopodichè troviamo diversi metodi per inviare notifiche, in base alla piattaforma di destinazione. Nel nostro caso, dato che stiamo interagendo con un’applicazione Windows 10, dobbiamo utilizzare il metodo SendWindowsNativeNotificationAsync() che accetta, come parametro, l’XML che descrive la notifica. In questo esempio, stiamo inviando una semplice notifica testa usando i nuovi adaptive template introdotti con la Universal Windows Platform.

Troviamo anche un metodo generico chiamato SendTemplateNotificationAsync(), che permette di inviare notifiche basate sul concetto di template. Anche se non sarà approfondito nel corso di questo post, vi consiglio di dare una lettura alla documentazione all’indirizzo https://msdn.microsoft.com/en-us/library/azure/dn530748.aspx: può risultare molto utile in caso di scenari avanzati, in quanto permette di gestire template per le notifiche che semplificano scenari di localizzazione, personalizzazione del contenuto o cross-platform.

In questo esempio, non abbiamo alcun specificato alcun criterio di selezione: di conseguenza, la notifica sarà inviata a tutti i dispositivi registrati nel nostro hub. Possiamo restringere l’invio sfruttando i tag, già nominati in precedenza. Esattamente come, lato client, avevamo a disposizione un overload del metodo di registrazione che ci permetteva di associare un device ad uno o più tag, qui possiamo sfruttare un overload del metodo di invio per specificare uno o più tag; la notifica sarà inviata solo ai dispositivi che sono associati ad esso.

Ecco un esempio di codice:

private async void OnSendNotificationsClicked(object sender, RoutedEventArgs e)

{

string xml = @”<toast>

<visual>

<binding template=””ToastGeneric””>

<text>Hello insiders!</text>

<text>This is a notification from Notification Hub</text>

</binding>

</visual>

</toast>”;

 

NotificationHubClient client = NotificationHubClient.CreateClientFromConnectionString(ConnectionString, “uwpsample”);

await client.SendWindowsNativeNotificationAsync(xml, new[] { “Milan” });

}

Gestire i device registrati

L’SDK completa, come anticipato in precedenza, vi offre anche la possibilità di gestire i device registrati all’interno del Notification Hub. Ad esempio, ecco come possiamo recuperare l’elenco di tutti i dispositivi registrati:

private async Task RefreshDevices()

{

NotificationHubClient client = NotificationHubClient.CreateClientFromConnectionString(ConnectionString, “uwpsample”);

CollectionQueryResult<RegistrationDescription> results = await client.GetAllRegistrationsAsync(0);

}

Il metodo GetAllRegistrationsAsync() (che richiede come parametro l’indice del primo device che vogliamo ottenere, passando 0 siamo in grado di recuperare l’elenco completo) ci restituisce una collezione di oggetti di tipo RegistrationDescription, ognuno dei quali rappresenta un device registrato. Tale classe ci offre una serie di proprietà che ci permettono di recuperare informazioni dettagliate sulla registrazione, come l’id, la data di scadenza del canale o i tag associati. In alternativa, possiamo anche filtrare i risultati per tag (tramite il metodo GetRegistrationsByTagAsync()) o per canale (tramite il metodo GetRegistrationsByChannelAsync()).

Infine, abbiamo a disposizione una serie di metodi per modificare la registrazione, cancellandola dall’hub o aggiornandone i dati. Ecco un esempio di cancellazione, gestita all’interno di una lista di device mostrata nell’interfaccia grafica:

private async void OnDeleteDeviceClicked(object sender, RoutedEventArgs e)

{

Button button = sender as Button;

RegistrationDescription device = (button.DataContext) as RegistrationDescription;

 

NotificationHubClient client = NotificationHubClient.CreateClientFromConnectionString(ConnectionString, “uwpsample”);

await client.DeleteRegistrationAsync(device);

}

La cancellazione viene effettuata tramite il metodo DeleteRegistrationAsync(), che accetta come parametro un oggetto di tipo RegistrationDescription.

Le notifiche push e Windows 10

Tramite l’uso dei Notification Hub, possiamo mettere in evidenza uno dei tanti vantaggi del nuovo modello di sviluppo introdotto dalle Universal Windows app di Windows 10. Dato che, rispetto al passato, non parliamo più di applicazioni separate (una per ogni piattaforma), ma di un unico binario che gira su tutte le piattaforme, anche il canale delle notifiche push sarà di conseguenza univoco.

Se lanciamo l’applicazione client sia sul nostro pc che sul telefono (usando l’emulatore o un telefono aggiornato alla preview di Windows 10 tramite il programma Insider), potremo notare che l’URL del canale sarà lo stesso. Di conseguenza, se proviamo ad inviare una notifica dalla sezione di debug del portale di Azure o dall’applicazione server, la vedremo arrivare sia sul pc che sul telefono contemporaneamente.

In conclusione

Nel corso di questo post abbiamo visto come integrare i Notification Hub di Azure all’interno di un’architettura basata sulle tecnologie Microsoft (sia lato server che client). E’ importante sottolineare, però, come la libreria citata nel corso dell’articolo sia disponibile per tutte le principali piattaforme. Di conseguenza, non importa se state sviluppando un’applicazione Android o iOS o se avete un server basato su .NET, Java o Ruby: i Notification Hub sono la soluzione che fa per voi se avete bisogno di gestire invii massivi di notifiche push.

Vi lascio, in conclusione, due link:

Happy coding!


Comments (0)

Skip to main content