Windows Phone, Microsoft, Silverlight, Coding4Fun, QuiBrowser.it, Dexter, HTML 5, Internet Explorer 9, Zune Client, .NET Campus, DevLeap, Microsoft Student Partner, Azure, WhyMCA, MVP Summit, MVP

Se siete già pratici del mondo Silverlight sarete già sicuramente a conoscenza di questo fatto, ma se vi siete avvicinati a questo ambiente di sviluppo grazie a Windows Phone potreste trovarvi nella situazione di perdere un sacco di tempo ad affrontare errori che, alla fin fine, non dipendono da voi.

Ma andiamo per gradi: come sapete, Silverlight è una tecnologia client, ovvero le nostre applicazioni girano all’interno del browser, sul nostro computer o sul nostro device ma, al contrario di un’applicazione web, non hanno modo di interfacciarsi direttamente con un server (ad esempio, per eseguire una query su un database). I servizi giocano un ruolo essenziale in questo scenario, dato che tipicamente fanno proprio da ponte tra la parte server della nostra applicazione (ad esempio, il database con i nostri dati) e la parte client (l’interfaccia in Silverlight).

Per motivi di sicurezza, lo stesso principio vale quando vogliamo recuperare una risorsa che sta all’esterno della nostra applicazione (ad esempio, un file XML). Per consentire questi scenari, chi gestisce il server web può concedere ad applicazioni Silverlight esterne di leggere le proprie risorse definendo un file di policy, che specifica a cosa può e a cosa non può accedere la nostra applicazione.

Silverlight è in grado di comprendere due tipologie di file di policy:

• clientaccesspolicy.xml: è il tipo di file nativamente supportato da Silverlight.
• crossdomain.xml: anche Flash è una tecnologia client esattamente come Silverlight e perciò deve sottostare alle stesse regole. Crossdomain.xml è il file di policy nativamente supportato dalla tecnologia Adobe, ma è comprensibile e utilizzabile anche da Silverlight.

Quando un’applicazione Silverlight cerca di accedere ad una risorsa esterna (tecnicamente, si tratta di una chiamata cross domain), va a cercare prima il file clientaccesspolicy.xml nella root del dominio. Se non lo trova, passa a cercare il file crossdomain.xml. Se non trova neanche quello, Silverlight considera il dominio come non abilitato alle chiamate cross domain e quindi restituirà un’eccezione. Tali file vengono cercati, come dicevo poco fa, nella root: se stiamo cercando di accedere ad esempio alla risorsa http://qmatteoq.tostring.it/resources/file.xml, Silverlight cercherà i file http://qmatteoq.tostring.it/clientaccesspolicy.xml e http://qmatteoq.tostring.it/crossdomain.xml.

Vediamo un semplice esempio di file clientaccesspolicy.xml:

<?xml version="1.0" encoding="utf-8"?>
<access-policy>
  <cross-domain-access>
    <policy >
      <allow-from http-request-headers="SOAPAction">
        <domain uri="http://*"/>
      </allow-from>
      <grant-to>
        <resource path="/" include-subpaths="true"/>
      </grant-to>
    </policy>
  </cross-domain-access>
</access-policy>

Questo file, utilizzando la wildcard *, garantisce alle applicazioni Silverlight accesso a qualsiasi risorsa all’interno del nostro dominio utilizzando il protocollo HTTP. E’ possibile definire maggiore granularità, per dare accesso solo ad alcuni percorsi del nostro dominio oppure dare accesso anche tramite altri protocolli / porte (ad esempio, tramite una socket).

Quando entra in gioco il file di policy

Per un applicazione Windows Phone, la risposta è semplice: ogni qualvolta dobbiamo recuperare una risorsa qualsiasi da un sito web, che si tratti di un file XML, di una immagine o altro. Tipicamente, queste richieste vengono fatte utilizzando gli oggetti WebClient (più semplice da utilizzare ma che consuma maggiori risorse) o HttpWebRequest (più veloce e performante, ma più complesso da usare). Se nell’utilizzo di una di queste due classi ci imbattiamo in errori del tipo Unspecified Error, allora quasi sicuramente ci siamo imbattuti in un sito il cui file di policy è mancante oppure vieta esplicitamente l’utilizzo delle risorse

Verificarlo è semplice: vi basta puntare l’URL del vostro browser al file di policy, che vi ricordo deve essere presente nella root di dominio (ad esempio, http://www.website.com/clientaccesspolicy.xml).

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

Non abbiamo fatto in tempo a passare in rassegna tutte le feature del toolkit targato Coding 4 Fun che subito ne è uscita una nuova release! Come sempre, potete scaricarla dal sito ufficiale.

Vediamo una breve panoramica delle novità introdottte.

Bug fixing

Questa nuova release è stata l’occasione per sistemare alcuni dei bug riscontrati nella release iniziale e per fare un po’ di refactoring del codice. Vi segnalo, ad esempio, che i controlli RoundButton ora espongono la proprietà ImageSource al posto di ImagePath: lo scopo rimane sempre lo stesso, ovvero definire l’immagine che verrà mostrata all’interno del pulsante. La differenza è che, al contrario di quanto suggeriva il nome precedente della proprietà, è possibile associare una vera e propria immagine (ad esempio, un oggetto di tipo BitmapImage) e non necessariamente il percorso dell’immagine.

PerformanceProgressBar

Il controllo PerformanceProgressBar è stato rimosso dalla libreria, dato che è stato introdotto nella recente release del SilverlightToolkit, come spiegato in questo post.

ToastPrompt

Questo controllo è una novità del toolkit e permette di visualizzare notifiche toast all’interno della nostra applicazione. Ovviamente, scopo del controllo è quello di visualizzare un elemento identico (sia come layout che come comportamento) ad una notifica toast: non si tratta però di una notifica push vera e propria.

Possiamo utiizzarlo per notificare all’utente un evento all’interno della nostra applicazione: ad esempio, può essere molto utile in un gioco per avvisare l’utente ogni qualvolta completa un achievement (per chi fosse digiuno di videogiochi, gli achievements sono degli obiettivi che, ogni qualvolta raggiunti all’interno del gioco, vengono sbloccati e danno diritto solitamente ad un premio. Esempi di achievements sono “Hai guadagnato 10000 punti” oppure “Hai completato il livello in meno di 1 minuto”).

Vediamo come utilizzarlo da codice:

ToastPrompt toast = new ToastPrompt
                        {
                            IsTimerEnabled = true,
                            MillisecondsUntilHidden = 3000,
                            Title = "Title",
                            Message = "Message"
                        };
toast.Show();

Innanzitutto dichiariamo un nuovo oggetto di tipo ToastPrompt, il quale eredita da FrameworkElement: questo significa che abbiamo a disposizione tutte le classiche proprietà esposte dai controlli Silverlight. Potremo quindi modificare font, colore di sfondo, ecc. Di default, il controllo utilizza come colore di background l’accent color, ovvero quello del tema corrente di Windows Phone. In più, abbiamo a disposizione le seguenti proprietà specifiche:

• IsTimerEnabled: proprietà booleana che indica se il controllo toast debba sparire dopo un certo periodo di tempo oppure no.
• MillisecondsUntilHidden: proprietà di tipo intero che, in combinazione con la proprietà precedente, permette di definire dopo quanto tempo il controllo toast debba sparire dallo schermo.
• Title: il titolo del controllo Toast. Viene visualizzato in grassetto nella parte destra del controllo.
• Message: il testo della “notifica”, viene visualizzato a fianco del titolo.
• Image: una immagine che viene mostrata prima del titolo. Nelle notifiche toast reali, corrisponde all’icona dell’applicazione.

Una volta definito l’oggetto, vi basta richiamare il metodo Show per mostrare l’elemento con le caratteristiche configurate.

In conclusione

Questa volta la lista è stata molto più breve In allegato trovate il vecchio progetto di esempio che avevo realizzato aggiornato con un esempio di utilizzo del controllo ToastPrompt.

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

Ci siamo: Microsoft ha iniziato a distribuire tramite Zune il tanto atteso NoDo, ovvero il primo reale update di Windows Phone (come sappiamo, infatti, l’update precedente aveva semplicemente lo scopo di “preparare” il device per i futuri aggiornamenti).

Rispetto a pre-NoDo, la distribuzione dell’aggiornamento sembra stia avvenendo in maniera più graduale e controllata: discorso carrier a parte (che, vi ricordo, hanno la possibilità di ritardare il rilascio di un update, anceh se con NoDo non dovrebbe accadere), anche chi è in possesso di un device unlocked non è detto che abbia già ricevuto il tanto atteso messaggio di notifica.

Il rilascio è comunque imminente e lo conferma un comunicato stampa fatto circolare da LG Italia, che invita i possessori di un Optimus 7 ad aggiornare il proprio telefono con pre NoDo in vista dell’uscita a brevissimo di un nuovo update.

La cosa più interessante, però, è che Microsoft ha aggiornato la pagina ufficiale dedicata agli update di Windows Phone, includendo il change log completo di NoDo. Con mio grande piacere, veniamo a conoscenza del fatto che oltre alle novità già annunciate diverso tempo fa questo update introduce un gran numero di fix e di miglioramenti, che vanno ad innalzare la qualità complessiva della piattaforma.

Vediamoli brevemente:

• Migliorata l’esperienza d’uso del Marketplace: oltre alle novità nella ricerca, di cui eravamo già a conoscenza, NoDo sistemerà molti dei problemi che sono stati riscontrati dal lancio della piattaforma, come l’impossibilità di aggiornare un’applicazione alla nuova versione se la si è scaricata in modalità trial. Altri miglioramenti prevedono la possibilità di condividere i link per il download delle applicazioni via mail, la possibilità di ordinare i giochi per data di uscita e la possibilità di creare un account XBox Live direttamente dall’hub Games.
• Connessioni WiFi: finalmente, nei Settings dedicati alle connessioni wireless, siamo ora in grado di conoscere il MAC del nostro device, informazione indispensabile nel  caso in cui siamo collegati ad una rete protetta da MAC authentication. Inoltre, è stato rimosso il limite di profili di rete che era possibile salvare e sono state migliorate le performance in caso si siano salvati sul telefono un numero elevato di profili.
• Outlook: anche il client di posta è stato perfezionato, grazie ad un miglior supporto alle Global Address List, agli allegati spediti da iPhone e ad una serie di bug fix.
• Bug fixes vari, negli ambiti MMS, integrazione con Facebook, supporto agli headset Bluetooth e fotocamera.

Scaldate i vostri device perchè NoDo è in arrivo: in caso abbiate attivato nella sezione Settings la ricerca di update anche tramite rete cellulare, riceverete un messaggio di notifica appena questi sarà disponibile. In caso contrario, riceverete la notifica solamente una volta connessi ad una rete WiFi oppure una volta collegato il device al computer. In tutti i casi, la procedura di update passa tramite Zune Client e, per lanciarla, vi basta andare nelle impostazioni e, alla voce Device, selezionare Update. L’applicazione cercherà la presenza di aggiornamenti su Internet, dopodichè vi proporrà di iniziare la procedura di installazione vera e propria.

Buon aggiornamento a tutti!

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

Come sicuramente saprete, uno dei punti di forza dell’avere una tastiera virtuale (non solo su Windows Phone ma anche su altri dispositivi touch) è la sua capacità di potersi adattare al contesto: può diventare una tastiera numerica se stiamo componendo un numero di telefono, una tastiera con accesso veloce alla chiocciola se stiamo scrivendo un indirizzo e-mail, ecc.

Windows Phone permette agli sviluppatori di definire il tipo di tastiera virtuale che vogliamo utilizzare quando viene selezionata una delle TextBox all’interno della nostra applicazione. Ciò è reso possibile tramite la proprietà InputScope esposta dal controllo TextBox e può essere assegnata in due modi.

La sintassi breve

La sintassi più corta e semplice è quella di assegnare un valore tra quelli disponibili (li vedremo dopo in dettaglio) alla proprietà InputScope, come nell’esempio:

<TextBox x:Name="txtDescription" InputScope="Text" />

Qual è lo svantaggio di questo sistema? Che non avremo accesso all’IntelliSense. Già, Visual Studio non propone un elenco dei valori assegnabili alla proprietà InputScope quando utilizziamo questa sintassi.

La sintassi estesa

In Silverlight è possibile definire le proprietà con una sintassi più estesa, che in alcuni casi ci permette di avere maggiore controllo e maggiore versatilità. Ne è un esempio la proprietà Content, esposta ad esempio dall’oggetto Button. Utilizzando la sintassi breve, possiamo limitarci ad assegnare un testo o utilizzare un’espressione di binding. Utilizzando la sintassi estesa, invece, siamo in grado di definire l’aspetto del bottone inserendo a sua volta altri controlli.

Vediamo come definire l’InputScope di un TextBox utilizzando la sintassi estesa:

<TextBox x:Name="txtDescription">
    <TextBox.InputScope>
        <InputScope>
            <InputScopeName NameValue="Text"></InputScopeName>
        </InputScope>
    </TextBox.InputScope>
</TextBox>

Il risultato sarà esattamente lo stesso dell’esempio precedente. La differenza è che con questa sintassi, nel momento in cui ci posizioniamo sull’attributo NameValue, si attiverà l’IntelliSense di Visual Studio, mostrandovi tutti i tipi di tastiera virtuale disponibili.

I tipi di tastiera virtuale

Non vi riporto tutti i tipi di tastiera virtuale disponibili, perchè sono veramente tanti e alcuni ridondanti. Mi limiterò a segnalarvi i principali:

• Text: per la digitazione di testo generico con il supporto al correttore ortografico.
• Number: per l’inserimento di numeri (per intenderci, è quella che compare quando nella tastiera tradizionale premiamo il pulsante &123).
• TelephoneNumber: per la digitazione di numeri telefono (è lo stesso tipo di tastiera che compare quando utilizzate l’applicazione nativa Phone per fare una chiamata).
• EmailNameOrAddress: per la digitazione di indirizzi e-mail, include un tasto per la chiocciola e un tasto per il suffisso .com.
• Url: per la digitazione di indirizzi di siti web, include un tasto per il suffisso .com.

Attenzione!

E’ molto importante ricordarsi sempre di impostare la proprietà InputScope e di non lasciarla vuota, anche se il suo scopo è quello di inserire un testo generico! Questo perchè il controllo TextBox, di default, utilizza una tastiera virtuale “standard” senza però il supporto al correttore ortografico, funzionalità che invece nel 90% dei casi può risultare molto utile. Perciò, a meno che non abbiate dei validi motivi per non abilitare il controllo ortografico (ad esempio, dovete richiedere all’utente uno username), ricordatevi di impostare la proprietà InputScope a Text.

This entry was posted on Monday, 14 March, 2011 and is filed under Windows Phone Tutorials . You can follow any responses to this entry through here . You can leave a response.

Abbiamo parlato in lungo e in largo della libreria Coding 4 Fun, sviscerando i vari controlli e converters inclusi. Ci sono però due helpers che fanno parte di questa libreria di cui non abbiamo ancora parlato, che possono risultare più che utili in moltissime situazioni. Vediamoli!

Binding helper

Scenario: abbiamo una pagina che contiene una serie di TextBox, che sono in binding con alcune proprietà dei nostri oggetti. Dopodichè, abbiamo un pulsante nella ApplicationBar che permette di salvare questi dati da qualche parte (ad esempio, nell’Isolated Storage o su un nostro server chiamando un servizio WCF). Si tratta di uno scenario molto tipico soprattutto con l’utilizzo del pattern M-V-V-M (Model – View – ViewModel, che vi ho accennato più volte in passato e di cui prima o poi troverò il tempo di parlarvi in maniera più approfondita. Se non volete aspettare, trovate tantissimi tutorial su Internet a riguardo).

Vediamo un esempio concreto con un po’ di XAML:

<phone:PhoneApplicationPage.Resources>
        <model:Resources x:Key="Resource" />
</phone:PhoneApplicationPage.Resources>

<Grid x:Name="ContentPanel" Grid.Row="1" Margin="12,0,12,0" DataContext="{Binding Source={StaticResource Resource}}">
        <StackPanel>
            <TextBlock Text="Write your name"></TextBlock>
            <TextBox Text="{Binding Path=Text, Mode=TwoWay}"></TextBox>
        </StackPanel>
    </Grid>
</Grid>

<phone:PhoneApplicationPage.ApplicationBar>
    <shell:ApplicationBar IsVisible="True" IsMenuEnabled="True">
        <shell:ApplicationBarIconButton IconUri="/Images/appbar_button1.png" Text="Save" Click="ApplicationBarIconButton_Click"/>
    </shell:ApplicationBar>
</phone:PhoneApplicationPage.ApplicationBar>

In questo XAML:

• Abbiamo dichiarato come risorsa locale un oggetto della classe Resources, che non è altro che una classe da me creata che espone due proprietà di tipo string, chiamate con molta fantasia Text  e Text2, che utilizzeremo per il binding.
• Abbiamo un controllo TextBox che è in binding con la proprietà Text del nostro oggetto di tipo Resources. Possiamo accedere a questa proprietà grazie al fatto che la nostra Grid, di nome ContentPanel, espone come DataContext proprio il nostro oggetto: questo significa che tutti i controlli figli potranno accedere alle sue proprietà. Notiamo inoltre che il binding è in modalità TwoWay: questo vuol dire che il TextBox non si limiterà a mostrare il valore della proprietà Text, ma che andrà anche a modificarlo quando andremo a cambiare il testo.
• Abbiamo una ApplicationBar con un pulsante, al cui evento click viene invocato un nostro metodo, che vediamo qui sotto.

private void ApplicationBarIconButton_Click(object sender, EventArgs e)
{
    Resources resource = ContentPanel.DataContext as Resources;
    MessageBox.Show(string.IsNullOrEmpty(resource.Text) ? "The TextBox is empty!" : resource.Text,
                    "Coding 4 Fun", MessageBoxButton.OK);
}

Cosa succede? Che al click andiamo a recuperare il DataContext dell’oggetto Grid e lo convertiamo in un oggetto di tipo Resources. A questo punto andiamo a leggerci la proprietà Text (che a questo punto contiene il valore che abbiamo scritto nella casella di testo) e la visualizziamo tramite un MessageBox.

Lanciamo questa semplice applicazione, scriviamo qualcosa nella casella di testo e premiamo il pulsante nella ApplicationBar e… qualcosa non va. Invece di essere visualizzato il nostro testo, come ci saremmo aspettati, apparirà il messaggio “The Textbox is empty”. Perchè? Perchè utilizzando il binding la proprietà Text viene valorizzata solo nel momento in cui il controllo TextBox perde il focus. La pressione del pulsante nella ApplicationBar, trattandosi di un elemento separato rispetto al resto della pagina, non fa spostare il focus dal controllo TextBox: ecco perciò che la proprietà Text è vuota. Se prima di premere il pulsante facciamo tap con il dito in un punto qualunque dello schermo (così da far sparire la tastiera virtuale), il MessageBox mostrerà correttamente il testo inserito.

Come potete facilmente intuire, si tratta di un problema non trascurabile: non possiamo realizzare un form di inserimento dati “sperando” che l’utente faccia tap da qualche parte dello schermo prima di premere il pulsante di conferma.

Per risolvere questo problema, il tool Coding 4 Fun espone un behavior che fa si che la proprietà Text di un controllo TextBox venga aggiornato ogni qualvolta il testo inserito cambia. Il suo utilizzo è molto semplice: innanzitutto dobbiamo includere il namespace che contiene il behavior.

xmlns:Binding="clr-namespace:Coding4Fun.Phone.Controls.Binding;assembly=Coding4Fun.Phone.Controls"

Dopodichè ci basta aggiungere un attributo al controllo TextBox:

<TextBox Text="{Binding Path=Text, Mode=TwoWay}" Binding:TextBoxBinding.UpdateSourceOnChange="True"></TextBox>

In questo modo, se riproviamo a cliccare sul pulsante nella ApplicationBar, vedremo che il MessageBox conterrà il testo inserito nella nostra TextBox, anche senza spostare il focus. Semplice vero?

Phone Helper

Un altro helper che il toolkit ci mette a disposizione si chiama PhoneHelper e ci permette di recuperare informazioni dal file di manifest (WMAppManifest.xml) da poter riutilizzare nella nostra applicazione. Nello specifico, può essere utile per recuperare tutte quelle informazioni che ci serve mostrare nella pagina di Credits, come titolo, publisher, ecc. In questo modo, non dovrete mantenere queste informazioni in due posti diversi (il file di manifest e la pagina di credits), ma vi basterà modificarle una volta sola.

L’utilizzo è molto semplice, come possiamo vedere nell’esempio:

using Coding4Fun.Phone.Controls.Data;
using Microsoft.Phone.Controls;

namespace Coding4Fun.Various.Views
{
    public partial class PhoneHelperView : PhoneApplicationPage
    {
        public PhoneHelperView()
        {
            InitializeComponent();
            string title = PhoneHelper.GetAppAttribute("Title");
        }
    }
}

Una volta aggiunto il namespace Coding4Fun.Phone.Controls.Data possiamo accedere alla classe PhoneHelper, che espone un metodo GetAppAttribute che accetta come parametro il nome della proprietà che vogliamo recuperare (esattamente così com’è scritta nel file di manifest).

In conclusione

Abbiamo finalmente concluso la carrellata di tutte le utility che ci mette a disposizione la libreria Coding 4 Fun: come avrete capito, il valore aggiunto per le vostre applicazioni non è indifferente e vi permette di avere un set di controlli, converters e helpers già pronti, senza che dobbiate reinventare la ruota ogni volta che dovete sviluppare una applicazione Windows Phone.

Come sempre, di seguito trovate il download del progetto completo, comprensivo di tutti gli esempi dei post precedenti dedicati alla libreria più quelli che abbiamo visto oggi.

This entry was posted on Monday, 07 March, 2011 and is filed under Windows Phone Devs . You can follow any responses to this entry through here . You can leave a response.

Dopo aver visto nel post precedente cosa sono i converters di Silverlight, vediamo quali ci vengono messi a disposizione dalla libreria Coding4Fun.

Visibility Converter

I controlli di Silverlight e Windows Phone espongono una proprietà chiamata Visibility che definisce se questi sia visibile o meno. Tale proprietà, contrariamente a quanto si possa pensare, non è di tipo booleano ma può assumere due valori:

• Visibility.Collapsed per nascondere il controllo.
• Visibility.Visible per mostrare il controllo.

Spesso però abbiamo la necessità di esprimere la visiblità di un controllo come valore booleano, per comodità o per necessità. Pensiamo ad esempio alle ProgressBar: se ricordate, come ho spiegato nel post precedente, quando dobbiamo mostrare e/o nascondere la barra di caricamento dobbiamo agire su due proprietà:

• IsIndeterminate, di tipo booleano, che serve ad iniziare/ fermare l’animazione di caricamento.
• Visibility, che abbiamo appena visto e che definisce la visibilità o meno del controllo.

Ciò significa che, in condizioni normali, avremmo bisogno di due proprietà diverse da mettere in binding con la nostra ProgressBar: una di tipo booleano da mettere in binding con la proprietà IsIndeterminate e una di tipo Visibility da mettere in binding con la proprietà Visibility. Possiamo evitare questo “sdoppiamento” proprio grazie ad un converter, che trasformi una proprietà booleana in una proprietà di tipo Visibility (true = Visibility.Visible; false = Visibility.Collapsed). 

Il toolkit Coding4Fun introduce due converters: uno per la conversione da Visibility a Boolean e uno per la conversione contraria da Boolean a Visibility. Vediamo un esempio di codice del primo (che è quello che probabilmente utilizzerete più spesso). Innanzitutto ecco il namespace da dichiarare per accedere ai converters esposti dal toolkit.

xmlns:converter="clr-namespace:Coding4Fun.Phone.Controls.Converters;assembly=Coding4Fun.Phone.Controls"

Poi dichiariamo i due converters come risorse locali, più una terza risorsa che è un oggetto da me creato che viene creato come DataContext per la pagina. Tale oggetto espone semplicemente una proprietà booleana di nome IsVisible ed una stringa di nome Text (che useremo dopo). In più, implementa l’interfaccia INotifyPropertyChanged, in modo che ogni volta il valore di tale proprietà viene cambiato il controllo che è in binding ne venga notificato.

<phone:PhoneApplicationPage.Resources>
    <resources:Resources x:Key="Resources" />
    <converter:BooleanToVisibilityConverter x:Key="BooleanToVisibility" />
    <converter:VisibilityToBooleanConverter x:Key="VisibilityToBoolean" />
</phone:PhoneApplicationPage.Resources>

E ora vediamo il converter all’opera:

<Grid x:Name="ContentPanel" Grid.Row="1" Margin="12,0,12,0" DataContext="{Binding Source={StaticResource Resources}}">
    <StackPanel>
        <StackPanel>
            <ProgressBar IsIndeterminate="{Binding Path=IsVisible}" Visibility="{Binding Path=IsVisible, Converter={StaticResource BooleanToVisibility}}"></ProgressBar>
            <StackPanel Margin="0, 40, 0, 0" Orientation="Horizontal">
                <Button x:Name="Show" Content="Show" Click="Show_Click"></Button>
                <Button x:Name="Hide" Content="Hide" Click="Hide_Click"></Button>
            </StackPanel>
        </StackPanel>
    </StackPanel>
</Grid>

Tutto ruota intorna alla proprietà booleana IsVisible, esposta dall’oggetto Resources che è disponibile tramite il DataContext. Il valore di questa proprietà viene cambiato da codice tramite la pressione dei due pulsanti. Quando premiamo il pulsante Show, tale proprietà viene impostata a true: di conseguenza avviamo l’animazione (IsIndeterminate = true) e, grazie al converter, la ProgressBar diventa visible (Visibility = Visibility.Visible). Quando premiamo il pulsante Hide, invece, la proprietà viene impostata a false, fermando l’animazione e nascondendo il controllo. Ecco il semplice codice sorgente del code behind:

public partial class Converters : PhoneApplicationPage
{
    private Resources resources;

    public Converters()
    {
        InitializeComponent();
        resources = ContentPanel.DataContext as Resources;
    }

    private void Hide_Click(object sender, System.Windows.RoutedEventArgs e)
    {
        resources.IsVisible = false;
    }

    private void Show_Click(object sender, System.Windows.RoutedEventArgs e)
    {
        resources.IsVisible = true;
    }
}

Il converter BooleanToVisibility fa esattamente il contrario: prende un valore di tipo Visibility e lo converte in un’espressione booleana.

Il toolkit contiene però un altro Converter che ha a che fare con la proprietà Visibility: il suo nome è StringToVisibilityConverter e trasforma una stringa in una proprietà di tipo Visibility, utilizzabile per mostrare o nascondere elementi. Il converter prende in input una stringa e restituisce:

• Visibility.Visible se la stringa è vuota (oppure non è stata inizializzata, perciò ha valore null).
• Visibility.Collapsed se la stringa contiene invece un valore.

Vediamo un semplice esempio. Ecco lo XAML in cui una Progress Bar è messa in binding con la proprietà di tipo string Text, esposta dal nostro oggetto Resources.

<StackPanel>
    <ProgressBar IsIndeterminate="True" Visibility="{Binding Path=Text, Converter={StaticResource StringToVisibility}}"></ProgressBar>
    <StackPanel Margin="0, 40, 0, 0" Orientation="Horizontal">
        <Button x:Name="ShowString" Content="Show" Click="ShowString_Click"></Button>
        <Button x:Name="HideString" Content="Hide" Click="HideString_Click"></Button>
    </StackPanel>
</StackPanel>

Quando la pagina viene caricata, di default la ProgressBar è visibile, dato che in fase di inizializzazione la stringa è vuota. Se premiamo il pulsante Show andiamo a valorizzare la stringa, nascondendo così il controllo. Viceversa, se premiamo il pulsante Hide la stringa viene reinizializzata con un valore vuoto, rendendo così nuovamente visibile la barra di caricamento.

Ecco i due metodi legati all’evento di Click sui pulsanti:

private void ShowString_Click(object sender, System.Windows.RoutedEventArgs e)
{
    resources.Text = string.Empty;
}

private void HideString_Click(object sender, System.Windows.RoutedEventArgs e)
{
    resources.Text = "This is a text";
}

Themed image converter

Spesso e volentieri, quando sviluppiamo applicazioni per Windows Phone ci dimentichiamo di tenere conto di un fattore che in realtà è fondamentale: il tema impostato dall’utente sul suo telefono. Tutti i testi e gli elementi grafici, di default, si adattano al tema scelto dall’utente: se non teniamo conto di questa cosa, rischiamo di avere applicazioni che sono bellissime se viene utilizzato un tema e inguardabili se invece ne viene utilizzato un altro. Spesso questa cosa si riflette anche sulle immagini che inseriamo: se non impostiamo un background fisso ma lasciamo che venga selezionato in base al tema, non possiamo inserire una immagine bianca se l’utente sta utilizzando il tema chiaro o un’immagine nera se l’utente sta utilizzando il tema scuro.

Una delle necessità che nasce è perciò quella di poter caricare a runtime una immagine piuttosto che un’altra a seconda del tema selezionato dall’utente. Questo converter ci serve proprio a questo: la sua logica fa si che venga identificato il tema correntemente selezionato (tramite la verifica di una delle risorse globali dell’applicazione) e venga caricata l’immagine corretta. Vediamo come funziona:

<phone:PhoneApplicationPage.Resources>
    <converter:ThemedImageConverter x:Key="ThemedImageConverter" />
    <System:String x:Key="ImagePath">/Media/icons/{0}/appbar.check.rest.png</System:String> 
</phone:PhoneApplicationPage.Resources>

Abbiamo dichiarato due risorse locali: uno è il nostro converter, l’altra invece è una stringa con il percorso dell’immagine che vogliamo inserire. Questo perchè un converter può essere utilizzato solo in combinazione con una espressione di binding: non possiamo perciò utilizzarlo se impostiamo il percorso dell’immagine direttamente nella proprietà Source del controllo Image. Notiamo che il percorso contiene il simbolo {0}. Questo perchè il converter non fa altro che prendere il percorso dell’immagine e, utilizzando la funzione string.Format, andare ad inserire alla posizione {0} il nome del tema correntemente selezionato (dark o light). Questo ci fa capire che, per utilizzare correttamente il converter, dobbiamo strutturare la cartella che contiene le nostre immagini in modo che:

• esista una sottocartella chiamata light che contenga tutte le immagini che vogliamo utilizzare in caso l’utente utilizzi il tema chiaro.
• esista una sottocartella chiamata dark che contenga tutte le immagini che vogliamo utilizzare in caso l’utente utilizzi il tema scuro.

Il percorso e il nome delle immagini deve essere assolutamente identico: l’unica cosa che deve cambiare è il nome della cartella che contiene le immagini specifiche del tema. Vediamo ora come utilizzarlo:

<Grid x:Name="ContentPanel" Grid.Row="1" Margin="12,0,12,0">
    <Image Source="{Binding Source={StaticResource ImagePath}, Converter={StaticResource ThemedImageConverter}}" Width="48" Height="48"/>
</Grid>

Come spiegato in precedenza, siamo costretti ad usare una espressione di binding per usare il conveter: ecco perciò che mettiamo in binding la proprietà Source del nostro controllo Image con la risorsa dichiarata in precedenza, che contiene il percorso dell’immagine.

La libreria Coding4Fun espone un’altro converter, chiamato ThemedInverseImageConverter, che svolge la funzione esattamente opposta: in caso l’utente stia utilizzando il tema chiaro le immagini verranno prese dalla cartella dark, se l’utente viceversa sta uitlizzando il tema scuro verrà utilizzata la cartella light.

In conclusione

Con questo post abbiamo visto i converters esposti dalla libreria Coding4Fun: ci manca veramente poco, nel prossimo e ultimo post (che sarà molto più breve) vedremo gli ultimi helper messi a disposizione da questa utile libreria. Di seguito trovate il codice sorgente del progetto dimostrativo aggiornato con le novità viste oggi.

This entry was posted on Thursday, 03 March, 2011 and is filed under Windows Phone Tutorials . You can follow any responses to this entry through here . You can leave a response.