Questo post è stato scritto da Matteo Pagani, Support Engineer in Microsoft per il programma AppConsult

Una delle novità che avrete sicuramente notato iniziando a sviluppare un progetto di tipo Universal Windows per Windows 10 è il ridotto numero di template disponibili in Visual Studio 2015. Se, per quanto riguarda Windows / Windows Phone 8.1, Visual Studio 2013 metteva a disposizione svariati template con i più diffusi layout grafici già impostati (Hub, Pivot, ecc.), in Visual Studio 2015 troviamo solo un template di nome "Blank app" o "Applicaziona vuota", che include semplicemente lo scheletro di una Universal Windows app.

La motivazione è che, spesso, i template predefiniti venivano usati dagli sviluppatori con meno esperienza nel campo della progettazione della User Experience per semplificare il loro lavoro e non dover creare da zero l'interfaccia grafica. Purtroppo però, alla lunga, questo approccio ha portato alla pubblicazione di molte applicazioni dall'interfaccia utente molto simile tra di loro. Di conseguenza, con Windows 10 si è deciso di lasciare molta più libertà creativa agli sviluppatori e di non costringerli o guidarli verso l'adozione di uno specifico design pattern. Attenzione, questo non significa che l'interfaccia utente si possa realizzare senza seguire alcun criterio: la qualità della user experience rimane sempre uno degli aspetti fondamentali di un'applicazione! A tal proposito, vi consiglio una lettura approfondita delle linee guida ufficiali per il design di Universal Windows app all'indirizzo https://dev.windows.com/en-us/design

Il nuovo template è molto semplice ed è il punto di partenza perfetto per realizzare qualsiasi applicazione. A volte, però, soprattutto quando si devono realizzare applicazioni complesse, può risultare fin troppo semplice: nel momento in cui abbiamo la necessità di gestisce scenari avanzati (l'uso del pattern MVVM, il salvataggio e il caricamento dello stato di una pagina, ecc.), dobbiamo farci carico di realizzare tutta l'infrastruttura necessaria.

A tale scopo, un team di persone in Microsoft, guidato da Jerry Nixon (Technical Evangelist noto per la sua serie di corsi su MVA, tenuti insieme ad Andy Wigley, dedicati allo sviluppo di applicazioni per Windows 10) ha iniziato lo sviluppo di un template più avanzato, chiamato Template10. Si tratta di un progetto open source, pubblicato su GitHub all'indirizzo https://github.com/Windows-XAML/Template10 e, di conseguenza, aperto ai contributi di qualsiasi sviluppatore voglia collaborare nella crescita di questo template.

Il progetto è in continua evoluzione e gli obiettivi sono molto ambiziosi: Template10 vuole diventare il punto di riferimento per gli sviluppatori di Universal Windows app, indipendentemente dall'approccio allo sviluppo che preferiscono (code behind o MVVM) e dalle librerie che già utilizzano. Se volete saperne di più, potete consultare la FAQ ufficiale all'indirizzo https://github.com/Windows-XAML/Template10/wiki/Questions. Nel prossimo futuro, Template10 sarà distribuito sia come pacchetto NuGet sia come estensione di Visual Studio, così da avere la possibilità di creare una nuova applicazione in grado di sfruttarlo direttamente dal menu New project di Visual Studio 2015. Per il momento, però, anche se il template è considerato stabile ed adatto all'utilizzo in progetti reali, è disponibile solamente su GitHub. Vediamo, perciò, i passi necessari, al momento, per iniziare lo sviluppo di una nuova applicazione basata su Template10.

Aggiornamento: Template10 è disponibile anche su NuGet http://www.nuget.org/packages/Template10/1.0.2.2-preview. Per poterlo trovare e installare da Visual Studio, però, è indispensabile abilitare l’opzione Include prerelease, dato che il pacchetto è stato pubblicato in modalità beta.

Nel corso di questo primo post vedremo la struttura di Template10 e il suo utilizzo in uno scenario base, ovvero lo sviluppo tradizionale in code behind. Nel prossimo post, invece, vedremo come Template10 dia il suo meglio quando viene usato in combinazione con il pattern MVVM.

Creare il primo progetto

Innanzitutto, dobbiamo clonare il progetto da GitHub. Possiamo farlo sfruttando direttamente gli strumenti messi a disposizione da Visual Studio 2015.

1. Apriamo la finestra di Visual Studio 2015 denominata Team Explorer. Come impostazione predefinita, è accessibile dall'apposita voce in basso a destra, affiancata al Solution Explorer.
2. Troveremo una sezione denominata Local Git Repositories, in cui vengono elencati tutti i repository Git che avete in locale. Premete il pulsante Clone.
3. Nel primo campo (evidenziato dallo sfondo giallo) dovete inserire l'URL del repository GitHub, ovvero https://github.com/Windows-XAML/Template10
4. Nel secondo campo, invece, dovete specificare il percorso locale sul vostro computer dove vorrete clonare il progetto.
5. Ora premete il pulsante Clone: Visual Studio si farà carico di scaricare il progetto e di copiarlo sul vostro computer.

Da questo momento in poi, sempre tramite Team Explorer, avrete la possibilità di accedere al repository e di scegliere l'opzione Sync: tale funzionalità vi permetterà di scaricare i sorgenti più aggiornati e di avere sempre accesso, perciò, alla versione più recente della libreria.

Un buon punto di partenza per creare una nuova applicazione con Template10 è sfruttare il progetto già pronto denominato Blank e contenuto all'interno della cartella Templates (Project), il quale predispone l'infrastruttura di base. Noi, però, partiremo da un progetto vuoto e, man mano, configureremo manualmente le parti che ci servono, così da capire meglio come funziona il template e quali sono i vantaggi che apporta.

Per il nostro scopo, perciò, creiamo un nuovo progetto di tipo Universal Windows utilizzando il template Blank App. Dopodiché, facciamo clic con il tasto destro sulla soluzione e scegliamo Add existing project: a questo punto andiamo a cercare, sul nostro computer, la cartella in cui abbiamo clonato la libreria da GitHub. Nello specifico, dobbiamo andare ad aggiungere il progetto di nome Template10Library: lo troviamo all'interno dell'omonima cartella della libreria, rappresentato dal file Template10Library.csproj. A questo punto è sufficiente, tramite il menu Add reference di Visual Studio, aggiungere un riferimento a tale progetto all'interno della nostra applicazione. Ora siamo pronti per iniziare ad usare Template10.

Il bootstrapper

La classe App, come ben saprete, è il punto di partenza di tutte le Universal Windows app: si fa carico di inizializzare la finestra dell'applicazione con, all'interno, il frame principale, che si fa carico di gestire il rendering e la navigazione tra le varie pagine.

La struttura base della classe App (dichiarata nel file App.xaml.cs) può essere però, a volte, un po' confusionaria. Trovate, infatti, dichiarati numerosi parti di codice che fanno parte dell'inizializzazione standard e, di conseguenza, non devono essere modificati dallo sviluppatore. Anche la gestione del ciclo di vita dell'applicazione (descritta in un post precedente su questo stesso blog) può risultare difficile da comprendere: a seconda della modalità di avvio (lancio dalla tile, attivazione tramite tile secondaria, restore dalla terminazione, ecc.), ci sono diversi punti di accesso, che corrispondono ad altrettanti metodi.

Template10 si fa carico di semplificare il funzionamento di tale classe introducendo il concetto di bootstrapper. Tutto il codice "standard" per l'inizializzazione dell'applicazione è stato spostato all'interno di una classe specifica della libreria, dalla quale dovremo far ereditare la nostra classe App.

Ecco come appare, perciò, la definizione del file App.xaml in un progetto che fa uso di Template10:

<common:BootStrapper

x:Class="BasicSample.App"

xmlns:common="using:Template10.Common"

xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">

</common:BootStrapper>

Come vedete, il nodo base App è stato sostituito dalla classe BootStrapper, contenuta all'interno del namespace Template10.Common. Di conseguenza, anche nel code-behind (quindi nel file App.xaml.cs) la classe App dovrà ereditare dalla classe BootStrapper, come nell'esempio seguente:

sealed partial class App : Template10.Common.BootStrapper

{

public App()

{

InitializeComponent();

}

}

Ecco come appare, invece, l'inizializzazione completa della classe App in un'applicazione basata su Template10:

sealed partial class App : Template10.Common.BootStrapper

{

public App()

{

InitializeComponent();

}

public override Task OnStartAsync(StartKind startKind, IActivatedEventArgs args)

{

NavigationService.Navigate(typeof(MainPage));

return Task.FromResult<object>(null);

}

}

Come potete notare, rispetto all'inizializzazione standard, il codice è estremamente semplificato. Il cuore è il metodo OnStartAsync(), che rappresenta il punto di ingresso dell'applicazione, indipendentemente dallo scenario: sia che l'applicazione sia stata aperta tramite la tile principale, da una tile secondaria o da uno dei contratti disponibili nella Universal Windows Platform (come quello di sharing), passerete attraverso questo metodo. Nel caso più semplice, il vostro codice sarà come quello mostrato nell'esempio: una semplice navigazione verso la pagina principale. La seconda riga di codice serve solo come "workaround" per gestire il fatto che il metodo OnStartAsync() è dichiarato come asincrono (e quindi, come da best practice, restituisce Task), ma non è detto che al suo interno faccia uso di metodi basati sul pattern async / await (come nell'esempio precedente). Di conseguenza, in tal caso, si restituisce un Task vuoto.

Questo approccio semplifica di molto la gestione delle varie modalità di attivazione di un'applicazione perchè il bootstrapper si fa carico, dietro le quinte, di gestire la creazione della finestra e del frame in maniera corretta. Nell'approccio tradizionale, invece, il frame viene creato unicamente all'interno del metodo OnLaunched(), lasciandovi "scoperti" nel caso in cui invece l'applicazione sia stata aperta con una modalità differente dal semplice tap sulla tile principale.

A titolo di esempio, ecco come appare la classe App in caso l'applicazione supporti la creazione (e di conseguenza, l'attivazione) di tile secondarie:

sealed partial class App : Template10.Common.BootStrapper

{

public App()

{

InitializeComponent();

SplashFactory = e => new SplashScreenView(e);

}

public override Task OnStartAsync(StartKind startKind, IActivatedEventArgs args)

{

AdditionalKinds cause = DetermineStartCause(args);

if (cause == AdditionalKinds.SecondaryTile)

{

LaunchActivatedEventArgs eventArgs = args as LaunchActivatedEventArgs;

NavigationService.Navigate(typeof (DetailPage), eventArgs.Arguments);

}

else

{

NavigationService.Navigate(typeof (MainPage));

}

return Task.FromResult<object>(null);

}

}

Come vedete, rispetto all'approccio tradizionale, il codice è estremamente semplificato. Tramite il metodo interno DetermineStartCause() siamo in grado di determinare la causa di attivazione dell'applicazione: in base ad essa, ci limitiamo a navigare verso una pagina piuttosto che l'altra dell'applicazione. Nell'esempio precedente, abbiamo ipotizzato che la tile secondaria dia la possibilità di aprire l'applicazione direttamente sul dettaglio di un elemento: ci limitiamo, perciò, a recuperare gli argomenti della tile (contenuti nella proprietà Arguments dei parametri di attivazione) e a portare l'utente verso la pagina predisposta della nostra applicazione, chiamata DetailPage. In caso, invece, di avvio dalla tile principale il flusso di navigazione rimane invariato e l'utente viene portato alla pagina principale.

Con lo stesso approccio, possiamo gestire tutti gli altri scenari di attivazione: da notifica toast, da Uri, da contratto di sharing, ecc. In questo caso, il metodo DetermineStartCause() vi restituirà il valore Other dell'enumeratore AdditionalKinds: dovremo perciò sfruttare la proprietà Kind del parametro di attivazione di tipo IActivatedEventArgs per determinare lo scenario di utilizzo.

All'interno del bootstrapper avete accesso a tre altri metodi di cui fare l'override, che possono risultare utili in alcuni scenari:

1. OnInitializeAsync() viene chiamato durante l'inizializzazione dell'applicazione e prima del metodo OnStartAsync(). E' utile se dovete inizializzare qualche funzionalità in fase di startup (ad esempio, i servizi di analytics come Application Insights).
2. OnResuming() equivale all'omonimo metodo disponibile nella classe App tradizionale e viene invocato quando l'applicazione viene riattivata dopo una sospensione. Normalmente, non è necessario gestire tale scenario: questo metodo, infatti, viene scatenato solamente quando l'applicazione è stata riattivata dallo stato di sospensione; il processo, perciò, non essendo stato terminato ma mantenuto in memoria, non ha bisogno di recuperare l'eventuale stato salvato in precedenza. Questo metodo può tornare utile quando, ad esempio, vogliamo forzare l'aggiornamento dei dati dell'applicazione, in caso l'utente l'abbia riattivata dopo lungo tempo dall'ultimo utilizzo.
3. OnSuspending() viene invocato quando l'applicazione viene sospesa. Tipicamente, questo metodo viene utilizzato per salvare lo stato dell'applicazione, così da poterlo ripristinare in caso di terminazione. In realtà, con Template10 questa operazione non è necessaria: ci pensa, infatti, in automatico il bootstrapper a gestire questo scenario. Nei prossimi post vedremo come sfruttare tale funzionalità.

Gestione avanzata della splash screen

La splash screen è un'immagine statica che viene mostrata all'utente durante la fase di inizializzazione dell'applicazione. Nel momento in cui questa è terminata, allora la splash screen viene nascosta e viene lanciata la navigazione verso la pagina principale dell'applicazione.

Come regola generale, la fase di inizializzazione dell'applicazione deve essere il più breve possibile: se, entro 10 secondi dalla comparsa della splash screen, l'applicazione non è ancora pronta per l'utilizzo questa sarà terminata dal sistema operativo. Può capitare, però, che possa essere necessario più tempo: pensiamo, ad esempio, ad un'applicazione che deve scaricare dei dati da Internet. Per evitare la terminazione da parte del sistema, è buona prassi non effettuare il caricamento dei dati in fase di inizializzazione all'interno della classe App, ma direttamente nella prima pagina dell'applicazione. In questo modo, l'inizializzazione sarà molto veloce e il controllo sarà subito passato alla pagina principale; dato che, però, ormai l'applicazione è stata avviata, il sistema operativo non tenterà più di terminarla, anche se poi all'interno della pagina ci volessero più di 10 secondi per caricare tutti i dati.

Questo approccio ha però lo svantaggio, a volte, di non offrire una user experience eccezionale: l'utente viene portato alla pagina principale che, però, per forza di cose, sarà completamente vuota e conterrà, al massimo, un messaggio di caricamento fino a che tutti i dati non sono pronti. Di conseguenza, alcune applicazioni adottano il concetto di extended splash screen: terminata l'inizializzazione base dell'applicazione, l'utente viene portato in un'altra pagina che assomiglia, in tutto e per tutto, alla splash screen. La differenza, in questo caso, è che non trattandosi di una semplice immagine statica possiamo includere degli elementi visivi per segnalare all'utente che l'operazione di caricamento è in corso, come una ProgressBar o un testo. Se vi interessa approfondire l'argomento, su MSDN trovate una descrizione su come implementare questa procedura, all'indirizzo https://msdn.microsoft.com/en-us/library/windows/apps/xaml/hh868191.aspx

Come vedete, c'è un po' di lavoro da fare, oltre a creare la extended splash screen. Template10 semplifica notevolmente questo scenario, mettendo a disposizione una classe che si fa carico di gestire la transizione splash screen -> extended splash screen -> prima pagina dell'applicazione per voi. Vediamo come fare.

Il primo passo è creare la splash screen estesa, tipicamente definita tramite uno User Control. Fate click con il tasto destro sul vostro progetto, scegliete Add new item e selezionate il template UserControl. All'interno di questo controllo potete mettere gli elementi grafici che volete, senza limitazioni di sorta. Dato, però, che l'obiettivo è quello di dare all'utente la parvenza di stare ancora visualizzando la splash screen, tipicamente viene incluso un controllo Image che punta all'immagine scelta come splash screen statica. Il resto, poi, è a vostro piacimento. Nell'esempio seguente, l'immagine viene inserita all'interno di un Canvas, con lo stesso colore di sfondo dell'immagine. In più, viene inserito un controllo ProgressRing, per notificare l'utente che c'è un caricamento in corso.

<UserControl

x:Class="BasicSample.Views.SplashScreenView"

xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

xmlns:d="http://schemas.microsoft.com/expression/blend/2008"

xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"

mc:Ignorable="d">

<Grid>

<Canvas x:Name="MyCanvas" HorizontalAlignment="Stretch" VerticalAlignment="Stretch" Background="#0971C3">

<Image x:Name="MyImage" Stretch="None" Source="/Assets/SplashScreen.png" />

</Canvas>

<ProgressRing VerticalAlignment="Bottom" HorizontalAlignment="Center" Width="50" Height="50" IsActive="True" Foreground="White" Margin="0, 0, 0, 100"/>

</Grid>

</UserControl>

Nel code-behind sfruttiamo l'accesso alla classe SplashScreen (che da alcune informazioni sull'immagine, come la dimensione e la posizione) per impostare la nostra immagine allo stesso modo: in questo modo, l'utente non noterà la transizione dalla splash screen statica a quella estesa.

public sealed partial class SplashScreenView : UserControl

{

public SplashScreenView(SplashScreen splashScreen)

{

this.InitializeComponent();

Action resize = () =>

{

MyImage.Height = splashScreen.ImageLocation.Height;

MyImage.Width = splashScreen.ImageLocation.Width;

MyImage.SetValue(Canvas.TopProperty, splashScreen.ImageLocation.Top);

MyImage.SetValue(Canvas.LeftProperty, splashScreen.ImageLocation.Left);

};

Window.Current.SizeChanged += (s, e) => resize();

resize();

}

}

Il ridimensionamento e il posizionamento dell'immagine viene incluso all'interno di una Action che, oltre ad essere eseguita in fase di inizializzazione del controllo, viene legata all'evento di ridimensionamento della finestra (SizeChanged). Questo perché, in ambito desktop, l'utente potrebbe ridimensionare la finestra durante l'avvio dell'applicazione e, di conseguenza, la splash screen deve riadattarsi di conseguenza.

Ora che abbiamo definito la nostra splash screen personalizzata, per utilizzarla è sufficiente aggiungere la seguente riga di codice nel boostrapper:

public App()

{

InitializeComponent();

SplashFactory = e => new SplashScreenView(e);

}

SplashScreenView rappresenta il nome dello UserControl appena creato, mentre e è l'istanza della classe SplashScreen che viene passata al costruttore del controllo (quella che abbiamo usato per posizionare e ridimensionare l'immagine).

Il gioco è fatto: a questo punto, nel momento in cui l'applicazione dovesse impiegare più di qualche secondo per avviarsi, l'utente sarà portato alla nostra splash screen personalizzata e, solo al termine del caricamento dei dati, alla pagina principale dell'applicazione. Per testare questo scenario, è sufficiente includere all'interno del metodo OnStartAsync() un delay di qualche secondo prima di effettuare la navigazione verso la pagina principale, come nell'esempio seguente:

sealed partial class App : Template10.Common.BootStrapper

{

public App()

{

InitializeComponent();

SplashFactory = e => new SplashScreenView(e);

}

public override async Task OnStartAsync(StartKind startKind, IActivatedEventArgs args)

{

await Task.Delay(TimeSpan.FromSeconds(5));

NavigationService.Navigate(typeof(MainPage));

}

}

Una volta terminata l'inizializzazione, l'applicazione avvierà il metodo OnStartAsync() e, fintanto che non sarà scatenata la navigazione con il metodo Navigate del NavigationService, sarà caricata la splash screen personalizzata. Dato che, in questo caso, abbiamo inserito un delay di 5 secondi, tale splash screen rimarrà a video per 5 secondi, dopodiché l'utente verrà portato alla pagina principale.

La gestione della navigazione

Un'altra funzionalità offerta da Template10 è la gestione automatica dello stack delle pagine. Se avete sviluppato, in passato, applicazioni per Windows e Windows Phone 8.1, saprete sicuramente che la gestione della navigazione è una delle differenze principali tra le due piattaforme. Se, su Windows Phone, non è necessario includere alcun elemento visuale per portare l'utente alla pagina precedente, dato che gli smartphone sono già dotati di un pulsante Back hardware, lo stesso non si può dire di Windows.

Le cose con Windows 10 sono cambiate: anche la versione desktop / tablet, infatti, offre una gestione integrata del pulsante Back, sollevando gli sviluppatori (se lo ritengono opportuno) dal doverlo gestire manualmente. Nello specifico, quando questa funzionalità viene abilitata, gli utenti avranno la possibilità:

• In caso di utilizzo dell'app in modalità desktop, il pulsante Back virtuale sarà incluso nella cornice della finestra in alto a destra.
• In caso di utilizzo dell'app in modalità tablet, il pulsante Back virtuale sarà incluso nella barra di sistema, tra il pulsante Start e a Cortana.

Normalmente, in un'applicazione tradizionale, l'abilitazione e la gestione di questa funzionalità è a carico dello sviluppatore (allo stesso modo in cui, in Windows Phone 8.1, dovevamo prevedere un handler dell'evento BackPressed della classe HardwareButtons). Con Template10, invece, come comportamento predefinito, questa gestione è abilitata in automatico. Di conseguenza:

• Quando l'applicazione viene eseguita su desktop e, nello stack delle pagine, sono presenti pagine precedenti a quella corrente, in alto a destra sarà abilitato il pulsante virtuale. Se, invece, lo stack è vuoto (ad esempio, perché ci si trova nella prima pagina), il pulsante sarà automaticamente nascosto.
• Quando l'applicazione viene eseguita in ambito mobile, la pressione del pulsante Back hardware condurrà l'utente alla pagina precedente o, in alternativa, se lo stack è vuoto, alla Start screen del telefono.

Se vogliamo disabilitare questo comportamento perché vogliamo gestire la navigazione in maniera autonoma (ad esempio, includendo un pulsante direttamente nell'interfaccia grafica) possiamo impostare la proprietà ShowShellButton a false nel costruttore del bootstrapper, come nell'esempio seguente:

public App()

{

InitializeComponent();

ShowShellBackButton = false;

}

Con questa opzione vi accorgerete di come, quando l'applicazione viene utilizzata su desktop, il pulsante Back nella finestra non comparirà più, anche se vi trovate in una pagina "interna".

Nella prossima puntata J

Nel corso di questo post abbiamo visto alcuni concetti base di Template10 e quali sono le funzionalità che possiamo iniziare a sfruttare per rendere più semplice lo sviluppo di una Universal Windows app. Abbiamo, però solamente "grattato" la superficie e, nel corso dei prossimi post, scopriremo le vere potenzialità di Template10, soprattutto in ottica di utilizzo del pattern MVVM. Se, nel frattempo, volete iniziare a "giocare" con Template10, potete sfruttare gli esempi già pronti contenuti all'interno del repository su GitHub. Happy coding!

Questo post è dedicato a tutti coloro che hanno una startup, un progetto in essere, o un'idea di progetto, che potrebbe realizzarsi in una nuova startup.

Come qualcuno di voi già saprà, Microsoft mette a disposizione BizSpark, un programma dedicato alle startup, pensato per aiutarle nelle prime fasi dello sviluppo, fornendo non solo i mezzi tecnici necessari, ma anche consulenza e supporto a livello di business. Per avere più dettagli a riguardo, se ancora non conoscete il programma, potete leggere il post di Mario Fontana e guardare il video di Daniele Pagani, Audience Marketing Manager del BizSpark Italy team.

Oggi, vorrei darvi qualche aggiornamento in merito alle novità che sono state apportate al programma negli ultimi mesi.

Iniziamo dalle novità world wide :)
Uno dei vantaggi offerti dal programma è quello di avere a disposizione fino a 8 sottoscrizioni Microsoft Azure con crediti gratuiti per poter attivare e utilizzare i servizi cloud.
Per le startup di BizSpark esiste la possibilità di potenziare questo vantaggio richiedendo BizSpark Plus. Questo "potenziamento" del programma offre la possibilità di incrementare il credito di una delle 8 sottoscrizioni Azure a disposizione.

Da luglio BizSpark Plus è diventato ulteriormente vantaggioso aumentando i crediti gratuiti da utilizzare su Azure da 60 mila dollari a 120 mila dollari per un anno per una a scelta delle 8 sottoscrizioni che si hanno a disposizione con BizSpark.
Richiedendolo avrete la possibilità di aumentare la complessità nelle vostre applicazioni e le risorse cloud che ad esse sono allocate, raggiungendo un bacino di utenti sempre più elevato, così da ottenere sempre più visibilità e successo.
Per ulteriori informazioni potete leggere il post sul blog di Steve Guggenheimer in cui viene annunciato l'aggiornamento.
Se siete già membri del programma BizSpark, richiedere questo ulteriore beneficio è molto semplice: vi basterà inviare una mail a Questo indirizzo e-mail è protetto dallo spam bot. Abilita Javascript per vederlo. e sarete contattati al più presto da un membro del team per procedere con l'application.
Se invece la vostra startup non è ancora iscritta al programma, potete scriverci esprimendo la volontà di accedere a tutti i vantaggi offerti, vi risponderemo con i dettagli per procedere all'iscrizione.

A livello nazionale, abbiamo intrapreso una nuova iniziativa per offrire alle startup che fanno parte del programma sempre più visibilità sul mercato italiano (e non solo), StartUp4You.
Si tratta di una piattaforma che permette di aggregare il meglio dell'ecosistema innovativo Italiano: da una parte le migliori startup digitali con prodotti e servizi innovativi, dall'altra aziende di industrie diverse alla ricerca di tecnologi e i partner.

La startup, iscritta a BizSpark, ha la possibilità di profilarsi sulla piattaforma e mettersi "in vetrina" per le aziende che accedono alla piattaforma, avendo così la possibilità di farsi notare e ricevere importanti offerte.
Le aziende possono, non solo, cercare team interessanti a cui proporre lo sviluppo di determinati progetti, ma anche lanciare delle vere e proprie Call for Action, a cui le startup profilate possono rispondere.
StartUp4You rappresenta per le startup una opportunità unica aggregando la domanda e l’offerta tecnologica.

Infine, ma non meno importante, abbiamo intrapreso, nell'ambito del nuovo show su Channel9 #TecHeroes , l'iniziativa della "Startup del mese". La startup scelta dal team BizSpark Italy avrà a disposizione una pagina all'interno del portale di StartUp4You in cui
potersi raccontare, apparirà sulla nuova pagina MSDN dedicata alle iniziative BizSpark e verrà invitata in sede Microsoft nello studio di #TecHeroes per registrare un breve video in cui potrà parlare delle applicazioni che sta sviluppando e di come il programma BizSpark sia stato d'aiuto durante le prime fasi della sua attività.

Potete trovare ai seguenti link le startup che sono già state intervistate:

• MyAppFree
• Starteed

Startup, che state aspettando? Scriveteci per entrare nel programma BizSpark se non l'avete ancora fatto, o per avere maggiori informazioni su tutte queste novità.

A presto :)

Questo post è stato scritto da Matteo Pagani, Support Engineer in Microsoft per il programma AppConsult

Le notifiche push sono uno dei sistemi più diffusi per gestire la comunicazione asincrona tra un client e un server. Con questo meccanismo il controllo sulla presenza di nuovi dati o informazioni viene spostato dal client (che dovrebbe mantenere una comunicazione continua verso il server, con conseguente impatto sulla batteria e sul consumo di dati) al server (che, invece, si limita a notificare il client quando c'è qualche novità).

L'importanza delle notifiche push, inoltre, assume maggiore rilevanza in ambito mobile, in quanto permettono di comunicare con un'applicazione anche quando questa non è in esecuzione, andando a sopperire al fatto che quasi tutte le principali piattaforme non consentono alle applicazioni di girare indiscriminatamente in background, con lo scopo di preservare la durata della batteria e le performance del sistema operativo. Certo, esistono dei meccanismi per gestire queste situazioni anche senza le notifiche push (pensiamo, ad esempio, ai background task della Universal Windows Platform, citati nel precedente post), ma non sono adatti a soddisfare qualsiasi scenario.

Prendiamo, come esempio, un'applicazione dedicata al calcio. Se volessimo comunicare all'utente, in maniera tempestiva, ogni qualvolta la sua squadra del cuore ha segnato, le notifiche push sarebbero l'unico meccanismo che ci permetterebbe di implementare questo scenario, in quanto:

1. L'evento (in questo caso, il gol) viene scatenato dall'esterno e non gestito localmente all'interno dell'applicazione.
2. Si tratta di un evento asincrono e "imprevedibile": nessuno dei trigger supportati dai background task ci permetterebbe di gestire questo scenario, dato che la maggior parte sono legati ad eventi di sistema (presenza di connettività, blocco del telefono, ecc.) o a vincoli temporali (ad esempio, controlli periodici).

Le notifiche push permettono di soddisfare al meglio scenari di questo tipo, proprio perché vengono generate lato server (e quindi possono gestire eventi indipendenti dall'applicazione) e non hanno vincoli temporali (il canale di comunicazione rimane sempre attivo, quindi fintanto che non ci sono problemi di connettività le notifiche vengono spedite e ricevute senza problemi).

L'architettura delle notifiche push

Nel corso di questo post parleremo, in dettaglio, del funzionamento delle notifiche push nel mondo Windows, ma l'architettura generale è molto simile per tutte le principali piattaforme mobile. Tale architettura prevede il coinvolgimento di tre attori:

1. Il client, ovvero l'applicazione mobile: si tratta dell'app che riceverà le notifiche push.
2. Il server, ovvero l'applicazione che si farà carico di generare la notifica push.
3. Un servizio cloud, che si fa carico di fare da tramite tra il client e il server e che viene fornito e gestito, solitamente, dal produttore della piattaforma mobile. Nel caso di Windows, questo servizio si chiama Windows Push Notification Service (WNS). Ogni qualvolta un'applicazione Windows o Windows Phone vuole sfruttare le notifiche push, questa si registra presso il WNS, il quale genererà un canale di comunicazione, rappresentato da un url. Dall'altro lato del canale si trova il server: ogni qualvolta vuole inviare una notifica push verso il device, dovrà inviare un pacchetto con una struttura ben precisa a tale url, sfruttando il comando POST del protocollo HTTP. Il WNS si farà carico di ricevere il pacchetto e inoltrarlo al device corretto e di restituire al server i dettagli dell'esito dell'operazione (notifica ricevuta, notifica non ricevuta per problemi di connettività, ecc.)

Tale architettura fa sì che l'invio di una notifica push da parte del server sia un'operazione molto semplice da implementare e, soprattutto, agnostica rispetto a qualsiasi piattaforma o tecnologia: trattandosi di un normale pacchetto HTTP inviato tramite una POST, è possibile aggiungere il supporto alle notifiche push in qualsiasi applicazione server, indipendentemente dalla tipologia (web, desktop, servizio, ecc.) e dalla tecnologia sottostante (.NET, Java, PHP, Ruby, etc.)

I Notification Hub di Azure

Nonostante l'architettura base di invio delle notifiche push sia molto semplice, richiede comunque un certo lavoro da parte dello sviluppatore per realizzare l'infrastruttura server necessaria. Nello specifico, è importante gestire una serie di requisiti fondamentali:

1. Tutti i principali servizi cloud (incluso il WNS) implementano un meccanismo di sicurezza, per evitare che chiunque possa inviare notifiche push ai device semplicemente conoscendo l'URL del canale. Di conseguenza, lato server occorre gestire l'autenticazione a tali servizi. Il WNS, ad esempio, sfrutta il protocollo oAuth: nel momento in cui l'applicazione viene registrata sullo Store, vengono fornite una serie di credenziali per l'autenticazione. Se le credenziali vengono validate dal WNS si riceve in ritorno un token , da includere in tutte le chiamate successive al WNS: senza tale token, le chiamate non andranno a buon fine.
2. Il server deve gestire l'elenco di tutti i dispositivi che si sono registrati per ricevere le notifiche push, con il relativo canale, memorizzandoli ad esempio in un database. Tale elenco, infatti, è indispensabile nel momento in cui il server vuole inviare una notifica a tutti i dispositivi che hanno installato e avviato l'applicazione. Opzionalmente, inoltre, potreste avere la necessità di memorizzare, oltre al canale, informazioni addizionali che vi permettano di identificare un singolo device o un gruppo di device. Ritornando all'esempio dell'applicazione calcistica di prima, probabilmente la notifica push relativa al gol segnato da una squadra dovrà essere inviata solamente agli utenti che hanno aggiunto tale squadra tra le preferite.
3. L'applicazione server deve farsi di carico di gestire la logica di registrazione dei dispositivi ed evitare, ad esempio, che vengano registrati due dispositivi con lo stesso canale o che rimangano memorizzati dei dispositivi "orfani" (ovvero per i quali il canale non è più valido).

I Notification Hub sono uno dei tanti servizi di tipo PaaS (Platform as a Service) disponibili su Azure: con questo termine, si indicano tutti quei servizi cloud già "pronti" per essere utilizzati dagli sviluppatori, senza che si debbano preoccupare di gestire l'infrastruttura sottostante (manutenzione dell'hardware, aggiornamento del sistema operativo e del software, ecc.).

I Notification Hub sono un prezioso alleato per risolvere in un colpo solo tutte le complessità elencate poco fa:

1. L'autenticazione viene gestita direttamente dal servizio: è sufficiente, nella configurazione, specificare le credenziali di autenticazione fornite dal servizio di notifiche push.
2. Il servizio si fa carico di gestire l'elenco di tutti i dispositivi che si sono registrati per ricevere notifiche push. Inoltre, i device possono essere associati ad uno o più tag, ovvero delle parole chiave che possono essere utilizzate per raggrupparli in categorie. Ad esempio, l'applicazione sportiva potrebbe gestire un tag per ogni squadra di calcio e associarlo ad ogni device nel quale l'utente ha scelto tale squadra come preferita.
3. Il servizio gestisce, in automatico, la logica necessaria per una corretta gestione dei dispositivi: ad esempio, in caso di canale già esistente, si farà carico di aggiornare la registrazione già esistente invece che crearne una nuova.

I Notification Hub, inoltre, hanno una caratteristica che li rende particolarmente adatti per scenari complessi: sono cross-platform, ovvero consentono di gestire dispositivi (e il relativo invio di notifiche) Windows, iOS, Android, ecc. Riprendendo l'esempio precedente, la vostra applicazione calcistica potrebbe essere disponibile per tutte le principali piattaforme: nel momento in cui una squadra ha segnato, sarete in grado, lato server, di inviare un'unica notifica a tutti gli utenti che hanno indicato tale squadra come preferite, indipendentemente dal fatto che stiano usando uno smartphone Windows Phone o un iPhone.

Per questo motivo, Microsoft mette a disposizione un SDK per interagire con i Notification Hub compatibile con le principali piattaforme e tecnologie, così da poterli facilmente integrare in qualsiasi scenario.

Nel corso di questo post, vedremo come farlo all'interno di un'applicazione Windows 10.

Creare un Notification Hub

I Notification Hub fanno parte dei servizi offerti dalla tecnologia Service Bus di Azure, che include, tra le altre, strumenti come Queue, Event Hub e Topic: si tratta, semplificando, di canali di comunicazione altamente scalabili che consentono di inviare e ricevere messaggi, anche ad una frequenza molto elevata.

Il punto di partenza per creare un Notification Hub, perciò, è accedere alla sezione del portale di Azure dedicata a Service Bus: ovviamente, vi servirà un account Azure valido, anche in modalità trial. Per il momento, Service Bus è gestibile solamente dal vecchio portale: non è ancora presente, infatti, nel nuovo portale in preview. Di conseguenza, dovrete fare login con il vostro account all'indirizzo http://manage.windowsazure.com.

All'interno della sezione chiamata Service Bus, premete il pulsante Create: ciò vi permetterà di creare un namespace, ovvero un "contenitore" all'interno del quale creare uno o più servizi. In realtà, i servizi di messaggistica e di Notification Hub sono mantenuti separati: una delle cose che vi sarà richiesta, infatti, è proprio la tipologia di servizio. Se scegliete Notification Hub, creerete un namespace all'interno del quale potrete aggiungere solamente servizi per le notifiche. La categoria Messaging, invece, vi consente di aggiungere uno qualsiasi dei servizi di messaggistica offerti da Service Bus.

Nel nostro caso, ovviamente, scegliamo Notification Hub: le altre informazioni richieste sono il nome del namespace (che costituirà la prima parte dell'indirizzo che verrà associato, ad esempio MyNotificationHub.servicebus.windows.net) e la regione di Azure in cui ospitarlo.

A questo punto abbiamo creato il namespace, che però sarà vuoto: dobbiamo creare il nostro primo Notification Hub, tramite il pulsante New posizionato in fondo alla pagina. Dovremo specificare il nome che vogliamo dare all'hub che, insieme all'indirizzo del namespace, lo identificherà in maniera univoca. Come impostazione predefinita, il Notification Hub viene creato sfruttando il piano gratuito, che offre 1 milione di notifiche push gratuite al mese e un massimo di 500 device registrati contemporaneamente. Esistono poi due piani a pagamento (Basic e Standard), nei quali questi limiti vengono progressivamente alzati (si arriva fino a 10 milioni di notifiche al mese e un numero illimitato di device registrati), e che offrono una serie di funzionalità più avanzate (come la possibilità di schedulare l'invio di notifiche o strumenti avanzati di telemetria). Troviamo un resoconto dettagliato delle caratteristiche dei vari piani all'indirizzo http://azure.microsoft.com/en-us/pricing/details/notification-hubs/

Il passo successivo è configurare il Notification Hub, così da poterlo usare con il servizio di notifiche push più adatto per la nostra applicazione. Nel nostro caso, andremo ad interagire con un'applicazione Windows 10, di conseguenza ci occuperemo di completare la configurazione relativa al supporto alle Universal Windows app.

Il primo passo è quello di recuperare le credenziali di accesso al WNS ed è indipendente dai Notification Hub: dovremmo seguire questa procedura anche se volessimo appoggiarci ad un'altra soluzione o farci carico noi di realizzarla. Per farlo, dobbiamo prima riservare un nome per la nostra applicazione Windows e associarlo: facciamo clic con il tasto destro sul nostro progetto in Visual Studio e, alla voce Store, scegliamo Associate app with Store. Dopo aver inserito le credenziali del nostro Microsoft Account legate al Dev Center, comparirà la lista di nomi che abbiamo già riservato: scegliamone uno o, in alternativa, riserviamone uno nuovo usando l'opzione in basso.

Dopo aver completato la procedura, dobbiamo portarci sul Dev Center, aprendo il browser all'indirizzo http://dev.windows.com. Entrando nella dashboard, troveremo tra le applicazioni recenti quella per cui abbiamo riservato il nome. Clicchiamoci sopra per accedere ai dettagli e, dal menu di sinistra, scegliamo la voce Push notifications dalla sezione Services.

Nella schermata che comparirà ci saranno descritte le varie opzioni disponibili per interagire con i servizi di notifica offerti da Microsoft. La sezione che interessa a noi è quella intitolata Windows Push Notification Services (WNS) and Microsoft Azure Mobile Services. La sezione sottostante, chiamata Microsoft Push Notification Service (MPNS), è infatti relativa al vecchio servizio di notifiche che veniva utilizzato nelle applicazioni Windows Phone 7.x e 8.0, il quale è ancora disponibile per retro compatibilità con le applicazioni già esistenti ma, a tutti gli effetti, da considerarsi deprecato in quanto sostituito dal WNS.

All'interno della pagina troveremo un link chiamato Live Services Site, evidenziato nella figura sottostante:

Clicchiamoci sopra per andare alla pagina dei servizi Live, in cui avremo accesso alle credenziali utilizzate per l'autenticazione. Nello specifico, quelle che servono a noi sono Package SID e Client secret.

Dopo che abbiamo preso nota di questi due valori, possiamo tornare sul portale di Azure e accedere alla sezione Configure del Notification Hub che abbiamo creato in precedenza. Tale sezione, tra le altre informazioni, offre la possibilità di indicare le credenziali di accesso per i principali servizi di notifiche push: oltre a quelli di Microsoft (WNS e MPSN), troviamo quelli di Google, Apple, Amazon e Baidu.

Nel nostro caso, ci interessa configurare la sezione chiamata Windows Notification Settings, all'interno della quale andare a specificare i Package SID e Client secret precedentemente recuperati, come nell'immagine seguente.

Gestire l'accesso al servizio da parte delle applicazioni

Abbiamo visto come un Notification Hub sia identificato dal namespace che lo contiene e da un nome univoco. Queste due informazioni, però, non sono sufficienti per consentire ad un'applicazione (sia essa client o server) di interagire con il servizio: per questi di sicurezza, infatti, le chiamate verso le API devono essere autenticate.

A questo scopo, i Notification Hub (ma, più generale, tutte le tipologie di servizi offerte da Service Bus) si basano sul concetto di Shared Access Signature, ovvero una chiave di accesso a cui possono essere legate differenti tipologie di permessi. Lo scopo di questo meccanismo è quello di consentire la distribuzione di tali chiavi a terze parti (ad esempio, se l'applicazione client e quella server sono sviluppate da due società differenti) senza, per questo, compromettere la sicurezza del servizio.

Una signature può avere tre tipologie di permessi (i quali possono anche essere combinati):

• Manage: consente la gestione completa del servizio, garantendo l'accesso all'elenco dei dispositivi registrati, alla loro configurazione, ecc.
• Send: consente il solo invio di notifiche push. E' utilizzata tipicamente dall'applicazione server.
• Listen: consente la sola sottoscrizione al Notification Hub. E' utilizzata tipicamente dall'applicazione client.

Ogni signature è associata ad un nome univoco e le possiamo gestire all'interno della sezione Configure del servizio. Come impostazione predefinita, quando creiamo un Notification Hub vengono generate due chiavi:

• Una con accesso completo (manage, send, listen) di nome DefaultFullSharedAccessSignature
• Una per i client (con il solo permesso di listen) di nome DefaultListenSharedAccessSignature

Ogni signature è collegata a due chiavi di accesso (una primaria e una secondaria), che devono essere condivise con lo sviluppatore dell'applicazione. Il modo più semplice per condividere tali chiavi è tramite la relativa stringa di connessione. Analogamente a quando dobbiamo collegarci un database possiamo usare una stringa di connessione (ovvero una stringa che contiene tutte le informazioni necessarie per il collegamento, come l'indirizzo del server, la username, la password, ecc.), anche i Notification Hub mettono a disposizione una stringa di connessione per ogni signature, con tutte le informazioni che serviranno all'applicazione per effettuare il collegamento.

Possiamo trovarle nella dashboard del servizio, premendo il pulsante View connection strings, evidenziato nell'immagine seguente.

Ecco un esempio di stringa di connessione ad un Notification Hub:

Endpoint=sb://windows10samples.servicebus.windows.net/;SharedAccessKeyName=DefaultFullSharedAccessSignature;SharedAccessKey=DlbQZoLHpq49BNJbP9YmkRVPoN4jqCfnJZwt+vAHU24=

Il client: l'applicazione Windows 10

Ora che abbiamo configurato il Notification Hub, possiamo iniziare a integrarlo nell'applicazione Windows, che sarà il destinatario delle nostre notifiche. Per interagire con i Notification Hub abbiamo a disposizione un'apposita libreria, disponibile su NuGet, dal nome WindowsAzure.Messaging.Managed. Si tratta di una versione dell'SDK per Azure Service Bus semplificata e specifica per i client: non offre, infatti, alcuna API per la gestione di scenari server (come l'invio di notifiche o la gestione dei device registrati). Esiste una libreria più completa, che vedremo più avanti nel corso del post, che però non possiamo usare in questo scenario perché richiede la versione full del framework .NET e, di conseguenza, non è compatibile con la Universal Windows Platform.

Il primo passo per integrare il Notification Hub è quello di registrare il canale per le notifiche push: in realtà, si tratta di un'azione indipendente dal servizio di Azure. Si tratta, infatti, della procedura standard da utilizzare quando vogliamo registrare un'applicazione Windows a ricevere notifiche push:

private async void OnRegisterForNotificationsClicked(object sender, RoutedEventArgs e)

{

PushNotificationChannel channel = await PushNotificationChannelManager.CreatePushNotificationChannelForApplicationAsync();

if (channel != null)

{

    //gestisco il canale

}

}

La creazione del canale viene eseguita tramite il metodo CreatePushNotificationChannelForApplicationAsync() della classe PushNotificationChannelManager. Se la registrazione va a buon fine, ci viene restituito un oggetto di tipo PushNotificationChannel, che contiene tutte le informazioni sul canale appena creato.

Anche il secondo passaggio è parzialmente indipendente dai Notification Hub: una volta registrato il canale, infatti, dobbiamo comunicarne l'url alla nostra applicazione server, così che lo possa usare. In caso non ci appoggiassimo ai Notification Hub, la gestione di tale attività sarebbe a nostro carico: ad esempio, potremmo decidere di esporre un servizio REST che la nostra applicazione Windows 10 potrebbe contattare per comunicare le informazioni sul canale. Dato che, in questo caso, stiamo invece sfruttando i Notification Hub di Azure, possiamo utilizzare le API offerte dalla libreria appena installata.

Ecco come appare il flusso completo:

private async void OnRegisterForNotificationsClicked(object sender, RoutedEventArgs e)

{

PushNotificationChannel channel = await PushNotificationChannelManager.CreatePushNotificationChannelForApplicationAsync();

if (channel != null)

{

NotificationHub hub = new NotificationHub("uwpsample", ConnectionString);

await hub.RegisterNativeAsync(channel.Uri);

}

}

Semplice no? Abbiamo creato un oggetto di tipo NotificationHub che, nel costruttore, richiede il nome del servizio e la stringa di connessione (di cui abbiamo parlato nel paragrafo precedente). Dopodichè, è sufficiente chiamare il metodo RegisterNativeAsync() passando, come parametro, l'url del canale, contenuto all'interno della proprietà Uri dell'oggetto di tipo PushNotificationChannel.

Esiste, inoltre, un overload del metodo RegisterNativeAsync() che accetta un secondo parametro, ovvero una collezione di tag, che ci permettono di categorizzare il device e, di conseguenza, inviare notifiche push ad un sottoinsieme dei dispositivi registrati.

private async void OnRegisterForNotificationsClicked(object sender, RoutedEventArgs e)

{

PushNotificationChannel channel = await PushNotificationChannelManager.CreatePushNotificationChannelForApplicationAsync();

if (channel != null)

{

NotificationHub hub = new NotificationHub("uwpsample", ConnectionString);

await hub.RegisterNativeAsync(channel.Uri, new[] { "milan", "juventus" });

}

}

Riprendendo l'esempio dell'applicazione sportiva, questo esempio di codice potrebbe essere utilizzato per gestire un dispositivo nel quale l'utente, all'interno dell'applicazione, abbia indicato Milan e Juventus come squadre preferite.

Il punto di forza di queste API è che si fanno carico di gestire, in automatico, l'eventuale aggiornamento del canale. Tra le best practice nell'utilizzo delle notifiche push, infatti, troviamo il fatto che l'applicazione dovrebbe, ad ogni avvio, richiedere l'apertura del canale: questo perché gli URL non sono immutabili, ma possono scadere e cambiare nel tempo. Di conseguenza, dovremmo farci carico di memorizzare (ad esempio, nello storage locale) l'url del canale e andare a registrarlo nuovamente sul server solo se questo è cambiato. Sfruttando l'SDK dei Notification Hub ciò non è necessario: il metodo RegisterNativeAsync() si farà carico, in automatico, di registrare un nuovo dispositivo o di aggiornare quello esistente, in base allo scenario.

Volendo, ancora prima di realizzare l'architettura lato server, i Notification Hub ci danno la possibilità di testare che il lavoro svolto fin qui sia corretto. Nel portale su Azure, infatti, troverete una voce chiamata Debug, che vi permetterà di inviare una notifica di test a tutti i device registrati (o ad un sottoinsieme, specificando uno o più tag).

.

In base alla piattaforma scelta e al tipo di notifica, la sezione body si popolerà con il contenuto standard del pacchetto relativo. Nel caso di notifiche per le piattaforme Windows, il pacchetto è rappresentato da un file XML, che contiene al suo interno le varie informazioni. Nell'immagine, possiamo vedere il template per l'invio di una notifica toast. Se abbiamo seguito i passaggi precedenti nel modo corretto, premendo il pulsante Send la nostra applicazione per Windows 10 dovrebbe ricevere una notifica toast, con all'interno il messaggio che abbiamo definito nel nodo text.

Il server: gestire i device e inviare le notifiche

Vediamo ora come implementare l'applicazione server, ovvero quello che interagirà con il Notification Hub per gestire i dispositivi registrati e per inviare le notifiche. Al momento, il requisito che abbiamo per sfruttare l'SDK apposita è che l'applicazione deve essere basata sulla versione full del framework .NET: per questo esempio, sfrutterò un'applicazione WPF, dato che ho maggiore famigliarità con lo sviluppo client e con lo XAML. Nulla vieta, ad esempio, di realizzare un'applicazione web basata su ASP.NET.

Il primo passo è di installare nell'applicazione la libreria NuGet dedicata, che si chiama WindowsAzure.ServiceBus. Rispetto a quella client trattata in precedenza, offre metodi aggiuntivi per inviare notifiche, gestire i dispositivi registrati, ecc.

Partiamo dall'operazione principale, ovvero inviare le notifiche.

private async void OnSendNotificationsClicked(object sender, RoutedEventArgs e)

{

string xml = @"<toast>

<visual>

<binding template=""ToastGeneric"">

<text>Hello insiders!</text>

<text>This is a notification from Notification Hub</text>

</binding>

</visual>

</toast>";

NotificationHubClient client = NotificationHubClient.CreateClientFromConnectionString(ConnectionString, "uwpsample");

await client.SendWindowsNativeNotificationAsync(xml);

}

Anche se con qualche differenza nel codice, il concetto base è lo stesso: le interazioni con il Notification Hub sono rese possibili dalla classe NotificationHubClient. Il modo più semplice per istanziarla è usare il metodo statico CreateClientFromConnectionString(), che accetta come parametri la stringa di connessione e il nome del Notification Hub.

Dopodichè troviamo diversi metodi per inviare notifiche, in base alla piattaforma di destinazione. Nel nostro caso, dato che stiamo interagendo con un'applicazione Windows 10, dobbiamo utilizzare il metodo SendWindowsNativeNotificationAsync() che accetta, come parametro, l'XML che descrive la notifica. In questo esempio, stiamo inviando una semplice notifica testa usando i nuovi adaptive template introdotti con la Universal Windows Platform.

Troviamo anche un metodo generico chiamato SendTemplateNotificationAsync(), che permette di inviare notifiche basate sul concetto di template. Anche se non sarà approfondito nel corso di questo post, vi consiglio di dare una lettura alla documentazione all'indirizzo https://msdn.microsoft.com/en-us/library/azure/dn530748.aspx: può risultare molto utile in caso di scenari avanzati, in quanto permette di gestire template per le notifiche che semplificano scenari di localizzazione, personalizzazione del contenuto o cross-platform.

In questo esempio, non abbiamo alcun specificato alcun criterio di selezione: di conseguenza, la notifica sarà inviata a tutti i dispositivi registrati nel nostro hub. Possiamo restringere l'invio sfruttando i tag, già nominati in precedenza. Esattamente come, lato client, avevamo a disposizione un overload del metodo di registrazione che ci permetteva di associare un device ad uno o più tag, qui possiamo sfruttare un overload del metodo di invio per specificare uno o più tag; la notifica sarà inviata solo ai dispositivi che sono associati ad esso.

Ecco un esempio di codice:

private async void OnSendNotificationsClicked(object sender, RoutedEventArgs e)

{

string xml = @"<toast>

<visual>

<binding template=""ToastGeneric"">

<text>Hello insiders!</text>

<text>This is a notification from Notification Hub</text>

</binding>

</visual>

</toast>";

NotificationHubClient client = NotificationHubClient.CreateClientFromConnectionString(ConnectionString, "uwpsample");

await client.SendWindowsNativeNotificationAsync(xml, new[] { "Milan" });

}

Gestire i device registrati

L'SDK completa, come anticipato in precedenza, vi offre anche la possibilità di gestire i device registrati all'interno del Notification Hub. Ad esempio, ecco come possiamo recuperare l'elenco di tutti i dispositivi registrati:

private async Task RefreshDevices()

{

NotificationHubClient client = NotificationHubClient.CreateClientFromConnectionString(ConnectionString, "uwpsample");

CollectionQueryResult<RegistrationDescription> results = await client.GetAllRegistrationsAsync(0);

}

Il metodo GetAllRegistrationsAsync() (che richiede come parametro l'indice del primo device che vogliamo ottenere, passando 0 siamo in grado di recuperare l'elenco completo) ci restituisce una collezione di oggetti di tipo RegistrationDescription, ognuno dei quali rappresenta un device registrato. Tale classe ci offre una serie di proprietà che ci permettono di recuperare informazioni dettagliate sulla registrazione, come l'id, la data di scadenza del canale o i tag associati. In alternativa, possiamo anche filtrare i risultati per tag (tramite il metodo GetRegistrationsByTagAsync()) o per canale (tramite il metodo GetRegistrationsByChannelAsync()).

Infine, abbiamo a disposizione una serie di metodi per modificare la registrazione, cancellandola dall'hub o aggiornandone i dati. Ecco un esempio di cancellazione, gestita all'interno di una lista di device mostrata nell'interfaccia grafica:

private async void OnDeleteDeviceClicked(object sender, RoutedEventArgs e)

{

Button button = sender as Button;

RegistrationDescription device = (button.DataContext) as RegistrationDescription;

NotificationHubClient client = NotificationHubClient.CreateClientFromConnectionString(ConnectionString, "uwpsample");

await client.DeleteRegistrationAsync(device);

}

La cancellazione viene effettuata tramite il metodo DeleteRegistrationAsync(), che accetta come parametro un oggetto di tipo RegistrationDescription.

Le notifiche push e Windows 10

Tramite l'uso dei Notification Hub, possiamo mettere in evidenza uno dei tanti vantaggi del nuovo modello di sviluppo introdotto dalle Universal Windows app di Windows 10. Dato che, rispetto al passato, non parliamo più di applicazioni separate (una per ogni piattaforma), ma di un unico binario che gira su tutte le piattaforme, anche il canale delle notifiche push sarà di conseguenza univoco.

Se lanciamo l'applicazione client sia sul nostro pc che sul telefono (usando l'emulatore o un telefono aggiornato alla preview di Windows 10 tramite il programma Insider), potremo notare che l'URL del canale sarà lo stesso. Di conseguenza, se proviamo ad inviare una notifica dalla sezione di debug del portale di Azure o dall'applicazione server, la vedremo arrivare sia sul pc che sul telefono contemporaneamente.

In conclusione

Nel corso di questo post abbiamo visto come integrare i Notification Hub di Azure all'interno di un'architettura basata sulle tecnologie Microsoft (sia lato server che client). E' importante sottolineare, però, come la libreria citata nel corso dell'articolo sia disponibile per tutte le principali piattaforme. Di conseguenza, non importa se state sviluppando un'applicazione Android o iOS o se avete un server basato su .NET, Java o Ruby: i Notification Hub sono la soluzione che fa per voi se avete bisogno di gestire invii massivi di notifiche push.

Vi lascio, in conclusione, due link:

• https://azure.microsoft.com/en-us/documentation/services/notification-hubs/ è la documentazione ufficiale, in cui trovate sample e tutorial relativi anche alle altre piattaforme.
• https://github.com/qmatteoq/Windows10-Samples/ è il mio repository GitHub dedicato agli esempi di sviluppo su Windows 10 e che include, tra gli altri, un progetto client – server dedicato proprio ai Notification Hub

Happy coding!

Questo post è stato scritto da Matteo Pagani, Support Engineer in Microsoft per il programma AppConsult

Se avete già avuto occasione, in passato, di sviluppare Universal Windows app per Windows o Windows Phone 8.1, il concetto di "ciclo di vita dell'applicazione" dovrebbe esservi famigliare.

Rispetto al mondo desktop tradizionale, dove il ciclo di vita delle applicazioni è piuttosto semplice (sostanzialmente, un'applicazione rimane in esecuzione fintanto che è aperta), nel mondo mobile le cose sono più complicate. Un dispositivo mobile (come uno smartphone), infatti, deve far fronte ad una serie di scenari che non sono tipici del mondo desktop, quali il consumo di batteria, la quantità di memoria limitata, ecc.

Di conseguenza, le Universal Windows app (sia su 8.1 che su 10) adottano un ciclo di vita che può essere sintetizzato con l'immagine seguente:

Nel momento in cui l'applicazione viene aperta, questa entra in uno stato di esecuzione chiamato running, che le dà la possibilità di sfruttare memoria, CPU, rete, sensori e quant'altro sia disponibile sul device. Nel momento in cui viene sospesa (l'utente preme il pulsante Start, oppure riceve una notifica proveniente da un'altra applicazione e decide di aprirla) questa dopo 5 secondi viene "congelata" in memoria: ciò significa che il processo sarà mantenuto nella memoria RAM del dispositivo, ma non sarà in grado di eseguire alcuna operazione. Di conseguenza, tutte le risorse del dispositivo (CPU, fotocamera, sensori, ecc.) saranno liberate e pronte per essere utilizzate dalla nuova applicazione. Nel momento in cui l'utente sceglie di riaprire l'applicazione, ecco che si verifica l'evento di resuming: il processo viene "risvegliato" e l'applicazione può tornare a sfruttare le risorse messe a disposizione del dispositivo. Può capitare, però, che le risorse di sistema inizino ad esaurirsi: ad esempio, l'utente potrebbe aprire molte applicazioni, oppure averne sospese una o due molto onerose in termini di memoria occupata (come un gioco). In questo caso, all'apertura di una nuova applicazione, il dispositivo potrebbe non avere memoria sufficiente per gestirla: ecco, perciò, che il sistema operativo ha la possibilità di terminare le applicazioni più vecchie (in termini di frequenza di utilizzo) per liberare memoria. In questo scenario è compito dello sviluppatore, in fase di sospensione, salvare lo stato dell'applicazione in modo che, quando l'utente deciderà di riaprirla, la ritrovi esattamente come l'aveva lasciata: per l'utente finale, la terminazione del sistema operativo dovrebbe essere completamente trasparente.

Eseguire operazioni in background: i background task

Come potete intuire dalla spiegazione precedente, le applicazioni non hanno la possibilità di eseguire operazioni quando sono sospese. Il processo, infatti, è congelato e, di conseguenza, non può eseguire alcun tipo di attività che richieda l'uso di CPU, connettività, ecc.

Di conseguenza, per permettere agli sviluppatori di gestire la necessità di eseguire operazioni anche quando l'applicazione è sospesa, il Windows Runtime ha introdotto il concetto di background task: si tratta di progetti indipendenti, che fanno parte della stessa soluzione che contiene l'applicazione principale, i quali contengono blocchi di codice che vengono eseguiti dal sistema operativo anche quando l'applicazione non è in esecuzione.

La struttura di un background task è molto semplice:

using Windows.ApplicationModel.Background;

namespace Tasks

{

public sealed class ExampleBackgroundTask : IBackgroundTask

{

public void Run(IBackgroundTaskInstance taskInstance)

{

}

}

}

Semplificando, si tratta semplicemente di creare una classe che implementi l'interfaccia IBackgroundTask e che definisca il metodo Run(), che viene invocato nel momento in cui task viene attivato.

I background task sono dei progetti di tipo Windows Runtime Component e sono legati al concetto di trigger, ovvero degli eventi che possono far scatenare l'esecuzione del task: può essere un trigger periodico (ogni 30 minuti, ad esempio), legato ad un evento di sistema (l'utente ha bloccato / sbloccato il device) o a alla comunicazione con altri dispositivi (ad esempio, esistono una serie di trigger legati all'interazione con dispositivi Bluetooth Low Energy).

Non approfondirò l'argomento background task all'interno di questo post, dato che il loro funzionamento è rimasto sostanzialmente invariato nel passaggio da Windows 8.1 a Windows 10. Sono state aggiunte, infatti, numerose nuove tipologie di trigger, ma i concetti basi che ne guidano lo sviluppo sono i medesimi. Se siete interessati all'argomento, potete fare riferimento alla documentazione MSDN disponibile all'indirizzo https://msdn.microsoft.com/en-us/library/windows/apps/xaml/hh977056.aspx

Mantenere l'applicazione in background anche quando viene sospesa

La vera novità introdotta in Windows 10 e oggetto di questo post è la classe ExtendedExecutionSession, che vi consente di supportare due nuovi scenari:

1. La vostra applicazione ha bisogno di salvare dei dati o terminare un'operazione in corso prima di essere sospesa e i 5 secondi assegnati dal sistema operativo non sono sufficienti.
2. La vostra applicazione ha bisogno di continuare l'esecuzione anche se viene sospesa, ad esempio per tracciare in maniera continuativa la posizione dell'utente (navigatore satellitare, applicazioni di fitness, ecc.)

Vediamo in dettaglio come gestire entrambi gli scenari.

Terminare un'operazione in corso

La gestione di questo scenario avviene all'interno del metodo che gestisce la sospensione: la nostra applicazione sta per essere sospesa e vogliamo la possibilità di terminare l'operazione in corso (ad esempio, l'upload di un file sul server). Di conseguenza, il punto di partenza è la classe App, dichiarata nel file App.xaml.cs, presente in tutti i progetti di tipo Universal Windows app.

All'interno troverete un'implementazione base del metodo OnSuspending(), così definito:

private void OnSuspending(object sender, SuspendingEventArgs e)

{

var deferral = e.SuspendingOperation.GetDeferral();

deferral.Complete();

}

Tale blocco di codice, all'atto pratico, non esegue nulla: si limita a richiedere un deferral, che dà la possibilità di eseguire operazioni asincrone (quindi, sfruttando le keyword async e await) all'interno dell'evento di sospensione. Senza l'uso del deferral, l'avvio di un'operazione asincrona su un thread differente da quello principale potrebbe causare la sospensione immediata dell'applicazione.

All'interno di questo blocco dobbiamo andare a sfruttare la classe ExtendedExecutionSession per richiedere un'estensione di tempo, così da avere la possibilità di terminare l'operazione. Ecco un esempio di codice:

private async void OnSuspending(object sender, SuspendingEventArgs e)

{

var deferral = e.SuspendingOperation.GetDeferral();

var extendedSession = new ExtendedExecutionSession();

extendedSession.Reason = ExtendedExecutionReason.SavingData;

extendedSession.Description = "Complete synchronization";

ExtendedExecutionResult result = await extendedSession.RequestExtensionAsync();

if (result == ExtendedExecutionResult.Allowed)

{

UploadCompleteData();

}

else

{

UploadBasicData();

}

deferral.Complete();

}

Nel momento in cui creiamo un nuovo oggetto di tipo ExtendedExecutionSession, dobbiamo specificare:

1. La motivazione per cui vogliamo che la nostra operazione continui anche dopo la sospensione. Nel nostro scenario, dobbiamo specificare il tipo SavingData dell'enumeratore ExtendedExecutionReason.
2. Una descrizione che riassume brevemente il tipo di operazione che andremo ad eseguire. E' una semplice stringa testuale.

Dopodichè possiamo chiamare il metodo RequestExtensionsAsync(). Come si evince dal nome stesso, tale metodo non ci garantisce che la richiesta andrà a buon fine: il sistema operativo, infatti, potrebbe decidere di negarla, in base alle risorse disponibili in quel momento. È importante, perciò, verificare il risultato della chiamata, che è di tipo ExtendedExecutionResult. Solo nel caso in cui sia di tipo Allowed, allora siamo autorizzati ad eseguire un'operazione più complessa, dato che l'applicazione non sarà sospesa dopo 5 secondi. In caso contrario, invece, dobbiamo gestire il fatto che il sistema operativo ci abbia negato l'esecuzione in background: di conseguenza, dobbiamo rispettare il vincolo di 5 secondi prima che qualsiasi processo attivo venga terminato.

Tale approccio deve essere usato per gestire operazioni che abbiano, comunque, una durata non eccessiva: il sistema operativo, infatti, in caso le risorse si stiano esaurendo potrebbe terminare preventivamente l'attività in corso.

Mantenere l'applicazione attiva in background

La seconda funzionalità garantita dalla classe ExtendedExecutionSession offre più flessibilità rispetto allo scenario precedente, ma anche più vincoli. Con questo approccio, infatti, nel momento in cui l'applicazione viene sospesa, in realtà, questa viene mantenuta attiva in background: il processo non viene congelato, ma rimane attivo e in grado di eseguire operazioni, reagire agli eventi, ecc. È come se l'applicazione fosse in esecuzione in foreground, solamente non visibile. Si tratta di una funzionalità molto utile in particolar modo per le applicazioni che fanno un uso intensivo del tracciamento della posizione dell'utente: un'applicazione dedicata al fitness, ad esempio, potrebbe continuare a tracciare la corsa dell'utente anche se il telefono si trova bloccato in tasca.

È proprio per questo motivo che la classe ExtendedExecutionSession identifica questo approccio assegnando il valore LocationTracking alla proprietà Reason. Inoltre, per poterla sfruttare è necessario che la capability Location, all'interno del file di manifest, sia abilitata. In realtà, il sistema operativo non vi obbliga ad usare le API di geolocalizzazione per mantenere attiva questa modalità: è sconsigliato, però, utilizzarla per scopi differenti dal tracciamento della posizione dell'utente, in virtù del fatto che dareste un'informazione errata all'utente. Quanto questi consulterà, infatti, la pagina sullo Store della vostra applicazione, troverà tra l'elenco di funzionalità richieste il tracciamento della posizione, anche se non la utilizzate realmente.

Rispetto allo scenario precedente di salvataggio dei dati, esiste un'importante differenza nell'utilizzo della classe ExtendedExecutionSession: se, nell'esempio di codice visto poco fa, la utilizzavamo all'interno del metodo OnSuspending() della classe App, in questo caso invece dobbiamo richiedere il permesso al sistema operativo di continuare l'operazione in background il prima possibile. Un buon punto, ad esempio, dove inizializzarla è all'interno dell'evento OnNavigatedTo() della pagina principale dell'applicazione, come nell'esempio seguente:

protected override async void OnNavigatedTo(NavigationEventArgs e)

{

if (e.NavigationMode == NavigationMode.New)

{

var extendedSession = new ExtendedExecutionSession();

extendedSession.Reason = ExtendedExecutionReason.LocationTracking;

extendedSession.Description = "Location tracking";

ExtendedExecutionResult result = await extendedSession.RequestExtensionAsync();

if (result == ExtendedExecutionResult.Allowed)

{

Debug.WriteLine("Background execution approved");

}

else

{

Debug.WriteLine("Background execution denied");

}

}

}

La prima riga di codice ci assicura che l'inizializzazione sia fatta solo quando la modalità di navigazione è New, ovvero si tratta del primo caricamento della pagina: questo per evitare che, ad esempio, l'inizializzazione venga ripetuta ogni volta che l'utente, da una pagina secondaria, torni indietro a quella principale.

Dopodiché, il codice è praticamente identico a quello visto in precedenza. Le uniche differenze sono:

• L'utilizzo del valore LocationTracking per la proprietà Reason della classe ExtendedExecutionSession
• Anche in questo caso, è importante verificare se il sistema operativo ci abbia autorizzato a continuare l'esecuzione in background: in realtà, però, in caso affermativo non dobbiamo fare nulla di particolare, dato che l'applicazione continuerà semplicemente le sue attività in background, come se non fosse mai stata sospesa. Di conseguenza, possiamo sfruttare il risultato dell'operazione RequestExtensionAsync() per scopi di logging e per dare un avviso all'utente, ma non dobbiamo eseguire alcuna operazione particolare. Attenzione: se vi dimenticate di abilitare la capability Location nel file di manifest, la chiamata a questo metodo vi ritornerà sempre Denied.

E' importante sottolineare come, anche se l'applicazione sia effettivamente in esecuzione, non abbia comunque il controllo della UI: se avete bisogno di mostrare degli avvisi di tipo visivo all'utente, perciò, dovrete sfruttare i meccanismi predisposti per questo scenario, come le notifiche.

Ovviamente, dato che questa modalità lascia maggiore libertà, ha anche dei vincoli più stringenti rispetto allo scenario di semplice salvataggio dei dati. Nello specifico, è possibile avere solamente una applicazione in esecuzione sul dispositivo in questo stato; se l'utente avviasse un'altra applicazione che fa uso dell'esecuzione in background, la nostra verrebbe terminata per lasciare spazio a quella nuova.

Inoltre, anche in questo caso il sistema operativo ha la possibilità di valutare, in base allo stato delle risorse di sistema, se negare l'esecuzione in background o se terminarla prematuramente.

In conclusione

Le funzionalità di esecuzione in background descritte in queste post saranno molto apprezzate dagli sviluppatori, in quanto aprono una serie di nuovi scenari che non era possibile gestire in Windows 8.1. In conclusione, vi ricordo che la classe ExtendedExecutionSession fa parte della Universal Windows Platform di Windows 10 e, di conseguenza, anche se risulta sicuramente più utile in scenari mobile, è utilizzabile anche da applicazioni desktop, IoT, ecc.

Happy coding!