Una delle piacevoli novità che ho visto introdotte con WinRT è la possibilità di definire e poter utilizzare oggetti di tipo MediaElement direttamente in codice WinRT, senza quindi passare dalla loro istanziazione in pagine Xaml. Questo comporta due vantaggi concreti:

– evita, come già detto, di dover definire tanti MediaElement nello Xaml, ciascuno con il suo nome. Dico “tanti” perchè se in un pagina dovevate far sentire più suoni (contemporanei o no) dovevate per forza mettere più MediaElement (a meno di non usarne uno solo switchando da un source all’altro)
– miglior utilizzo del MVVM, conseguenza del punto precedente. Nel ViewModel associato ad una pagina posso mandare in play un suono senza aver a che fare con la view corrente

Detto questo, mi sono potuto fare una serie di classi helper:

public static class MediaElementGenerator
{
    public async static Task<MediaElement> Get(string source)
    {
        MediaElement result = new MediaElement();
        var package = Windows.ApplicationModel.Package.Current;
        var installedLocation = package.InstalledLocation;
        var storageFile = await installedLocation.GetFileAsync(source);
        
        if (storageFile != null)
        {
            var stream = await storageFile.OpenAsync(Windows.Storage.FileAccessMode.Read);
            result.SetSource(stream, storageFile.ContentType);
        }

        return result;
    }
}

Questa riportata qui sopra è una classe statica che lavora in modo asincrono (async/await) e che restituisce un MediaElement associato ad un source specifico. Il source ovviamente deve essere un qualsiasi Uri, che punta ad un file wav/mp3 incluso come “Content” all’interno della nostra solution.

All’interno dei miei ViewModel utilizzo ciò che mi viene esposto dalla classe ApplicationContext:

private async Task Play(string source)
{
    if (ApplicationContext.Instance.Sound)
    {
        if (!this.MediaElements.ContainsKey(source))
        {
            this.MediaElements.Add(source, await MediaElementGenerator.Get(source));
        }

        this.MediaElements[source].Play();
    }
}

public async Task PlayClickButton()
{
    await this.Play("Media\ClickButton.mp3");
}

public async Task PlayReady()
{
    await this.Play("Media\Ready.mp3");
}

Gli ultimi due metodi pubblici (PlayClickButton e PlayReady) si appoggiano su Play che invece è privato. Notare che nel metodo Play controllo anche che il suono all’interno dell’applicazione sia attivo: ricordiamoci infatti che è buona norma permettere all’utente di attivare/disattivare i suoni nelle nostre app Windows 8, tramite il pannellino dei settings che va gestito correttamente. Ma questo è forse un tema da affrontare in un altro post.

Send to Kindle

Con le applicazioni Windows, compreso Silverlight, che quindi comprende a sua volta anche il mondo Windows Phone, potevamo scrivere il codice seguente:

string version = System.Reflection.Assembly.GetExecutingAssembly().FullName.Split(',')[1];
string[] fullversion = version.Split('=')[1].Split('.');
return fullversion[0] + "." + fullversion[1];

Questo mi permette di estrarre dal FullName di un Assembly il numero di versione dell’assembly stesso, molto comodo per essere visualizzato su una Page di Silverlight.

Il codice da scrivere con WinRT, e quindi con Windows 8, è leggermente diverso.

string version = typeof(<qualsiasi_classe_usata_nel_codice>).GetTypeInfo().Assembly.FullName.Split(',')[1];

La differenza è tutta nella prima riga di codice. In pratica si tratta di avere un’istanza di Type relativa ad una qualsiasi classe del proprio codice, chiamare il metodo GetTypeInfo(), per arrivare all’Assembly, etc. etc. Notare che GetTypeInfo() è un’extension method, per cui bisogna includere il namespace System.Reflection.

Tutto qua, il resto del codice è analogo al precedente. Con qualche split si ottiene il numero di versione dell’assembly.

Send to Kindle

Facciamola breve: mi sono stancato di dover – per ciascun app Windows Phone o Windows 8 che necessiti di push notification – di dover implementare bene o male le stesse cose. Ovvero, in breve:

1. una tabella “Subscribers” sul database SQL Server che mantenga i subscriber per quella specifica app
2. implementare sul servizio WCF specifico dell’app i metodi Subscribe/Unsubscribe invocati internamente all’app per permettere all’utente di attivare/disattivare le notifiche

Dal punto di vista server, ogni mia app (Duello in Cucina, Deputati Italiani, la futura Diretta Volley, Piloti Virtuali Italiani, etc.) ha bene o male una certa parte di sistema ripetuta, cosa che cominciava a non andarmi del tutto a genio. Inoltre può sembrare poca roba, ma vi assicuro che non è così. Ed anche se fosse poca roba, è comunque una cosa da ripetere e scrivere ogni volta, con rischio ovviamente di codice ripetuto, a rischio di bug, etc. etc. Quindi, mi sono detto, sarebbe fattibile creare un’unica infrastruttura database & WCF talmente generica da poter essere sfruttata in ogni mia futura app, indipendentemente dal fatto che sia Windows Phone o Windows 8, per gestire le push notification? E magari talmente generica da poter essere addirittura “venduta/affittata” a terzi? La risposta è ovviamente sì.

Cosa vi metto quindi a disposizione?
E’ semplice: un servizio WCF che espone i seguenti metodi:

I metodi sono autoesplicativi:

1. va chiamato il metodo Subscribe quando da una qualsiasi delle vostre app wp7/win8 volete aggiungere un nuovo subscriber
2. va chiamato il metodo Unsubscribe quando da una qualsiasi delle vostre app wp7/win8 volete rimuovere un nuovo subscriber

Il metodo Push invece deve essere invocato dal vostro servizio web/cloud: questo è il vero motore che invia le notifiche a tutti i subscriber relativi alla vostra app.

Chiaramente le chiamate ai metodi WCF descritti qui sopra utilizzano una serie di classi (SubscribeRequest, UnsubscribeRequest e PushRequest) che incapsulano un po’ di informazioni, grazie alle quali vi autenticate, mi dite che siete (inteso come “cliente”), mi dite quale app siete, etc. etc. Nel momento in cui volete inviare le notifiche, stessa cosa: mi dite chi siete, quale app siete, il tipo di notifica (toast, tile, badge, etc.), l’xml della push notification che volete inviare, etc. etc.

Io mi occupo di memorizzare sui miei server i vostri utenti e di inviare a tutti la notifica.

Limitazioni
Chiaramente, per ora metto a disposizione questa cosa solo ad amici e colleghi developer.

Ci sono alcune limitazioni note di cui vi voglio parlare.

1. Poca sicurezza, nel senso che ad oggi mi dovete comunicare (solo per le app Windows 8) la SecretKey ed il Sid relativo a ciascuna app che volete gestire
2. Non c’è la possibilità di fare push notification “selettive”: cioè, se la vostra app ha 1000 subscribers attivi, in questo momento la chiamata al metodo Push invia a tutti la notifica, mentre in realtà potrebbe non essere così (immaginate un’app di calcio, ed immaginate che l’utente voglia ricevere una notifica solo quando segna la squadra per cui tifa – questo scenario non è ancora coperto – ma ci sto lavorando su)

Se volete aiutarmi, se volete provarlo, se avete qualche suggerimento/segnalazione da darmi, sono tutt’orecchi!

Send to Kindle

Lavorando sulla mia prima app per Windows 8 mi sono scontrato con un problema davvero fastidio e difficilmente debuggabile.

In pratica, ho implementato una normalissima Page che – in condizioni normali di full-screen – mostra una BingMap che visualizza un volo aereo. Sulla mappa potete fare normali operazioni come zoom, pan, etc. etc. Nella versione snapped view della stessa pagina avevo deciso di rimuovere la BingMap, e di mostrare solo un’altra serie di informazioni. Quello che accadeva è nel momento in cui facevo lo snap della pagina, l’app si schiantava e Visual Studio mi segnalava una unhandled exception. Ho cercato di capire per sicuramente più di un paio d’ore, alla fine sono riuscito ad isolare il problema, che riguardava proprio la BingMap. Se la rimuovevo dallo XAML, infatti, tutto funzionava senza problemi. La cosa si verificava sia se metteva in snapped la pagina – come ho appena descritto – sia se partivo dalla pagina precedente in snapped view.

Come risolvere?

Questa cosa è spiegata sommariamente nella sezione Q&A della pagina Bing Maps SDK for Metro style apps (RP).

Per risolvere, quindi, basta impostare una MinWidth al controllo BingMap, impostandolo ad un valore qualsiasi maggiore di zero. A quanto pare, infatti, durante l’operazione di snapping la width e la height finiscono uguali a zero, causando non pochi problemi, tra cui il crash dell’app e del debugger. Io l’ho impostata a “160” ed il problema è sparito!

Send to Kindle

Sviluppando applicazioni Metro per Windows 8, una delle funzionalità più interessanti – non solo dal punto di vista developer ma anche utente – è la possibilità di fare lo share di un qualsiasi contenuto usando una delle app già installate nel sistema. In pratica per un utente il tutto si riassume in pochi passi, ovvero:

• vedo un contenuto interessante all’interno di un’app (una foto, un link, un articolo, un punteggio in un videogioco, il prezzo di un articolo, un film da vedere al cinema, qualsiasi cosa) e decido di condividerla con qualcuno
• l’espressione “condividerla con qualcuno” è volutamente generica, perchè vuol dire un sacco di cose (molte delle quali ancora da intuire, probabilmente): vuol dire poter mandare una mail, twittare, postarla sulla propria pagina Facebook, postare una foto su PInteret, marcare un link tra quelli preferiti in Diio, aggiungere una foto in un photoset di Flickr, etc. etc.
• per farlo, l’utente non deve far altro che richiamare lo charm di Share di Windows 8 premendo Win + H (oppure Win + C e poi cliccare su Share). Se l’app che state usando prevede questa funzionalità, Windows 8 mostrerà l’elenco di app installate nel sistema che sono predisposte a condividere l’informazione

Nell’app Windows 8 che sto sviluppando, pviCommunity, è possibile per esempio fare lo share di fotografie scattate durante i voli virtuali di Piloti Virtuali Italiani. Ogni fotografia è identificata da un url ben preciso, quindi…mi sono detto…perchè non permette di twittare dalla mia app quanto sia bella una certa foto. Sappiamo tutti che i tweet hanno una lunghezza massima di 140 caratteri. L’url di una fotografia può essere una cosa tipo questa:

http://service.vivendobyte.net/FlightLogs/7600/2012-7-6_11-47-26-546.jpg

E’ una fotografia reale, quindi se cliccate sul link potete tranquillamente guardarla.

La domanda è la seguente: come è possibile fare lo short di questo url, per esempio usando le API di Google. Il primo passo è quello di registrarsi qui per ottenere una apikey da utilizzare direttamente nel vostro codice C#. Fatto questo, utilizzate questa classe per fare tutto il resto:

public static class GoogleUrlShortnerApi

    {

        private const string key = "api_key";

        public static string Shorten(string url)

        {

            string post = "{"longUrl": "" + url + ""}";

            string shortUrl = url;

            HttpWebRequest request = (HttpWebRequest)WebRequest.Create("https://www.googleapis.com/urlshortener/v1/url?key=" + key);

            try

            {

                request.Method = "POST";

                request.ContentType = "application/json";

                using (Stream requestStream = request.GetRequestStreamAsync().Result)

                {

                    byte[] postBuffer = System.Text.Encoding.UTF8.GetBytes(post);

                    requestStream.Write(postBuffer, 0, postBuffer.Length);

                }

                using (HttpWebResponse response = (HttpWebResponse)request.GetResponseAsync().Result)

                {

                    using (Stream responseStream = response.GetResponseStream())

                    {

                        using (StreamReader responseReader = new StreamReader(responseStream))

                        {

                            string json = responseReader.ReadToEnd();

                            shortUrl = Regex.Match(json, @"""id"": ?""(?<id>.+)""").Groups["id"].Value;

                        }

                    }

                }

            }

            catch (Exception ex)

            {

                // if Google's URL Shortner is down...

                System.Diagnostics.Debug.WriteLine(ex.Message);

                System.Diagnostics.Debug.WriteLine(ex.StackTrace);

            }

            return shortUrl;

        }

    }

Il codice è pensato per girare all’interno di un’app Windows 8 Metro-style, chiaramente.

Send to Kindle

Nelle ultime settimane ho studiato pesantemente tutta la nuova architettura che Microsoft ha messo in piedi per permettere a noi dev di inviare push notification alle nostre app Metro. Partivo con un po’ di vantaggio per il semplice fatto che avevo già fatto la stessa cosa con Windows Phone 7, ma ci ho comunque dovuto sbattere un po’ la testa. Alcune cose sono cambiate, come è logico che sia.

Facciamola breve. Gli ingredienti di cui avete bisogno per mettere in piedi le push notification per la vostra app Metro sono i seguenti:

• ovviamente, un’app Metro-style Windows 8. La vostra app deve permettere ai vostri utenti di sottoscriversi alle notifiche push: questo vuol dire banalmente mettere un controllo tipo ToggleSwitch nei settings della vostra app grazie al quale l’utente può scegliere se ricevere oppure no le notifiche (poi sta a voi magari fargli scegliere se vuole ricevere solo le tile notification, oppure solo le toast, le badge, etc. etc.). E’ buona norma farvi restituire l’esito di questa operazione, per informare l’utente se tutto è andato bene oppure no: questo può essere un semplice bool oppure qualcosa di più complesso. Quando una vostra app si sottoscrive alle push notification riceve un url, che identifica univocamente quel device e quell’applicazione
• un vostro “cloud-service”, ovvero un servizio Web che al momento opportuno spara a tutti i vostri utenti la notifica. In quasi tutte le mie app Windows Phone 7 ho praticamente un servizio WCF che fra le altre cose serve anche a questo scopo. In pratica, quindi, vi serve un qualsiasi servizio di hosting che vi metta a disposizione database SQL Server, l’hosting di servizi WCF, etc. etc.
• tornando al punto (1), quando l’utente attiva il ToggleSwitch invoca un metodo esposto dal servizio WCF, che si occupa di memorizzare server-side gli url che vengono associati al proprio dispositivo (dico dispositivo perchè potrebbe essere un pc, un notebook, un ultrabook, un tablet, un Surface, un qualsiasi dispositivo su cui gira Windows 8)

I punti qui sopra sono ovviamente un po’ più complessi, andrebbero sviscerati fino a riempire libri su libri. Io la faccio molto semplice, basta googlare per raccogliere informazioni in quantità. E devo anche aggiungere che MSDN è decisamente migliorata sotto questo punto di vista, rispetto ai primi tempo con Windows Phone. Adesso potete davvero trovare quickstart, tutorial, esempi di codice, xml, etc. etc.

Per cui una volta messa in piedi tutta l’infrastruttura software, la cosa è piuttosto semplice. Quando si scatena un determinato evento, il servizio WCF passa in rassegna la tabella dei vostri utenti che vogliono ricevere le notifiche: per ciascuno dei vostri utenti avete un url che lo identifica in modo inequivocabile ed univoco. A questo url inviate un certo blocco XML ed il gioco è fatto. L’XML può identificare qualsiasi tipo di notifica, anche se di un solo tipo per volta: non potete specificare con un unico XML una notifica toast e di tipo tile. All’interno di una notifica tile, però, potete specificare sia quella square che quella wide (ovvero: sia quella quadrata, che quella rettangolare): questo è indispensabile, perchè dal punto di vista del servizio WCF non sapete quale tile sta usando l’utente, e quindi è necessario mandargliele entrambe. Se sta usando quella square, vedrà quella, altrimenti quella wide.

Parliamo un secondo di settings della nostra app Windows 8 Metro-style.
Generalmente, con un’app Windows 8 verrebbe le tentazione di salvare tutti i settings all’interno di quelle roaming. Questo significa che i vostri settings viaggiano su tutti i device Windows 8 su cui state usando quell’app, e rimangono sincronizzate. Se cambiate un’impostazione su un PC, vi ritroverete la stessa impostazione su tutti gli altri device, insomma. Attenzione, però: parlando di push notification non è una buona idea. Nei settings delle mie app Windows 8 che fanno uso di push notification mantengo sempre due informazioni: un bool che mi dice se le notifiche sono attive, e l’url univoco di quel device. Questi due settings li salvo all’interno dei settings locali e non su quelle roaming, perchè sono impostazioni specifiche del device e non dell’app. Magari su un PC desktop (che non ha problemi di salvaguardia della batteria) vorrei sempre lasciare abilitate le notifiche, mentre potrebbe non essere la stessa cosa su un tablet. Su un device voglio le notifiche attive, sull’altro no. Quindi è opportuno decidere cosa salvare nei settings di tipo roaming, e cosa salvare nei settings di tipo local.

Forse la cosa più difficile è stato capire quali tipi di tile sono supportati dal sistema di notifiche (e quale XML inviare per ciascuna di esse, soprattutto).
Per questo vi lascio questa pagina:

http://msdn.microsoft.com/library/windows/apps/Hh761491

che riporta tutte le tile, siano essere quadrate o rettangolari. Ce ne sono un bel po’, che supportano solo testo, solo immagine, oppure testo ed immagine insieme, con diverse formattazioni.

Lo so, rispetto a tanti altri, questo post è un po’ sconclusionato: ho solo voluto riassumere in modo sparso un po’ di concetti con cui mi sono scontrato nei giorni scorsi, lavorando sulle push notification.

Send to Kindle