Windows Phone, Mappe, Microsoft, MVP, SQLite, DotNetLombardia, Windows 8, SQL Lite

Nella serata di ieri Microsoft ha rilasciato un update per l’SDK di Windows Phone dedicata al supporto per Windows Phone 7.8, la nuova versione del sistema operativo dedicata ai device della precedente generazione. Vi ricordo, infatti, che Windows Phone 8, in virtù del nuovo kernel, non è disponibile come update per i device già presenti sul mercato: per non abbandonare però chi ha dato fiducia alla nuova piattaforma sin dall’inizio, Microsoft sta per rilasciare la versione 7.8, che va ad introdurre alcune delle feature di Windows Phone 8 anche sulla vecchia piattaforma.

Le novità sono principalmente consumer: supporto ai nuovi formati di tile, possibilità di cambiare il motore di ricerca di default, integrazione di Bing come provider di sfondi per la lock screen, ecc.

Dal punto di vista dello sviluppo, invece, nulla cambia: non sono state aggiunte feature o nuove API che possono essere utilizzate dagli sviluppatori. L’unica novità a riguardo è il supporto ai nuovi formati di tile anche per le applicazioni di terze parti. Per sfruttarla, però, non sono state incluse nuove API, ma occorre utilizzare il meccanismo della reflection: la DLL di sistema che si occupa di interagire con le tile viene caricata a runtime e, se l’applicazione è in esecuzione su un device aggiornato a Windows Phone 7.8, è possibile sfruttarla per supportare i nuovi template e le nuove dimensioni.

La strada più semplice per sfruttare questa feature è utilizzare Mangopollo, di cui vi ho parlato in questo articolo pubblicato sul blog di MSDN Italia. Tale libreria “nasconde” il meccanismo della reflection offrendo delle API di alto livello, che consentono di gestire le nuove tile con l’approccio a cui siamo già abituati.

Dato che non ci sono nuove API, a cosa serve la nuova SDK? Innanzitutto occorre precisare che non si tratta di una major release ma di una patch, compatibile sia con la versione 7.1 (se non avete la versione 7.1.1, ci penserà questa patch ad aggiornarlo) che con la versione 8 dell’SDK . Tale aggiornamento andrà ad aggiungere, all’elenco degli emulatori con cui è possibile testare l’applicazione, anche due versioni dotate di Windows Phone 7.8: una normale e una con 256 MB di RAM, per simulare l’esecuzione sui device low cost.

In questo modo potrete testare il comportamento della vostra applicazione anche con il nuovo aggiornamento. Potete scaricare il nuovo update dall’indirizzo http://www.microsoft.com/en-us/download/details.aspx?id=36474

This entry was posted on Wednesday, 23 January, 2013 and is filed under Windows Phone . You can follow any responses to this entry through here . You can leave a response.

Le mappe in Windows Phone 8 sono probabilmente il segno più importante dei buoni rapporti tra Nokia e Microsoft: l’applicazione delle mappe installata su tutti i dispositivi Windows Phone 8, anche quelli prodotti da società diverse, è basata sulla cartografia di Nokia.

La novità più interessante per gli sviluppatori è che non solo l’applicazione vera e propria, ma anche il controllo utilizzabile all’interno delle applicazioni di terze parti è stato aggiornato, con l’introduzione di molti miglioramenti: in primis, le performance, che nel vecchio controllo Bing Maps erano spesso deludenti, soprattutto se si inserivano diversi elementi in overlay (come i punti di interesse).

Inoltre, il nuovo controllo offre molte più opzioni: è possibile abilitare la visualizzazione 3D degli edifici, supportare la visualizzazione notturna, calcolare facilmente percorsi da un punto all’altro, ecc.

Aggiungere il controllo in un’applicazione è molto semplice: innanzitutto nello XAML è necessario aggiungere una reference al namespace Microsoft.Phone.Maps:

xmlns:maps="clr-namespace:Microsoft.Phone.Maps.Controls;assembly=Microsoft.Phone.Maps"

Dopodichè è possibile inserire il controllo vero e proprio dichiarandolo nello XAML, come nell’esempio:

<maps:Map
    x:Name="myMap"
    Center="30.712474,-132.32691"
    ZoomLevel="17"
    Heading="45"
    Pitch="25"
    CartographicMode="Road"
    ColorMode="Dark"
    PedestrianFeaturesEnabled="True"
    LandmarksEnabled="True"
    />

In questo esempio potete vedere alcune delle proprietà disponibili:

• Center è la posizione nella quale la mappa è centrata. Accetta un parametro di tipo GeoCoordinate, che è un oggetto complesso che contiene tutte le informazioni geografiche riguardo alla posizione, come latitudine, longitudine, altitudine, ecc.
• ZoomLevel è il livello di zoom della mappa, da 1 (molto lontano) a 20 (molto vicino)
• Heading rappresenta la rotazione della mappa rispetto al centro
• Pitch rappresenta l’altezza della visuale rispetto all’orizzonte
• CartographicMode è il tipo di mappa visualizzato, a scelta tra Aerial, Road, Terrain e Hybrid.
• ColorMode può essere utilizzato per migliorare la leggibilità della mappa in condizioni di scarsa luminosità (Dark) oppure in ambienti molto luminosi (Light)
• LandmarksEnabled permette di abilitare la rappresentazione 3D di alcuni luoghi celebri, come monumenti, chiese e musei.
• PedestrianFeaturesEnabled permette di mettere in evidenzia elementi del paesaggio di interesse per chi si sta muovendo a piedi, come scale e sottopassaggi

Una delle feature più interessanti nel nuovo controllo per le mappe è che è veramente semplice aggiungere un layer, ovvero una collezione di elementi che vengono visualizzati sopra la mappa. Ecco un esempio di codice:

private void OnAddShapeClicked(object sender, RoutedEventArgs e)
{
    MapOverlay overlay = new MapOverlay
                             {
                                 GeoCoordinate = myMap.Center,
                                 Content = new Ellipse
                                               {
                                                   Fill = new SolidColorBrush(Colors.Red),
                                                   Width = 40,
                                                   Height = 40
                                               }
                             };
    MapLayer layer = new MapLayer();
    layer.Add(overlay);

    myMap.Layers.Add(layer);
}

Per ogni elemento che voglio visualizzare sulla mappa creiamo un oggetto di tipo MapOverlay, che ha due proprietà importanti: GeoCoordinate, ovvero le coordinate geografiche in cui deve essere posizionato l’elemento, e Concent, che una proprietà di tipo object e accetta perciò qualsiasi controllo XAML. In questo esempio ho creato un cerchio di colore blu, sfruttando il controllo Ellispe, che viene posizionato nella stessa posizione in cui la mappa è stata centrata.

Infine creo un oggetto di tipo MapLayer, che è una collezione di MapOverlay: nell’esempio andiamo ad aggiungere solo il cerchio blu creato in precedenza, ma avrei potuto creare altri oggetti di tipo MapOverlay e aggiungerli allo stesso layer (oppure ad un altro differente). L’ultimo passaggio è quello di aggiungere il layer alla collezione Layers del controllo mappa.

Ecco il risultato finale:

Si tratta di una feature molto potente: dato che la classe MapOverlay utilizza una generica proprietà Content, è possibile personalizzare a piacimento gli elementi da mostrare sulla mappa. C’è però un prezzo da pagare: l’SDK non include nulla di già pronto per implementare scenari di uso comune come l’utilizzo di segnaposto o la visualizzazione della posizione dell’utente sulla mappa.

Ad ovviare a questa mancanza viene in aiuto il Phone Toolkit, che probabilmente conoscete già dato che è uno dei toolkit essenziali per qualunque sviluppatore Windows Phone, dato che contiene molti controlli e utility che non sono disponibili nell’SDK. Il Phone Toolkit è disponibile su Codeplex, ma il modo più semplice per aggiungerlo al nostro progetto è utilizzare NuGet. Nell’ultima release Microsoft, oltre ad aver aggiunto nuovi controlli ed animazioni, ha introdotto anche alcune utility per il controllo mappe. Nel nostro scenario ci vengono in aiuto due controlli: UserLocationMarker e Pushpin. Entrambi hanno lo stesso comportamento: sono elementi che vengono posizionati in overlay sulla mappa in una posizione specifica; l’utente, inoltre, ha la possibilità di interagire con gli stessi, dandogli la possibilità, ad esempio, di fare tap su un segnaposto per vedere i dettagli del punto di interesse selezionato. L’unica differenza tra i due controlli è visiva: il Pushpin (nell’immagine di sinistra) nasce per evidenziare punti di interesse nella mappa e ha lo stesso look & feel del controllo Pushpin che era disponibile in Bing Maps; il controllo UserLocationMarker (a destra) serve invece per evidenziare la posizione dell’utente.

Come utilizzare i pushpin

In questo post andiamo a vedere innanzittutto il modo più semplice per aggiungere un controllo Pushpin o UserLocationMarker: tramite lo XAML. Innanzitutto dovete dichiarare il seguente namespace:

xmlns:toolkit="clr-namespace:Microsoft.Phone.Maps.Toolkit;assembly=Microsoft.Phone.Controls.Toolkit"

Dopodichè potete utilizzarli nel modo seguente:

<maps:Map x:Name="myMap">
    <toolkit:MapExtensions.Children>
        <toolkit:UserLocationMarker x:Name="UserLocationMarker" />
        <toolkit:Pushpin x:Name="MyPushpin" Content="My Position"></toolkit:Pushpin>
    </toolkit:MapExtensions.Children>
</maps:Map>

Innanzitutto dovete utilizzare le MapExtensions¸una delle estensioni disponibili nel tookit, la quale ha una proprietà Children che funge da contenitore per tutti gli elementi che saranno mostrati sulla mappa. Nel codice sopra riportato potete vedere un esempio di entrambi i controlli: l’unica differenza è che, nel caso del controllo Pushpin, vado ad impostare anche la proprietà Content, che è l’etichetta che viene visualizzata sul segnaposto.

Possiamo gestire il posizionamento di questi controlli direttamente da codice:

UserLocationMarker marker = (UserLocationMarker)this.FindName("UserLocationMarker");
marker.GeoCoordinate = myMap.Center;

Pushpin pushpin = (Pushpin)this.FindName("MyPushpin");
pushpin.GeoCoordinate = new GeoCoordinate(30.712474, -132.32691);

Dopo aver recuperato un riferimento al controllo utilizzando il metodo FindName (utilizzando come parametro il valore della proprietà xName che abbiamo assegnato) siamo in grado di interagire con la proprietà GeoCoordinate. Inoltre, entrambi i controlli espongono l’evento Tap, che viene scatenato nel momento in cui l’utente fa tap sul segnaposto. Possiamo utilizzare per interagire con l’utente, come nell’esempio:

 

<maps:Map x:Name="myMap" Height="400">
    <toolkit:MapExtensions.Children>
        <toolkit:Pushpin x:Name="MyPushpin" Content="My Position" Tap="MyPushpin_OnTap" />
    </toolkit:MapExtensions.Children>
</maps:Map>

private void MyPushpin_OnTap(object sender, GestureEventArgs e)
{
    Pushpin pushpin = sender as Pushpin;
    MessageBox.Show(pushpin.Content.ToString());
}

Nello XAML abbiamo dichiarato un event handler per gestire l’evento Tap: nel codice recuperiamo il riferimento al pushpin che è stato selezionato (tramite l’oggetto sender che viene passato come parametro) e ne mostriamo l’etichetta tramite una MessageBox.

Un converter per lavorare con le coordinate

Se avete già avuto l’opportunità di utilizzare  i servizi di geo localizzazione disponibili nelle nuove API del Windows Runtime avrete notato una cosa curiosa: la classe utilizzata dalle API per memorizzare le informazioni sulla posizione è chiamata Geolocalization, mentre quella utilizzata dal controllo mappa è GeoLocalization. Sfortunatamente non si tratta di un refuso, sono a tutti gli effetti due classi differenti: il risultato è che non potete prendere le coordinate restituite dai servizi di geo localizzazione è assegnarle direttamente alla mappa, ma è necessario effettuare una conversione. Fortunatamente il Phone Toolkit include un extension method per questo scopo, utilizzabile semplicemente aggiungendo il namespace Microsoft.Phone.Maps.Toolkit nel vostro codice:

Geolocator geolocator = new Geolocator();
Geoposition geoposition = await geolocator.GetGeopositionAsync();
myMap.Center = geoposition.Coordinate.ToGeoCoordinate();

L’extension method ToGeoCoordinate() si occupa di convertire l’oggetto Coordinate restituito dalla classe Geolocator nel tipo corretto richiesto dal controllo mappa.

Nel prossimo post

In questo post abbiamo visto alcuni scenari base di utilizzo della mappa: sono utili per capire come il Phone Toolkit ci può essere d’aiuto nello sviluppo di un’applicazione che utilizza le mappe, ma non sono altrettanto utili in uno scenario reale. Ad esempio, solitamente un’applicazione reale ha la necessità di mostrare più di un segnaposto sulla mappa, per mostrare i punti di interesse intorno all’utente, come ristoranti o negozi. Nel prossimo post vedremo come raggiungere questo obiettivo utilizzando alcuni dei concetti chiave che ogni sviluppatore Windows Phone dovrebbe conoscere: template e binding.

This entry was posted on Tuesday, 22 January, 2013 and is filed under Windows Phone Tutorials . You can follow any responses to this entry through here . You can leave a response.

Proprio pochi giorni fa vi ho parlato, tramite un post, dello stato attuale del supporto a SQLite da parte di Windows Phone. Nel giro di qualche settimane le cose sono un po’ cambiate, dato che Peter Huene, uno sviluppatore, ha realizzato un porting della libreria originale sqlite-net per Windows Phone 8. Tale porting consente di utilizzare l’engine nativo di SQLite (di cui ho parlato nel post precedente e che è disponibile tramite la Visual Studio Gallery) in un’applicazione Windows Phone 8, utilizzando la stessa libreria di manipolazione dati (sqlite-net) che è disponibile anche su Windows 8. Questo vi permette di realizzare uno strato di accesso ai dati che sia facilmente utilizzabile su entrambe le piattaforme.

Al momento il progetto non è disponibile su NuGet, sono richiesti perciò due passaggi per poterlo utilizzare: il primo è quello di aggiungere una libreria nativa alla vostra soluzione, che funge da wrapper per le funzionalità utilizzate da sqlite-net; il secondo è quello di scaricare una versione specifica di sqlite-net, in grado di utilizzare l’engine nativo anche su Windows Phone (mentre, la versione originale, su Windows Phone fa uso di un altro engine, chiamato csharp-sqlite).

Iniziamo!

Facciamo amicizia con GitHub

Entrambi i progetti sono ospitati da GitHub, un sito molto popolare che ospita progetti open source e che funge anche da source control basato su Git. Il modo migliore per scaricare i progetti è proprio quello di affidarsi a Git: potete scaricare anche l’intero progetto in un singolo file zip ma, in questo modo, non sarete sincronizzati con il repository originale. Di conseguenza, ogni volta che lo sviluppatore farà una modifica sarete costretti a riscaricare l’intero progetto da capo. Il modo più semplice per lavorare con i repository di GitHub è utilizzare il tool GitHub for Windows, disponibile per il download sul sito ufficiale.

Dopo averlo installato e lanciato dovrete configurarlo per la prima volta: per farlo, vi servirà un account su GitHub, se non ce l’avete semplicemente collegatevi sul sito e createne uno. Dopodichè dovreste trovarvi davanti ad una schermata molto simile a questa:

A meno che non abbiate giù utilizzato GitHub in precedenza e abbiate già creato uno o più repository, tale schermata sarà vuota. Ora collegatevi al sito di GitHub, nello specifico al repositoriy del progetto sqlite-net-wp8, che è disponibile all’indirizzo https://github.com/peterhuene/sqlite-net-wp8. In cima alla pagina troverete il pulsante Clone in Windows: cliccateci sopra, assicurandovi di aver già fatto login sul portale con le stesse credenziali che avete utilizzato nell’applicazione.

 

A questo punto sarà nuovamente aperto il client GitHub for Windows and il repository sarà automaticamente aggiunto all’elenco dei vostri repository locali: dopo un po’ (la progress bar vi mostrerà lo stato dell’operazione) l’intero repository sarà clonato in locale sul vostro computer, all’interno della cartella C:\Users\User\Documents\GitHub (dove User è il vostro nome utente di Windows). Questa è la cartella in cui il tool posiziona tutti i repository locali: di conseguenza, ne troverete una chiamata sqlite-net-wp8, che contiene il progetto che dovrete aggiungere alla vostra soluzione.

Dato che stiamo già utilizzando GitHub, cogliamo l’occasione per scaricare anche il fork di sqlite-net compatibile con Windows Phone 8: dovete semplicemente le operazioni che abbiamo appena fatto sul repository https://github.com/peterhuene/sqlite-net.

L’ultimo requisito indispensabile è di installare, tramite la Visual Studio Gallery, il SQLite Runtime for Windows Phone, disponibile al seguente indirizzo: http://visualstudiogallery.msdn.microsoft.com/cd120b42-30f4-446e-8287-45387a4f40b7

Ora abbiamo tutto quello che ci serve, possiamo iniziare a lavorare sull’applicazione Windows Phone 8.

Utilizziamo SQLite

La prima cosa da fare è aprire Visual Studio 2012 e creare un’applicazione per Windows Phone 8. A questo punto dovete aggiungere alla soluzione la libreria sqlite-net-wp8 che abbiamo scaricato da GitHub: fate clic con il tasto destro sulla soluzione, selezionate Add existing project e cercate il file Sqlite.vcxproj nella cartella sqlite-net-wp8 folder che è stata scaricata in precedenza. Vedrete comparire il nuovo progetto in Solution Explorer: potete notare che ha un’icona differenta da quella del progetto Windows Phone, dato che la libreria è scritta in codice nativo.

Come spiegato in precedenza, si tratta semplicemente di un wrapper per alcune delle funzionalità utilizzate da sqlite-net: dobbiamo perciò aggiungere la libreria sqlite-net vera e proprio, semplicemente copiando i file Sqlite.cs e SqliteAsync.cs contenuti all’interno della cartella src del repository locale che abbiamo scaricato in precedenza all’interno del nostro progetto. Per farlo, è sufficiente fare click con il tasto destro sul progetto Windows Phone e scegliere Add existing item.

L’ultimo stpe necessario è aggiungere, al nostro progetto Windows Phone, una reference sia al wrapper sqlite-net-wp8 sia all’engine vero e proprio di SQLite. Per farlo fate clic con il tasto destro sul progetto, scegliete Add Reference e cercate:

• Nel tab Solution, la libreria sqlite
• Nel tab Windows Phone – Extensions, la libreria SQLite for Windows Phone

AGGIORNAMENTO: in seguito ad una modifica da parte dello sviluppatore per continuare a supportare anche il porting in C# dell’engine di SQLite, è necessario uno step aggiuntivo per poter usare l’engine nativo: occorre aggiungere un simbolo condizionale tra le impostazioni di build del progetto. Per farlo, fate click con il tasto destro sul vostro progetto (quello che contiene i file Sqlite.cs e SqliteAsync.cs aggiunti in precedenza), scegliete Properties, andate nella sezione Build e, nella casella Conditional compilation symbols, aggiungete alla fine della riga il valore USE_WP8_NATIVE_SQLITE. Nel caso di un progetto standard per Windows Phone 8 il contenuto della casella di test sarà:

SILVERLIGHT;WINDOWS_PHONE;USE_WP8_NATIVE_SQLITE

A questo punto possiamo riutilizzare il codice che abbiamo già visto negli altri post dedicati a sqlite-net: il codice necessario per interagire con il database e creare e leggere dati sarà esattamente lo stesso. Ecco alcuni esempi per effetuare le operazioni più comuni:

//creo il database
private async void CreateDatabase()
{
    SQLiteAsyncConnection conn = new SQLiteAsyncConnection("people.sql");
    await conn.CreateTableAsync<Person>();
}

//inserisco dei dati nel database
private async void Button_Click_1(object sender, RoutedEventArgs e)
{
    SQLiteAsyncConnection conn = new SQLiteAsyncConnection("people.sql");

    Person person = new Person
    {
        Name = "Matteo",
        Surname = "Pagani"
    };

    await conn.InsertAsync(person);
}

//leggo i dati memorizzati nel database
private async void Button_Click_2(object sender, RoutedEventArgs e)
{
    SQLiteAsyncConnection conn = new SQLiteAsyncConnection("people.sql");

    var query = conn.Table<Person>().Where(x => x.Name == "Matteo");
    var result = await query.ToListAsync();
    foreach (var item in result)
    {
        Debug.WriteLine(string.Format("{0}: {1} {2}", item.Id, item.Name, item.Surname));
    }
}

Qualche consiglio per gli acquisti

Ci sono alcune cose da tenere a mente quando si lavora con questa libreria e SQLite. La prima è che, attualmente, nessuna delle librerie che abbiamo visto è disponibile su NuGet: dovrete mantenerle aggiornate utilizzando GitHub for Windows e, periodicamente, effettuare un sync dei repository. La seconda è che la libreria sqlite-net-wp8 è compilata in base ad una specifica versione di SQL Lite: se il team rilasciata un nuovo update tramite l’estensione di Visual Studio, aspettate ad aggiornarla fino a quando lo sviluppatore non avrà aggiornato anche la libreria; in caso contrario, le reference non saranno più valide e non sarete più in grado di aprire il progetto.

This entry was posted on Friday, 28 December, 2012 and is filed under Windows Phone Tutorials . You can follow any responses to this entry through here . You can leave a response.

Il 2012 è stato un anno veramente intenso per gli sviluppatori Microsoft: prima Windows 8, poi Windows Phone 8 e, nel mezzo, diversi aggiornamenti importanti per molte tecnologie, come Azure (con l’introduzione dei Web Sites e dei Mobile Service) e ASP.NET MVC (con le nuove WebAPI).

Come DotNetLombardia abbiamo cercato di aiutare gli sviluppatori ad imparare a sfruttare il più possibile queste tecnologie, proponendo diversi eventi “specializzati” nel corso dell’anno. Uno di quelli che ha catalizzato il maggior numero di partecipanti è stato quello di Giugno dedicato a Windows Phone, che è stata l’occasione per fare il punto della situazione a pochi mesi dal lancio di Windows Phone 8, che sarebbe avvenuto di lì a poco.

Visto il forte interesse e la passione di molti di noi verso la nuova piattaforma mobile di Microsoft abbiamo pensato di riproporre l’appuntamento, questa volta dedicato ad esplorare tutte le novità di Windows Phone 8.

La novità principale, che abbiamo già sperimentato con l’Azure Day, sarà la presenza di due track parallele: una basic, rivolta a chi è alle prime armi e vuole imparare le basi dello sviluppo per Windows Phone, e una deep, per chi ha già esperienza e vuole approfondire le novità e, perchè no, anche qualche argomento alternativo e diverso dal solito.

Ad aiutarci in questo appuntamento ci sarà Microsoft, che ci ospiterà presso la sua sede di Peschiera Borromeo (MI), e gli amici provenienti dalle community di tutta Italia, che porteranno il loro bagaglio di conoscenze e la loro esperienza e li condivideranno con tutti voi.

L’appuntamento è per Lunedì 28 Gennaio 2013 presso, appunto, il Microsoft Innovation Campus: inizieremo intorno alle 9.30 per il keynote, per poi dividerci nelle due track e ritrovarci alla fine per rispondere alle vostre domande (oltre che, ovviamente, durante il pranzo e i break).

L’agenda è molto ricca: trovate tutti i dettagli e il link per iscrivervi sul sito ufficiale.

Cosa state aspettando? I posti sono limitati! Vi aspettiamo!

This entry was posted on Thursday, 20 December, 2012 and is filed under Windows Phone Events . You can follow any responses to this entry through here . You can leave a response.

Settimana scorsa sul blog ufficiale MSDN è stato pubblicato un mio guest post, dedicato all’ottimizzazione delle applicazioni Windows Phone 7.x per Windows Phone 8. Come sappiamo, infatti, le applicazioni per Windows Phone 7 sono compatibili con la nuova versione del sistema operativo, ma non è vero il contrario. Di conseguenza, se vogliamo supportare entrambe le piattaforme abbiamo la necessità di mantenere due progetti differenti.

In alcuni casi può essere un costo troppo oneroso, soprattutto se si tratta di un’applicazione semplice e che potrebbe trarre benefici molto limitati dalle novità di Windows Phone 8.

Nel corso dell’articolo scoprirete alcuni trucchi e consigli per supportare i device di nuova generazione senza essere costretti ad aggiornare il vostro progetto.

Trovate l’articolo all’indirizzo http://blogs.msdn.com/b/italy/archive/2012/12/10/guest-post-supportare-i-dispositivi-windows-phone-8-da-un-applicazione-windows-phone-7-x.aspx

Buona lettura!

This entry was posted on Monday, 17 December, 2012 and is filed under Windows Phone . You can follow any responses to this entry through here . You can leave a response.

Mercoledì 5 Dicembre si è tenuto presso il Microsoft Innovation Center il Windows Phone Developer Day, una giornata di approfondimento dedicata alle novità di Windows Phone 8. Tra gli speaker coinvolti ho avuto l’onore di esserci anche io, proponendo una sessione dedicata alla condivisione di codice con altre piattaforme Microsoft, nello specifico Windows Phone 7 (per ottimizzare le applicazioni già sviluppate per il nuovo sistema operativo) e Windows 8.

Tutte le sessioni della giornata sono state registrate, in separate sede, nella video room di Microsoft e saranno prossimamente disponibili su Channel 9. Nel frattempo, metto a disposizione slide e demo utilizzate durante la mia sessione: sarà mia premura aggiornare il post nel momento in cui anche il video sarà disponibile.

This entry was posted on Tuesday, 11 December, 2012 and is filed under Windows Phone Windows 8 . You can follow any responses to this entry through here . You can leave a response.

Mi sono reso conto che, l’altro giorno durante il Windows Phone Developer Day, posso aver fatto passare un messaggio un po’ confusionario durante la mia sessione: SQL Lite è supportato da Windows Phone 8, ma allo stesso tempo non è utilizzabile.

Vediamo di chiarire meglio, facendo però prima un passo indietro: Windows Phone 7.5 aveva finalmente introdotto il supporto ai database relazionali mediante SQL CE e sfruttando la tecnologia LINQ to SQL per effettuare operazioni. Con Windows Phone 8 c’è stato però un cambiamento di rotta, con l’ottica di offrire una maggiore compatibilità con Windows 8 e, più in generale, con le altre piattaforme mobile come Android e iOS. SQL CE è ancora disponibile in Windows Phone 8, ma la nuova tecnologia consigliata da Microsoft è SQL Lite: si tratta di un engine cross platform e, di conseguenza, offre la possibilità di utilizzare lo stesso database su altre piattaforme.

Microsoft ha lavorato a stretto contatto con il team affinchè, poco dopo il rilascio, fosse disponibile una versione dell’engine di SQL Lite per le sue due nuove piattaforme, ovvero Windows Phone e Windows 8. Il risultato è disponibile nella Visual Studio Gallery di Visual Studio: sono infatti disponibili due package (uno per Windows Phone 8 e uno per Windows 8) che consentono di includere il motore di SQL Lite in un progetto.

Attenzione però (ed è da qui che può nascere un po’ di confusione): si tratta solamente del motore di SQL Lite, ovvero di quella libreria che si occupa di supportare tutte le operazioni più comuni di interazione con un database. Tale libreria è nativa: è necessario perciò codice nativo per effettuare le operazioni vere e proprie, come creare una tabella o estrarre dei dati.

Di conseguenza, l’unico modo per interagire con un linguaggio ad alto livello è quello di utilizzare una libreria che faccia da wrapper verso le chiamate native e che permetta di raggiungere lo stesso risultato che si ottiene utilizzando LINQ to SQL con SQL CE: effettuare operazioni con il database senza scrivere a mano le query, ma lavorando con collezioni e oggetti.

Il problema e la confusione attuale nascono dal fatto che, al momento, questa libreria non esiste ancora per Windows Phone 8: Microsoft è al lavoro su un progetto di questo tipo e possiamo aspettarci delle interessanti novità a breve ma è un dato di fatto che, al momento, anche se SQL Lite è ufficialmente supportato non sia possibile utilizzarlo in un progetto Windows Phone, a meno di non scrivere noi stessi un wrapper verso le chiamate native.

Su Windows 8 la situazione invece è diversa, perché esistono già delle librerie di questo tipo, come sqlite-net, di cui ho parlato in questo articolo che ho pubblicato sul mio blog in inglese. Purtroppo tale libreria non è compatibile con Windows Phone 8, perché utilizza alcune funzionalità del Windows Runtime che non sono disponibili nel subset di Windows Phone.

Se avete la necessità, perciò, di sviluppare un’applicazione Windows Phone che faccia uso di un database e non potete posticipare i lavori, quali possibilità avete?

La prima è quella di utilizzare SQL CE: si tratta di una valida soluzione, da prendere in considerazione nel caso in cui non vi interessi la compatibilità con Windows 8 o con altre piattaforme.

Una seconda possibilità è quella di utilizzare csharp-sqlite, una libreria pubblicata su Google Code che consente di utilizzare il motore di SQL Lite all’interno di applicazioni scritte in C#. Anche Windows Phone è supportato: questa soluzione vi permette di condividere il database con altre piattaforme ed è supportato anche da Windows Phone 8. Il difetto? Che la libreria integrata per accedere ai dati utilizza classi e metodi che fanno riferimento al framework .NET e, di conseguenza, non sono disponibili nel Windows Runtime. Ciò significa che non potrete riutilizzare il vostro strato di accesso ai dati, ad esempio, in un’applicazione Windows Store, ma solamente il database vero e proprio.

Spero di aver aiutato chi ha partecipato al Windows Phone Developer Day (e non solo, questa domanda mi è stata fatta anche da altri sviluppatori tramite altri canali) ad avere le idee più chiare sullo stato attuale del supporto a SQL Lite da parte di Windows Phone!

This entry was posted on Friday, 07 December, 2012 and is filed under Windows Phone . You can follow any responses to this entry through here . You can leave a response.

Nel post precedente abbiamo iniziato a dare uno sguardo approfondito ad una delle nuove feature più interessanti di Windows Phone 8: lo sharing di dati tra applicazioni. L’esempio che stiamo utilizzando nel corso di questo tutorial è composto da due applicazioni: nel post precedente abbiamo creato l’applicazione “launcher”, che genera un file di testo e prova ad aprirlo. In questo post, invece, andremo a creare l’applicazione “reader”, che riceverà il file creato dall’applicazione “launcher” e lo elaborerà per mostrarne il contenuto all’utente.

L’applicazione “reader”: come registrare un’estensione

Iniziamo a creare l’applicazione “reader”: create un nuovo progetto di tipo Windows Phone 8 (potete utilizzare il template base Windows Phone App) e iniziamo con il modificare il file di manifest. Purtroppo, come ho già avuto modo di sottolineare nell’articolo pubblicato su ASPItalia dedicato alle novità di Windows Phone 8, il nuovo editor visuale ha ancora qualche limite e non supporta tutti gli scenari: per registrare una specifica estensione di file dovremo perciò modificare manualmente il manifest, facendo clic con il tasto destro sul file WMAppManifest.xml all’interno della cartella Properties e scegliendo View code.

Protocolli ed estensioni vengono registrati nella sezione Extensions: nel caso in cui sia assente, potete aggiungerla manualmente sotto la sezione Tokens. Ecco come registriamo l’estensione log:

      <FileTypeAssociation Name="LogFile" TaskID="_default" NavUriFragment="fileToken=%s">
        <SupportedFileTypes>
          <FileType ContentType="text/plain">.log</FileType>
        </SupportedFileTypes>
      </FileTypeAssociation>

Ogni associazione è identificata dal nodo FileTypeAssociation, caratterizzato da una proprietà Name univoca. Gli attributi TaskID e NavUriFragment definiscono come il file viene passato all’applicazione: si tratta di due valori fissi, non devono essere modificati ma devono essere sempre come nel codice di esempio.

All’interno di questo nodo potete specificare le tipologie di file che andrete a supportare, aggiungendo un nodo di tipo FileType e specificando l’estensione e il content type. Avete anche la possibilità di includere un logo che rappresenta la tipologia di file, che sarà utilizzato dal sistema operativo ove necessario (ad esempio, di fianco al nome di un allegato nell’applicazione Mail). In tal caso, dovete creare tre differenti tipologie di immagine (con le risoluzioni 33x33, 69x69 e 176x176), aggiungerle al vostro progetto e includerle nella definizione del nodo FileTypeAssociation, come nell’esempio:

 <FileTypeAssociation Name="LogFile" TaskID="_default" NavUriFragment="fileToken=%s">
<Logos>
           <Logo Size="Small">log-33x33.png</Logo>
           <Logo Size="Medium">log-69x69.png</Logo>
           <Logo Size="Large">log-176x176.png</Logo>
       </Logos>
        <SupportedFileTypes>
          <FileType ContentType="text/plain">.log</FileType>
        </SupportedFileTypes>
      </FileTypeAssociation>

Una volta che avete registrato la vostra estensione è tempo di scrivere un po’ di codice. Sono due le operazioni che andremo a fare: definire un UriMapper e creare una pagina che gestirà il file ricevuto.

La classe UriMapper

Prima di parlare della classe UriMapper, è meglio spiegare come il sistema operativo gestisce l’associazione di file da parte di applicazioni di terze parti. Quando un’applicazione viene aperta come conseguenza dell’apertura di un file supportato (utilizzando il meccanismo visto nel post precedente), viene utilizzato uno speciale Uri che ha la seguente struttura:

/FileTypeAssociation?fileToken=89819279-4fe0-4531-9f57-d633f0949a19

Dopo la parola chiave by FileTypeAssociation viene passato un unico parametro chiamato fileToken, che è un GUID che identifica in maniera univoca il file. Come vedremo a breve, Windows Phone 8 espone delle API per recuperare fisicamente il file tramite il token.

Ora che abbiam ocapito come funziona dietro la quinte la gestione dei file, dovrebbe essere semplice capire lo scopo della classe UriMapper, ovvero quello di mettersi “in mezzo” alle richieste di navigazione dell’applicazione e ridirigere le chiamate verso la pagina più appropriata, a seconda dell’Uri che è stato richiesto. Nel nostro caso, andremo a verificare se l’applicazione è stata aperta in seguito all’apertura di un file e, in caso affermativo, porteremo l’utente in una specifica pagina dell’applicazione che sarà in grado di elaborare il nostro file di log.

    public class UriMapper : UriMapperBase
    {
        private string tempUri;

        public override Uri MapUri(Uri uri)
        {
            tempUri = uri.ToString();

            // File association launch
            if (tempUri.Contains("/FileTypeAssociation"))
            {
                // Get the file ID (after "fileToken=").
                int fileIDIndex = tempUri.IndexOf("fileToken=") + 10;
                string fileID = tempUri.Substring(fileIDIndex);

                // Get the file name.
                string incomingFileName =
                    SharedStorageAccessManager.GetSharedFileName(fileID);

                // Get the file extension.
                int extensionIndex = incomingFileName.LastIndexOf('.') + 1;
                string incomingFileType =
                    incomingFileName.Substring(extensionIndex).ToLower();

                // Map the .log files to the appropriate pages.
                switch (incomingFileType)
                {
                    case "log":
                        return new Uri("/LogDetail.xaml?fileToken=" + fileID, UriKind.Relative);
                    default:
                        return new Uri("/MainPage.xaml", UriKind.Relative);
                }

            }
            // Otherwise perform normal launch.
            return uri;
        }
    }

La prima cosa da fare è aggiungere una nuova classe al vostro progetto, che deve ereditare dalla classe UriMapperBase. Questa classe vi richiederà di implementare il metodo MapUri, che viene chiamato nel momento in cui l’applicazione viene inizalizzitata portando con sè come parametro un Uri.

Nel caso in cui l’applicazione sia stata aperta in seguito all’apertura di un file, l’URL conterrà la stringa FileTypeAssociation: in questo caso, siamo in grado di ottenere il token del file semplicemente manipolando la stringa dell’URL, dato che le parole chiave FileTypeAssociation e fileToken sono fisse. Dopodichè, andiamo ad utilizzare la classe SharedStoreAccessManager, che è in grado di gestire le operazioni con i file: in questo caso utilizziamo il metodo GetSharedFileName che, dato il token, restituisce il nome del file così come era stato definito nel’applicazione “launcher”.

Tramite il nome e giocando con le stringhe siamo in grado di ottenere l’informazione che ci serve: l’estensione del file. In questo modo siamo in grado di identificarne la tipologia e gestirla nella maniera più appropriata. Nel nostro caso, gestiamo solamente l’estensione .log, perciò il blocco switch contiene solo due possibilità: l’estensione log (in tal caso l’utente viene portato alla pagina LogDetail.xaml, portando con sè in query string il token), mentre in caso non ci sia una corrispondenza l’utente viene semplicemente portato alla pagina principale.

L’ultima cosa che dobbiamo fare è dire all’applicazione che abbiamo un oggetto UriMapper, che deve essere invocato ogni qualvolta viene lanciata una navigazione: per farlo dobbiamo aprire il file App.xaml.cs e, all’interno del metodo InitializePhoneApplication(), subito dopo che l’oggetto RootFrame è stato inizializzato, valorizzare la sua proprietà UriMapper con l’oggetto che abbiamo appena creato, come nell’esempio:

private void InitializePhoneApplication()
{
    if (phoneApplicationInitialized)
        return;

    // Create the frame but don't set it as RootVisual yet; this allows the splash
    // screen to remain active until the application is ready to render.
    RootFrame = new PhoneApplicationFrame();
    RootFrame.Navigated += CompleteInitializePhoneApplication;
    RootFrame.UriMapper = new Helpers.UriMapper();

    // Handle navigation failures
    RootFrame.NavigationFailed += RootFrame_NavigationFailed;

    // Handle reset requests for clearing the backstack
    RootFrame.Navigated += CheckForResetNavigation;

    // Ensure we don't initialize again
    phoneApplicationInitialized = true;
}

Recuperiamo il file!

Ora è tempo di creare la pagina LogDetail.xaml, che utilizzeremo per mostrare il contenuto del file. Aggiungete una nuova pagina vuota al progetto e dategli il nome LogDetail.xaml: nel code behind andremo a gestire l’evento OnNavigatedTo, che viene invocato nel momento in cui l’utente naviga verso la pagina corrente.

In questo evento andremo a recuperare il token che identifica il file e lo utilizzeremo per recuperarne il contenuto, che ci è stato passato dall’applicazione “launcher”. Ecco il codice:

        protected override async void OnNavigatedTo(NavigationEventArgs e)
        {
            base.OnNavigatedTo(e);
            if (NavigationContext.QueryString.ContainsKey("fileToken"))
            {
                await SharedStorageAccessManager.CopySharedFileAsync(ApplicationData.Current.LocalFolder, "rss.log",
                                                               NameCollisionOption.ReplaceExisting,
                                                               NavigationContext.QueryString["fileToken"]);

            }
        }

Se avete già sviluppato applicazioni Windows Phone il meccanismo dovrebbe esservi famigliare, dato che è simile a quello introdotto in Windows hone 7.5 per gestire alcuni scenari avanzati di navigazione (ad esempio, quando l’applicazione viene aperta da una tile secondaria): se il NavigationContext contiene un parametro in query string chiamato fileToken allora andiamo ad utilizzare nuovamente la classe SharedStorageManager per recuperare il file vero e proprio tramite il metodo CopySharedFileAsync.

Questo metodo si occupa di tradurre il token in un file vero e proprio e di copiarlo all’interno dello storage locale dell’applicazione. I parametri richiesti sono:

• La cartella dello storage dove salvare il file, sotto forma di oggetto di tipo StorageFolder. Nell’esempio passiamo l’oggetto base LocalFolder: in questo caso il file sarà copiato nella root dello storage.
• Il nome del file da salvare.
• Cosa fare nel caso in cui esista già un file con lo stesso nome.
• Il token che identifica il file che abbiamo recuperato dalla query string.

Una volta che il file è disponibile nello storage possiamo elaborarlo a piacimento. Per esempio, possiamo leggerne il contenuto e mostrarlo in una casella di testo utilizzando l’extension method ReadFromFile, che andremo a dichiarare nella classe FileExtensions creata nel post precedente:

public static class FileExtensions
{
    public static async Task<string> ReadFromFile(string fileName,StorageFolder folder = null)
    {
        folder = folder ?? ApplicationData.Current.LocalFolder;
        var file = await folder.GetFileAsync(fileName);

        using (var fs = await file.OpenAsync(FileAccessMode.Read))
        {
            using (var inStream = fs.GetInputStreamAt(0))
            {
                using (var reader = new DataReader(inStream))
                {
                    await reader.LoadAsync((uint)fs.Size);
                    string data = reader.ReadString((uint)fs.Size);
                    reader.DetachStream();
                    return data;
                }
            }
        }
    }
}

Ora, grazie a questo extension method, possiamo fare nell’evento OnNavigatedTo della classe LogDetail una cosa di questo tipo:

protected override async void OnNavigatedTo(NavigationEventArgs e)
{
    base.OnNavigatedTo(e);
    if (NavigationContext.QueryString.ContainsKey("fileToken"))
    {
        SharedStorageAccessManager.CopySharedFileAsync(ApplicationData.Current.LocalFolder, "rss.log",
                                                       NameCollisionOption.ReplaceExisting,
                                                       NavigationContext.QueryString["fileToken"]);

        string content = await FileExtensions.ReadFromFile("rss.log");
        log.Text = content;
    }
}

It’s debugging time!

Fare  il debug di questa feature è piuttosto semplice: è sufficiente fare il deploy di entrambe le applicazioni sull’emulatore o su un device (facendo click con il tasto destro su entrambi i progetti e selezionando la voce Deploy). Dopodichè eseguite l’applicazione “launcher” che abbiamo sviluppato nel post precedente, create il file di log e premete il pulsante Open file. Se avete fatto tutto correttamente, vedrete avviarsi l’applicazione “reader” e aprirsi direttamente sulla pagina LogDetail, la quale mostrerà il contenuto file XML.

This entry was posted on Tuesday, 04 December, 2012 and is filed under Windows Phone Tutorials . You can follow any responses to this entry through here . You can leave a response.

Una delle limitazioni più “fastidiose” per gli sviluppatori Windows Phone era quella di non poter condividere dati tra le applicazioni. Questa limitazione non era esclusiva delle applicazioni di terze parti, ma non eravamo in grado di gestire neanche le tipologie di file supportate nativamente da Windows Phone (come i file di Office): l’unico workaround disponibile era quello di aprire il file utilizzando il browser; in questo modo, se la tipologia era supportata dal sistema operativo, il file veniva scaricato e aperto con l’applicazione corretta. Il problema di questo workaround è che funzionava solo con i file disponibili online: se il file era memorizzato nello storage dell’applicazione, non era possibile applicarlo.

E’ perciò che, con un caloroso applauso, diamo il benvenuto ad una nuova funzionalità di Windows Phone 8, che consente alle applicazioni di terze parti di registrare uno specifico procollo o tipologia di file: in questo modo, nel momento in cui un’altra applicazione dovesse cercare di aprire un file di quel tipo, la nostra sarebbe in grado di intercettare la richiesta ed elaborare il file.

Ci sono due modalità per condividere dati: registrandosi per una specifica tipologia di file o per un protcollo. Nel primo caso, l’applicazione registra una specifica estensione (ad esempio, .log): quando un’altra app tenta di aprire un file con questa estensione, il file viene passato all’applicazione e copiato nel suo storage locale. Nel secondo caso, invece (che andremo ad approfondire in un altro post), possiamo registrarci per uno specifico protocollo (ad esempio, log:/), così che un’altra applicazione possa utilizzarlo per inviarci dei dati in formato testuale.

Cosa succede quando un’applicazione di terze parti registra una tipologia di file? Il sistema operativo va alla ricerca di applicazioni che, tramite il file di manifest, hanno dichiarato di essere in grado di trattare quella specifica tipologia: se l’utente non ne ha, avrà la possibilità di accedere allo Store e di visualizzare solo le applicazioni in grado di supportare quell’estensione. Se sono disponibili, invece, più applicazioni, avrà la possibilità di scegliere quale vuole utilizzare; infine, se ne è presente solamente una, sarà aperta direttamente, senza che sia necessario alcun intervento dell’utente.

In questo tutorial ci focalizzeremo sull’associazione di file. Nell’esempio andremo a creare due applicazioni Windows Phone separate: la prima, che chiameremo “launcher”, sarà l’applicazione che tenterà di aprire un file di tipo .log, il quale sarà elaborato dall’app che invece chiameremo “reader”. Useremo un file testuale con estensione .log, con il quale condivideremo del testo tra le due applicazioni.

L’applicazione “launcher”: creare e aprire il file.

Nell’applicazione “launcher” andremo a svolgere due compiti: il primo è quello di creare un file tipo log, che sarà un semplice file di testo. Il secondo è quello di tentare di aprire il file, così che l’applicazione reader possa utilizzarla. Iniziamo con il creare il file di log: per questo scopo useremo una classe che aggiunge due semplici extension method per lavorare con le stringh e e con lo storage. Il primo metodo è chiamato WriteToFile e serve per salvare il contenuto di una stringa in un file locale, il secondo si chiama invece ReadFromFile e fa esattamente l’opposto: apre un file dallo storage, contenente del testo, e ne restituisce la rappresentazione sotto forma di stringa.

Iniziamo perciò proprio con il creare la classe che includerà i nostri extension methods: facciamo clic con il tasto destro sul vostro progetto e selezionate Add New File. Dategli un nome a piacimento e marcate la classe come static, come nell’esempio. In questo post andremo a vedere solo il metodo WriteToFile, dato che è l’unico che useremo nell’applicazione “launcher”.

namespace ShareData.Launcher.Helpers
{
    public static class FileExtensions
    {   
        public static async Task WriteToFile(this string contents, string fileName, StorageFolder folder = null)
        {
            folder = folder ?? ApplicationData.Current.LocalFolder;
            var file = await folder.CreateFileAsync(
                fileName,
                CreationCollisionOption.ReplaceExisting);
            using (var fs = await file.OpenAsync(FileAccessMode.ReadWrite))
            {
                using (var outStream = fs.GetOutputStreamAt(0))
                {
                    using (var dataWriter = new DataWriter(outStream))
                    {
                        if (contents != null)
                            dataWriter.WriteString(contents);

                        await dataWriter.StoreAsync();
                        dataWriter.DetachStream();
                    }

                    await outStream.FlushAsync();
                }
            }
        }
    }
}

Questo metodo prende una stringa come parametro e lo salva in un file nello storage locale, il cui nome viene passato come parametro. Il metodo accetta anche un altro parametro in ingresso, il cui tipo è StorageFolder (che è la classe di WinRT che identifica una cartella nello storage locale): possiamo utilizzarlo nel caso in cui vogliamo che il file sia memorizzato in una specifica cartella, altrimenti il file sarà creato nella root.

Questo metodo utilizza le API standard di WinRT per creare il file e le classi OutputStream e DataWriter per salvare il contenuto della stringa al suo interno.

Il prossimo passo è installare il pacchetto Microsoft.Bcl.Async da NuGet, che abbiamo imparato ad utilizzare in questo post: il suo scopo, in questo tutorial, è quello di metterci a disposizione degli extension method per utilizzare la classe WebClient con le keyword async e await, che utilizzeremo per scaricare il contenuto di un feed RSS da salvare in un file.

Ora lavoriamo sulla UI: aggiungeremo semplicemente due pulsanti all’interno del file MainPage.xaml, uno per scaricare l’XML del feed e salvarlo in un file, l’altro per “aprirlo”.

<Grid x:Name="ContentPanel" Grid.Row="1" Margin="12,0,12,0">
    <StackPanel>
        <Button Content="Create file" Click="OnCreateFileButtonClicked" />
        <Button Content="Open file" Click="OnOpenFileButtonClicked" />
    </StackPanel>
</Grid>

Graze all’extension method che abbiamo creato per lavorare con i file e a quello incluso nella libreria Microsoft.Bcl.Async per espandere la classe WebClient, diventa molto semplice raggiungere l’obiettivo di scaricare l’XML del feed RSS e salvarlo in un file dall’estensione .log.

private async void OnCreateFileButtonClicked(object sender, RoutedEventArgs e)
{
    WebClient client = new WebClient();
    string result = await client.DownloadStringTaskAsync("http://feeds.feedburner.com/qmatteoq");

    await result.WriteToFile("rss.log");
}

Quello che andiamo a fare è semplicemente scaricare l’RSS utilizzando il metodo DownloadStringTaskAsync (nell’esempio, andiamo a scaricare l’RSS di questo blog) e lo salviamo in un file chiamato rss.log, che viene posizionato nella root dello storage locale.

Lo step successivo è quello di aprire il file, andando a gestire l’evento di tap sul secondo pulsante:

private async void OnOpenFileButtonClicked(object sender, RoutedEventArgs e)
{
    StorageFile file = await ApplicationData.Current.LocalFolder.GetFileAsync("rss.log");
    Windows.System.Launcher.LaunchFileAsync(file);
}

Anche in questo caso l’operazione che andiamo a fare è molto semplice: dopo aver ottenuto un riferimento al file (utilizzando il metodo GetFileAsync) lo apriamo utilizzando il metodo LaunchFileAsync della classe Launcher (appartenente al namespace Windows.System). Cosa succede nel momento in cui premiamo il pulsante? Allo stato attuale, comparirà un messaggio che vi avviserà che non avete applicazioni in grado di aprire file di tipo log e vi verrà proposto di cercarla nello store. Per il momento, ignorate il messaggio: nel prossimo post andremo a vedere come creare l’applicazione “reader”, che registrerà l’estensione log e che sarà in grado di aprire il nostro file.

Se volete mettere alla prova quanto abbiamo sviluppato, nel frattempo, provate a rinominare il file salvato dall’applicazione in rss.txt, semplicemente cambiando il nome che viene passato ai metodi result.WriteToFile() e LocalFolder.GetFileAsync(). Dato che txt è un’estensione supportata nativamente dal sistema operativo, il file sarà aperto da Word e avrete la possibilità di leggere il contenuto del file XML.

Nella prossima puntata

Nel prossimo post andremo a sviluppare l’applicazione “reader”, che sarà in grado di intercettare l’operazione di apertura e di elaborare il file rss.log che abbiamo creato in questo post.

This entry was posted on Friday, 30 November, 2012 and is filed under Windows Phone Tutorials . You can follow any responses to this entry through here . You can leave a response.