.NET World

Questo post può essere considerato una “seconda parte” di quest’altro mio post, di qualche giorno fa. Ho ricevuto un solo commento, dicendomi che la cosa era per “smanettoni”. Troppo complicato, insomma. Ho quindi creato una solution Visual Studio 2012, ridotta all’essenziale, che esprime tutti i concetti base spiegati l’altra volta. Gli ingredienti sono i seguenti:

1. Visual Studio 2012
2. ASP.NET MVC 4, specificatamente Web Api (non ci sono view, insomma, ma le action restituiscono dati puri, via http)
3. Json.Net
4. qualche riga di C#

La solution è scaricabile dal mio account SkyDrive.

L’unica modifica che dovete apportare è modificare il file JsonDownloader.cs, valorizzando correttamente le variabili stringa oauth_token, oauth_token_secret, oauth_consumer_key e oauth_consumer_secret. Queste quattro stringhe servono per l’autenticazione oAuth obbligatoria per le nuove API Twitter. Per ottenere le vostre credenziali dovete registrare la vostra app sul sito https://dev.twitter.com/ (l’account per il login è lo stesso del vostro utente Twitter, chiaramente). Una volta inserite le vostre credenziali, siete a posto. Eseguendo il progetto, verrà aperto il browser all’indirizzo http://localhost:5279/api/rss/GetRssFeedTwitter?id=IgorDamiani: il codice non farà nient’altro che prelevare il JSON da Twitter e restituirvi sul browser l’XML del feed RSS. Chiaramente è sufficiente passare un utente diverso come id per ottenere altri feed.

Nota bene
In base alle vostre esigenze, vorreste modificare il codice delle classi RssParser e RssItem. Queste classi sono le responsabili della conversione tra JSON e XML. Le mie esigenze non sono troppo complesse: visualizzando i tweet su device mobili (app per Windows Phone e Windows 8), mi serve solamente il testo del tweet, la data di pubblicazione, e poco altro. Il testo contiene chiaramente il messaggio, l’eventuale link contenuto, e basta. Ma – ripeto – più che sufficiente, nel mio caso. Voi magari avete altre esigenze, più o meno complesse, quindi potrà essere necessario adattarle: ma questo dipende da voi.

Send to Kindle

Da circa una decina di giorni, Twitter ha apportato grossi cambiamenti alle proprie API, cambiamenti che hanno afflitto me – come developer di app per Windows Phone e Windows 8 – e non solo me. Basta una googlata per venire a sapere che chiunque abbia sviluppato app (per OS mobile, quindi iOS ed Android, ma non solo) che accedono a Twitter sia rimasto pesantemente fregato.

Prima infatti era possibile effettuare una chiamata via http al seguente url:
http://api.twitter.com/1/statuses/user_timeline.rss?screen_name=IgorDamiani

Con questo url si otteneva un bel feed RSS dell’utente Twitter passato come parametro, in questo caso “IgorDamiani”, cioè me stesso. Il feed era quindi consumabile dalle app per visualizzare tutti i tweet di un certo utente. Questa cosa era valida fino a 10 giorni fa, appunto. Adesso dà un messaggio inequivocabile: “The Twitter REST API v1 is no longer active. Please migrate to API v1.1.”. Morale: bisogna usare le API 1.1, che sostanzialmente hanno introdotto due cambiamenti:

• autenticazione obbligatoria via OAuth
• Json-only: questo significa che le API Twitter vi rispondono sempre e solo in formato JSON, mentre il feed RSS (che chiaramente è XML) non è più supportato
• il nuovo url è nel formato http://api.twitter.com/1.1/statuses/user_timeline.json?screen_name=IgorDamiani

Bella fregatura, vero? Ovviamente la soluzione c’è, basta adeguarsi, e fortunatamente io sono partito con qualche mese di anticipo, facendo prima di tutto in modo di far puntare tutte le mie app ad un unico url, hostato sui miei server, in modo tale da diventare trasparente rispetto ai cambiamenti apportati da Twitter. Quindi, diciamo, se ho 60 app che utilizzano Twitter, non ho cablato in ciascuna app l’url di Twitter, ma un mio url, che sarà sempre valido, dal momento che sono io a gestirlo e farò di tutto per non cambiarlo mai! Quindi, supponiamo, io ho un url nel formato seguente:

http://mioserver/Dammi_Il_FeedRssTwitter?id=<TwitterUsername>

Ho rimosso il collegamento perchè comunque non sarebbe valido. Questo url è un entry-point per tutte le mie app che devono mostrare un feed Twitter. Quindi, l’app “I Love Milan” per Windows Phone chiamerà l’url usando “acmilan”, l’app “Nove Colli” chiamerà l’url con “novecolli”, mentre l’app “Piloti Virtuali Italiani” (per Windows Phone e Windows 8) chiamerà l’url usando “pvi_org”. Questo è un mio servizio, che fa da adapter tra ciò che Twitter espone con le sue API e ciò che le mie app si aspettano. Quindi: con le API 1.0 invocavo Twitter, ottenevo un RSS e lo passavo così com’era alle mie app. Cone le API 1.1 invoco Twitter con l’autenticazione, ottengo un JSON, costruisco da zero un feed RSS in formato XML e lo restituisco a chi di dovere.

Passo 1 – Come ottenere il JSON

Il primo passo è utilizzare questa classe JsonDownloader che ho scritto questa mattina (e basandomi su questo articolo su CodeProject), molto semplice, che fa la chiamata verso Twitter, in modo autenticato, che vi restituisce una string, che in pratica è il JSON da parserizzare.

Lo zip contiene un file JsonDownloader.cs, da includere nel verso progetto e modificare come necessario. L’unica accortezza – cosa che prima non era necessaria – è che dovete necessariamente registrare la vostra app su https://dev.twitter.com/, per ottenere quattro key da inserire nel codice per l’autenticazione OAuth, ovvero:

• Consumer Key
• Consumer Secret
• Access Token
• Access Token Secret

Nel .cs che scaricate gli oggetti string ci sono già, pronti all’uso, vanno solo valorizzati correttamente.

Passo 2 – Parserizzare lo JSON ed ottenere l’XML del feed RSS

Usando la libreria Json.NET, reperibile su Twitter, le cose sono semplici, ma mica tanto. Innanzitutto, immaginiamo una chiamata del genere:

string rss = RssParser.GetRss(json, id);

Da questo si evince che abbiamo una classe statica RssParser, che espone un metodo pubblicato GetRss. Il cui codice è il seguente:

public static string GetRss(string json, string screenName)
{
    try
    {
        if (!string.IsNullOrEmpty(json))
        {
            json = "{"root": " + json + "}";

            var result = JObject.Parse(json);
            var elements = (JArray)result.Children().Children().FirstOrDefault();
            var first = ((JObject)elements.FirstOrDefault()).Property("created_at").Value.ToString();
            var firstDate = RssItem.ParseDateTime(first);

            StringBuilder bld = new StringBuilder();
            string feed = GetRssHeader();
            string itemBlock = GetRssItemBlock();
            bld.AppendFormat(feed, screenName, firstDate, screenName);

            foreach (JObject elem in elements)
            {
                RssItem item = RssItem.Get(elem);

                if (item != null)
                {
                    bld.AppendFormat(itemBlock, item.Title, screenName, item.Id,
                        item.FormattedDate, item.FormattedDate,
                        screenName, item.Id);
                }
            }

            bld.Append("</feed>");

            return bld.ToString();
        }
        else
        {
            return string.Empty;
        }
    }
    catch (Exception exc)
    {
        return exc.ToString();
    }
}

Questo metodo esplora lo JSON e restituisce la string del feed RSS. Navigando sugli oggetti JObject e JArray, e nelle relative proprietà, costruisco di fatto. Ci sono due metodi GetRssHeader() e GetRssItemBlock() che non fanno altro che recuperare delle embedded resource del progetto: di fatto contegono rispettivamente lo XML di intestazione del feed XML:

<?xml version="1.0" encoding="utf-8" ?>
<feed xml:lang="en-US" xmlns="http://www.w3.org/2005/Atom">
<title>Twitter / {0}</title>
<id>tag:twitter.com,2007:Status</id>
<link type="text/html" rel="alternate" href="http://twitter.com"/>
<updated>{1}</updated>
<subtitle>Twitter updates from {2}.</subtitle>

e del blocco da ripetere per ciascun tweet:

<item>
<title>{0}</title>
<content type="html">content</content>
<id>tag:twitter.com,2013:http://twitter.com/{1}/status/{2}</id>
<pubDate>{3}</pubDate>
<updated>{4}</updated>
<link type="text/html" rel="alternate" href="http://twitter.com/{5}/status/{6}" />
</item>

All’interno del ciclo foreach viene costruito un oggetto RssItem:

public class RssItem
{
    static CultureInfo culture = new CultureInfo("en-US");

    public string Id { get; set; }
    public string Title { get; set; }
    public DateTime Date { get; set; }
    public string FormattedDate { get; set; }

    public static RssItem Get(JObject obj)
    {
        RssItem result = new RssItem();
        result.Id = obj.Property("id").Value.ToString();
        result.Title = obj.Property("text").Value.ToString();
        result.Date = ParseDateTime(obj.Property("created_at").Value.ToString());
        result.FormattedDate = result.Date.ToString("dd/MM/yyyy HH.mm.ss");

        return result;
    }

    public static DateTime ParseDateTime(string value)
    {
        // Fri Jun 21 10:22:17 +0000 2013
        try
        {
            int index = value.IndexOf('+');

            if (index != -1)
            {
                // Devo rimuovere il "+0000 "
                string partToRemove = value.Substring(index, 6);
                value = value.Replace(partToRemove, string.Empty);
            }

            return DateTime.ParseExact(value, "ddd MMM dd H:mm:ss yyyy", culture, System.Globalization.DateTimeStyles.None);
        }
        catch (Exception)
        {
            return DateTime.Now;
        }
    }
}

Il metodo pubblico Get restituisce un’istanza di RssItem, valorizzata in base al JObject corrente. All’interno ci sono un po’ di operazioni di parsing, soprattutto sulle date, che andrebbero magari riviste per essere ottimizzate, ma per adesso funzionano!

Passo 3 – Fine!

E fine. A questo punto abbiamo una string che in pratica è il feed RSS da dare in pasto alle nostre applicazioni. Se avete qualche decina di app che improvvisamente avevano smesso di funzionare a causa di questa breaking change di Twitter, le vedrete riprendere vita di colpo! La cosa molto interessante che il tutto è gestito in modo centralizzato, e non sarete obbligati a rilasciare nuove versioni delle vostre app, inseguendo i cambiamenti di Twitter. Qualsiasi modifica che si renderà necessaria è centralizzata con questo codice, e per le app è del tutto trasparente.

Send to Kindle

Ci saranno tanti modi per ottenere un array di byte, di N elementi, tutti valorizzati con lo stesso valore. Io ho trovato questo, che utilizza Linq:

var array = Enumerable.Repeat<byte>(0xFF, 100).ToArray();

Con una sola rapida riga di codice, otteniamo un bell’array, in questo caso di 100 elementi, tutti valorizzati a 0xFF (ovvero 255 decimale). Comodo. Grazie Linq!

Send to Kindle

Uno degli installer più lunghi che abbia mai visto nella mia vita è sicuramente l’Update 1 di Visual Studio 2012. Lo sto eseguendo su un PC Desktop, senza SSD, e dopo 70 minuti non ha ancora terminato. Il problema principale sembra essere il fatto che l’installer è di circa 1,1MB: i pacchetti vengono scaricati sul momento dalla Rete.

Stasera ho scoperto che non esiste l’installer in formato .ISO, ma è possibile comunque effettuare il download preventivo di tutti i pacchetti richiesti. Dopo il download è possibile mettere il tutto su chiavetta, oppure masterizzare, e procedere così in modo molto più veloce.

Come? Semplice!

L’Update 1 (scaricabile da qui) consiste in un unico file chiamato vsupdate_KB2707250.exe. E’ sufficiente lanciare questo .exe con il parametro /layout. L’installer parte in modo interattivo, e vi viene chiesta la cartella in cui effettuare il download dei pacchetti. Poi basta avere più o meno pazienza in base alla vostra velocità di download…

Tutto qua!

Send to Kindle

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