I miei compagni di avventura Alessio e Marco vi hanno già introdotto a Take Me Back: la nostra prima applicazione OzoSoftware. Con questo e altri post vorrei parlarvi delle tecniche impiegate per la realizzazione dell'applicazione di cui, per metodologia di sviluppo, impegno e risultato vado molto fiero.

Partiamo dall'architettura che sfrutta un framework appositamente sviluppato per facilitarci appositamente nello sviluppo di applicazioni per Windows Phone 7, usato poi nell'applicazione per ASPItalia.com. Senza grosse pretese, non abbiamo abbondato di astrazione, ma ci siamo limitati (per ora) alle tecniche più classiche di architettura che si usano con Silverlight, adattandole leggermente. Prima di tutto è basato su MVVM, sviluppando classi base, mediator pattern e classi più core (che colmano la mancanza di certe API perché basato su SL 3.0) create da un fork del MVVM Light Toolkit.

Ci siamo concentrati nello sviluppare i view model in modo che siano completamente testabili, perciò tutti gli aspetti che riguardano MessageBox, gestione errori, canale notifiche, task e chooser, sono affidati dal mediator pattern, di cui parlo in questo articolo: lancio il messaggio e qualcuno, la parte legata alla view, agisce di conseguenza.

La variazione sul tema MVVM risiede nell'associazione View-ViewModel. Poiché è nel ViewModel che eseguo i comandi e spesso l'attività è quella di navigare tra le pagine, abbiamo scelto di sviluppare un oggetto ViewModelApplication che tramite il metodo NavigateToViewModel permette di navigare ad un'altra pagina. In un'applicazione Windows Phone di fatto ogni pagina (la view) ha il suo ViewModel e solitamente la navigazione è richiesta da esso. Richiedendo la navigazione per ViewModel, posso istanziarlo come voglio (al volo, IoC, ecc) e passare parametri che possono servire al ViewModel da mostrare. Di fatto il ViewModelApplication è un controller pluggabile per la navigazione tra pagine. Il bello è affidato al IViewBinder, la cui implementazione predefinita risolve la View a cui navigare via reflection. Se richiediamo di navigare quindi ad un'istanza o al tipo MapViewModel, il frame navigherà all'uri MapView.xaml.

ViewModelApplication.NavigateToViewModel(new MapViewModel());

Il controller che gestisce quindi la navigazione tra le pagine ci permette di avere un po' di funzionalità in più che fanno molto comode. Prima tra tutte la possibilità di implementare l'interfaccia IViewModelNavigation sul VM per gestire gli eventi di navigazione NavigatingFrom, NavigatedFrom, NavigatedTo, comodo per avviare il caricamento delle informazioni o fermarle quando si esce dalla pagina. Poi la possibilità di implementare l'interfaccia IPersistable, per salvare o caricare le informazioni per il tombstoning. E' tutto automatizzato, se la pagina si chiude viene chiamato il SaveState, se si riapre il LoadState; se il ViewModel infatti rappresenta le informazioni da mostrare tramite la View, è in esso che vanno persistite o mostrate.

Poiché alcune informazioni sono condivise tra più ViewModel è difficile determinare chi ha il compito di salvarle nella fase di tombstoning, per cui abbiamo optato per creare della classi singleton che si autogestiscono. Implementando la classe IKeyPersistable si registrano al motore con ViewModelApplication.RegisterPersistable per partecipare anch'esse alla fase di tombstoning. Tutto questo ha semplificato notevolmente la gestione del tombstoning, perché affidata ad ogni parte a cui compete. Non serve neanche un locator dei ViewModel perché questi sono sempre indipendenti tra loro o eventualmente lavorano con intermediari sopra citati.

Per quanto riguarda infine il supporto a Blend, ci limitiamo ad usare il DataContext del namespace di design di blend, utilizzando la voce "Create Sample Data From Class" che ci assicura di avere il supporto a design time allineato al ViewModel sottostante.

Nel prossimo post vi parlerò di come abbiamo gestito la parte delle chiamate HTTP che ha richiesto molto lavoro per creare una soluzione completa.