Il blog di Matteo Pagani

Il multitasking in Mango: i background transfers

2012-10-12T10:00:00Z

Continuiamo il nostro percorso alla scoperta delle novità di Mango e parliamo questa volta dei background transfers, ovvero una nuova funzionalità che ci permette di gestire i download e gli upload di dati all’interno della nostra applicazione anche quando questa non è in esecuzione.

Al giorno d’oggi siamo abituati ad utilizzare due classi per gestire il flusso di dati verso l’esterno: WebClient (più semplice da usare ma meno performante) e HttpWebRequest (più complessa da usare ma più completa e veloce). In Mango abbiamo a disposizione una nuova classe per questo scopo, chiamata BackgroundTransferRequest, che ha la particolarità di poter continuare a mantenere il trasferimento attivo anche ad applicazione chiusa.

E’ bene ricordare che, dato che questo tipo di trasferimento può avere un impatto sulle performance e sul consumo di batteria, sono stati introdotti dei limiti analoghi a quelli per il download di applicazioni dal Marketplace: se si è collegati ad una rete 3G, il trasferimento massimo di dati consentito è di 20 MB, che diventano 2 GB se invece siamo collegati ad una rete Wi-Fi.

Prima di approfondire l’argomento, però, dobbiamo parlare di un’altra nuova feature di Mango, molto importante nell’utilizzo dei background transfers: il mapping dell’Isolated Storage.

Un nuovo metodo di mapping dell’Isolated Storage

Nella versione attuale di Windows Phone l’unico modo per lavorare con i file memorizzati nell’Isolated Storage è utilizzare le classi messe a disposizione dal framework, come IsolatedStorageFile e IsolatedStorageFIleStream.

In Mango è stata introdotta la possibilità di esprimere i file memorizzati nell’Isolated Storage con un Uri, in questo modo:

private Uri destinationUrl = new Uri("/shared/transfers/Cocaine.mp3", UriKind.RelativeOrAbsolute);

L’esempio qui riportato è un Uri che punta al file Cocaine.mp3 memorizzato nella cartella transfers dell’Isolated Storage. Nei background transfers questo nuovo metodo di mapping è molto importante, dato che quando viene inizializzata la classe BackgroundTransferRequest è necessario specificare sia la sorgente che la destinazione proprio sotto forma di Uri. Questo perchè il download potrebbe terminare anche ad applicazione chiusa: in quel caso, se mantenessimo il file scaricato solamente in memoria non avremmo modo di gestirlo.

In realtà, questo nuovo metodo di mapping può tornare utile in tutti gli scenari in cui l’oggetto con cui si sta lavorando esponga delle proprietà che accettano un Uri come sorgente: se prima eravamo limitati a riferirci solamente a risorse incorporate nel progetto oppure esposte sul web, da oggi possiamo anche utilizzare file memorizzati nell’Isolated Storage (pensiamo ad esempio alla proprietà BackgroundImage delle tile).

Iniziamo il trasferimento

Ora che abbiamo capito come funziona il nuovo metodo di mapping, vediamo come gestire il trasferimento di dati. Innanzitutto dobbiamo definire un Uri sorgente (il file che vogliamo scaricare) e un Uri di destinazione (dove vogliamo salvare il file). Occhio che abbiamo l’obbligo di salvare tutti i file scaricati usando la classe BackgroundTransfer all’interno della cartella shared/transfers che, se non esiste, verrà creata all’occorrenza (occhio che, come raccontato in un mio post, la posizione di questa cartella è cambiata dalla beta1 alla beta2). Possiamo aggiungere altri file o altre sottocartelle all’interno di transfers, possiamo spostare il file una volta terminato il download, ma non abbiamo la possibilità di scaricare direttamente i file al di fuori di essa.

L’URL sorgente deve essere passato come parametro in fase di inizializzazione dell’oggetto, mentre l’URL di destinazione può essere passato sia come secondo parametro, sia definito in un secondo momento tramite la proprietà DownloadLocation.

Vediamo un esempio di codice, che poi commenteremo:

backgroundRequest = new BackgroundTransferRequest(sourceUrl, destinationUrl);
backgroundRequest.Method = "GET";
backgroundRequest.TransferPreferences = TransferPreferences.AllowCellularAndBattery;
backgroundRequest.TransferProgressChanged += new EventHandler<BackgroundTransferEventArgs>(backgroundRequest_TransferProgressChanged);
backgroundRequest.TransferStatusChanged += new EventHandler<BackgroundTransferEventArgs>(backgroundRequest_TransferStatusChanged);

BackgroundTransferService.Add(backgroundRequest);

Come potete notare, la classe BackgroundRequest permette di definire le classiche impostazioni di una connessione HTTP, come il metodo (nell’esempio, POST) e gli headers. Ben più importante è sottolineare la proprietà TransferPreferences, che permette di definire le condizioni che devono essere soddisfatte affinché il trasferimento venga mantenuto in background. Le possibili opzioni sono:

None: è l’impostazione di default, consente il trasferimento solo se il device è in ricarica e collegato ad una rete Wi-Fi.
AllowBattery: consente il trasferimento solo se il device è collegato ad una rete Wi-Fi, ma è indifferente quale tipo di alimentazione si sta usando.
AllowCellular: consente il trasferimento solo se il device è in ricarica, ma è indifferente se sia collegato ad Internet tramite una rete Wi-Fi o tramite rete cellulare.
AllowCellularAndBattery: consente sempre il trasferimento, indipendente dal tipo di alimentazione e dal tipo di rete a cui è collegato.

Infine notiamo come l’oggetto ci metta a disposizione due eventi che possiamo sottoscrivere:

TransferProgressChanged: questo evento viene scatenato ogni qualvolta la quantità di dati trasferita cambia. Tipicamente, viene utilizzato per gestire eventuali progress bar o indicatori di altro tipo che mostrino lo stato del trasferimento.
TransferStatusChanged: questo evento viene scatenato nel momento in cui lo stato del trasferimento cambia. Questo tipo di informazione ci dice non solo se il trasferimento è stato completato (Completed), ma anche se ad esempio il device è in attesa di essere collegato ad una sorgente di alimentazione esterna (WaitingForExternalPower), ad una rete Wi-Fi (WaitingForWiFi) o se si trova in modalità risparmio batteria (WaitingDueToBatterySaverMode), in base alle impostazioni che abbiamo definito in precedenza.

Per dare via al trasferimento lo dobbiamo aggiungere al BackgroundTransferService che, analogamente a quanto fa lo SchedulerActionService per i task, si occupa di gestire lo scheduling dei trasferimenti in background.

Nella prossima puntata

Nel prossimo post vedremo un progetto di esempio più articolato, in cui gestiremo sia gli eventi esposti dalla classe BackgroundTransferRequest, sia il fatto che il trasferimento del file potrebbe terminare nel momento in cui la nostra applicazione è chiusa.

Aprire Internet Explorer da codice in un’applicazione Metro style

2012-02-25T10:00:00Z

Una delle applicazioni che ho sviluppato per Windows 8 è quella dedicata al mio blog, che permette di consultare i miei post più recenti sfruttando alcune delle feature di Windows 8 (sharing, notifiche, ecc.).

Una delle problematiche ho dovuto affrontare nello sviluppo è stata la gestione della modalità snapped: se per quanto riguarda la pagina principale non ho avuto difficoltà (è stato sufficiente convertire una GridView orizzontale in una ListView verticale), qualche problema è sorto quando si è trattato di gestire la pagina di dettaglio, costituita da una web view con il contenuto del post. La modalità snapped, infatti, lascia troppo poco spazio affinchè la web view sia usabile.

Durante il lab mi è stato dato un suggerimento molto intelligente: far si che, in modalità snapped, non venga visualizzata la pagina di dettaglio ma venga direttamente aperto Internet Explorer: in questo modo il browser va ad occupare lo spazio restante (in modalità Filled), rendendo il post leggibile.

Ma come fare? Il primo passo è stato determinare lo stato in cui si trova l’applicazione: la gestione della selezione dell’elemento nella lista deve essere differente a seconda se mi trovo in modalità Snapped (apertura del browser) o in una delle qualsiasi altre disponibili (navigazione alla pagina di dettaglio).

Per fare questo ci viene in aiuto la classe ApplicationView, facente parte del namespace Windows.UI.ViewManagement. Tale oggetto contiene la proprietà statica Value, che è di tipo ApplicationViewState: si tratta di un enumeratore che espone un valore per ognuno degli stati visivi disponibili (Snapped, Filled, FullScreenLandscape e FullScreenPortrait). Il valore di questa proprietà corrisponde allo stato visivo corrente dell’applicazione.

Il secondo passo è stato trovare il modo di avviare il browser direttamente sul post selezionato, un po’ come avviene su Windows Phone quando si utilizza il launcher WebBrowserTask. Anche in questo caso la documentazione MSDN è venuta in mio aiuto: il namespace Windows.System.Launcher contiene una classe statica chiamata Launcher, che espone il metodo asincrono LaunchUriAsync, che accetta come parametro un url di tipo Uri.

Ecco perciò un esempio di codice in cui ci sottoscriviamo all’evento SelectionChanged per ottenere il risultato desiderato:

private void Selector_OnSelectionChanged(object sender, SelectionChangedEventArgs e)
{
    if (ApplicationView.Value == ApplicationViewState.Snapped)
    {
        Launcher.LaunchUriAsync(new Uri(e.AddedItems[0]));
    }
    else
    {
        Frame.Navigate(typeof (DetailPage), e.AddedItems[0]);
    }
}

Migrazione di un’applicazione Metro style dalla Consumer Preview alla Release Preview

2012-02-24T10:00:00Z

Come vi ho anticipato nel post precedente, le modifiche dalla Consumer Preview alla Release Preview non hanno coinvolto solo l’esperienza utente, ma anche lo sviluppo di applicazioni Metro Style.

La parte che ha subito le modifiche maggiori è quella relativa a WinJS, quindi allo sviluppo di applicazioni con HTML e Javascript: non ve ne parlerò in questo post, però, perchè non ho esperienza diretta, avendo lavorato solo su applicazioni con XAML e C#.

Mi sono trovato, perciò, nella situazione di dover migrare alla Release Preview la mia applicazione Ricette Toscane, il porting dell’omonima applicazione per Windows Phone. Piccolo spazio promozionale: assieme ad un manipolo di altre brutte persone l’applicazione ha superato la precertificazione, dandomi così la possibilità di avere un token di accesso per la pubblicazione. Potete vedere le altre brutte facce sul sito ufficiale http://it.windows8app.eu/

Vediamo quali sono gli interventi principali che ho dovuto effettuare per adattare l’applicazione.

Il primo impatto

Il primo problema da affrontare è stato il fatto che la soluzione non compilava! Ciò è dovuto alla classe LayoutAwarePage, dichiarata nell’omonino file all’interno della cartella Common, che ha subito delle modifiche: da tale classe ereditano le pagine dell’applicazione basate sul template standard e contiene una serie di facilitazioni che semplificano la gestione dei vari stati visuali di una pagina (landscape, portrait, snapped, ecc.).

Per riuscire a compilare il progetto ho perciò creato un nuovo progetto “vuoto” utilizzando la nuova RC di Visual Studio 2012 e ho copiato la cartella Common, sovrascrivendo quella del vecchio progetto.

L’intervento non è stato perciò sufficiente: l’applicazione compilava ma, appena superata la splash screen, si verificava un’eccezione nel parsing dello XAML, nello specifico error HRESULT E_FAIL has been returned from a call to a COM. A poco è servito cercare di isolare il problema: il messaggio di errore è assolutamente criptico e non da alcuna indicazione sulla causa del problema.

La soluzione più semplice è stata perciò creare un nuovo progetto e, man mano, riportare i file del vecchio progetto nel nuovo progetto, prestando attenziones a non sovrascrivere i nuovi file generati da Visual Studio che sono cambiati con la Release Preview (ad esempio, quelli contenuti nella cartella Common o il file App.xaml).

Con questo intervento il problema è stato risolto: l’applicazione compila e la pagina principale viene visualizzata correttamente.

Il SuspensionManager

Tra le novità nelle applicazioni Metro Style c’è il SuspensionManager, una classe che semplifica la gestione del ciclo di vita nelle applicazioni che fanno uso di pagine basate sulla classe LayoutAwarePage: il SuspensionManager viene infatti utilizzato in automatico nell’App.xaml.cs (nell’evento OnLaunched, scatenato quando l’applicazione viene avviata) e negli eventi di navigazione (OnNavigatedTo e OnNavigatedFrom) per salvare e recuperare lo stato dell’applicazione, nel caso in cui questa venga terminata (vi ricordo, infatti, che le applicazioni Windows 8 hanno un ciclo di vita pressochè identico a quello delle applicazioni Windows Phone e, quando si trovano in sospensione, possono essere terminate prematuramente in caso di esaurimento delle risorse disponibili).

Di default le pagine create dal template standard di Windows 8 implementano un override dell’evento NavigatedTo, che viene utilizzato solitamente per caricare i dati da mostrare nella pagina corrente: ad esempio, in una tipica situazione master – detail l’elemento selezionato viene passato proprio tramite le API per la navigazione di Windows 8 e, per tale motivo, l’informazione viene recuperata nell’evento OnNavigatedTo. Il problema, però, è che la classe LayoutAwarePage contiene un’implementazione dei metodi di navigazione che salva e recupera lo stato in automatico tramite il SuspensionManager: il risultato è che, se voi non chiamate il metodo base prima di eseguire le operazioni specifiche, otterrete un errore in fase di navigazione verso un’altra pagina, perchè il SuspensionManager non troverà i dati che ha salvato.

Occorre ricordarsi perciò di includere sempre la chiamata al metodo base come nell’esempio:

protected override void OnNavigatedTo(NavigationEventArgs e)
{
    base.OnNavigatedTo(e);
   //carico i dati della pagina
}

Nel mio caso, ottenevo un’eccezione dato che la versione sviluppata per la Consumer Preview non aveva questo requisito, perciò la chiamata al metodo base era assente.

Nuovo prefisso per gli URL che puntano ai file di progetto

Il terzo e ultimo problema l’ho riscontrato nella gestione delle tile secondarie. Creare una tile secondaria in un’applicazione Windows 8 è molto semplice, come potete vedere nell’esempio:

SecondaryTile secondaryTile = new SecondaryTile(id, shortName, displayName, arguments, options,
                                                new Uri(logo));

await secondaryTile.RequestCreateAsync();

Si crea una nuova istanza della classe SecondaryTile (passando alcuni parametri che definiscono le caratteristiche della tile, come l’id identificativo e il testo visualizzato) e si richiama il metodo RequestCreateAsync.

Nella versione Consumer Preview si utilizzava il prefisso ms-resource per creare un oggetto di tipo Uri che puntasse ad un file del progetto: nell’esempio, la variabile logo puntava ad un’immagine all’interno della cartella Assets ed era perciò del tipo:

ms-resource:Assets/logo.png

Nella Release Preview, però, nel momento in cui andavo a creare una tile si scatenava un’eccezione, che mi comunicava che uno dei parametri passati in fase di creazione della tile non era valido. Una breve indagine e, grazie alla documentazione MSDN, ho scoperto che nella Release Preview il prefisso ms-resource è stato rimpiazzato da ms-appx:///.

Il percorso all’immagine utilizzata per la tile è diventata perciò:

ms-appx:///Assets/logo.png

Un ultimo consiglio

Un ultimo consiglio quando sviluppate un’applicazione Windows 8 è quello di separare gli stili standard da quelli creati ad hoc da voi: se dovete creare degli stili non includeteli perciò nel file StandardStyles.xaml, ma inseriteli in un file di tipo ResourceDictionary a parte e dichiaratelo nell’App.xaml.

In questo modo se, dalla Release Preview alla RTM, dovessero cambiare nuovamente alcuni stili standard, sarà sufficiente sovrascrivere il vecchio file con il nuovo, senza che corriate il rischio di perdere i vostri stili.

Come testare il Search contract di Windows 8

2012-02-23T10:00:00Z

Una delle caratteristiche più interessanti per le applicazioni di terze parti di Windows 8 è quella dei contract: si tratta, letteralmente, di contratti tra l’applicazione e il sistema operativo, che permetteno di integrarla con gli strumenti offerti da Windows 8.

Uno dei contract più utilizzati è il Search contract, che permette di includere la nostra applicazione tra i possibili risultati di una ricerca lanciata tramite il sistema operativo (tramite il pulsante Search presente nella barra laterale o semplicemente iniziando a digitare un testo all’interno del nuovo menu Start).

Implementare il Search contract è piuttosto semplice: si tratta di una delle voci disponibili nel menu Add New Item di Visual Studio 11. In automatico, sarà aggiunta:

La dichiarazione all’interno del file di manifest.
Una nuova pagina all’interno dell’applicazione, che mostrerà i risultati della ricerca.
L’aggiunta, all’interno del file App.xaml.cs, dell’evento OnSearchActivated, che è il punto di ingresso dell’applicazione nel caso in cui venga attivata da una ricerca.

Quest’ultimo evento restituisce un parametro di tipo SearchActivatedEventArgs, che contiene la proprietà QueryText con il testo cercato dall’utente. Dopodichè il controllo viene passato alla pagina di ricerca e sta a noi includere la logica necessaria per recuperare i risultati, a seconda della sorgente dati che sta alla base della nostra applicazione.

Durante la fase di testing potrebbe sorgere però il dubbio su come fare debug di uno scenario che, all’apparenza, non sembra testabile: l’attivazione dell’applicazione in seguito ad una ricerca. Fintanto che la ricerca viene lanciata mentre è in esecuzione non ci sono problemi: è sufficiente avviare il debugger e, una volta che l’applicazione è aperta, effettuare la ricerca.

L’utente però potrebbe anche lanciare la ricerca senza aver avviato in precedenza l’applicazione: in questo caso abbiamo la necessità di testare lo scenario in cui l’applicazione, in partenza, è chiusa, perciò il debugger non è attivo. Ad aggirare questo inconveniente ci viene in aiuto Visual Studio 11, grazie ad un’opzione che mi ha fatto scoprire il buon Corrado: se facciamo tasto destro sul progetto, scegliamo Properties, dopodichè ci spostiamo nella sezione Debug troveremo la voce Do not launch, but debug my code when it starts.

Quando questa opzione è attiva, premendo F5 sarà avviato solamente il debugger: nel momento in cui l’applicazione verrà eseguita (sia in maniera tradizionale tramite un tap sulla tile, sia in seguito ad una ricerca, sia in seguito all’utilizzo di uno share contract per la condivisione, ecc.) il debugger si collegherà, dandoci accesso a tutto quello a cui siamo abituati (breakpoint, watch, ecc.). A questo punto vi basta perciò, senza aprire l’applicazione, lanciare la ricerca per testare il vostro scenario.

Questo meccanismo funziona per qualsiasi test che richieda che, di base, l’applicazione non sia in esecuzione: un altro esempio potrebbe essere l’avvio dell’applicazione da una tile secondaria.

Windows Phone Commands: una preziosa estensione per Visual Studio

2012-02-21T10:00:00Z

Se siete sviluppatori Windows Phone (cosa molto probabile se state leggendo questo blog ) vi farà sicuramente piacere fare la conoscenza di Windows Phone Commands, una preziosa estensione di Visual Studio che va a migliorarne le funzionalità per quanto riguarda il testing delle applicazioni.

L’estensione è installabile dalla Visual Studio Gallery all’indirizzo http://visualstudiogallery.msdn.microsoft.com/945a718f-82d5-429f-a0b1-88bd6202c1a3

Una volta installata, si può accedere al tool dal menu View – Other windows di Visual Studio:

Il tool permette, dalla schermata principale, di collegarsi sia all’emulatore che ad un device reale. Dopodichè avremo accesso a diverse funzioni:

Informazioni sul device

Una volta connesso al dispositivo, il tool è in grado di mostrare alcune preziose informazioni come la build del sistema operativo, il tipo di processo e la quantità di memoria disponibile. Per collegarsi, è sufficiente premere l’icona del fulmine, selezionare dal menu a tendina il tipo di dispositivo e premere Connect.

Accedere a applicazioni ed impostazioni “nascoste” dell’emulatore

Come sappiamo, l’emulatore contiene una versione minimale del sistema operativo, che nasconde molte delle applicazioni e delle impostazioni che sono disponibili invece su un device reale. Questo a volte limita la possibilità di testare alcuni tipi di applicazioni (ad esempio, quelle in grado di integrarsi nell’hub Pictures) o determinate condizioni (ad esempio, i servizi di geolocalizzazione disabilitati). Tramite la sezione accessibile con la terza icona (quella con il simbolo di una cartella e di un piccolo ingranaggio) è possibile visualizzare l’elenco delle applicazioni native e delle voci della sezione Settings del sistema operativo, che possono poi essere aperte con un click.

Esplorare l’Isolated Storage

L’SDK di Windows Phone 7.5 ha introdotto un tool per esplorare l’isolated storage di un’applicazione: purtroppo però si tratta di un tool a linea di comando, poco intuitivo e user friendly. Il tool integrato all’interno dei Windows Phone Commands offre un’interfaccia visuale molto semplice, che permette di vedere i file e le cartelle all’interno dell’isolated storage; di scaricare un file sul computer per analizzarlo; di caricare un file dal nostro computer. Per accedere a questo tool è sufficiente premere sempre la terza icona dell’estensione: in cima alla sezione troverete tutte le applicazioni di terze parti installate sul telefono, identificate da un guid. Per ognuna di queste avrete una serie di opzioni (ad esempio, per lanciare o disinstallare l’applicazione): il terzo pulsante è quello che consente di accedere all’Isolated Storage Explorer.

Deploy e update di applicazioni

E’ possibile fare il deploy di applicazioni non solo dal tool Application Deployment o da Visual Studio, ma anche tramite questa estensione: il vantaggio è che potete anche installare uno XAP simulando un update, dandovi così la possibilità di testare anche scenari di aggiornamento della vostra applicazione (ad esempio, per verificare l’integrità dei dati o l’aggiornamento dello schema del database). Potete accedera a questaa opzione con la quarta icona, con il simbolo di un telefono e di un martello.

Editor visuale del file di manifest

Se siete sviluppatori Windows Phone dovreste conoscere molto bene il file di manifest: tale file, contenuto nella cartella Properties di ogni progetto, è un file XML contenente tutte le informazioni che identificano l’applicazione: titolo, numero di versione, feature del telefono utilizzate, ecc. Purtroppo Visual Studio non include un editor visuale che permette di modificare le varie voci: è necessario modificare manualmente il file. L’ultimo tool incluso in questa estensione cerca di sopperire a questo limite, offrendo un’interfaccia visuale per agire sul file di manifest. Potete accedere tramite l’ultima icona, con il simbolo di un foglio e di una pergamena.

Due importanti novità per il Marketplace di Windows Phone

2012-02-21T10:00:00Z

E’ fresca la notizia da parte del team di Windows Phone di due importanti cambiamenti che coinvolgono il Marketplace e che, soprattutto il secondo, hanno un impatto non indifferente (in senso positivo, a mio avviso) per gli sviluppatori. Ma vediamoli in dettaglio.

No more Zune

Attualmente ci sono tre modi per scaricare un’applicazione Windows Phone: dal telefono, dal marketplace web o da Zune. A partire dai prossimi giorni rimarrano attive solamente le prime due possibilità: non sarà più consentito acquistare o scaricare applicazioni dal Marketplace tramite Zune.

Personalmente, non mi sembra un grande danno: non è un segreto che la parte di gestione delle applicazioni di Zune sia piuttosto limitata e le statistiche in possesso di Microsoft hanno confermato che la maggior parte degli utenti utilizza il telefono e il marketplace web per cercare e installare le proprie applicazioni. Fino a che non verrà introdotta una gestione delle applicazioni più efficiente, non credo che qualcuno ne sentirà la mancanza

No Windows Phone 7.5, no party!

Windows Phone 7.5 è ormai una realtà da diversi mesi e non esiste device di prima generazione sul mercato che non abbia ricevuto l’aggiornamento. Per tale motivo e in previsione degli investimenti futuri di Microsoft sul marketplace in termini di funzionalità e sicurezza a partire dai prossimi giorni il download e l’acquisto di applicazioni dal Marketplace non sarà più disponibile per gli utenti che stanno ancora utilizzando la versione 7.0 di Windows Phone. Sarà possibile solamente sfogliare il Marketplace ma, in caso di download, comparirà un messaggio di errore. In questo modo, anche gli sviluppatori saranno sollevati dal compito di mantenere aggiornate due versioni distinte dell’applicazione, una per Windows Phone 7.0 e una per Windows Phone 7.5 e successivi (vi ricordo, infatti, che con il rilascio della versione 7.5 Microsoft aveva dato la possibilità agli sviluppatori di caricare e mantenere due XAP separati per entrambe le versioni del sistema operativo).

Anche questa, personalmente, mi sembra una buona notizia: spingere gli utenti ad avere un dispositivo il più aggiornato possibile è sicuramente una buona strategia, che avvantaggia tanto gli sviluppatori (che possono creare applicazioni senza preoccuparsi della retrocompatibilità) sia gli utenti (che possono beneficiare delle tante novità introdotte in Windows Phone 7.5).

Effettuare il parsing di un file XML in un’applicazione Metro style per Windows 8

2012-02-20T10:00:00Z

Mi sto cimentando nel compito di portare una delle applicazioni sviluppate da me e Marco Leoncini (la serie dedicata alle ricette italiane) da Windows Phone a Windows 8: una delle prime sfide che mi sono trovato ad affrontare è il porting dei dati. L’applicazione Windows Phone si appoggia infatti ad un database SQL CE, che al momento non è compatibile con Windows 8. La soluzione più semplice da noi scelta è l’utilizzo di un file XML: alla fine la struttura del database era molto semplice ed era costituita da un’unica tabella con l’elenco delle ricette.

Nel mio caso, non ho la necessità di memorizzare dati nello storage: il file XML contenente l’elenco delle ricette è incluso nel progetto di Visual Studio, dato che deve essere di sola lettura, in quanto nella mia applicazione l’utente può solo consultare le ricette e e non modificarle.

Il primo problema era perciò capire come leggere il file presente all’interno del progetto: in Windows Phone avrei utilizzato ad esempio il metodo GetResourceStream esposto dalla classe Application, che permette di accedere proprio ai file inclusi all’interno del progetto. Dopodichè avrei sfruttato la classe XDocument per effettuare il parsing dell’XML e avrei utilizzato LINQ to XML per manipolare i dati. Ecco un esempio:

Uri uri = new Uri("recipe.xml", UriKind.Relative);
StreamResourceInfo sri = Application.GetResourceStream(uri);
XDocument doc = XDocument.Load(sri.Stream);

// eseguo le query per recuperare i dati sul file XML

Il problema è che la classe Application non è disponibile in Windows 8 e quindi non si è in grado di utilizzare il metodo GetResourceStream. Spulciando nella documentazione di Windows 8 ho scoperto che tramite WinRT possiamo accedere a diversi tipi di storage: c’è quello locale dell’applicazione, ci sono le librerie di sistema (come la cartella Documents o Pictures) e così via. Uno di questi storage consente proprio di accedere alla “cartella” dell’applicazione, cartella che viene nascosta dal pacchetto preparato da Visual Studio nel formato .appx (che è l’equivalente dello XAP delle applicazioni Windows Phone, ovvero un pacchetto che contiene tutto il necessario per far funzionare l’applicazione, come librerie, contenuti, manifest, ecc.).

Una volta fatto il build della nostra applicazione Metro sytle andiamo nella cartella bin/Debug all’interno del nostro progetto: troveremo una cartella AppX, che rappresenta il contenuto del nostro pacchetto.

La prima cosa da fare è perciò quella di selezionare il file XML incluso nel nostro progetto e, dalla finestra Proprietà, impostare la Build Action su Content e Copy to Output Directory su Copy if newer. In questo modo il file XML verrà incluso all’interno del pacchetto.

A questo punto da codice possiamo accedervi grazie allo storage chiamato InstalledLocation, che espone il metodo GetFileAsync() che permette di recuperare un file dal pacchetto.

Importante! Eravamo già abituati con Windows Phone, ma in Windows 8 questo concetto è ancora più importante: tutte le operazioni che possono impiegare più di 50 millisecondi per essere completate sono asincrone in WinRT! La differenza, che ci semplifica un po’ l’utilizzo di questo metodo di programmazione, è che WinRT supporta nativamente le parole chiave async e await, introdotte in C# 5, che permettono di scrivere codice che all’apparenza sembra sincrono ma in realtà viene eseguito su thread differenti.

Il trucco in questo caso sta nel:

marcare la funzione che stiamo creando con la parola chiave async
anteporre alla chiamata al metodo asincrono la parola chiave await. In questo modo il codice che scriveremo sembrerà asincrono (una riga sotto l’altra), ma in realtà, grazie alla parola chiave await, le righe successive non verranno eseguite fino a che l’operazione asincrona non ha restituito un risultato.

Occhio all’inghippo

Prima di spiegarvi l’inghippo di cui sto parlando, eccovi l’XML di esempio che ho usato per questi test:

<?xml version="1.0" encoding="utf-8" ?>
<recipes>
  <recipe>
    <title>Pasta al pomodoro</title>
    <ingredients>Pasta, pomodoro, formaggio</ingredients>
  </recipe>
  <recipe>
    <title>Pasta al ragù</title>
    <ingredients>Pasta, pomodoro, ragù</ingredients>
  </recipe>
</recipes>

Ovviamente non è completo di tutti i dati relativi alla ricetta, ma ho volutamente usato un XML “minimale” con lo scopo di capire la procedura più corretta per effettuarne il parsing con WinRT.

L’inghippo che ho citato prima è il mio tentativo di sfruttare il metodo Parse della classe XDocument (che permette di trasformare un XML piatto in una struttura dati complessa “navigabile” grazie a LINQ) è fallito miseramente. Ecco un estratto del codice che ho cercato di utilizzare:

public async void GetAllRecipes()
{
    StorageFile file = await Windows.ApplicationModel.Package.Current.InstalledLocation.GetFileAsync("Recipes.xml");
    string xml = await FileIO.ReadTextAsync(file);
    XDocument doc = XDocument.Parse(xml);
    ...
  
}

In prima istanza ho recuperato il file Recipes.xml, sfruttando il metodo GetFileAsync citato poco fa. Dopodichè ho utilizzato un’altra classe di WinRT che permette di effettuare operazioni sui file, chiamata FileIO: nel mio caso, ho usato il metodo ReadTextAsync che, dato un oggetto di tipo StorageFile (ovvero un file recuperato da uno dei vari storage disponibili), lo tratta come testuale e memorizza in una stringa il testo contenuto (ovviamente, anch’esso in maniera asincrona).

Infine, ho utilizzato il metodo XDocument.Parse su tale stringa: il risultato però, durante l’esecuzione, è un’eccezione di tipo ArgumentException, con il messaggio Data at the root level is invalid. Line 1, position 1, che solitamente sta a indicare un file XML non valido o con degli errori di sintassi. Una breve verifica però mi ha fatto capire che c’era qualcosa non andava, dato che il file XML non conteneva alcun errore di sintassi.

Il trucco sta nel leggere il file XML come stream e di sfruttare il metodo XDocument.Load che, tra le varianti disponibili, accetta anche un oggetto di tipo Stream.

Ecco il codice corretto:

StorageFile storageFile = await Windows.ApplicationModel.Package.Current.InstalledLocation.GetFileAsync("Recipes.xml");
var file = await storageFile.OpenAsync(FileAccessMode.Read);
Stream stream = file.AsStreamForRead();
XDocument doc = XDocument.Load(stream);


ApplicationContext.Current.Recipes = doc.Descendants("recipes").Elements("recipe").Select(x => new Recipe
                                                              {
                                                                  Title = x.Element("title").Value,
                                                                  Ingredients = x.Element("ingredients").Value,
                                                                  Category = x.Element("category").Value
                                                              });

La differenza rispetto al codice precedente è che apriamo il file in lettura in maniera asincrona, tramite il metodo OpenAsync, e lo convertiamo in uno stream sfruttando il metodo AsStreamForRead esposto dall’oggetto file.

A questo punto possiamo inizializzare un’istanza della classe XDocument: le operazioni successive non differiscono in alcun modo da quelle che avremmo dovuto eseguire in un’applicazione Windows Phone o ASP.NET. Una volta in possesso del documento, ho recuperato tutti i nodi recipe e ho trasformato ogni nodo in un oggetto di tipo Recipe, che non fa altro che mappare 1 ad 1 le informazioni memorizzate nell’XML.

public class Recipe
{
    public string Title { get; set; }
    public string Ingredients { get; set; }
}

Una volta in possesso di una collezione di oggetti di tipo Recipe (nel mio caso, una List<Recipe>) possiamo utilizzarla a piacimento nella nostra applicazione: ad esempio, possiamo utilizzarla come sorgente dati di ua ListView o di una GridView, esattamente come faremmo in un’applicazione Windows Phone.

Ecco un esempio di ListView in XAML:

<ListView x:Name="Recipes">
    <ListView.ItemTemplate>
        <DataTemplate>
            <StackPanel>
                <TextBlock Text="{Binding Path=Title}" />
                <TextBlock Text="{Binding Path=Ingredients}" />
            </StackPanel>
        </DataTemplate>
    </ListView.ItemTemplate>
</ListView>

E il codice che si occupa di recuperare le ricette e visualizzare sfruttando la ListView:

public MainPage() 
{
    StorageFile storageFile = await Windows.ApplicationModel.Package.Current.InstalledLocation.GetFileAsync("Recipes.xml");
    var file = await storageFile.OpenAsync(FileAccessMode.Read);
    Stream stream = file.AsStreamForRead();
    XDocument doc = XDocument.Load(stream);


    List<Recipe> recipes = doc.Descendants("recipes").Elements("recipe").Select(x => new Recipe
                                                                          {
                                                                              Title = x.Element("title").Value,
                                                                              Ingredients = x.Element("ingredients").Value,
                                                                              Category = x.Element("category").Value
                                                                          }).ToList();
    Recipes.ItemsSource = recipes;
}

Visualizzare immagini GIF in un’applicazione Windows Phone

2012-02-18T10:00:00Z

L’altro giorno ho fatto due chiacchiere via Skype con Nazareno Manco, un amico sviluppatore, che si è trovato ad affrontare un problema nello sviluppo di un’applicazione Windows Phone: la sua necessità era quella di recuperare delle immagini dal web, da visualizzare all’interno di una pagina. Il problema è che queste immagini erano in formato GIF, che non è supportato da Silverlight e, di conseguenza, da Windows Phone.

Facendo una breve ricerca su Internet mi sono imbattuto in questo post di Jaime Rodriguez, in cui viene citata la libreria Image Tools per Silverlight, che offre una serie di controlli e converters che permettono di convertire in tempo reale un’immagine da un formato all’altro. Vediamo come utilizzarla per visualizzare imamgini GIF anche all’interno di un’applicazione Windows Phone.

Innanzitutto dovete includere le varie DLL di cui è composta la libreria all’interno dell’applicazione: il modo più semplice è utilizzare NuGet, così che venga copiato il necessario in automatico.

Dopodichè l’utilizzo di questa libreria si articola in due step:

L’utilizzo del controllo AnimatedImage, che va a sostiture il controllo Image e funge da contenitore all’interno del quale verrà visualizzata l’immagine.
L’utilizzo del converter ImageConverter, che si occupa di fare la conversione da un formato all’altro.

Entrambe le classi fanno parte del namespace ImageTools.Controls, che deve essere quindi dichiarato nello XAML:

xmlns:imagetools="clr-namespace:ImageTools.Controls;assembly=ImageTools.Controls"

A questo punto potete dichiarare come risorsa (locale nella pagina o globale a livello di applicazione) il converter ImageConverter, come nell’esempio:

<phone:PhoneApplicationPage.Resources>
    <imagetools:ImageConverter x:Key="ImageConverter" />
</phone:PhoneApplicationPage.Resources>

Ora vi basta inserire il controllo AnimatedImage, valorizzando la proprietà Source con l’indirizzo dell’immagine GIF e applicando il converter appena dichiarato.

<StackPanel>
    <imagetools:AnimatedImage x:Name="Image" Source="{Binding Path=ImageSource, Converter={StaticResource ImageConverter}}" />
</StackPanel>

Nel codice, la proprietà ImageSource è di tipo Uri e punta all’indirizzo di un’immagine GIF di esempio:

ImageSource = new Uri("http://www.nonstopgifs.com/animated-gifs/games/games-animated-gif-002.gif", UriKind.Absolute);

Il trucco per “far funzionare la magia” è l’utilizzo di uno dei decoder messi a disposizione dalla libreria Image Tools: è sufficiente registrarlo all’avvio dell’applicazione, specificando il formato dell’immagine che deve essere decodificato. Nel nostro esempio, dobbiamo utilizzare un GifDecoder, che viene registrato come nell’esempio:

public MainPage()
{
    InitializeComponent();
    ImageTools.IO.Decoders.AddDecoder<GifDecoder>();
}

A questo punto, grazie ai due controlli utilizzati in precedenza qualsiasi immagine GIF che verrà caricata sarà automaticamente convertita in modo da essere visualizzata: la cosa interessante è che, grazie anche al controllo AnimatedImage, sono supportate le GIF animate, per cui l’animazione verrà visualizzata correttamente.

Di seguito trovate il link per scaricare il progetto di esempio di riferimento di questo post.

Scarica il codice sorgente

Nuovo requisito per la certificazione: Application Testability

2012-02-18T10:00:00Z

Tra i requisiti tecnici indispensabili per passare la certificazione sul Marketplace è stata introdotta una nuova sezione, chiamata Application Testability. In realtà, si tratta di un requisito che si dava già per scontato: evidentemente però non tutti gli sviluppatori ne tenevano conto e perciò Microsoft ha deciso di “ufficializzarlo”, includendolo nella documentazione.

Cosa richiede questo requisito? Semplicemente che l’applicazione sia testabile in tutte le sue parti da parte dei tester del Marketplace: questo significa che dovete fornire tutti gli strumenti necessari per poter utilizzare tutte le funzionalità dell’applicazione. Ad esempio, se questa è legata ad un servizio che richiede delle credenziali (ad esempio, un client Twitter o Instapaper) dovete fornire delle credenziali di test; se l’applicazione è legata ad un client desktop (ad esempio, un tool di accesso remoto) dovete fornire anche un link per scaricare tale client.

Dove specificare queste informazioni? Nell’ultimo step della certificazione, in cui si seleziona la modalità di pubblicazione (privata, automatica, manuale, ecc.), c’è un campo apposito dove lasciare delle note per il tester: questo è il posto giusto dove specificare credenziali, link per il download e quant’altro.

Mi raccomando, non dimenticatevi! Se non fornite tutte le informazioni necessarie l’applicazione verrà sicuramente bocciata, costringendovi ad un nuovo “giro” di certificazione e allungando i tempi di pubblicazione della vostra applicazione.

Windows Phone SDK 7.1.1 rilasciato in versione finale

2012-02-17T10:00:00Z

Dopo non molto tempo dalla prima release dell’SDK 7.1.1 per Windows Phone in versione CTP, ecco arrivare la versione finale, dedicata principalmente al testing delle applicazioni con i nuovi device di fascia bassa. Questa SDK contiene infatti un nuovo emulatore, in grado di simulare sia i device tradizionali dotati di 512 MB di RAM, sia quelli più economici dotati di 256 MB. Come già ricordato nel post precedente, la ridotta quantità di memoria non è l’unica differenza rispetto ai device tradizionali: è però l’unico aspetto che ha un impatto sullo sviluppo di applicazioni, dato che quelle troppo onerose in termini di memoria consumata non saranno in grado di funzionare.

Per una panoramica completa su questa versione e sulle tecniche per ottimizzare il consumo di memoria delle applicazioni vi rimando ai due articoli da me scritti che sono stati pubblicati poco tempo fa sul blog MSDN.

Quali sono le principali differenze rispetto alla versione CTP di qualche tempo fa?

Trattandosi di una versione finale, questa SDK ha la licenza go live: può essere usata perciò per sviluppare applicazioni che verranno pubblicate sul Marketplace.
Ora l’SDK è localizzato in 10 lingue, al contrario della CTP che era disponibile solo in inglese.
Grazie a questa versione dell’SDK ora l’emulatore è compatibile con Windows 8: è sempre stato possibile installare i tool di sviluppo sulla Consumer Preview del nuovo OS di Microsoft (anche se con Visual Studio 2010, la versione 11 non è ancora supportata) ma, a causa dell’incompatibilità dell’emulatore, era possibile effettuare i test solo su un device reale. Con questa nuova versione l’emulatore torna ad essere funzionante e, di conseguenza, potete fare come il sottoscritto e sbarazzarvi di Windows 7 per iniziare ad usare solamente Windows 8

Potete scaricare la nuova versione all’indirizzo http://www.microsoft.com/download/en/details.aspx?id=29233: vi ricordo che non si tratta di una nuova versione dell’SDK ma di un aggiornamento, che va ad installarsi sopra la versione 7.1 dell’SDK. Non è necessario perciò disinstallare la versione precedente.

I primi passi con PhoneGap: accesso ai dati tramite Web API di MVC 4

2012-02-14T10:00:00Z

Come promesso la volta scorsa, avevo intenzione di scrivere un post con lo scopo di mostrare come raggiungere lo stesso obiettivo dell’altra volta (consumare un servizio REST sfruttando jQuery) utilizzando però un servizio realizzato da noi invece di uno già esistente (ricordate Bacom Ipsum)?

Nel momento in cui ho scritto quel post erano due le strade che stavo valutando utilizzando le tecnologie Microsoft: WCF Data Services oppure ASP.NET MVC. La prima è la soluzione più adatta, dato che WCF è una tecnologia che nasce espressamente per gestire servizi, ovvero tutte quelle applicazioni che tipicamente non richiedono un’interazione umana ma si limitano a esporre dati e/o operazioni che vengono poi consumate da altre applicazioni.

I servizi WCF non sono però così semplici da realizzare e, anche utilizzando la variante Data Services con il supporto al protocollo OData, non è offerto il supporto nativo a JSON come formato in cui esporre i dati (ma bisogna ricorrere ad alcuni espedienti, come quelli spiegati in questo post); supporto che invece è fornito da ASP.NET MVC, grazie alla possibilità di restituire una JsonResult come risultato di una Action definita in un controller.

ASP.NET MVC però non sempre è la tecnologia migliore, dato che il suo scopo, al contrario di WCF, è quello di realizzare applicazioni che sappiano rispondere all’interazione umana: siti, form, intranet, ecc. Se abbiamo già un sito realizzato con questa tecnologia e dobbiamo esporre alcune informazioni tramite servizi, allora può essere una buona soluzione quella di appoggiarsi direttamente a ASP.NET MVC e “ospitarli” in un controller. Se però dobbiamo mettere in piedi un sito basato su ASP.NET MVC solamente per esporre questi servizi, allora il gioco potrebbe non valere la candela.

Settimana scorsa è stata presentata ufficialmente la prima beta di ASP.NET MVC 4, che tra le altre cose ha introdotto proprio una novità che fa al caso nostro: le Web API. Tale tecnologia era conosciuta come WCF Web API e si trattava di un progetto open source ospitato su Codeplex, che ora è stata integrata all’interno di ASP.NET MVC e ha preso il nome ufficiale di ASP.NET Web API.

Questa tecnologia cerca di coniugare, in maniera più semplice, il meglio di entrambi i mondi: permette di realizzare servizi, usando però le stesse feature di ASP.NET MVC (funzionalità definite all’interno di un controller, routing, supporto a JSON, ecc.).

Quale miglior occasione per sperimentare con questa nuova tecnologia per realizzare un servizio da far consumare alla nostra applicazione Windows Phone realizzata con PhoneGap?

Cosa ci serve?

Per poter utilizzare Web API è necessario installare la beta di MVC 4, tramite la Web Platform Installer, la piattaforma di Microsoft che semplifica l’installazione di tool e prodotti legati al mondo web. Collegatevi perciò alla pagina http://www.asp.net/mvc/mvc4, cliccate sul link Install ASP.NET MVC 4 Beta e seguite le istruzioni.

Una volta completata l’operazione, dovreste trovare in Visual Studio un nuovo template nella sezione Web, chiamato ASP.NET MVC 4 Web Application. E’ quello che andremo ad utilizzare per realizzare il nostro servizio.

La nostra prima applicazione Web API

Dopo aver scelto di creare un nuovo progetto di tipo ASP.NET MVC 4, noteremo subito una differenza con MVC 3: i template a disposizione sono molto più numerosi. Tra questi, ci sarà anche quello che fa al caso nostro: Web API.

Selezioniamolo e diamo OK e verrà creato un progetto con la stessa identica struttura di un sito ASP.NET MVC: si tratta infatti di un progetto ibrido, che ospita sia un sito web con un template di default e alcune pagine fittizie, sia le Web Api. Se apriamo infatti la cartella Controllers, troveremo due classi già pronte: HomeController è un controller “standard”, che eredita dalla classe Controller e funge da controller per la vista web; ValuesController è invece il controller utilizzato per il servizio ed eredita dalla classe ApiController.

Se guardate il contenuto di questa classe noterete subito una prima differenza rispetto ai controller standard di MVC: le varie funzioni definite al suo interno non restituiscono una ActionResult, ma void o un tipo specifico (ad esempio, string), a seconda della funzione.

Questo perchè i servizi Web API sono servizi REST e, sfruttando il protocollo HTTP, rispondono semplicemente ai comandi resi disponibili da tale protocollo: GET, POST, PUT e DELETE. Le WebAPI sfruttano perciò una convenzione tale per cui è sufficiente che i metodi abbiano i nomi dei comandi perchè vengano invocati in seguito ad una richiesta HTTP con quel comando.

Le Web API sfruttano anche le stesse convenzioni di ASP.NET MVC per quanto riguarda il routing: di default, le API vengono esposte all’URL /api/nomedelcontroller, dove il nome del controller è il nome della classe esclusa la parola Controller (nel controller di default ValuesController, l’URL ad esempio è /api/values).

Le regole del routing, così come per i controller tradizionali che servono le pagine web, sono definite nel file global.asax.cs del progetto: è qui che dobbiamo agire, se, ad esempio, vogliamo cambiare la prima parte dell’URL (/api) oppure definire delle regole di routing più complesse.

Creiamo il nostro controller

Invece di utilizzare il controller di default ValuesController, andremo a crearne uno personalizzato: facciamo clic con il tasto destro sulla cartella Controllers, diamo un nome al controller (nell’esempio che seguirà l’ho chiamato ComicsController, dato che restituirà una serie di nomi di personaggi dei fumetti) e selezioniamo come template API Controller with empty read / write actions.

Avremo a disposizione un controller con la stessa struttura di quello che abbiamo visto in precedenza: la differenza è che questa volta i servizi verranno esposti tramite l’URL /api/comics.

Il controller che andremo a realizzare è semplicissimo: creeremo un array di stringhe contenente un elenco di personaggi dei fumetti, dopodichè definiremo una funzione Get generica (che restituisca l’intera lista), e una funzione Get specifica che, accettando un parametro in ingresso, permette di ritornare un elemento specifico della lista.

public class ComicsController : ApiController
{
   private string[] heroes = new string[] {"Iron Man", "Wolverine", "Hulk", "Thor", "Captain America"};


   // GET /api/comics
   public IEnumerable<string> Get()
   {
       return heroes;
   }

   // GET /api/comics/5
   public string Get(int id)
   {
       return heroes[id];
   }
}

Testare il funzionamento è molto semplice: lanciamo il debug del nostro progetto (magari avendo preventivamente selezionato di ospitare il sito su IIS Express tramite l’apposita opzione disponibile quando si fa clic con il tasto destro sul progetto in Solution Explorer); verrà caricato di default il sito “fittizio” generato dal template. Ci basta ora inserire l’URL del nostro servizio, come definito nel routing, per vedere il risultato (ad esempio, http://localhost:7392/api/comics, dove 7392 è la porta assegnata da IIS Express alla nostra applicazione).

Aggiungendo l’identificativo all’URL dopo lo /, ecco che verrà restituito uno specifico elemento della lista:

L’applicazione Windows Phone con PhoneGap

Dal punto di vista dell’applicazione Windows Phone realizzata con PhoneGap nulla cambia rispetto all’esempio del post precedente, se non l’indirizzo a cui far puntare la chiamate del metodo getJSON:

$("#btnCall").click(function () {
    $.support.cors = true;
    $.getJSON("http://localhost:7392/api/comics/", function (data) {
        $.each(data, function (index, element) {
            $("#result").append(element + "<br />");
        });
    });
});

Il risultato sarà il medesimo della volta scorsa, ovvero gli elementi contenuti all’interno della lista verranno mostrati a video:

Where in the world is JSON?

Se siete state attenti, avrete notato qualcosa di anomalo: quando avete chiamato il servizio appena creato con il browser, i dati vi sono stati restituiti nel formato XML. Eppure il metodo getJSON di jQuery è stato in grado di elaborare i dati e mostrarli a schermo: questo è stato possibile grazie ad una delle funzionalità più interessanti delle Web API, ovvero la possibilità per i servizi di restituire in automatico dati XML o JSON a seconda dell’header della richiesta HTTP. Volendo, è possibile inoltre creare dei formatter custom per restituire i dati in altri formati.

Possiamo avere una prova di questo meccanismo utilizzando un tool come Fiddler, che ci permette di intercettare il traffico di rete: qui sotto potete vedere due screenshot, il primo relativo alla chiamata effettuata tramite il browser e il secondo a quella fatta tramite jQuery e l’applicazione Windows Phone.

Come potete vedere, in base al valore dell’header Accept della chiamata HTTP il nostro servizio è stato in grado di restituire i dati nel formato richiesto.

In conclusione

Abbiamo concluso una panoramica molto semplice su Windows Phone, PhoneGap e accesso ai dati. Magari in futuro ritorneremo sull’argomento, parlando più approfonditamente dell’integrazione tra PhoneGap e le API native di Windows Phone. Come sempre, di seguito trovate il link per scaricare il codice sorgente dell’applicazione basata su Web API che abbiamo realizzato (per quanto riguarda quella Windows Phone potete riutilizzare la stessa del post precedente).

Scarica il codice sorgente

I primi passi con PhoneGap: accesso ai dati tramite un servizio REST – Parte 1

2012-02-12T10:00:00Z

Dopo aver visto qualche semplice esempio di utilizzo di PhoneGap, vediamo ora qualcosa di più complesso ma anche più utile: come importare dati esposti da un servizio. In questo post non andremo ad utilizzare le funzionalità specifiche di PhoneGap: quello che faremo sarà consumare un servizio REST, esattamente come faremmo con un’applicazione web tradizionale. C’è però qualche accorgimento da adottare per far si che il tutto funzioni anche su Windows Phone, a causa di qualche problemino di compatibilità tra jQuery e PhoneGap per Windows Phone.

Ma andiamo per gradi.

I servizi REST

I servizi di tipo REST sono una realtà sempre più diffusa, grazie anche alla semplicità di utilizzo indipendentemente dalla tecnologia utilizzata per “consumarli”. Al contrario dei web service tradizionali (basati su SOAP), i servizi REST si basano sul solo protocollo HTTP e si rifanno al concetto di risorsa più che di operazione. Cosa significa? Che un web service tipicamente espone una serie di operazioni, le quali vengono interpretate e utilizzate dal client grazie al protocollo SOAP; i servizi REST invece mappano questa richiesta sotto forma di risorsa, usando la normale notazione degli URL del protocollo HTTP. Ecco perciò che un’ipotetica funzione per recuperare le informazioni di un utente specifico verrebbe tradotta in un web service con il metodo getUser(int id), mentre in un servizio REST si tratterebbe semplicemente di richiamare l’URL /User/5 (dove 5 è l’ipotetico id di un utente).

Il vantaggio di questo meccanismo è evidente: lato client per consumare un web service è necessaria una libreria che sia in grado di tradurre la chiamata SOAP in un qualcosa di comprensibile per il linguaggio che stiamo utilizzando, a meno che non vogliamo elaborare manualmente le chiamate SOAP di richiesta e di risposta. E’ il caso ad esempio di Visual Studio: quando importiamo un servizio tramite l’opzione Add Service Reference viene generata una classe proxy, che non è altro che la rappresentazione sotto forma di classe in C# o VB.NET del servizio.

Con i servizi REST tutto ciò non è necessario: è sufficiente chiamare l’URL ed elaborare la risposta (tipicamente un XML o un JSON). Proprio per questo motivo, i servizi REST sono sicuramente la scelta più utilizzata nel mondo Javascript, in quanto non richiedono nessun tool o libreria particolari per essere utilizzati. E’ sufficiente effettuare una semplice chiamata HTTP verso l’URL ed elaborare la risposta (operazione resa ancora più semplice da librerie come jQuery, come vedremo tra poco).

Per il nostro esempio utilizzeremo un servizio JSON già pronto, nei prossimi post vedremo invece come crearne uno sfruttando ASP.NET MVC. Il servizio scelto per questo tutorial è quello offerto da, rullo di tamburi, Bacon Ipsum, fantastico sito che ho scoperto grazie ad un tweet di Lorenzo. Avete presente Lorem Ipsum, celebre sito utilizzato per la generazione di testi casuali? Questi testi solitamente vengono utilizzati in fase di montaggio di un prototipo o di un sito Internet, per dare l’idea dell’ingombro che occuperanno i testi. Bacon Ipsum fa la stessa cosa, ma sostituendo alle parole latine i nomi di vari tipi e tagli di carne (come steak, bacon, beef, ecc.).

Al di là della goliardia, questo sito fa al caso nostro perchè espone proprio un servizio REST che permette di recuperare testi generati a caso in formato JSON.

Creiamo il progetto

Non sto qui a ripetere punto per punto i passi per creare un progetto PhoneGap per Windows Phone, dato che li abbiamo già visti nel post precedente: ne approfitto solamente per segnalarvi che, rispetto al post precedente, è stata rilasciata una nuova versione di PhoneGap, la 1.4.1 per la precisione. Il procedimento per installarla è sempre lo stesso: scaricate il pacchetto e copiate il file PhoneGapStarter.zip nella cartella dei template di Visual Studio. Dopo aver creato un nuovo progetto PhoneGap, vi ritroverete la struttura che ormai dovrebbe esservi famigliare: andremo ad agire all’interno della cartella www per consumare il servizio e mostrare a video i testi generati a caso.

La prima cosa da fare è includere jQuery, la celebre libreria che semplifica la vita a chi sviluppa in Javascript, offrendo una sintassi più semplice e il supporto nativo per alcune delle funzionalità più utilizzate con questo linguaggio, come le chiamate asincrone e il parsing di dati JSON. Abbiamo due possibilità:

Utilizzare una CDN (Content Delivery Network), ovvero appoggiarci ad uno dei tanti servizi che ospitano in maniera distribuita jQuery. Microsoft stessa ci offre questa opportunità, mettendoci a disposizione sia la versione tradizionale per lo sviluppo che quella minificata per la distribuzione.
Scaricare jQuery dal sito ufficiale http://www.jquery.com e includere la libreria all’interno della cartella www di PhoneGap.

L’unico vantaggio di utilizzare una versione locale di jQuery è che saremo in grado di utilizzarla anche in assenza di connettività: dato che però la nostra demo ruota attorno all’utilizzo di un servizio REST esposto su Internet, direi che possiamo tranquillamente utilizzare la CDN di Microsoft tramite l’URL http://ajax.aspnetcdn.com/ajax/jQuery/jquery-1.7.1.js

Ci basta perciò inserire nella sezione <head> del file index.html la seguente riga:

<script type="text/javascript" src="http://ajax.aspnetcdn.com/ajax/jQuery/jquery-1.7.1.js"></script>

Aggiornamento: il buon Marco De Sanctis mi ha fatto giustamente notare che l’utilizzo di una CDN su un’applicazione mobile non è consigliata, in quanto se per un problema di sicurezza un hacker dovesse riuscire a “mettersi” in mezzo alla CDN sarebbe poi in grado, grazie alle API di PhoneGap, di accedere ai dati del vostro telefono. Il consiglio è quindi quello di scaricare jQuery in locale (tramite NuGet o direttamente dal sito ufficiale) e includerlo nella cartella www, dopodichè aggiungere una referenza alla copia locale invece che alla CDN, come nell’esempio:

<script type="text/javascript" src="scripts/jquery-1.7.1.js"></script>

A questo punto siamo pronti per sfruttare le feature di jQuery per interagire con il servizio REST di Bacon Ipsum. Nel prossimo post vedremo come fare!

I primi passi con PhoneGap per Windows Phone: creiamo il primo progetto

2012-02-11T10:00:00Z

Nel post precedente abbiamo iniziato a capire che cos’è PhoneGap e cosa significa al giorno d’oggi sviluppare un’applicazione mobile cross-platform. Ora iniziamo a “sporcarci le mani” e vediamo come iniziare a lavorare con PhoneGap, creando il nostro primo progetto e scrivendo qualche riga di codice.

Installare PhoneGap

Innanzitutto occorre scaricare il pacchetto di PhoneGap dal sito ufficiale all’indirizzo http://phonegap.com/. Il package contiene le librerie per tutte le principali piattaforme: la versione Windows Phone si presenta come un template per Visual Studio, incluso nel file PhoneGapStarter.zip, da copiare all’interno della cartella C:\Users\[USERNAME]\Documents\Visual Studio 2010\Templates\ProjectTemplates\Silverlight for Windows Phone, dove [USERNAME] è ovviamente il nome del vostro account utente.

Una volta fatta questa operazione, se avviate Visual Studio e scegliete di creare un nuovo progetto, nella sezione Visual C# (sia per le versioni Express che per le versioni a pagamento) troverete un nuovo template chiamato PhoneGapStarter: date un nome al progetto, premete Ok e Visual Studio inizierà la creazione includendo tutti i file necessari a PhoneGap.

La struttura di un progetto PhoneGap

Il progetto PhoneGap, rispetto ad un progetto tradizionale Windows Phone, include una serie di file e cartelle in più, che sono quelle utilizzate da PhoneGap. Quella più importante è la cartella www, che contiene l’applicazione web e propria e, di default, contiene:

il file index.html, che è la pagina che viene caricata all’avvio
il file master.css, che è il foglio di stile di default che viene utilizzato
il file phonegap-1-3-0.js, che è la libreria Javascript che funge da wrapper verso le chiamate native della piattaforma e con la quale andrete ad interagire per sfruttare le funzionalità native del device.

L’applicazione PhoneGap è a tutti gli effetti una vera e propria applicazione web, per cui all’interno di questa cartella potete inserire tutte le risorse che volete, incluse librerie come jQuery o Knockout.js, molto conosciute nell’ambito dello sviluppo web. In automatico, all’avvio, PhoneGap compilerà un file chiamato GapSourceDictionary.xml includendo i riferimenti a tutte queste risorse, per poi poterle utilizzare.

La struttura della pagina index.html

Il file index.html non è nient’altro che una normalissima pagina HTML5 (lo riconoscete dal doctype), con già inclusi al suo interno gli script e i fogli di stile standard di PhoneGap che vi ho elencato prima.

In più, la pagina include la sottoscrizione, tramite un event listener di Javascript, all’evento deviceready, che viene invocato da PhoneGap nel momento in cui l’applicazione è stata inizializzata ed è pronta a interagire con l’utente. Tale sottoscrizione viene gestita dalla funzione onDeviceReady (definita poco sotto), in cui potete includere il codice che volete eseguire all’avvio dell’applicazione. Di default, questa funzione contiene semplicemente due righe di codice Javascript per:

Mostrare il classico Hello World indicando anche la versione di PhoneGap in uso sfruttando la funzione window.device.phonegap
Dato che fare debug di Javascript in una pagina che gira all’interno di un browser mobile non è così agevole come con un browser tradizionale, PhoneGap include una funzione Javascript che permette di scrivere nella Output Window di Visual Studio, che si chiama console.log. Di default, il progetto di PhoneGap include la scrittura di un messaggio di prova nella Output Window.

Mostriamo una MessageBox

Iniziamo a mettere mano al progetto con un esempio molto semplice: mostriamo a video una MessageBox nel momento in cui l’utente fa click su un pulsante. La parte di rendering del pulsante e di gestione del click viene affidata ad HTML e Javascript standard; la visualizzazione dell’alert invece verrà fatta utilizzando una funzione proprietaria di PhoneGap.

Vediamo l’HTML.

<body>
    <input onclick="onClick()" type="button" value="Click me" />
</body>

La pagina è composta da un semplice div, a cui abbiamo dato l’id welcomeMsg per poterlo identificare in Javascript, e un tag input, che rappresenta il nostro bottone, del quale gestiremo l’evento onclick tramite la funzione onClick(), che è così definita:

<script type="text/javascript">
    function onClick() {
        navigator.notification.alert("This is a message box");
    }
</script>

Qui entra in gioco PhoneGap: la funzione navigator.notification.alert provvede a interfacciarsi con le API native di Windows Phone e a mostrare una MessageBox con il testo che viene passato come parametro della funzione. Lanciamo l’applicazione tramite il debugger di Visual Studio, facciamo clic sul pulsante e vedrete comparire la MessageBox nativa di Windows Phone con il testo che avete scelto.

In conclusione

In questo post abbiamo visto un esempio molto semplice: nel prossimo post vedremo qualcosa di più approfondito, che ci permettà di sfruttare più a fondo le potenzialità di Windows Phone. In allegato, trovate il codice sorgente del semplice esempio realizzato in questo post.

Scarica il codice sorgente

I primi passi con PhoneGap per Windows Phone

2012-02-10T10:00:00Z

Vi ho già parlato un po’ di tempo fa di PhoneGap, un framework sviluppato da Nitobi (società recentemente acquisita da Adobe) con uno scopo decisamente ambizioso: realizzare applicazione cross – platform in grado di girare su qualunque dispositivo mobile. L’approccio è lo stesso utilizzato dalle applicazioni web mobile (HTML + Javascript), ma con una marcia in più: PhoneGap infatti espone tramite una libreria Javascript una serie di funzioni che vanno a interagire direttamente con il device, permettendo di utilizzare funzionalità native (come i servizi di geolocalizzazione, i sensori, ecc.) che altrimenti non sarebbero utilizzabili solamente tramite HTML / JS standard. Queste funzioni sono univoche, ma “sotto il cofano” PhoneGap si preoccupa di mapparle sulle chiamate native della piattaforma specifica: ecco perciò che, ad esempio, per mostrare un alert utilizzeremo sempre la funzione Javascript navigator.notification.alert, la quale verrà poi declinata da PhoneGap per mostrare la MessageBox di Windows Phone, di iOS o di Android.

Per questo motivo un progetto PhoneGap non è una generica applicazione web, ma viene creato un progetto specifico per ogni piattaforma, da aprire e manipolare con i tool di sviluppo specifici (Visual Studio per Windows Phone, XCode per iOS e Eclipse per Android).

E dove sta l’interoperabilità, direte voi? Ogni progetto PhoneGap include una cartella, chiamata www, che include tutti i file necessari della vera e propria applicazione web: è quello il progetto su cui andremo a lavorare, che poi andremo a duplicare per ogni piattaforma (anche se in realtà c’è una soluzione alternativa, di cui vi parlerò più avanti). Questa applicazione web viene poi inclusa all’interno dell’app nativa tramite il controllo browser che è disponibile per ogni piattaforma (ad esempio, WebBrowser in Windows Phone).

Applicazioni native vs applicazioni cross – platform

Il dibattito sull’utilizzo di applicazioni cross – platform rispetto a quelle native è molto acceso tutt’oggi. Ma quali sono i vantaggi e gli svantaggi di questo approccio?

I vantaggi

Con l’aumentare del numero di piattaforme mobile disponibili sul mercato molte società si sono trovate davanti un problema non indifferente: sviluppare un’applicazione per ogni piattaforma ha un costo non trascurabile e il gioco può non valere la candela, soprattutto nel caso in cui il mobile non sia il core business della società.

In più, una delle cose che incide maggiormente sui costi è la difficoltà ad acquisire le conoscenze necessaria: HTML e Javascript sono tecnologie molto diffuse e non sono una prerogativa degli sviluppatori, al contrario dei linguaggi nativi come C#, Objective-C e Java.

Strumenti come PhoneGap permettono di prendere due piccioni con una fava: l’applicazione viene sviluppata una volta sola ed è possibile demandare il compito anche ad uno sviluppatore web, senza necessità di cercare uno sviluppatore mobile ad hoc per ogni piattaforma (e, date le differenze, è molto difficile trovare una persona con piena conoscenza di ognuna di esse).

Gli svantaggi

Lo svantaggio principale è che l’interoperabilità in certi casi è una chimera, a causa delle grandi differenze nella User Experience proposta da ogni piattaforma: è praticamente impossibile realizzare un’applicazione che offra una user experience e abbia una grafica che si adatti bene ad ogni singola piattaforma. Prendete un’applicazione iPhone e una Windows Phone: le differenze sono numerosissime, a partire dalla grafica, passando per alcuni paradigmi di navigazione (pensiamo al Panorama di Windows Phone).

In più, non si tratta solo di UX ma anche di sfruttare appieno le funzionalità della piattaforma: pensiamo alle Live Tile, forse la caratteristica più particolare delle applicazioni Windows Phone. Si tratta di una feature che non ha un corrispettivo sulle altre piattaforme: se vogliamo sfruttarla, dovremo perciò scrivere del codice non interoperabile. L’alternativa è quella di non usare questa caratteristica, ma ciò si traduce in un abbassamento della qualità: a parità di funzioni dell’applicazione, l’utente finale ne sceglierà sicuramente una in grado di sfruttare le Live Tile.

Infine è importante considerare il discorso performance: un’applicazione cross – platform non sarà mai performante quanto un’applicazione nativa. Inoltre, tanto più c’è la necessità di interagire con il device, tanto più soluzioni di questo tipo diventano complesse da realizzare.

Credo inoltre che, dal punto di vista grafico, Windows Phone sia la piattaforma più difficile: iOS, ad esempio, ha un tipo di interfaccia molto semplice e pulita, facilmente replicabile da un’applicazione web (tanto che con librerie come jQuery Mobile è possibile realizzare applicazioni web mobile praticamente indistinguibili da un’applicazione nativa). Windows Phone ha invece un’interfaccia più particolare e che fa uso di paradigmi come Panorama e Pivot che sono più difficili da ricreare in HTML.

Il rischio perciò è di realizzare applicazioni con un look & feel lontano dalle guidelines di Metro e quindi in grado di attrarre meno gli utenti rispetto ad un’app nativa, facendo nascere così la necessità di dover sviluppare comunque un’interfaccia diversa per ogni sistema.

E quindi?

Non c’è un vincitore in realtà: tutto dipende dal tipo di applicazione che dovete sviluppare, dalle funzionalità del device che volete sfruttare e dal budget che avete a disposizione. Le applicazioni native hanno e avranno sempre comunque una marcia in più, perlomeno fino a quando HTML e Javascript non saranno supportati nativamente (un po’ come sta avvenendo per le applicazioni Metro style di Windows 8).

Chiudo questa “introduzione teorica” con il link ad un bell’articolo di Marco De Sanctis di ASPItalia, che traccia un quadro molto preciso della situazione attuale per quanto riguarda lo sviluppo di applicazioni cross platform.

PhoneGap e Windows Phone

Il matrimonio tra PhoneGap e Windows Phone risale all’uscita di Windows Phone 7.5: questo perchè PhoneGap si appoggia alla tripletta HTML5 / CSS 3 / Javascript, supportata pienamente da Internet Explorer solo a partire dalla versione 9 (vi ricordo che Windows Phone 7 era basato invece su una versione intermedia tra la 7 e la 8).

La versione 1.3 di PhoneGap (che è anche la release più recente) è stata la prima a supportare pienamente Windows Phone, come potete vedere da questa tabella: PhoneGap supporta numerosi altri OS mobile (come Symbian o Bada), ma Windows Phone, iOS (a partire dall’iPhone 3GS in poi) e Android sono le uniche 3 piattaforme alle quali è fornito un supporto completo.

Come già anticipato, tale applicazione viene poi renderizzata attraverso un controllo WebBrowser, il quale è in grado di interagire con il sistema tramite alcune feature messe a disposizione dal controllo (una su tutte, la possibilità di intercettare una funzione Javascript in una pagina e gestirla all’interno dell’applicazione). Se volete approfondire l’argomento, vi consiglio questo articolo del mio amico Ugo pubblicato sul blog di MSDN Italia, dedicato proprio al controllo WebBrowser e alle sue potenzialità.

Nel prossimo post

Dopo questa introduzione teorica, nel prossimo post inizieremo a vedere come usare concretamente PhoneGap: scaricheremo il pacchetto, lo installeremo e inizieremo a lavorare con Visual Studio per creare una semplice applicazione.

Nuova versione di SQL CE Toolbox: supporto a VB, log delle query e stringa di connessione read-only

2012-02-06T10:00:00Z

Vi ho già parlato più volte di SQL CE Toolbox, sia su questo blog che sulle pagine di ASPItalia: è una utilissima estensione di Visual Studio che vi semplifica la vita quando dovete lavorare con database SQL CE nelle applicazioni Windows Phone.

E’ di recente uscita la versione 2.6, che aggiunge tre feature molto utili.

Supporto a VB.NET

Fino ad oggi SQL CE Toolbox era pensato solo per gli sviluppatori C#, in quanto era disponibile la generazione del DataContext e delle varie entità solamente in C#. Con questa nuova versione è disponibile il supporto anche per VB.NET: trovate l’opzione direttamente nella schermata di generazione del DataContext, accessibile dal menu contestuale che compare facendo clic con il tasto destro su un database all’interno del tool.

Log delle query

Come saprete se avete letto il mio articolo introduttivo sull’argomento, la tecnologia utilizzata da Windows Phone per l’accesso ai dati memorizzati in un database SQL CE è LINQ to SQL, ORM di casa Microsoft passato in secondo piano con l’evoluzione del fratello maggiore Entity Framework ma tornato alla ribalta su Windows Phone, in virtù della maggiore semplicità e leggerezza.

Utilizzare un ORM, in particolar modo su Windows Phone, significa non scrivere mai query SQL a mano, ma lavorare con gli oggetti, che verranno poi tradotti in righe da inserire nelle varie tabelle del database. A volte, soprattutto in caso di comportamenti anomali o problemi di performance, sarebbe interessante vedere effettivamente il codice SQL generato. Il DataContext generato da LINQ to SQL supporta la proprietà Log, che permette di specificare un output nel quale vogliamo mostrare le query SQL eseguite. Su Windows Phone non è così semplice sfruttare questa feature, dato che non è disponibile una console e i file possono essere salvati solamente nell’Isolated Storage, rendendo complicata l’operazione di estrazione e visualizzazione.

Il DataContext generato dalla nuova versione di SQL CE Toolbox include un’implementazione della classe TextWriter che va a scrivere il log nella Output Window di Visual Studio nel momento in cui l’applicazione viene eseguita con il debugger collegato. Utilizzarlo è molto semplice: vi basta impostare la proprietà LogDebug del DataContext a true, come nell’esempio:

using (OrdersContext context = new OrdersContext(OrdersContext.ConnectionString))
{
    context.LogDebug = true;
    context.Orders.InsertOnSubmit(order);
    context.SubmitChanges();
}

Il risultato sarà, come poteve vedere nello screenshot, che nella Output Window di Visual Studio verrà scrittà la query SQL effettivamente eseguita da LINQ to SQL.

Stringa di connessione read-only

Una caratteristica dei database in Windows Phone è il supporto alle connessioni in sola lettura: potete infatti aggiungere un database SQL CE già pronto e popolato (sotto forma di file .sdf) direttamente all’interno del vostro progetto, per poi accedervi dall’applicazione. La stringa di connessione per questo tipo di database è caratterizzata da:

Il prefisso appdata:/ come punto di partenza della stringa di connessione (e corrisponde alla root del progetto), mentre per i database memorizzati nello storage viene utilizzato il prefisso isostore:/
L’accesso in sola lettura: l’unico modo per inserire dati in un database SQL CE su Windows Phone è mantenerlo nell’Isolated Storage.

Con la versione 2.6 di SQL CE Toolbox il DataContext generato contiene anche una stringa di connessione in modalità read-only per questo tipo di approccio. L’utilizzo è molto semplice, nella vostra applicazione è sufficiente specificare il tipo di connessione in fase di utilizzo del DataContext, come nell’esempio:

//database memorizzato nell'isolated storage
using (OrdersContext context = new OrdersContext(OrdersContext.ConnectionString))
{
    context.Orders.InsertOnSubmit(order);
    context.SubmitChanges();
}

//database aggiunto come file di progetto
using (OrdersContext context = new OrdersContext(OrdersContext.ConnectionStringReadOnly))
{
    context.Orders.InsertOnSubmit(order);
    context.SubmitChanges();
}

Conclusione

Potete scaricare SQL CE Toolbox dalla pagina ufficiale su Codeplex: occhio che, essendo un’estensione, è compatibile solamente con le versione a pagamento di Visual Studio.