Notifiche Push con Google Cloud Messaging

Molte app Android possono avere la necessità di usufruire delle cosiddette Push Notifications (o notifiche Push in italiano). Si tratta di una tecnologia che consente al destinatario di una notifica, di riceverla senza che esso debba eseguire un'esplicita operazione di scaricamento delle notifiche disponibile (secondo il più tradizionale schema pull).

L'implementazione di un meccanismo di notifiche push, e l'integrazione di esso all'interno di un'app Android, sarebbero operazioni complesse e proibitive se non
esistesse una piattaforma dedicata come Google Cloud Messaging.

Perchè usare Push Notifications?

Tipicamente, nelle applicazioni di rete basate sul protocollo HTTP, l'iniziatore del dialogo tra il client ed
il server è, solitamente, il client.

Immaginiamo una situazione applicativa in cui un server fornisca dati (news tematiche, articoli tecnici o altro ancora) ed un'app Android sia progettata
per usufruire del servizio. Supponiamo anche che i nuovi dati non vengano pubblicati con regolarità ma con tempistiche del tutto imprevedibili, più volte
al giorno o solo poche volte in un mese.

L'ottimizzazione di un'app del genere ruota attorno alla modalità scelta per verificare la disponibilità o meno di contenuti aggiornati. Come prima
ipotesi, potremmo pensare ad un accesso periodico al server, implementato mediante AlertManager. Una tecnica di questo genere, detta polling, ha come unico vantaggio la semplicità concettuale e realizzativa, ma presenta anche alcuni svantaggi. In primis, il client invia molte richieste, la
maggior parte delle quali non forniscono nuovi dati prodotti. Immaginiamo, ad esempio, che un client acceda al servizio remoto ogni 30 minuti, e che il server, per un qualche motivo, generi nuovi dati solo una volta nell'arco della giornata in esame. Avremmo fatto 2 accessi all'ora per un'unica fornitura di dati, sprecando traffico di rete ed energia. Un altro svantaggio è che la produzione di
nuovi dati dal server non viene comunicata tempestivamente al client. Supponiamo che il nostro client, collegandosi al server ogni 30 minuti, faccia un
accesso alle 10:00. Se il server fornisse i dati alle 10:01, essi perverrebbero al client solo con l'accesso delle 10:30, quasi con mezz'ora di ritardo.

Il meccanismo delle Push Notification funziona esattamente in maniera opposta al polling: il server sarà in grado di avvisare il client, in modo asincrono, al momento della
disponibilità di nuovi dati.

La gestione di questo meccanismo su Android può essere affidata ad un servizio chiamato Google Cloud Messaging (o GCM), che semplifica di molto l'onere implementativo.
Tale piattaforma è facilmente integrabile in Android mediante Google Play Services.

Google Cloud Messaging

Il meccanismo delle notifiche push, come vedremo, consente ad un'applicazione esterna di
influenzare il normale flusso di esecuzione delle nostre app.

Per questo motivi, d'ora in avanti parleremo di tre attori principali:

• l'app Android, intesa nella totalità delle installazioni che di essa sono state fatte nel mondo;
• l'applicazione esterna, che ha la necessità di inviare notifiche alle app Android interessate;
• GCM, che svolge il ruolo di mediatore tra i due attori precedentemente elencati.

Essenzialmente, l'applicazione esterna invierà le notifiche alla piattaforma GCM, la quale si occuperà di inoltrarle alle applicazioni destinatarie.

Affinchè tutto questo funzioni è necessario che il dispositivo mobile, alla prima esecuzione dell'app che starà in attesa delle notifiche push, si registri presso GCM e comunichi all'applicazione esterna il codice di registrazione ricevuto.

Pertanto il nostro progetto dovrà trattare tre tipi di token di informazione:

• il SENDER ID: conservato nell'app Android, verrà inviato in fase di registrazione a GCM;
• il REGISTRATION ID: un codice che GCM restituirà al client a seguito della registrazione. Il client, a sua volta, lo inoltrerà all'applicazione che invia le notifiche;
• la SERVER KEY: una chiave di autenticazione che l'applicazione esterna possiede, utilizzata per ogni richiesta di invio di notifiche a GCM.

Vedremo nel seguito che ogni volta che l'applicazione esterna dovrà inviare ad un client una notifica push, essa fornirà a GCM:

• le informazioni che costituiscono la notifica;
• la propria SERVER KEY per essere riconosciuto;
• i REGISTRATION ID dei dispositivi mobili che dovranno ricevere la notifica.

Prerequisiti e preparazione tecnica all'esempio

Prima di passare all'esempio pratico, è bene elencare gli strumenti di cui avremo bisogno, e che abbiamo già visto in precedenza:

• Google Play Services: il progetto Android deve esserne provvisto, procedendo come spiegato in una lezione precedente;
• progetto Google: dovremo avere a disposizione un progetto Google creato tramite Google Developers Console, come illustrato in una lezione precedente. Il Project Number assegnato al progetto costituirà il SENDER ID che l'app Android
  userà in fase di registrazione;
• configurazione del progetto Google: per prima cosa si dovranno attivare le API relative a GCM nella sezione APIs & Auth, denominate
  Google Cloud Messaging for Android. Successivamente, nella sezione Credentials, si dovrà creare una Public Access Key. Anche questo aspetto è stato già
  illustrato in una lezione precedente.

La differenza rispetto a quanto visto negli altri servizi Google è che questa volta non avremo bisogno di una chiave di tipo Android key, bensì di una Server key, che verrà usata dall'applicazione esterna per inviare le notifiche. Nella finestra di dialogo che si apre cliccando sul pulsante Create new Key, dovremo selezionare Server key, cerchiato in rosso nella figura seguente:

L'esempio

L'esempio proposto nelle lezioni seguenti mostrerà come utilizzare le notifiche push. Essp è composto da:

• un'app Android che si registra presso GCM e riceve notifiche push;
• una pagina PHP, rappresentante l'applicazione esterna, che deve inviare notifiche al client. Tale ruolo può essere interpretato con qualunque tecnologia basata sul protocollo HTTP. La leggibilità di PHP dovrebbe consentire, anche a chi non ha mai usato questo linguaggio, una facile interpretazione del codice.

Il meccanismo dell'esempio segue lo schema rappresentato in figura.

Osserviamolo soffermandoci sul significato delle frecce numerate:

1. all'apertura dell'applicazione, il client invia il SENDER ID a GCM, che consiste nel Project Number del progetto Google;
2. GCM, a registrazione avvenuta con successo, invia all'app il REGISTRATION ID, un codice alfanumerico piuttosto lungo;
3. l'app riceve il REGISTRATION ID e lo invia allo script remoto in PHP;
4. lo script PHP, appena ricevuto il REGISTRATION ID, potrà (in qualsiasi momento, in maniera asincrona) chiedere a GCM di inviare una notifica al client. Le informazioni che gli fornisce sono costutuite dal
   REGISTRATION ID per riconoscere il client, la SERVER KEY per identificare sé stesso ed il messaggio da inviare al client;
5. GCM invia la notifica push al client. Tale comunicazione verrà intercettata da un BroadcastReceiver che segnalerà l'evento con una notifica all'utente.

Nelle prossime lezioni vedremo l'implementazione pratica dell'esempio appena descritto, che sarà semplice ma mostrerà tutte le fasi fondamentali della comunicazione.