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

Print Content | More

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 Smile 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/ Smile

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.


Windows 8 , Microsoft

0 comments

Related Post


(will not be published)
(es: http://www.mysite.com)


  1. #1 da http://www.scoop.it/t/windows-8-development/p/1899360534/www-qmatteoq-com-migrazione-di-un-applicazione-metro-style-dalla-consumer-preview-alla-release-preview

    www.qmatteoq.com - Migrazione di un’applicazione Metro style dalla Consumer Preview alla Release Preview | Windows 8 Development | Scoop.it