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!

Questo post è stato scritto da Roberto Albano, Team Leader in Lynx.

Cos'è dotNET{podcast}

dotNET{podcast} (www.dotnetpodcast.com) è il primo podcast italiano interamente dedicato alle tecnologie Microsoft.

Lo scopo principale è quello è quello di informare, divulgare, incuriosire l'ascoltatore e dargli spunti di riflessione su cui avviare in maniera autonoma degli approfondimenti.

La formula del podcast è quella dell'intervista, in cui ci si trova a chiacchierare sulle tematiche con vari ospiti, tutte persone appassionate ed estremamente disponibili, e con le quali confrontarsi sulle tecnologie per le quali hanno, per lavoro o per passione, una grande esperienza o un particolare interesse.

Quando nasce

L'idea nasce nell'estate del 2014, quindi ormai un anno fa, quando ci si rese conto (io, Antonio Giglio e Massimo Bonanni) che non esistevano podcast tecnici dedicati al mondo Microsoft in lingua italiana.
Questa "grave" mancanza andava colmata ad ogni costo e così avviammo il progetto prendendo spunto da format di successo e già collaudati quali, ad esempio dotNetRocks e HanselMinutes, e modellammo il tutto tenendo conto delle nostre idee e calandolo nel contesto italiano.

La potenzialità dell'iniziativa fu chiara praticamente da subito, infatti prima ancora di partire con qualunque attività, facemmo un veloce sondaggio tra vari MVP ed appassionati (ovvero i potenziali ospiti), e l'idea fu subito accolta con grande simpatia.

In poco meno di un mese (lavorando anche di notte, nel vero senso della parola) si riuscì a partire e nel settembre 2014 pubblicammo la prima puntata, con Massimo Bonanni come primo ospite/cavia.

Da allora ogni lunedì siamo riusciti a produrre sempre una nuova puntata, in alcuni casi anche puntate supplementari di mercoledì.

In poco tempo siamo stati riconosciuti, con grande e sincero orgoglio, quale community tecnica nel circuito delle Microsoft Technical Communities, e questo onore è per noi un vanto oltre che uno sprono per continuare sempre nella divulgazione.

Anche per questo sono nate le puntate "community" (pubblicate appunto di mercoledì) che intendono, di volta in volta, presentare le community tecniche esistenti in Italia (sia locali che nazionali), per promuoverle ulteriormente e far sì che siano conosciute da chi vive nella zona di competenza e non ne conosce l'esistenza o le attività.

Le difficoltà

Il progetto, le idee, i vari argomenti, ok… Ma cosa vuol dire fare un podcast?

Senza scendere troppo nel dettaglio, elenchiamo alcune delle fasi necessarie per realizzare ognuna delle puntate che abbiamo pubblicato:

• Scelta degli argomenti e degli ospiti
• Contatto dell'ospite
• Studio dell'argomento e preparazione delle domande
• Condivisione delle domande con l'ospite per la verifica
• Pianificazione della puntata
• Registrazione della puntata
• Montaggio

Ognuno di questi passaggi, scritto così, sembra poca roba, ma per completare ogni fase ci vuole impegno e, soprattutto, tempo.

E siccome (non so se si era capito) per questi podcast "nessuna ora di lavoro aziendale viene e/o verrà sacrificata", bisogna affidarsi al tempo rimanente, ovvero al tempo libero (in pratica sera e weekend).

Santi subito i nostri familiari, che ci sopportano in questa "insana pazzia" di voler dedicare questo tempo (tanto, spesso troppo) per realizzare un progetto che, tra l'altro, non porta alcun tipo di ricavo, anzi…

Ma noi siamo caparbi, e soprattutto abbastanza folli da continuare ancora, e continueremo finché ce la faremo a reggere i ritmi, anche se sempre più pesanti, di questo (a tutti gli effetti) "secondo lavoro".

Gli obiettivi

L'obiettivo di dotNET{podcast} è tanto semplice quanto ambizioso: essere utile.

La crescita che abbiamo avuto, in termini numerici e di consensi, soprattutto se rapportati alla difficoltà di diffusione dei podcast (sempre erroneamente sottovalutati) ci ha portato a pensare a nuove idee per renderci utili. Quindi, nello stesso tempo a disposizione (sempre meno) abbiamo aumentato le cose da fare.

La prossima idea, che vedrà la luce a brevissimo, sarà una nuova sezione relativa ai "premi" per chi ci ascolta.
Spiego meglio la cosa: in quanto community tecnica, abbiamo a disposizione dei gadget (comunque di valore, ad esempio e-book, subscription per siti tecnici, licenze software ecc.) che ci vengono forniti per gli eventi che le community normalmente organizzano.

Fermo restando che l'idea di un evento non è lontana dal realizzarsi (non a breve termine ma ci saranno sicuramente), intanto abbiamo pensato di mettere a disposizione di chi ci ascolta questi gadget.
Un incentivo in più ad ascoltare le nostre puntate e migliorare il proprio bagaglio di conoscenze, unito piacere di avere allo stesso tempo ricevere un libro tecnico da leggere o una licenza per vedere webcast di grossi esperti internazionali o licenze utile per migliorare, ad esempio, le proprie app mobile con controlli più evoluti.
Insomma oltre ad aiutarvi nella crescita professionale, proviamo a darmi una mano anche con qualche "strumento" di lavoro, e tutto ovviamente in maniera gratuita. E scusate se è poco :-).

I social

Per far conoscere più possibile la nostra community ci siamo affidati ovviamente ai canali social, quindi al nostro account Twitter, al nostro gruppo Facebook e per chi è pigro o "poco social" abbiamo anche una newsletter a cui potersi iscrivervi per seguire le nostre attività e/o le nuove puntate pubblicate.

Per chi invece ha un po' più di dimestichezza con i podcast, abbiamo allestito anche un feed RSS da cui potete alimentare i vostri lettori RSS e/o di podcast per poterci seguire in maniera automatica.

Infine, per chi volesse contattarci direttamente può farlo attraverso la pagina dei contatti del nostro sito.

Insomma, non ci siamo risparmiati per seguirvi e farci seguire, cercando di essere sempre presenti più possibile sui social in modo da poter interagire ancora di più. Dai nostri ascoltatori ci piace sicuramente ricevere complimenti, ma anche e soprattutto suggerimenti, idee, e anche critiche che possano in maniera costruttiva aiutarci a crescere e migliorare.

L'interazione è garantita anche puntata per puntata, infatti in ogni pagina della puntata è possibile inserire commenti e feedback più puntuali.

Gli ospiti

Uno dei fattori di successo del podcast sono stati sicuramente i nostri ospiti, tutti estremamente gentili e disponibili, oltre che ovviamente preparati.

Abbiamo avuto da subito una buona "adesione" e man mano che siamo "cresciuti", abbiamo riscontrato sempre maggiori consensi, sia dagli ascoltatori che abbiamo avuto modo di incontrare agli eventi, ma ancor di più dagli "addetti ai lavori".

Questo ovviamente ci gratifica e ci rende più lieve il duro lavoro che costa ogni puntata, dietro le quinte.

Approfitto di questa occasione, a nome di tutto lo staff di dotNET{podcast}, per ringraziare ancora una volta tutti gli ospiti che sono intervenuti finora (e anticipatamente quelli che verranno) per la loro disponibilità.
Senza di loro, nessuna delle oltre cinquanta puntate pubblicate finora avrebbe avuto lo stesso valore.

Gli argomenti

Arduo ma non troppo scegliere gli argomenti per le puntate. Con l'ampio ventaglio di tecnologie e prodotti Microsoft a disposizione, la scelta è sicuramente facilitata.
In alcuni casi, tuttavia, alcuni degli argomenti scelti sembravano assolutamente inadatti ad essere oggetto di una spiegazione solo verbale.
Ma alla fine, quasi inspiegabilmente, alcune di queste puntate sono state tra le più ascoltate.

Citiamo alcuni esempi:

• la puntata dedicata a DDD e CQRS con Andrea Saltarello (DDD e CQRS per tutti), parla di argomenti architetturali che, generalmente, vengono trattati durante sessioni tecniche coadiuvate da slide e codice ma che, anche grazie alla particolare capacità dell'ospite, sono stati perfettamente spiegati e sono diventati fruibili anche solo con il "verbo";
• analogo discorso per la puntata dedicata a NServiceBus di Mauro Servienti che, a dispetto dell'argomento decisamente ostico è stata una delle più seguite e apprezzate;
• sul fronte dei linguaggi di programmazione, puntate come quella su F# con Alessandro Melchiori (Introduzione a F#) oppure C++ con Marco Arena (Perchè nel 2015 parliamo ancora di C++ ?), sembravano pura follia, e invece sono risultate molto gradite e ascoltate;
• infine l'argomento del cloud di Microsoft, ovvero Microsoft Azure, di cui abbiamo prima fatto una puntata introduttiva con Vito Flavio Lorusso (Azure for developers), e a cui sono seguite poi altre puntate su funzionalità specifiche, è sembrato un argomento gradito, e su cui sicuramente continueremo a lavorare.

La cosa che, comunque, ci ha sorpreso di più è che la maggior parte delle puntate sono state apprezzate (alcune hanno avuto dei picchi ma non abbiamo avuto puntate particolarmente inascoltate) il che ci conferma che la scelta di un podcast "made in italy" è quella giusta!

Starà a noi, e soprattutto a voi ascoltatori, continuare su questa strada e, se possibile, migliorare ulteriormente.

Per questa estate, scaricate le puntate e portateci con voi, al mare sotto l'ombrellone o al fresco in alta montagna, vi terremo compagnia!

Ci risentiamo a settembre con nuove puntate e iniziative!!!