Ho cercato di riassumere lo scopo del post nel titolo, ma lo riassumo qui per maggiore chiarezza. Lo scopo è quello di scatenare il ‘seleziona tutto il testo’ quando una TextBox prende il focus. Chiaramente in ottica MVVM, quindi senza sporcare il code-behind della pagina. E’ uno dei comportamenti di default che più mi mancano, anche perchè sarebbe bastato aggiungere una proprietà AutoSelectAll nella TextBox e parecchi developer sarebbero stati più contenti.

Fortunatamente è piuttosto semplice scrivere una classe che raggiungere lo stesso risultato.

public static class TextBoxHelper
{
    public static bool GetAutoSelectAll(DependencyObject obj)
    {
        return (bool)obj.GetValue(AutoSelectAllProperty);
    }

    public static void SetAutoSelectAll(DependencyObject obj,
        bool value)
    {
        obj.SetValue(AutoSelectAllProperty, value);
    }

    public static readonly DependencyProperty AutoSelectAllProperty =
        DependencyProperty.RegisterAttached("AutoSelectAll",
        typeof(bool),
        typeof(TextBoxHelper),
        new PropertyMetadata(null,
        new PropertyChangedCallback(Setup)));

    private static void Setup(DependencyObject obj,
        DependencyPropertyChangedEventArgs e)
    {
        TextBox tb = obj as TextBox;

        if (tb != null)
        {
            bool oldValue = (bool)e.OldValue;
            bool newValue = (bool)e.NewValue;

            if (oldValue == false && newValue == true)
            {
                tb.GotFocus += tb_GotFocus;
            }
            else if (oldValue == true && newValue == false)
            {
                tb.GotFocus -= tb_GotFocus;
            }
        }
    }

    static void tb_GotFocus(object sender, RoutedEventArgs e)
    {
        TextBox tb = sender as TextBox;

        if (tb != null)
        {
            tb.SelectAll();
        }
    }
}

Questa classe va ovviamente utilizzata nello XAML:

<TextBox common:TextBoxHelper.AutoSelectAll="True" />

Quando questa TextBox prende il focus, il testo in esso contenuto viene automaticamente selezionato grazie al behavior che gli abbiamo agganciato. Tutto questo direttamente nello XAML, senza code-behind, in perfetta sintonia con MVVM.

Send to Kindle

Prima di poter tentare il submit di un’app Windows 8 per lo Store, è necessario far girare localmente sul vostro PC il tool in oggetto, il Windows App Cert Kit. Non ve ne potete scordare, perchè vi viene automaticamente proposto da Visual Studio appena terminate di creare il package da uploadare nella dashboard. Questo tool fa un sacco di controlli in locale, e vi segnala eventuali problemi che causerebbero la bocciatura dell’app stessa, senza però farvi perdere tempo (qualche giorno) prima di avere un feedback da parte di Microsoft.

Ieri sera, facendolo girare a seguito della creazione di un nuovo package, mi ha bocciato l’app con la seguente unica motivazione:

Il rapporto del contrasto tra colore di sfondo e colore del testo in primo piano è 1,16. Questo rapporto deve essere maggiore o uguale a 1,5.

La morale, ben spiegata dal testo, è che non c’è abbastanza contrasto tra il colore di sfondo ed il colore del testo. Un valore 1 significa che in pratica avete lo stesso colore, il che è assurdo. Prima che vi mettiate a ripensare un altro colore di sfondo, a rifare i loghi, a ridisegnare le icone, etc. etc., aprite il file di manifest dell’app (Package.appxmanifest) e date un’occhiata alle seguenti impostazioni:

• Foreground text
• Background color

Il Windows App Cert Kit non misura quel rapporto guardando veramente i colori delle vostre Page, ma guarda questi due parametri. Nel mio caso, avevo impostato un colore di sfondo #F2EEDC, mentre il colore del testo era impostato a Light. In pratica, un colore molto simile al bianco, con il testo bianco. Direi poco contrasto, come riportato dal tool! La realtà quindi è che la mia app era perfettamente visibile ed usabile, perchè nei vari elementi della UI non usavo quel valore, ma avevo io impostato “Black” tramite una mia risorsa, senza usare le risorse di sistema.

E’ bastato mettere il ‘Foreground text’ a Dark e l’app ha passato il test con successo.

Send to Kindle

Ok ok, il titolo di questo post è un po’ assurdo. Se siete sviluppatori di app Windows 8, probabilmente vi è già capitato. Oppure no. Nel qual caso, prendete appunti. Immaginate una pagina di un’app Windows 8 strutturata – in soldoni – da una Grid con tre righe, il cui contenuto è:

• prima riga: intestazione, logo, quello che volete, nulla di importante
• seconda riga: ScrollViewer a scorrimento orizzontale, che contiene UI più complessa, che rappresenta il contenuto vero e proprio dell’app
• terza riga: controllo AdControl per mostrare un po’ di pubblicità

Ora, ieri sera mi è accaduta una cosa strana. Dal punto di vista utente, voglio che i miei utenti possano utilizzare la rotella del mouse per scorrere lo ScrollViewer indicato prima. Ricordiamocelo: le app Windows 8 non sono solamente touch, ma devono funzionare anche con tastiera & mouse. Appena l’app viene avviata, l’utente deve fin da subito poter rotellare usare la rotella del mouse per scorrere avanti ed indietro i contenuti. A me questo meccanismo non funzionava, sebbene avessi impostato nello XAML le proprietà IsTabStop=”true” e TabIndex=”"0” sullo ScrollViewer. Se invece andavo cliccare manualmente all’interno dello ScrollViewer, ecco che la rotella aveva effetto.

Vi riassumo in due righe circa 2 ore di litigate col codice per capire il problema. Sgrunt.

In pratica ho scoperto che il controllo AdControl per l’advertising contiene al suo interno un controllo WebView che – guarda caso – si appropriava del focus. Quindi all’avvio dell’app lo ScrollViewer perdeva automaticamente il focus, e la rotella smetteva di funzionare.

Come ho risolto? Così:

<adv:AdControl IsEnabled="False"
ApplicationId="xyz"
AdUnitId="xyz" />

.csharpcode, .csharpcode pre
{
font-size: small;
color: black;
font-family: consolas, “Courier New”, courier, monospace;
background-color: #ffffff;
/*white-space: pre;*/
}
.csharpcode pre { margin: 0em; }
.csharpcode .rem { color: #008000; }
.csharpcode .kwrd { color: #0000ff; }
.csharpcode .str { color: #006080; }
.csharpcode .op { color: #0000c0; }
.csharpcode .preproc { color: #cc6633; }
.csharpcode .asp { background-color: #ffff00; }
.csharpcode .html { color: #800000; }
.csharpcode .attr { color: #ff0000; }
.csharpcode .alt
{
background-color: #f4f4f4;
width: 100%;
margin: 0em;
}
.csharpcode .lnum { color: #606060; }

Impostando la proprietà IsEnabled a false, l’AdControl, e la WebView al suo interno, non si prendono più il focus e tutto funziona egregiamente. Sulla UI non c’è alcuna differenza: il banner appare come deve apparire, è cliccabile, per cui non cambia nulla: ma essendo disabilitato non può prendersi il focus.

Ultima nota: non so se questo comportamento accade sempre o magari nel mio caso avevo una situazione più complessa o fuorviante. Ho risolto nel modo descritto: se dovesse capitare anche a voi, sapete quale potrebbe essere una possibile causa.

Send to Kindle

Sebbene condividano lo stesso approccio, c’è una enorme grande differenza tra costruire un’app per Windows Phone 7 ed un’app per Windows 8. Quest’ultima deve adattarsi alla risoluzione del device su cui sta girando (notebook, ultrabook, tablet, etc.) e soprattutto deve essere in grado di adattarsi a tre modalità di visualizzazione, ovvero:

• landscape (quando tenete il pc in orizzontale)
• portrait (quando tenete il pc in verticale)
• snapped (quando andate ad agganciare l’app sul bordo sinistro o destro dello schermo)

Sappiamo tutti che il modo migliore è lasciare che il runtime .NET o WinRT faccia tutto il lavoro di intercettazione del cambiamento della vista: tramite il Visual State Manager possiamo andare a modificare qualsiasi proprietà della UI per fare in modo che la vista si adatti. In pratica, possiamo, possiamo per esempio rendere visibili/invisibili dei controlli, possiamo stringere/allargare colonne e via dicendo. Questo implica una cosa piuttosto importante: ad ogni controllo su cui vogliamo interagire tramite Visual State Manager dobbiamo assegnare un nome.

Io dal canto mio ho trovato un modo che mi piace di più, riassunto del codice XAML qui sotto.

<Page>
    <Page.Resources>
    </Page.Resources>
    <Grid>
        <”Panel” x:Name="FullScreenMainGrid">
        </”Panel”>
        <Panel x:Name="PortraitMainGrid">
        </”Panel”>
        <Panel x:Name="SnappedMainGrid">
        </”Panel”>
    </Grid>
</Page>

.csharpcode, .csharpcode pre
{
font-size: small;
color: black;
font-family: consolas, “Courier New”, courier, monospace;
background-color: #ffffff;
/*white-space: pre;*/
}
.csharpcode pre { margin: 0em; }
.csharpcode .rem { color: #008000; }
.csharpcode .kwrd { color: #0000ff; }
.csharpcode .str { color: #006080; }
.csharpcode .op { color: #0000c0; }
.csharpcode .preproc { color: #cc6633; }
.csharpcode .asp { background-color: #ffff00; }
.csharpcode .html { color: #800000; }
.csharpcode .attr { color: #ff0000; }
.csharpcode .alt
{
background-color: #f4f4f4;
width: 100%;
margin: 0em;
}
.csharpcode .lnum { color: #606060; }

In pratica avete una Grid esterna che non fa altro che contenere altri tre Panel al suo interno (tali Panel possono essere Canvas, altre Grid, StackPanel, qualsiasi pannello previsto da WinRT – io ho messo Panel giusto per rendere l’idea). In modo alla visualizzazione corrente, solo uno di questi Panel sarà visibile in un dato momento. C’è il Panel che contiene il layout specifico per il landscape, poi c’è quello per il portrait, ed infine c’è quello dedicato alla visualizzazione snapped. Può sembrare una cosa prolissa, eppure io mi trovo bene così. So che toccando una certa porzione di XAML non vado a modificare le altre viste. E se lavorate con MVVM, basta fare binding e siete a posto: il codice del viewmodel che governa la view è sempre lo stesso.

Lo parte di XAML relativa al Visual State Manager è la seguente:

<VisualStateManager.VisualStateGroups>
    <VisualStateGroup x:Name="ApplicationViewStates">

        <VisualState x:Name="FullScreenLandscape">
            <Storyboard>
                <ObjectAnimationUsingKeyFrames
                    Storyboard.TargetName="FullScreenMainGrid"
                    Storyboard.TargetProperty="Visibility">
                    <DiscreteObjectKeyFrame KeyTime="0" Value="Visible"/>
                </ObjectAnimationUsingKeyFrames>
                <ObjectAnimationUsingKeyFrames
                    Storyboard.TargetName="SnappedMainGrid"
                    Storyboard.TargetProperty="Visibility">
                    <DiscreteObjectKeyFrame KeyTime="0" Value="Collapsed"/>
                </ObjectAnimationUsingKeyFrames>
                <ObjectAnimationUsingKeyFrames
                    Storyboard.TargetName="PortraitMainGrid"
                    Storyboard.TargetProperty="Visibility">
                    <DiscreteObjectKeyFrame KeyTime="0" Value="Collapsed"/>
                </ObjectAnimationUsingKeyFrames>
            </Storyboard>
        </VisualState>

        <VisualState x:Name="Filled">

        </VisualState>

        <VisualState x:Name="FullScreenPortrait">
            <Storyboard>
                <ObjectAnimationUsingKeyFrames
                    Storyboard.TargetName="FullScreenMainGrid"
                    Storyboard.TargetProperty="Visibility">
                    <DiscreteObjectKeyFrame KeyTime="0" Value="Collapsed"/>
                </ObjectAnimationUsingKeyFrames>
                <ObjectAnimationUsingKeyFrames
                    Storyboard.TargetName="SnappedMainGrid"
                    Storyboard.TargetProperty="Visibility">
                    <DiscreteObjectKeyFrame KeyTime="0" Value="Collapsed"/>
                </ObjectAnimationUsingKeyFrames>
                <ObjectAnimationUsingKeyFrames
                    Storyboard.TargetName="PortraitMainGrid"
                    Storyboard.TargetProperty="Visibility">
                    <DiscreteObjectKeyFrame KeyTime="0" Value="Visible"/>
                </ObjectAnimationUsingKeyFrames>
            </Storyboard>
        </VisualState>

        <VisualState x:Name="Snapped">
            <Storyboard>
                <ObjectAnimationUsingKeyFrames
                    Storyboard.TargetName="FullScreenMainGrid"
                    Storyboard.TargetProperty="Visibility">
                    <DiscreteObjectKeyFrame KeyTime="0" Value="Collapsed"/>
                </ObjectAnimationUsingKeyFrames>
                <ObjectAnimationUsingKeyFrames
                    Storyboard.TargetName="SnappedMainGrid"
                    Storyboard.TargetProperty="Visibility">
                    <DiscreteObjectKeyFrame KeyTime="0" Value="Visible"/>
                </ObjectAnimationUsingKeyFrames>
                <ObjectAnimationUsingKeyFrames
                    Storyboard.TargetName="PortraitMainGrid"
                    Storyboard.TargetProperty="Visibility">
                    <DiscreteObjectKeyFrame KeyTime="0" Value="Collapsed"/>
                </ObjectAnimationUsingKeyFrames>
            </Storyboard>
        </VisualState>
    </VisualStateGroup>
</VisualStateManager.VisualStateGroups>

.csharpcode, .csharpcode pre
{
font-size: small;
color: black;
font-family: consolas, “Courier New”, courier, monospace;
background-color: #ffffff;
/*white-space: pre;*/
}
.csharpcode pre { margin: 0em; }
.csharpcode .rem { color: #008000; }
.csharpcode .kwrd { color: #0000ff; }
.csharpcode .str { color: #006080; }
.csharpcode .op { color: #0000c0; }
.csharpcode .preproc { color: #cc6633; }
.csharpcode .asp { background-color: #ffff00; }
.csharpcode .html { color: #800000; }
.csharpcode .attr { color: #ff0000; }
.csharpcode .alt
{
background-color: #f4f4f4;
width: 100%;
margin: 0em;
}
.csharpcode .lnum { color: #606060; }

Il concetto è molto semplice: per ogni stato (FullScreenLandscape, FullScreenPortrait, Snapped) rendete invisibili due Panel e rendete visibile quello previsto per quello stato.

In questo modo evitate di impazzire assegnando nomi ai controlli qua e là, e siete assolutamente sicuri di come viene renderizzata una vista in un certo stato. Ogni vista è indipendente dalle altre. Prima cercavo di stringere/allargare colonne e righe di una Grid, oppure di rimpicciolire il FontSize delle TextBlock e degli altri controlli, ma finivo sempre per impazzire. Alla fine penso che la strada più lineare, semplice e comoda da gestire sia questa.

Che ne dite?

Send to Kindle

Mi sono scontrato con due problemi, secondo me piuttosto oscuri, mentre lavoravo sull’advertising di una mia app per Windows Phone. Piuttosto oscuri perchè su Internet ho trovato ben poco.

Parto dal presupposto che sappiate già di cosa parlo: controllo AdControl, registrazione su PubCenter, qualche concetto di XAML, capabilities di un’app Windows Phone, etc.

Il primo problema è il seguente: nonostante voi mettiate il controllo AdControl sulla vostra pagina XAML, quando mandate in esecuzione l’app esso improvvisamente scompare. Questo vale sia all’interno del simulatore, sia su un device vero e proprio. E continua a valere anche se impostate i valori delle seguenti proprietà:

• proprietà ApplicationId a “test_client”
• proprietà AdUnitId a “Image480_80”

Questo due valori permettono di testare il motore di advertising, senza realmente accedere ai banner pubblicitari veri e propri. A design-time vedete il vostro bel controllo, ma se mandate in esecuzione sparisce tutto nel giro di un decimo di secondo. Attenzione: non sto dicendo che non vedete alcun banner: è proprio il controllo che sparisce dalla Page. Beh, se questa cosa capita anche a voi, fate una bella cosa: sottoscrivete l’evento ErrorOccured nello XAML e nel code-behind della pagina potete semplicemente scrivere (vado a memoria):

MessageBox.Show(e.Error.ToString())

Nel mio caso, mancavano alcune capabilities necessarie per far funzionare l’advertising, ovvero:

• ID_CAP_PHONEDIALER
• ID_CAP_IDENTITY_USER
• ID_CAP_MEDIALIB
• ID_CAP_WEBBROWSERCOMPONENT

Se non mettete queste capabilities nella vostra app, l’advertising non andrà mai.

L’altro problema, invece, è ancora più oscuro, almeno fintantochè non trovate e capite la soluzione. Sempre grazie all’evento ErrorOccured citato prima, potreste ottenere una AdException con pressapoco un errore simile a “An unexpected error occured during response processing (Name: ECN)”. Non state a sbatterci la testa: impostate la lingua del telefono su inglese e riprovate. Se funziona, significa che le categorie impostate sulla unità di annunci non hanno banner per la lingua italiana. Quindi o tornare su PubCenter e provate a cambiare categorie, oppure boh! L’importante è che avete capito è che non avete un errore nel codice o nello XAML della vostra app, ma è semplicemente qualcosa che riguarda la configurazione del vostro advertising server-side. A meno che, chiaramente, non dobbiate cambiare ApplicationId o AdUnitId nello XAML.

Send to Kindle