Microsoft Push Notification Service

header_logoAl MIX che si è da poco svolto a Las Vegas, stanno (finalmente) venendo fuori tutti i dettagli relativi a Windows Phone 7. Molte sono le novità relative all’usabilità, alla nuova interfaccia, al concetto di HUB etc.

Ma…da buoni dev, quello che ci interessa maggiormente è cosa si nasconde “sotto il cofano” e come possiamo usarlo per i nostri scopi.

Silverlight e XNA sono ovviamente le novità più interessanti e succulente. La scelta strategica fatta da Microsoft è azzeccatissima e, personalmente, la condivido in pieno. L’unificazione dei modelli e delle tecnologie di sviluppo non può che portare vantaggi non indifferenti tanto al mercato quanto a tutto l’ecosistema che ruota intorno ai dispositivi.

Ma (ed è il secondo ma Smile), come cerco sempre di far notare ogni volta che parlo di programmazione per dispositivi mobili, un “mobile device” NON è un PC (e ne lo sarà mai). E questo a prescindere dalla tecnologia usata per creare applicazioni.

E questo è un bene (quando lo si capisce) Smile

Ma cosa c’entra tutto questo con il titolo del post?
La risposta è che c’entra davvero tanto. Semplificando (ma mi riprometto di passarci con più dettaglio nei prossimi post), la situazione è questa:

  1. un dispositivo mobile funziona a batteria
  2. le applicazioni lasciate aperte, consumano cicli di CPU
  3. i cicli di CPU consumano batteria
  4. le applicazioni lasciate aperte inutilmente consumano batteria inutilmente

Questi punti riassumono (molto ma molto brevemente), la scelta di eliminare il multitasking su Windows Phone 7 Series.

Ci dobbiamo preoccupare?

Non se abbiamo delle strategie alternative! E queste strategie c’erano già all’epoca di Windows Mobile 5.
Ho parlato spesso di State and Notification Broker, con il quale, già da diversi anni, potevamo evitare di avere applicazioni inutilmente in running sul device. Ed ho sperato che, togliendo in multitasking da Windows Phone 7, rimanessero queste API.

Poi l’inizio del MIX e la demo relativa al sistema di Push Notification Service mi ha fatto tirare un mezzo sospiro di sollievo:

Qualcosa quindi si può sicuramente fare. Ora c’è da capire il “come” farla.

Qualche dettaglio in più, l’ho trovato partendo da questo post di Charlie Kindel:

The Microsoft Push Notification Service lets end-users get “live” updates for their favorite apps no matter what they are doing on their Windows Phone. (This is what I get to demo during the keynote!).  Its a mechanism for proactively sending changing or updating information to the phone, regardless of whether or not the application is running. It helps preserve battery life and network and the API for using it on both the Phone and web service is amazingly simple!  Notifications can updated Live Tiles on the Start Screen or show a drop-down “toast” notification at any time and developers can handle notifications directly in their apps

Quindi, ricapitolando:

  1. Non ho multitasking: ok, vediamo cosa si può fare
  2. Ho un sistema di notifiche: perfetto, impariamo ad usarlo
  3. Il sistema NON è State & Notification Broker: mmmmm, cerchiamo quindi di capire cosa e come gestire questa situazione

Ho quindi iniziato a cercare qualche info in più rispetto a questo nuovo meccanismo, arrivando a questo articolo su MSDN, da cui scippo liberamente questa immagine che descrive meglio la struttura delle push notification:

PushNotification

Ok…è evidente che qualcosa è cambiato.
La notifica arriva da un “cloud service”, richiesta, a quanto sembra, grazie ad un “Push Notification Framework” che “istanzia” un “Push Client” che comunica con la parte “cloud” grazie ad un “Microsoft Push Notification Service”.

Per il momento mi fermo qui. Nel prossimo post sull’argomento cercheremo di capire meglio come far funzionare il tutto e quali sono i pro e contro (secondo me) di questa tecnologia.

Stay tuned Smile

Fonte: The Right MIX – Windows Phone Developer Blog – The Windows Blog