VENDITE: 1-800-867-1389

Panoramica degli hub notifiche

Aggiornamento: settembre 2014

Gli hub di notifica di Windows Azure assicurano un'infrastruttura di semplice utilizzo che consente di inviare notifiche push mobili da qualsiasi back-end (nel cloud o in locale) a qualsiasi piattaforma mobile.

Con gli hub di notifica è possibile inviare facilmente notifiche push personalizzate multipiattaforma, eliminando i dettagli dei diversi sistemi di notifica tramite piattaforma (PNS). Con una sola chiamata all'API, è possibile raggiungere singoli utenti o interi segmenti di pubblico con milioni di utenti su tutti i dispositivi.

È possibile utilizzare gli hub notifiche per scenari sia aziendali che consumer. Ad esempio:

  • Inviare notifiche relative ad edizioni straordinarie a milioni di utenti con bassa latenza (gli hub di notifica utilizzano applicazioni Bing preinstallate su tutti i dispositivi Windows e Windows Phone).

  • Inviare coupon basati sulla posizione a segmenti di utenti.

  • Inviare notifiche di eventi a utenti o gruppi per applicazioni sportive/finanziarie/di gioco.

  • Inviare agli utenti notifiche relative ad eventi aziendali, come nuovi messaggi/messaggi di posta elettronica, e clienti potenziali.

  • Inviare password monouso richieste per l'autenticazione a più fattori.

Smartphone e tablet sono in grado di "notificare" agli utenti il verificarsi di un evento. Nelle applicazioni di Windows Store e Windows Phone, la notifica produce un avviso popup (una finestra non modale visualizzata nella parte superiore della schermata) o aggiornamenti dei riquadri sulla schermata iniziale. Analogamente, nei dispositivi Android e Apple iOS, le notifiche appaiono raggruppate in un riquadro di notifica facilmente accessibile dalla parte superiore della schermata.

Le notifiche push consentono ai back-end delle app di visualizzare informazioni aggiornate sui dispositivi mobili, anche quando l'app sul dispositivo non è attiva.

Le notifiche push vengono recapitate attraverso infrastrutture di piattaforme specifiche denominate sistemi di notifica tramite piattaforma (PNS, Platform Notification System). Un sistema PNS offre funzioni limitate (non fornisce, ad esempio, il supporto per la trasmissione o la personalizzazione) e i PNS specifici di piattaforma non hanno un'interfaccia comune. Per inviare una notifica a un'app di Windows Store, ad esempio, uno sviluppatore deve contattare i Servizi notifica Push Windows (WNS, Windows Push Notification Service). Per inviare una notifica a un dispositivo iOS, lo stesso sviluppatore deve contattare il servizio di notifiche push Apple (APNS, Apple Push Notification Service) e inviare nuovamente il messaggio. Il processo è simile per le app per Windows Phone 8 e Android.

A livello generale, i sistemi di notifica tramite piattaforma seguono tutti lo stesso modello:

  1. L'applicazione client contatta il sistema PNS per recuperare il proprio handle. Il tipo di handle dipende dal sistema. Per i servizi WNS, è un URI o un "canale di notifica", mentre per il servizio APNS è un token.

  2. L'applicazione client archivia l'handle nel back-end dell'app per un utilizzo successivo. Per i servizi WNS, il back-end è generalmente un servizio cloud. Per i servizi Apple, il sistema prende il nome di provider.

  3. Per inviare una notifica push, il back-end dell'app contatta il PNS utilizzando l'handle per individuare un'istanza di una specifica applicazione client.

  4. Il PNS inoltra quindi la notifica al dispositivo specificato dall'handle.

Hub di notifica

L'infrastruttura richiesta per implementare questo flusso è relativamente complessa e piuttosto distante dalla logica aziendale di base dell'app. Di seguito sono illustrate alcune delle principali difficoltà associate alla creazione di un'infrastruttura push su richiesta:

  • Dipendenza dalla piattaforma. Per poter inviare notifiche a dispositivi basati su piattaforme diverse, è necessario codificare nel back-end più tipi di interfacce. Non solo, infatti, i dettagli di livello base sono diversi, ma la presentazione stessa della notifica (riquadro, avviso popup o badge) dipende dalla piattaforma. Queste differenze determinano inevitabilmente un codice di back-end complesso e difficile da gestire.

  • Scalabilità. Il ridimensionamento di questa infrastruttura deve tenere in considerazione due aspetti:

    • In base alle linee guida del sistema PNS, i token di dispositivo devono essere aggiornati ogni volta che viene lanciata l'app. Questo comporta la produzione di un grande volume di traffico (e del conseguente accesso al database) solo per tenere aggiornati i token di dispositivo. Se il numero di dispositivi cresce (giungendo a qualche milione di unità), i costi per la creazione e la gestione dell'infrastruttura diventano piuttosto significativi.

    • La maggior parte dei sistemi PNS non supporta la trasmissione a più dispositivi. Per la trasmissione a milioni di dispositivi, quindi, è necessario effettuare milioni di chiamate ai sistemi PNS. La corretta scalabilità di queste richieste, pertanto, è un obiettivo difficile da raggiungere, poiché in genere gli sviluppatori desiderano tenere bassa la latenza totale (l'ultimo dispositivo a cui viene inviato il messaggio, ad esempio, dovrebbe ricevere la notifica non più di 30 minuti dopo l'invio della prima notifica, poiché altrimenti verrebbe annullato il presupposto essenziale delle notifiche push).

  • Routing. I PNS forniscono un modo per inviare un messaggio a un dispositivo. Nella maggior parte delle app, tuttavia, le notifiche sono destinate a utenti e/o gruppi di interesse (ad esempio, tutti i dipendenti assegnati a un determinato account cliente). Il back-end dell'app deve quindi mantenere un registro in cui i vari gruppi di interesse siano associati ai relativi token di dispositivo, in modo che le notifiche vengano indirizzate ai dispositivi corretti. Questo sovraccarico contribuisce inevitabilmente ad aumentare i tempi di produzione e i costi di manutenzione di un'applicazione.

  • Monitoraggio e telemetria. Tenere traccia e aggregare i risultati di milioni di notifiche non è semplice ed è normalmente un processo essenziale di qualsiasi soluzione che utilizzi notifiche push.

Gli hub notifiche semplificano notevolmente l'attività degli sviluppatori, evitando loro di gestire le difficoltà associate alle notifiche push. Gli hub notifiche utilizzano un'infrastruttura di notifiche push scalabile e completamente multipiattaforma, in grado di ridurre considerevolmente il codice specifico del push eseguito nel back-end dell'app. Implementano inoltre tutte le funzionalità di un'infrastruttura push. I dispositivi devono eseguire soltanto la registrazione dei propri handle PNS, mentre il back-end è responsabile dell'invio di messaggi indipendenti dalla piattaforma a utenti o gruppi di interesse, come illustrato nella figura seguente:

Hub di notifica

Gli hub notifiche assicurano un'infrastruttura push che offre i seguenti vantaggi:

  • Supporto multipiattaforma:

    • supporto di tutte le principali piattaforme mobili (Windows/Windows Phone, iOS, Android).

    • Nessun protocollo specifico di piattaforma. L'applicazione comunica solo con gli hub notifiche.

    • Gestione degli handle di dispositivo. Gli hub notifiche conservano il registro degli handle e il feedback proveniente dai PNS.

  • Compatibilità con qualsiasi back-end. Cloud o locale, .NET, PHP, Java, Node e così via.

  • Scalabilità. Gli hub notifiche garantiscono la scalabilità necessaria per inviare notifiche a milioni di dispositivi senza dover eseguire il partizionamento o la riprogettazione dell'architettura. Disponibilità in tutte le aree geografiche.

  • Ricca serie di modelli di implementazione. Associazione dei dispositivi a tag, che rappresentano utenti o gruppi di interesse logici.

    • Trasmissione: trasmissione quasi simultanea a milioni di dispositivi con una sola chiamata all'API.

    • Unicast/Multicast: push a tag che rappresentano singoli utenti, con tutti i relativi dispositivi, o a un gruppo più ampio, ad esempio formati separati quali tablet o telefoni.

    • Segmentazione: push a segmenti complessi definiti da espressioni tag (ad esempio, dispositivi a New York che seguono gli Yankees).

  • Personalizzazione. Ogni dispositivo può avere uno o più modelli, per una localizzazione e una personalizzazione basate sul dispositivo, che non incidono sul codice di back-end.

  • Protezione. Autenticazione SAS (Shared Access Secret) o federata.

  • Avanzata telemetria. Disponibile nel portale e a livello di programmazione.

  • Le notifiche push costituiscono un elemento essenziale delle modern app, poiché aumentano l'interesse dell'utente per le app consumer e l'utilità delle app aziendali.

  • Gli hub notifiche forniscono un'infrastruttura push di facile utilizzo, multipiattaforma e con scalabilità orizzontale, che consente di ridurre notevolmente il lavoro di scrittura e gestione del codice del back-end dell'app.

  • Possono inoltre essere utilizzati da qualsiasi back-end (cloud o locale) per inviare notifiche push a tutte le principali piattaforme mobili (Windows/Windows Phone, iOS, Android).

Di seguito sono riportati i riferimenti rilevanti per l'API gestita .NET relativa alle notifiche push:

Microsoft.WindowsAzure.Messaging.NotificationHub

Microsoft.ServiceBus.Notifications

Negli argomenti elencati di seguito vengono fornite informazioni sugli hub notifiche:

Pagina del servizio Hub notifiche di Windows Azure

Panoramica sulle notifiche push (app di Windows Store)

Servizio di notifiche push Apple

Notifiche push di Windows Azure

Google Cloud Messaging

Il documento è risultato utile?
(1500 caratteri rimanenti)
Grazie per i commenti inviati.
Mostra:
© 2014 Microsoft