Come funziona il Push Notification Service in Windows Phone 7 Series

header_logo Nel precedente post, abbiamo visto per grandi linee il principio di funzionamento del Push Notification Service di Windows Phone 7 Series.
In questo post, cercheremo di capire più in dettaglio come funziona il sistema.

A tale scopo, riprendiamo lo schema del post precedente:

PushNotification

Da questa immagine, emergono alcuni degli elementi fondamentali che contribuiscono all’architettura dell’intero sistema:

  1. direttamente sul device, compaiono 2 elementi interessanti come il push notification framework ed il push client. Il primo fornisce l’infrastruttura per gestire le notifiche mentre il secondo è il vero e proprio “proxy” per la gestione delle notifiche. 
  2. il secondo elemento è il Microsoft Push Notification Service, il cui scopo è quello di inviare la notifica al push client. Come vedremo più avanti, si tratta si server Microsoft (live) e, a quanto sembra, sono gli unici a poter inviare notifiche ai client.
  3. il terzo elemento della catena è rappresentato dal cloud service. Come vedremo in seguito, è questo l’elemento che genera le notifiche.

Ammetto che, questa immagine, rende relativamente poco il senso delle push notification. Io per primo ho fatto un po’ di fatica a capirne il giro completo.
Ma, una volta capito il giro, tutto diventa più semplice.

Partiamo innanzitutto dallo scopo delle notifiche: avendo eliminato la possibilità di eseguire applicazioni in background, c’è la necessità di fornire all’utente un meccanismo per essere avvisato di eventuali situazioni di interesse. Ad esempio, un utente può voler essere interessato ai cambiamenti di stato di una spedizione a lui destinata (tracking).

Sottolineo “fornire all’utente” in quanto, questa affermazione è decisamente importante per comprendere la filosofia delle notifiche. Lo vedremo in seguito.

Una volta compreso il perchè delle push notifications, cerchiamo di capire il come funziona l’itero meccanismo e dove si collocano i tre elementi dell’immagine vista in precedenza.

CHI avvia la richiesta di notifica, è una applicazione che è in running sul device. Nel caso dell’esempio del tracking, sarà l’applicazione fornita dalla compagnia di spedizioni che dovrà essere predisposta allo scopo (e questo ha delle implicazioni a livello di marketplace che vedremo in un post futuro).

Dunque, la nostra applicazione di tracking, dovrà aprire un push channel verso il push client del device. Questa operazione viene svolta grazie al push notification framework. Questa è, di fatto, l’operazione che predispone il device a ricevere delle specifiche notifiche. Il risultato di questa operazione di apertura del channel è, di fatto, la restituzione di un URI alla nostra applicazione. L’URI ricevuto avrà un formato simile a http://ns1.notify.live.net/… seguito da un identificativo univoco del device in uso.

Una volta ricevuto l’URI, la nostra applicazione dovrà comunicarlo ad un nostro server di back end che eroga il servizio. Ed questo rappresenta il cloud service dell’immagine di sopra. Quello che ho definito il “nostro server di back end”, nel nostro esempio relativo al tracking, sarà il server che già oggi firnisce queste informazioni al sito web a cui accediamo per controllare il tracking della nostra spedizione. Ovviamente, dovremmo intervenire per gestire queste nuove notifiche ma, come vedremo, l’intervento è di fatto limitato.

Siamo dunque arrivati al punto in cui, la nostra applicazione, invia al nostro server (in the cloud) l’uri ricevuto dal push client. Il modo in cui inviamo questa notifica è a nostra cura. Nel senso che possiamo possiamo decidere noi il channel con cui effettuare questa comunicazione, gestire noi l’autenticazione etc.

A questo punto, tutto si sposta sul nostro server che, al verificarsi dell’elemento da notificare, dovrà effettuare delle operazioni. Nel caso specifico dell’esempio, al verificarsi di un cambio di stato della nostra spedizione, il nostro server dovrà notificare al Microsoft Push Notification Service, attraverso l’URI ricevuto dal device, i dati da notificare al client. Lo farà attraverso un HTTP Post dei dati formattati con uno schema definito.

A questo punto, il Microsoft Push Notification Service invierà al push client del device la nostra notifica con le informazioni che abbiamo deciso di inviare. La notifica può essere di uno dei 3 tipi consentiti (Tile, Toast o Raw). Una volta ricevuta la notifica, essa verrà gestita dal device (e non dalla nostra applicazione) e mostrata all’utente in base al tipo di notifica scelta.

Riassumendo i passi appena elencati:

  1. L’applicazione è in running sul device
  2. L’applicazione apre un push channel verso il push client del device
  3. Il push client rimanda un URI all’applicazione in running
  4. L’applicazione comunica l’URI ricevuto al nostro servizio di notifica (il nostro back end server)
  5. Quando si verifica l’evento da notificare, il nostro server comunica i dati al Push Service attraverso l’URI ricevuto attraverso un HTTP post all’uri dei dati formattati secondo uno schema definito
  6. Il push service invia la notifica al push client (sul device) che poi segnala la notifica (o all’applicazione o notifica di tipo toast o tile)

Ma, cosa ce ne facciamo della notifica?

Come detto in precedenza, lo scopo delle notifiche è di segnalare qualcosa all’utente, che poi deciderà cosa farne. E’ quindi l’utente il destinatario del messaggio, gestito tecnicamente da Windows Phone 7 Series e non dalla nostra applicazione.

Al momento non c’è un modo per far eseguire una applicazione in automatico all’arrivo di una notifica. In presenza di una TOAST notification, l’utente può cliccare sul messaggio ed avviare l’applicazione che ha richiesto la notifica. Applicazione che poi dovrà, eventualmente, contattare un servizio web e recuperare tutte le info della nostra spedizione. Ma, ed è importante da sottolineare, la notifica non verrà gestita in automatico dall’applicazione.

La logica dietro questa decisione è da ricercare negli studi fatti sull’usabilità. Di fatti, non c’è un modo per sapere se è corretto che una applicazione svolga un determinato compito in automatico in un determinato istante (l’arrivo di una notifica). E’ l’utente che deve decidere se processare la notifica o meno.

E’ evidente che sono cambiate parecchie cose rispetto al precedente modello di Windows Mobile. Questo nuovo modello introduce sia enormi vanta
ggi che qualche svantaggio. Ma ne parleremo in seguito.

Nei prossimi post, vedremo più in dettaglio i tipi di notifiche, le differenze e gli usi specifici.

Stay tuned