Analisi e sviluppo del sistema di notifiche push per un'applicazione mobile multipiattaforma

Il servizio Azure di Microsoft offre una suite di prodotti molto ampia.
Nel progetto sono stati utilizzati i servizi Notification Hubs e App Service: questi sono stati usufruiti con piani di abbonamento gratuiti.
Il servizio App Service non è indispensabile, in quanto è stato utilizzato per caricare il backend locale e renderlo disponibile online; pertanto, l'azienda non deve farsi carico di questo specifico servizio di Azure.

Invece, il servizio Notification Hubs risulta fondamentale, in quanto rappresenta il fulcro dell'intera infrastruttura che garantisce il funzionamento della ricezione delle notifiche push. Il piano base gratuito utilizzato durante lo stage è limitante, in quanto consente, nel namespace dell'hub di notifica, di fissare a 500 il tetto massimo di installazioni dei dispositivi. Inoltre, possono essere inviate al massimo un milione di notifiche push.

Quindi, nel contesto aziendale va preventivato che si dovrà usufruire del servizio Notification Hubs mediante piani di abbonamento a pagamento, per poter gestire una mole maggiore di dispositivi e garantire un corretto funzionamento del servizio di notifica.

Le motivazioni della scelta

Gestire tutti i dettagli implementativi, a livello di codice, di un PNS [G] particolare, garantisce una sua migliore gestione e maggiore specializzazione. D'altronde, questo lavoro diventa difficile da gestire nel momento in cui le piattaforme con cui comunicare sono più di una, in quanto richiederebbe maggiori risorse in termini temporali. Inoltre, l'invio di notifiche push richiede un'infrastruttura complessa che non è correlata alla logica di business principale dell'applicazione.

I problemi principali che si affrontano con l'implementazione diretta dei PNS [G] sono molteplici [18]:

• il backend richiede una logica dipendente dalla piattaforma, e la complessità aumenta con l'aumentare del numero di piattaforme da gestire;
• le linee guida affermano che è necessario aggiornare i token di dispositivo ad ogni avvio dell'applicazione. Ciò significa che se il numero di dispositivi da raggiungere è considerevole, allora l'infrastruttura intera non riuscirebbe ad ottimizzare il traffico che verrebbe a generarsi, fallendo nell'obiettivo di garantire una scalabilità orizzontale;
• il backend deve mantenere un registro per salvare tutti i dispositivi ed associarli a gruppi di interesse (tag), e questo carico di lavoro aumenta i tempi di produzione e i costi di manutenzione del codice;
• monitorare e fare la telemetria di tutti i dati è molto difficile.

Per ovviare a questi problemi, è stato scelto l'utilizzo di Azure Notification Hubs [28], in quanto:

• supporta tutte le piattaforme push e la complessità dellec omunicazioni con i PNS [G] viene astratta, offrendo un'interfaccia semplice e comune;
• è compatibile con qualsiasi backend;
• garantisce scalabilità grazie all'infrastruttura ben progettata, e quindi un invio istantaneo delle notifiche;
• i dispositivi possono essere associati a tag, che rappresentano utenti specifici o gruppi di interesse;
• ogni dispositivo può avere modelli di notifica non solo nativi della piattaforma, ma anche personalizzabili;
• fornisce un servizio di telemetria ben equipaggiato.

Il fatto che Azure sia un prodotto Microsoft spinge ulteriormente a prendere in definitiva questa decisione, in quanto l'azienda utilizza linguaggi e servizi della casa di Redmond. Questa scelta aiuterà gli sviluppatori aziendali, che riutilizzeranno parte del codice sorgente del prototipo, a risparmiare tempo nell'apprendimento di Azure Notification Hubs.