Sviluppando una mia app Windows 8 mi è capitata una cosa strana riguardante i Background Task. Se volete capire cosa sono, a cosa servono e come si sviluppano i Background Task vi rimando a questi due post (in inglese) dell’amico Matteo Pagani: post 1 e post 2.

Quello che mi è accaduto è che il debugging effettuato tramite Visual Studio 2012 non è veramente la stessa cosa che accade quando invece il codice gira realmente tramite l’app deployata. Ora vi spiego.

Immaginate di sviluppare un’app che vi fa il countdown relativamente ad un certo evento. Oggi è il 14 Gennaio. Supponiamo di voler impostare un countdown per San Valentino. Il countdown appare sulla tile dell’app stessa. Quindi oggi apparirebbe una cosa tipo “mancano 30 giorni a san valentino”, domani vedreste “mancano 29 giorni a san valentino”, e così via.

In pratica, il Background Task della mia app, che gira ogni 15 minuti, non fa altro che aggiornare la tile riportando il tempo rimanente. Le informazioni sull’evento sono banalmente scritte in un file .txt, che viene creato nel momento in cui scegliete l’evento. Quindi, per riassumere, ecco il codice contenuto nel metodo Run del Background Task.

public async void Run(IBackgroundTaskInstance taskInstance)
{
    BackgroundTaskDeferral deferral = taskInstance.GetDeferral();

    try
    {
        var container = Windows.Storage.ApplicationData.Current.LocalFolder;
        var file = await container.GetFileAsync("File.txt");
        var lines = await Windows.Storage.FileIO.ReadLinesAsync(file);
        var header = lines[0];
        var time = DateTime.Parse(lines[1]);

        if (time > DateTime.Now)
        {
            var ts = time.Subtract(DateTime.Now);
            string content = ts.TimeSpanDescription(" all'evento scelto. Non mancare!");
            TileHelper.UpdateTileWidePeekImage01("Assets/WideLogo.reminder.png", header, content);
        }
        else
        {
            TileHelper.UpdateTileWideImage("Assets/WideLogo.scale-100.png");
        }
    }
    catch (Exception)
    {

    }

    deferral.Complete();
}

Questo è il codice corretto, che gira senza problemi, per cui sa volete prendere ispirazione, fatelo pure. Occhio però a come usate la keyword await, necessaria per eseguire i metodi asincroni. Stupidamente, io in una prima versione del codice non la usavo, ed usavo invece il metodo GetResults(). Per spiegarmi meglio, ecco il pezzetto di codice incriminato:

var lines = Windows.Storage.FileIO.ReadLinesAsync(file).GetResults();

Ripeto il concetto: invece di usare await, ho chiamato GetResults(), convinto – chissà perchè – che facessero la stessa cosa. Purtroppo questa cosa è stata ereditata da un pezzetto di codice scritto mesi fa, quando avevo ancora a che fare con le versioni beta di Windows 8 e Visual Studio 2012 11. La cosa bella è proprio questa: questo codice qui sopra quando eseguito da Visual Studio gira senza problemi (dentro l’oggetto lines avete la List<string> delle righe contenute nel file di testo appena letto), mentre quando gira “in produzione” si schianta. Ci ho litigato per un weekend prima di raggiungere la soluzione, proprio perchè dovevo aspettare realmente 15 minuti prima di verificare il comportamento.

Anche in questo caso, tutto è bene ciò che finisce bene.

Send to Kindle

Sono incappato in un problema realizzando un’app Windows 8 per lo Windows Store. L’app è Gps Coordinate Converter, e ad oggi è regolarmente pubblicata. In pratica accadeva che sui sistemi Windows 8 x86 e x64 (in pratica i classici PC desktop, notebook ed ultrabook) girava senza presentare problemi, mentre sui device Windows RT (con architettura ARM) l’app si schiantava all’avvio.

La cosa è allo stesso tempo chiara ma insidiosa.

Dunque: innanzitutto, quando in un’app per lo Windows Store aggiungiamo nelle reference il componente Bing Map, siamo costretti ad impostare nelle proprietà del progetto stesso un’architettura: o x86, o x64 oppure ARM. Non possiamo impostare Any CPU, dal momento che il progetto a questo punto non compila proprio. Io evidentemente a suo tempo selezionai x64: in questo modo compilavo e potevo tranquillamente far girare l’app sul mio notebook.

Quando poi arriva il momento di produrre il package da uploadare sullo Store, bisogna nuovamente selezionare l’architettura del package stesso. Questa cosa può magari sfuggirvi come è sfuggita a me, perchè siete convinti che il package viene prodotto in base a ciò che viene impostato nelle proprietà del progetto, ma non è così. Perciò ricordatevi che a seconda di cosa selezionate in questo momento, l’app potrà essere trovata sullo Store dai diversi device Windows. Mi spiego meglio. Supponiamo di aver fatto la build per x64, e poi di produrre il package selezionando Any CPU. Se approvata, l’app potrà essere trovata anche da tablet Windows RT (Asus Vivo RT o Surface RT, per intenderci): il risultato è che l’app verrà scaricata ed installata, ma si schianta quasi immediatamente…il tempo di vedere lo splash screen. Quindi bisogna stare attenti: se nelle proprietà del progetto mettete x64, dovete poi produrre il package per x64. Se nelle proprietà mettete ARM, dovete produrre il package per ARM.

Come gira il Windows App Cert Kit ?
Ok, passiamo oltre. Come ben sapete, prima di uploadare un’app sullo Store dovete farla validare dal WACK, che vi trova eventuali problemi prima di passare dalla trafila della certificazione. Ovviamente, il WACK è in grado di mettere sotto torchio la vostra app solo quando state producendo il package corrispondente all’architettura del vostro pc che state usando per sviluppare. Morale: quando compilate l’app e producete il package per x64, il WACK sarà in grado di testare l’app, altrimenti no. Nel primo caso, una volta terminata la creazione del package, vi verrà chiesto se volete far girare il WACK. Nel secondo caso, invece, vi verrà solamente fornito il link alla cartella nel quale è contenuto il package.

Upload dei diversi package differenziati per architettura del processore
Ok, supponiamo di aver prodotto due package differenti per la stessa app: un package è specifico per x64, l’altro package per ARM. Come si fanno ad uploadare sullo Store? E’ molto semplice: andate nel dashboard del vostro Windows Store Dev Center, create l’app (o semplicemente una nuova release come ho dovuto fare io per risolvere il mio problema) e quando dovete uploadare i package (files con estensione .appxupload) semplicemente fate l’upload di tutti i package per le diverse piattaforme. Direi nulla di più semplice.

Send to Kindle

Nei giorni scorsi mi sono scontrato con il problema indicato dal titolo del post. La procedura non è poi così diversa da quella a cui ero già abituato:

• Creare un progetto di tipo Class Library (Windows Store apps)
• Aggiungere un “New Item” al progetto e selezionare “User Control”
• Sviluppare il controllo, scrivendo XAML, codice, code-behind, etc. etc.: tutto ciò che volete

Il bello arriva quando volete distribuire il vostro controllo. Normalmente, infatti, compilereste il progetto di cui sopra e dareste in giro l’assembly che avete ottenuto. Quindi, se avete creato un progetto chiamato “CheBelloIlMioControllo”, quando compilate ottenete un assembly chiamato “CheBelloIlMioControllo.dll”.

Non è sufficiente. La sola dll non è sufficiente. Dovete distribuire anche lo XAML relativo ai vostri controlli, e lo dovete fare in un modo piuttosto particolare.

Rispetto alla location in cui si trova l’assembly, dovete:

• Creare un folder chiamato esattamente come la dll (nel nostro esempio “CheBelloIlMioControllo”)
• Nel folder di cui sopra dovete copiare i files XAML relativi al controllo

Se il controllo nel vostro progetto è stato creato all’interno di un folder, la struttura di folder diventa: NomeAssembly/NomeFolder/NomeFileXaml.

Ultima cosa assolutamente importante: dovete distribuire anche il file con estensione .PRI, che ha lo stesso nome del nostro assembly.

Ecco un piccolo esempio:

L’assembly si chiama VivendoByteToolkit. I controlli sono stati creati dentro il folder Controls, che quindi contiene i tre files XAML relativi ai tre controlli: CurrencyPicker.xaml, DatePicker.xaml e NumberPicker.xaml.

All’interno del folder VivendoByteToolkit ho inserito il file VivendoByteToolkit.dll e VivendoByteToolkit.pri.

Direi che è tutto.

Send to Kindle

Con qualche riga di C# è possibile utilizzare la webcam o la fotocamera del nostro PC/tablet/ultrabook e salvarla all’interno della cartella roaming, che viene automaticamente sincronizzata tra tutti i vostri device Windows 8.

Il codice è piuttosto semplice.

StorageFolder folder =
     Windows.Storage.ApplicationData.Current.RoamingFolder;
CameraCaptureUI dialog = new CameraCaptureUI();

Qui sopra ho istanziato due oggetti che ci serviranno nel codice.

private async void Button_Click_1(
   object sender, Windows.UI.Xaml.RoutedEventArgs e)
{
    var file = await dialog.
      CaptureFileAsync(CameraCaptureUIMode.Photo);

    if (file != null)
    {
        string filename = string.Concat
          (Guid.NewGuid().ToString(), file.FileType);
        await file.MoveAsync(folder, filename);
    }
}

La prima cosa che faccio è invocare il metodo CaptureFileAsync. Questo metodo avvia la fotocamera del device, e vi permette di catturare una foto od un video. Se concludete l’operazione con successo (ovvero: se non annullate l’operazione), il vostro file media viene salvato in una cartella temporanea che – stando a ciò che ho letto in giro sul Internet – può venir ripulita dal sistema.

La prima cosa che faccio quindi è spostare il file nella cartella roaming, rinominando il file, dandogli un nome univoco – nel mio caso genero un nuovo Guid, voi potete applicare qualsiasi logica vi venga in mente.

Questo approccio ha diversi vantaggi:

• salvandola nel roaming folder, le vostro foto/video vengono sincronizzate tra tutti i vostri device Windows 8 (ovviamente se fate login con il vostro Microsoft Account)
• Se avete MediaElement o Image nel codice XAML, potete far riferimento alle immagini salvate nel roaming folder tramite l’url “ms-appdata:///roaming/nomefile”. Facile e veloce, senza troppi fronzoli

Detto questo, ricordatevi solamente nelle Capabilities della vostra app per abilitare la webcam.

Send to Kindle

Ho messo a disposizione questa piccola solution, da poter scaricare liberamente, per provare in due secondi le funzionalità della SwipeCommandHelper che mi sono creato.

Chiaramente dovete avere Windows 8, Visual Studio 2012 e – volendo – un bel monitor touch (ma non è indispensabile).

L’esempio è chiaramente molto semplice. Il viewmodel espone un’unica proprietà Number, un numero intero, che viene visualizzata sulla UI. Facendo le gesture sulla Grid (che è la parte evidenziata dal colore beige) eseguite i command associati in base alla gesture stessa:

• Verso l’alto, incrementate il valore di 1
• Verso il basso, decrementate il valore di 1
• Verso sinistra, dividete il valore per 2
• Verso destra, moltiplicate il valore per 2

L’esempio è chiaramente stupido e banale, ma il succo del discorso non è certamente questo. Il punto centrale è poter assegnare dei command in base alla gesture: la complessità dei command dipende chiaramente dal vostro viewmodel. Questo è solo un sample. E – lo ripeto – posso agganciare la gestione dello swipe a qualsiasi FrameworkElement, che sia una Grid, un Button, un’Image, qualsiasi controllo, insomma.

Una cosa importante che voglio aggiungere è che lo swipe funziona anche con il mouse, quindi non è indispensabile avere un display touch per poterlo provare ed usare. Basta trascinare il puntatore del mouse verso una qualsiasi delle quattro direzioni, e secondo WinRT avviene comunque una manipulation.

Send to Kindle

Vi piacerebbe poter gestire lo swipe verso sinistra/destra/alto/basso, su qualsiasi elemento della UI, e sfruttando ovviamente Model-View-ViewModel, per gli amici MVVM? Ovvero, poter scrivere un blocco di XAML così?

<Border Background="Cyan" Width="500" Height="200"
        helper:SwipeCommandHelper.Up="{Binding IncrementCommand}"
        helper:SwipeCommandHelper.Down="{Binding DecrementCommand}"
        helper:SwipeCommandHelper.Right="{Binding MultiplyCommand}"
        helper:SwipeCommandHelper.Left="{Binding DivideCommand}" />

Al Border qui sopra ho dato la possibilità di eseguire un command differente in base a quale tipo di swipe l’utente fa sopra il Border stesso. Se scorro il dito verso l’alto, eseguo l’IncrementCommand. Se lo scorro verso destra, eseguo il MultiplyCommand. E così via. La cosa bella è che la classe SwipeCommandHelper può agganciarsi a qualsiasi oggetto FrameworkElement.

Il codice è abbastanza semplice.

public static class SwipeCommandHelper
{
    public static ICommand GetUp(DependencyObject obj)
    {
        return (ICommand)obj.GetValue(UpProperty);
    }

    public static void SetUp(DependencyObject obj,
        ICommand value)
    {
        obj.SetValue(UpProperty, value);
    }

    public static readonly DependencyProperty UpProperty =
        DependencyProperty.RegisterAttached("Up",
        typeof(ICommand),
        typeof(SwipeCommandHelper),
        new PropertyMetadata(null,
        new PropertyChangedCallback(Setup)));
}

Il codice qui sopra è una semplificazione, e riporta solo la dependency property per gestire lo swipe verso l’alto. La dependency property è UpProperty, ed è di tipo ICommand. Il valore predefinito è null, e quando il suo valore viene modificato viene invocato il metodo Setup(). Questo metodo fa un po’ di code, ma il succo del discorso è che si aggancia all’evento ManipulationStarted del controllo, in modo tale che quando l’utente farà qualche gesture noi potremo intercettare questo evento ed eseguire il command associato. Il codice del metodo Setup() è il seguente:

private static void Setup(DependencyObject obj,
            DependencyPropertyChangedEventArgs e)
{
    FrameworkElement ctl = obj as FrameworkElement;

    if (ctl != null)
    {
        ICommand oldValue = (ICommand)e.OldValue;
        ICommand newValue = (ICommand)e.NewValue;

        if (oldValue == null && newValue != null)
        {
            {
                if (GetAttached(ctl) == false)
                {
                    ctl.ManipulationMode = ManipulationModes.TranslateX |
                        ManipulationModes.TranslateY;
                    SetAttached(ctl, true);
                    ctl.ManipulationCompleted += ctl_ManipulationCompleted;
                }
            }
        }
        else if (oldValue != null && newValue == null)
        {
            ctl.ManipulationMode = ManipulationModes.None;
            ctl.SetValue(AttachedProperty, false);
            ctl.ManipulationCompleted -= ctl_ManipulationCompleted;
        }
    }
}

Aggiungo due note importanti: per default, in Windows 8 su un oggetto sulla UI non si possono intercettare gesture. Con Windows Phone, per esempio, è sufficiente sottoscrivere l’evento ManipulationCompleted ed il gioco è fatto. Con Windows 8, invece, prima dovete impostare il ManipulationMode, poi sottoscrivete l’evento. Per default, ManipulationMode è None, e quindi anche se impazzite a fare gesture sopra l’oggetto, nel codice non accadrà nulla. Ma non abbiate paura: ci pensa il mio codice a fare tutto ciò: non appena associate un command ad uno dei quattro tipi di swipe, vado automaticamente ad impostare il ManipulationMode su TranslateX | TranslateY.

A questo punto non ci resta che scrivere il codice dell’evento ManipulationCompleted:

static void ctl_ManipulationCompleted(object sender,
            ManipulationCompletedRoutedEventArgs e)
{
    var element = sender as FrameworkElement;
    ICommand command = null;

    // x < 0 --> verso sinistra
    // x > 0 --> verso destra
    var x = e.Cumulative.Translation.X;

    // y < 0 --> verso l'alto
    // y > 0 --> verso il basso
    var y = e.Cumulative.Translation.Y;

    if (y < 0 && Math.Abs(y) > Math.Abs(x))
    {
        command = GetUp(element);
    }
    else if (y > 0 && Math.Abs(y) > Math.Abs(x))
    {
        command = GetDown(element);
    }
    else if (x > 0 && Math.Abs(x) > Math.Abs(y))
    {
        command = GetRight(element);
    }
    else if (x < 0 && Math.Abs(x) > Math.Abs(y))
    {
        command = GetLeft(element);
    }

    if (command != null)
    {
        if (command.CanExecute(null))
        {
            command.Execute(null);
        }
    }
}

All’interno dell’evento posso capire quale tipo di gesture ha fatto l’utente sul controllo. Avendo impostato il ManipulationMode solamente alle traslazioni X e Y, sappiamo per forza di cose che arriveremo qui solo in presenza di questa gesture. Capisco la direzione del movimento seguendo due fattori:

• il valore di x e y, ovviamente
• quale dei due valori x e y ha più rilevanza l’uno con l’altro (spostando il dito verso l’alto, probabilmente lo sposterete anche a sinistra o a destra – grazie a Math.Abs() capisco quale asse ha avuto più rilevanza nella gesture)

I base alla direzione, ottengo l’ICommand associato. Ovviamente può anche essere null, nel caso in cui non abbia bindato alcun command. Se invece c’è, invoco il CanExecute, ed in caso di esito positivo, eseguo finalmente il comando associato.

Si potrebbe pensare di aggiungere il CommandParameter per ciascuna delle quattro direzioni, ma a me non serve, per cui lo lascio fare voi!

Il codice completo della classe pronta all’uso è qui. E’ stata scritta in circa 30 minuti, ci sarà sicuramente qualche bug: avvisatemi e correggiamola/miglioriamola insieme!

Send to Kindle