Windows Phone, Windows 8, Microsoft, WinRT, DotNetLombardia, Gaia, Funambol, Surface

Tranquilli, non ho tradito Windows Phone per Windows 8 Windows Phone al momento si trova in una situazione un po’ di stallo: la versione 7.5 è ormai sul mercato da più di un anno, perciò diventa sempre più difficile trovare qualcosa di nuovo su cui bloggare a riguardo. Si tratta però di uno stallo temporaneo: nel corso dell’estate Microsoft rilascerà la prima beta del’SDK di Windows Phone 8, allora vedrete che i post su Windows Phone torneranno in gran numero

In più, alla luce dei recenti annunci, imparare a conoscere WinRT è sicuramente un ottimo trampolino di lancio per preparsi al futuro.

Ma veniamo al dunque: oggi vi voglio parlare di un servizio che vi semplificherà la navigazione da una pagina all’altra nella vostra applicazione XAML / C# sviluppata utilizzando il pattern MVVM. Questo servizio arriva direttamente dalla mia esperienza di sviuppo per Windows Phone; una delle sfide da affrontare nell’utilizzo del pattern MVVM è che solitamente la navigazione verso un’altra pagina viene avviata da qualcosa che si è verificato in un ViewModel: il variare di una proprietà (ad esempio, l’elemento selezionato di una lista) o l’utilizzo di un comando (ad esempio, la pressione di un pulsante). Il problema è che il NavigationService è accessibile solo dal code behind, in quanto fa parte delle proprietà esposte dalla classe PhoneApplicationPage, dalla quale derivano tutte le pagine di Windows Phone.

Per risolvere questo inghippo ci sono diverse strategie: quella da me utilizzata sfrutta un’implementazione di un NavigationService illustrata in un post di Laurent Bugnion. Questo servizio non fa altro che da wrapper al NavigationService reale, offrendo la possibilità in un ViewModel di avviare una navigazione semplicemente inizializzando questo servizio all’interno dello stesso.

Veniamo ora all’applicazione Windows 8: il NavigationService di Windows Phone, così com’è, non è in grado di funzionare, dato che questi utilizza la proprietà Application.Current.RootVisual per accedere al frame principale dell’applicazione e, di conseguenza, gestire gli eventi di navigazione. Tale proprietà non è disponibile in WinRT: ecco perciò che è stato necessario trovare una soluzione alternativa.

La mia prima soluzione, funzionale ma non molto elegante, è stata quella di esporre come proprietà pubblica il rootFrame che viene inizializzato nel file App.xaml.cs: è tramite l’inizializzazione di questa classe che abbiamo la possibilità, nel code behind di una pagina, di avviare una navigazione tramite il metodo Frame.Navigate. In questo modo, l’implementazione del NavigationService era sostanzialmente la stessa di Windows Phone, con la differenza che utilizzavo la proprietà appena definita per accedere al frame e gestire gli eventi di navigazioneal posto di usare Application.Current.RootVisual, come nell’esempio:

 _mainFrame = (Application.Current as App).rootFrame;

Il mio amico Joost van Shaik, MVP anche lui nella categoria Windows Phone Development, partendo dal mio approccio è riuscito ad elaborare una soluzione molto più elegante: il costruttore del NavigationService accetta ora come parametro in fase di inizializzazione l’oggetto frame da utilizzare. Sfruttando poi il meccanismo della dependency injection siamo in grado, nell’App.xaml.cs, di registrare all’avvio il NavigationService opportunamente inizializzato con il rootFrame e di utilizzare questa istanza in tutti i nostri view models, mantenendo perciò sempre attivo il riferimento al frame.

Ecco il codice del NavigationService:

public class NavigationService : INavigationService
{
public NavigationService(Frame mainFrame)
{
  _mainFrame = mainFrame;
}

private Frame _mainFrame;

public event NavigatingCancelEventHandler Navigating;

public void NavigateTo(Type type)
{
    _mainFrame.Navigate(type);
}

public void NavigateTo(Type type, object parameter)
{
    _mainFrame.Navigate(type, parameter);
}

public void GoBack()
{
  if (_mainFrame.CanGoBack)
  {
    _mainFrame.GoBack();
  }
}

Rispetto al NavigationService di Windows Phone illustrato nel post di Laurent Bugnion le uniche differenze sono:

• Il tipo di parametro passato al metodo NavigateTo, dato che il metodo Frame.Navigate di Windows 8 richiede il tipo della pagina verso cui ci vogliamo spostare, al contrario di quello di Windows Phone che accetta un URL.
• La presenza di un overload del metodo NavigateTo, dato che Windows 8 supporta la possibilità di portare un oggetto da una pagina all’altra, al contrario di Windows Phone che supporta solo il passaggio di parametri tramite query string.

Ecco un esempio di come avviene questa inizializzazione utilizzando uno dei dependency injection container disponibile per WinRT, chiamato MetroIoc. La registrazione avviene all’interno del metodo OnLaunched del file App.xaml.cs, che viene invocato nel momento in cui l’applicazione viene avviata dalla tile principale o da una di quelle secondarie (se supportate).

protected override void OnLaunched(LaunchActivatedEventArgs args)
{
    var rootFrame = new Frame();
    // Do not repeat app initialization when already running, just ensure that
    // the window is active
    if (args.PreviousExecutionState == ApplicationExecutionState.Running)
    {
        Window.Current.Activate();
        return;
    }

    if (args.PreviousExecutionState == ApplicationExecutionState.Terminated || args.PreviousExecutionState==ApplicationExecutionState.NotRunning)
    {
        ioc.RegisterInstance(typeof (INavigationService), new NavigationService(rootFrame));
    }
    
    if (!rootFrame.Navigate(typeof(MainPage)))
    {
        throw new Exception("Failed to create initial page");
    }

    // Place the frame in the current Window and ensure that it is active
    Window.Current.Content = rootFrame;
    Window.Current.Activate();
}

A questo punto all’interno dei vostri view model, previa inizializzazione del NavigationService (tramite dependency injection oppure in maniera tradizionale) potete avviare la navigazione semplicemente chiamando il metodo NavigateTo, come nell’esempio:

public MainViewModel(INavigationService navigationService)
{
    navigationService.NavigateTo(typeof(DetailPage));
}

Happy coding!

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

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]);
    }
}

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

No, non sto parlando dello schermo touch screen prodotto da Microsoft, ma di una novità ben più interessante e sostanziosa: con un evento organizzato ad hoc e mantenuto ben segreto fino alla fine, Microsoft la notte scorsa a presentato la sua nuova idea di tablet, Surface per l’appunto.

Ideologicamente, si tratta di una novità importantissima: dopo la parentesi XBox, Microsoft si butta nel campo dell’hardware con un nuovo prodotto dedicato al mercato consumer, che è indice di quanto Microsoft stia puntando su Windows 8, tanto da convincerla a scendere in campo in prima persona.

Tecnologicamente, si tratta di un prodotto molto affascinante, sia come form factor che come caratteristiche. Partiamo dal primo: Surface si presenta con un design semplice e molto solido (lo schermo è di 10.6 pollici), con però qualche accorgimento, che alza il livello della qualità del prodotto. La prima è un supporto integrato nello chassis stesso, che consente di appoggiare il tablet su un tavolo e tenerlo in piedi; la seconda novità, a mio avviso geniale, sono le Touch Cover e Type Cover, due cover magnetiche (disponibili in diversi colori), molto simili a quella dell’iPad 2, ma con un tocco di classe in più: non è solo una cover per proteggere il tablet, ma integra una tastiera da utilizzare quando si appoggia il tablet su una superficie. Le due tipologie si differenziano per il tipo di tastiera: la prima è basata sulla tecnologia touch ed è più sottile, la seconda è più spessa ma offre un feeling più simile a quello di una tastiera tradizionale.

Dal punto di vista delle caratteristiche tecniche, in realtà i modelli disponibili di Surface sono due: Surface for Windows RT nasce come tablet puro ed è dotato di Windows RT, ovvero la versione di Windows 8 specifica per i tablet ARM. Si tratta nè più nè meno di un (validissimo, a mio avviso) concorrente dei tablet attualmente sul mercato: vi ricordo infatti che Windows RT è la versione più “tablet” di Windows 8, in quanto non supporta la modalità desktop (se non per l’uso di Office e Internet Explorer) ma solo le applicazioni Metro style.

I punti di forza di questa versione saranno il prezzo (anche se ancora non sono stati diffusi), il peso ridotto (circa 600 grammi) e l’autonomia (garantita dall’uso di processori ARM): completano la dotazione uno storage SSD da 32 o 64 GB, una webcam e diverse porte di connessione (USB, memory card, HDMI).

Il secondo modello si chiama Surface for Windows Pro e più che un tablet è uno slate pc: dimensioni e form factor sono assolutamente identici, però al suo interno non troviano un ARM ma un i5 Intel, con uno storage da 64 a 128 GB (sempre con disco SSD). In questo caso, essendo un processore x86, troviamo installata la versione “full” di Windows 8, che rende questo modello di Surface un sostituto di un notebook o un ultrabook, grazie al supporto alla modalità desktop e quindi alla compatibilità con tutte le applicazioni “tradizionali” e non solamente con quelle Metro style.

Rispetto alla versione Windows RT questo modello avrà sicuramente un prezzo superiore e una autonomia più ridotta: anche il peso è maggiore (quasi 1 Kg). Ne guadagna però in flessibilità: grazie all'utilizzo di una versione "tradizionale" di Windows 8, questo modello può facilmente sostituire un portatile o un ultrabook. Si tratta sicuramente di un prodotto molto interessante per il mondo business, in quanto coniuga la versatilità di un computer tradizionale con il look & feel di un prodotto consumer, quindi piacevole da vedere e utilizzare.

Personalmente non vedo l’ora di poterci mettere le mani sopra: l’attesa non dovrebbe essere lunghissima, si parla di un rilascio della versione Windows RT più o meno in contemporanea con la RTM di Windows 8, mentre bisognerà aspettare 2 o 3 mesi in più per la versione Windows Pro.

Vi lascio con un approfondimento di Engadget, dove trovate foto, video e una prova su strada del prodotto.

This entry was posted on Wednesday, 20 June, 2012 and is filed under Windows 8 . You can follow any responses to this entry through here . You can leave a response.