Introduzione all'approccio MVVM rispetto alla componente viewmodel
In una applicazione MVVM scritta correttamente il livello view model e le viste dovrebbero risultare completamente indipendenti. Questo significa che all'interno della classe che implementa il view model non dovrebbe esserci alcun riferimento alla struttura visuale della presentation. La comunicazione dovrebbe avvenire tramite databindings, behaviors e commands invocati direttamente dalla vista sul data context. Dove possibile, viene preferito l'uso delle interfacce.
Questo approccio permette il test indipendente della vista, del viewmodel e del model, ma ha anche come controindicazione un aumento della complessità del codice, sia per quanto riguarda la parte concettuale di progettazione, ovvero la nuvola delle relazioni di chiamata tra le varie proprietà del viewmodel e la vista, sia banalmente per quanto riguarda la quantità di codice scritto. E' evidente che un approccio del genere applicato allo sviluppo di una app per effettuare la moltiplicazione di due numeri è puro suicidio, a meno di avere codice già pronto e riutilizzabile.
La problematica della navigazione nelle app Windows Store e Windows Phone
Al contrario delle applicazioni classiche per desktop che fanno uso di finestre, gli applicativi mobile per Windows Phone e le app per Windows Store mettono a disposizione una sola area, detta Frame, dove vengono visualizzati i contenuti dell'applicativo come pagine, alla stregua di un sito internet contenente elementi più ricchi graficamente e con accesso diretto al dispositivo. La navigazione a pagine permette di avere una cache di navigazione in entrambe le direzioni, indietro e avanti, e la garanzia del focus totale dell'utente rispetto ai contenuti attualmente visualizzati dal frame. Questo approccio, seppur ostico da implementare inizialmente da parte del programmatore, è di facile comprensione per quanto riguarda l'aspetto dell'esperienza di utilizzo dell'applicativo.
Utilizzando un pattern basato sugli eventi e utilizzando l'approccio classico code-behind per le pagine, per fare una analogia scrivendo il nostro codice come se l'applicativo fosse un website ASP.NET, l'implementazione della navigazione risulta banale. All'interno della singola finestra corrente esposta dall'app identifichiamo l'elemento root che rappresenta il frame e questo ci andrà a esporre i metodi di navigazione, sostanzialmente GoBack(), GoForward() e Navigate(), insieme ai metodi ausiliari CanGoBack() e CanGoForward(). Il funzionamento del frame risulta essere autoesplicativo.
Ma nel caso di MVVM ci troveremmo di fronte a una implementazione che crea dipendenza rispetto al namespace delle viste e al frame di navigazione, anch'esso da considerare parte della componente view. La dipendenza sul frame è evidente, in quanto è l'oggetto che implementa i metodi di navigazione, mentre quella sulle vista risulterebbe necessaria perché Navigate richiede un Type come argomento per determinare la pagina da inizializzare e navigare.
Le soluzioni che ci vengono in mente sono solo due. La prima è implementare la navigazione nel code-behind della vista. E noi vorremmo evitare il più possibile l'uso del code-behind. Preferiamo manutenere lo XAML piuttosto che un insieme di metodi di una classe parziale. La seconda è trovare un modo per inserire nel viewmodel la navigazione rispettando però la sua indipendenza dalla componente visuale.
Il navigation service, ovvero "come ti standardizzo il problema".
La soluzione in realtà è relativamente semplice. Il viewmodel deve essere progettato in modo da essere indipendente. Così facendo sarà possibile anche effettuare dei test sulle classi del vm in maniera automatica. Allora come si fa a far navigare una classe che non ha dipendenze sulla vista, quando tutti i template implementano i servizi di navigazione sulla classe della pagina? Ci aiutano le interfacce.
Una eventuale dipendenza su un oggetto che implementa una interfaccia di navigazione ci interesserebbe poco. Infatti, basterebbe usare direttamente l'interfaccia nel viewmodel e il layer che implementa i metodi di navigazione sarebbe per la nostra classe del tutto trasparente. In più, potremmo virtualmente utilizzare una implementazione per ogni piattaforma con una compilazione condizionale. Potremmo scegliere un approccio rispetto a un altro in fase di inizializzazione in base ad alcune regole da noi dettate. Il comportamento non cambierebbe mai, il viewmodel avrà sempre i suoi GoBack(), GoForward() e Navigate() disponibili, a prescindere dal comportamento del layer sottostante. In uno unit test, ad esempio, potremmo usare una classe dummy per la navigazione che andrà a fornire una simulazione degli input al viewmodel per poter testare determinati comportamenti.
Sfortunatamente, o fortunatamente, non è esposta una interfaccia INavigationService dal framework .NET o da WinRT. E' presente solo INavigate, che descrive il metodo Navigate() standard. Implementeremo noi la nostra versione dell'interfaccia, in base alle esigenze della nostra app.
Innanzitutto, a mio parere la cosa migliore è mettere le classi di navigazione in un namespace specifico. Nel mio caso, semplicemente Navigation.
INavigationService.cs
public interface INavigationService
{
#region Events
event NavigatedEventHandler Navigated;
event NavigationFailedEventHandler NavigationFailed;
#endregion
#region Methods
bool CanGoBack();
bool CanGoForward();
void GoBack();
void GoForward();
void Navigate(Type page);
void Navigate(Type page, object parameter);
void Navigate(String page);
void Navigate(String page, object parameter);
void ClearBackStack();
#endregion
}
La nostra interfaccia permetterà la navigazione e la cancellazione della cache di navigazione e informerà tramite evento l'esito delle richieste ricevute.
Esistono tre overloads di funzione. Il primo e il secondo sono per mantenere la compatibilità con gli oggetti frame standard. Il terzo e il quarto per permettere di disgiungere e ottimizzare la navigazione verso una pagina dalla parte visuale, ma questo si vedrà in dettaglio nell'implementazione.
Implementiamo INavigationService: WindowsNavigationService.cs
L'implementazione di INavigationService per le applicazioni Windows Store e Windows Phone, che chiameremo WindowsNavigationService, fa uso della reflection per disgiungere dalla componente visuale e ottimizzare il codice di navigazione. Abbiamo due approcci, uno è quello di implementare un attributo custom NavigableViewAttribute, oppure di implementare una interfaccia INavigableView. In entrambi i casi non cambia il sistema per riconoscere all'interno del nostro assembly le viste: utilizzando la reflection, otteniamo un handle al nostro assembly. A questo punto, tramite LINQ, passiamo al setaccio tutti i defined types che implementano l'interfaccia, o che hanno applicato il custom attribute che abbiamo implementato. Nel primo caso, il codice risulta secondo me più semplice e leggibile. Otteremo così tutti i Types adatti alla navigazione. Inserendo quanto enumerato all'interno di un Dictionary di tipo <String, Type>, con la chiave String rappresentata solitamente dal nome della classe, quindi della vista, otterremo un sistema di navigazione disgiunto dall'implementazione della nostra app che automaticamente riconosce le viste disponibile e ne permette l'utilizzo semplicemente "chiamandole per nome".
E' utile anche implementare una classe base astratta NavigationService che esponga una proprietà statica Default dove in fase di inizializzazione dell'applicativo andremo a memorizzare il sistema di navigazione di default dell'architettura che stiamo utilizzando.
L'implementazione di WindowsNavigationService è la seguente:
public class WindowsNavigationService
: NavigationService
{
#region Fields
private Frame currentFrame = null;
#endregion
#region Properties
protected Frame Frame
{
get
{
if (Window.Current != null)
{
if (Window.Current.Content != null && Window.Current.Content is Frame)
{
if (Window.Current.Content != this.currentFrame)
{
if (this.currentFrame != null)
{
try
{
this.currentFrame.Navigated -= CurrentFrame_Navigated;
this.currentFrame.NavigationFailed -= CurrentFrame_NavigationFailed;
}
catch
{
}
}
this.currentFrame = Window.Current.Content as Frame;
this.currentFrame.Navigated += CurrentFrame_Navigated;
this.currentFrame.NavigationFailed += CurrentFrame_NavigationFailed;
}
}
}
return this.currentFrame;
}
}
#endregion
#region .ctor
public WindowsNavigationService()
: base()
{
}
#endregion
#region Methods
public override bool CanGoBack()
{
bool result = false;
if (this.Frame != null)
result = this.Frame.CanGoBack;
return result;
}
public override void GoBack()
{
if (this.Frame != null)
this.Frame.GoBack();
}
public override void Navigate(string page)
{
Type pageType = null;
if (String.IsNullOrEmpty(page))
throw new ArgumentNullException("page");
if (this.viewsDictionary != null)
{
if (this.viewsDictionary.ContainsKey(page))
pageType = this.viewsDictionary[page];
}
if (pageType != null)
this.Navigate(pageType, null);
}
public override void Navigate(Type page, object parameter)
{
if (page == null)
throw new ArgumentNullException("page");
if (this.Frame != null)
if (parameter == null)
this.Frame.Navigate(page);
else
this.Frame.Navigate(page, parameter);
}
#endregion
#region Event Handlers
private void CurrentFrame_NavigationFailed(object sender, NavigationFailedEventArgs e)
{
this.OnNavigationFailed(this, e);
}
private void CurrentFrame_Navigated(object sender, NavigationEventArgs e)
{
this.OnNavigated(this, e);
}
#endregion
Mentre la classe base astratta NavigationService, che svolge un ruolo fondamentale, è implementata mediante questo codice:
public abstract class NavigationService
: INavigationService
{
#region Singleton
private static readonly object syncLock = new object();
private static INavigationService defaultNavigationService = null;
public static INavigationService Default
{
get
{
return NavigationService.defaultNavigationService;
}
set
{
if (value == null)
throw new ArgumentNullException("navigationService");
lock (NavigationService.syncLock)
{
if (NavigationService.defaultNavigationService != value)
NavigationService.defaultNavigationService = value;
}
}
}
#endregion
#region Events
public event NavigatedEventHandler Navigated = null;
public event NavigationFailedEventHandler NavigationFailed = null;
#endregion
#region Fields
protected Dictionary<String, Type> viewsDictionary = null;
#endregion
#region Properties
public String[] Views
{
get
{
String[] result = null;
if (this.viewsDictionary != null)
result = this.viewsDictionary.Keys.ToArray();
if (result == null)
result = new String[] { };
return result;
}
}
#endregion
#region .ctor
public NavigationService()
{
this.OnInitialized();
}
#endregion
#region Methods
protected virtual void OnInitialized()
{
this.viewsDictionary = new Dictionary<string, Type>();
this.PopulateViewsDictionary();
}
protected virtual void PopulateViewsDictionary()
{
Assembly currentAssembly = null;
TypeInfo[] viewsTypeInfos = null;
if (this.viewsDictionary == null)
throw new NullReferenceException("viewsDictionary");
else
{
if (this.viewsDictionary.Count > 0)
this.viewsDictionary.Clear();
}
currentAssembly = this.GetType().GetTypeInfo().Assembly;
viewsTypeInfos = currentAssembly.DefinedTypes.Where(dt => dt.ImplementedInterfaces.Any(ii => ii == typeof(INavigableView))).ToArray();
foreach(TypeInfo ti in viewsTypeInfos)
{
Type viewType = null;
String viewName = null;
viewName = ti.Name;
viewType = ti.AsType();
this.viewsDictionary.Add(viewName, viewType);
}
}
public virtual bool CanGoBack()
{
throw new NotImplementedException();
}
public virtual bool CanGoForward()
{
throw new NotImplementedException();
}
public virtual void GoBack()
{
throw new NotImplementedException();
}
public virtual void GoForward()
{
throw new NotImplementedException();
}
public virtual void Navigate(Type page)
{
throw new NotImplementedException();
}
public virtual void Navigate(Type page, object parameter)
{
throw new NotImplementedException();
}
public virtual void Navigate(string page)
{
throw new NotImplementedException();
}
public virtual void Navigate(string page, object parameter)
{
throw new NotImplementedException();
}
public virtual void ClearBackStack()
{
throw new NotImplementedException();
}
protected void OnNavigationFailed(object sender, NavigationFailedEventArgs e)
{
if (this.NavigationFailed != null)
this.NavigationFailed(sender, e);
}
protected void OnNavigated(object sender, NavigationEventArgs e)
{
if (this.Navigated != null)
this.Navigated(sender, e);
}
#endregion
#region Event Handlers
#endregion
}
ultima, e meno importante, l'interfaccia con la quale identifichiamo le viste nel progetto:
public interface INavigableView
{
}
Utilizzando questi tre oggetti il sistema di navigazione è perfettamente funzionante.
Ultime considerazioni
Nell'interfaccia INavigationService sono presenti due eventi, con handlers definiti come NavigatedEventHandler e NavigationFailedEventHandler. Queste due classi sono definite nel namespace Windows.UI.Xaml.Navigation. Volendo disgiungere completamente l'interfaccia dalle componenti XAML del .NET Framework, basterà ridefinire la classi nel nostro progetto. Ovviamente, aumentare il carico di lavoro ha senso se e solo se sappiamo già che i nostri oggetti potrebbero venire utilizzati in progetti in cui XAML potrebbe non essere disponibile, come ad esempio ASP.NET MVC. In questi casi è possibile tentare di standardizzare la navigazione, ma è logico supporre che molti oggetti di supporto del framework andranno riscritti e inclusi nel nostro progetto.
Informazioni sull'esempio
Allegato a questo articolo rilascerò una Universal App Windows Phone 8.1 / Windows 8.1 di esempio. I metodi di navigazione non risulteranno tutti implementati, ma solamente Navigate(String) e Navigate(Type, Object). Il primo, perchè risulta il più semplice da utilizzare e obiettivamente il più utilizzato. Il secondo perchè è la fondamenta su cui si basa l'implementazione di tutti gli altri metodi, che sono semplici derivazioni del primo sul secondo.
Upload dell'archivio di esempio a breve.
