Laboratori e iniziative a go go su Windows Phone e Windows 8

Print Content | More

Nell’ultimo periodo i laboratori su Windows Phone, organizzati da Microsoft in varie città o all’interno di altri eventi (come per i recenti Community Days), stanno riscuotendo un ottimo successo: la disponibilità e la competenza delle persone che guidano il laboratorio e la possibilità di usare dei Nokia Lumia per il testing sono sicuramente dei punti di forza che attirano molte persone.

Microsoft, forte di questo successo, ha pensato bene di allargare questa iniziativa, organizzando numerosi laboratori in tutta Italia, molti dei quali “trasversali”, dedicati non solamente a Windows Phone ma anche a Windows 8 (la cui Consumer Preview, vi ricordo, è prevista per il rilascio il 29 Febbraio).

Le città toccate sono numerose: Bologna, Milano, Catania, Pisa, ecc. In più, a breve verranno annunciate nuove date anche in altre città, come Genova, Roma e Ancona.

Trovate tutte le informazioni in questo post pubblicato sul blog di MSDN Italia, che verrà aggiornato con tutti i link con l’agenda e l’iscrizione man mano che saranno disponibili.

Cosa state aspettando?


Microsoft , Windows Phone , Windows 8 , Lab

0 comments

Volete far testare la vostra applicazione prima di pubblicarla? Leggete qui!

Print Content | More

Da qualche mese a questa parte sulla piattaforma dei forum di MSDN Italia è stata inaugurata una sezione dedicata agli sviluppatori Windows Phone che vogliono far testare le loro applicazioni prima di rilasciarle al grande pubblico sul Marketplace. Come sapete, con l’uscita di Windows Phone 7.5 è stato inaugurato il marketplace beta, che permette di distribuire la propria applicazione ad un insieme di persone selezionate (l’accesso viene garantito tramite il Live Id) saltando il processo di certificazione (dato che, ovviamente, trattandosi di una beta è più che plausibile che contenga qualche bug).

Scopo di questo forum è di mettere in contatto gli sviluppatori con chiunque abbia voglia di spendere del tempo per provare le loro applicazioni e riportare eventuali problemi o, più in generale, dare un feedback.

Il forum è ad accesso privato: come fare a partecipare? Semplice, come riportato nelle istruzioni contenute in questo thread, dovete semplicemente mandare una mail a Irina Turcu (moderatrice dei forum MSDN), specificando il vostro Live Id e il nonimativo sul forum e chiedendo di entrare nel gruppo dei beta testers.

Una volta ricevuta la conferma di iscrizione, avrete a disposizione una bacheca in cui segnalare le vostre applicazioni e accesso all’elenco completo di tutti gli iscritti, Live Id incluso, così da poter aggiungere i nominativi da abilitare in fase di submission sul marketplace beta.

L’iscrizione è aperta sia a chi è uno sviluppatore e vuole proporre le proprie applicazioni, sia a chi è un “normale” utente e vuole rendersi utile testando le applicazioni: vi ricordo infatti che il Marketplace Beta non richiede un device sbloccato, dato che il download avviene direttamente dal Marketplace.

Cosa aspettate a iscrivervi?


Windows Phone , Microsoft , Marketplace

0 comments

Community Days 2012 al via!

Print Content | More

Oggi, nella sede di Microsoft a Peschiera Borromeo, hanno inizio i Community Days, l’evento community più grande dell’anno: 2 giorni in cui i partecipanti, in maniera totalmente gratuita e grazie al supporto di Microsoft e delle community, potranno usufruire di sessioni tecniche, laboratori su Windows Phone e su Azure nonchè incontrare tante persone con gli stessi interessi e la stessa passione per la tecnologia e lo sviluppo.

Io sarò presente questo pomeriggio per parlarvi di accesso ai dati in Windows Phone 7.5, focalizzandomi sulle novità introdotte grazie al supporto ai database relazionali.

Per poter seguire al meglio l’evento ed essere sempre aggiornati gli organizzatori hanno reso disponibile un pratico widget che vi terrà sempre aggiornati sulle sessioni in corso e sui tweet riguardanti la conferenza (l’hashtag ufficiale è #cdays12), che ho pubblicato in questo post.

Buona conferenza a tutti!

 


Microsoft , Community Days

0 comments

I primi passi con PhoneGap: accesso ai dati tramite un servizio REST – Parte 2

Print Content | More

Nel post precedente abbiamo creato il nostro progetto e abbiamo incluso jQuery, libreria che ci servirà per interagire con il servizio JSON di Bacon Ipsum.

Per prima cosa, inseriamo un po’ di HTML: per questo primo esempio ci limiteremo ad aggiungere un semplice pulsante (con il quale invocheremo il servizio) e un div, nel quale andremo a visualizzare i dati recuperati dal servizio.

<input type="button" id="btnCall" value="Call service" />
<div id="result"></div>

La prima cosa da fare è gestire l’evento relativo alla pressione del pulsante e per fare questo usiamo jQuery, sfruttando i selettori (per recuperare il pulsante tramite il suo id) e la funzione click:

$("#btnCall").click(function () {
   //code goes here
});

$ è il selettore di jQuery, che permette di navigare il DOM di una pagina HTML e di recuperare gli elementi al suo interno (va a sostituire le varie funzioni Javascript document.getElement, in quanto funge da selettore per tag, per id, per classe, ecc.). Nello specifico, andiamo a recuperare il nostro pulsante che ha come id btnCall. Dopodichè andiamo a definire la funzione che verrà eseguire al click del pulsante, tramite la proprietà click che accetta come parametro la funzione vera e propria.

Affinchè il tutto funzioni correttamente, è importante inserire questo codice all’interno della funzione onDeviceReady, che abbiamo imparato a conoscere nel post precedente: è la funzione che viene invocata nel momento in cui PhoneGap è stato inizializzato ed è pronto a gestire le nostre operazioni.

Andiamo ora a interagire con il servizio vero e proprio e recuperare alcuni testi fittizi:

$("#btnCall").click(function () {
    $.support.cors = true;
    $.getJSON("http://baconipsum.com/api/?type=meat-and-filler&callback=?", function (data) {
        $.each(data, function (index, element) {
            $("#result").append(element);
        });
    });
});

Per farlo andiamo a utilizzare la funzione getJSON esposta da jQuery, che accetta in input:

  • L’URL del servizio
  • La callback che viene invocata nel momento in cui il servizio ha restituito i dati richiesti e siamo pronti ad elaborarlo.

Notate il parametro &callback=? al termine dell’URL del servizio: questo perchè viene utilizzato il formato JSONP, che è un pattern che è stato ideato per risolvere i problemi di cross scripting di Javascript (per motivi di sicurezza, infatti, in condizioni normali non è possibile da una pagina recuperare tramite Javascript dei dati esposti da un servizio che è ospitato in un dominio differente da quello della pagina stessa).

Il punto di forza del metodo getJSON è che si occupa in automatico di fare il parsing  dei dati, trasformando una semplice stringa JSON in un oggetto vero e proprio (un po’ quello che ad esempio ci permette di fare LINQ to XML con i file XML). Questo significa che il parametro data (restituito all’interno della callback) è in realtà un array contenente una serie di testi, che possiamo ciclare grazie alla funzione jQuery $.each, che è l’equivalente del foreach di C#. Il suo compito è infatti quello di ciclare tutti gli elementi all’interno della collezione, restituendo tramite i due parametri della funzione rispettivamente l’indice e l’elemento corrente.

Quello che facciamo è semplicemente “appendere” al div con id result gli elementi della collezione, visualizzando così a video i testi recuperati dal servizio, uno di seguito all’altro.

Importantissimo! Notate la riga di codice $.support.cors = true? Questa operazione serve per forzare jQuery a supportare le richieste di tipo XMLHttpRequest (sulle quali si basa il metodo getJSON) anche tra domini differenti. Per un problema di compatibilità noto tra PhoneGap, jQuery e Windows Phone 7 se non si inserisce questa riga di codice qualsiasi richiesta verso la rete (che sia getJSON, ajax o quant’altro) fallirà miseramente e alla pressione del pulsante non otteremo alcun risultato.

A questo punto possiamo provare l’applicazione: premiamo F5 per lanciarla nell’emulatore e, se tutto è andato a buon fine, premendo il pulsante Call Service apparirà a video un testo fittizio recuperato dal servizio di Bacon Ipsum.

bacon


Testare la pagina con un browser

E se volessimo testare la pagina con un browser? Sicuramente è una strada molto più comoda che tramite l’emulatore, dato che questi richiede un nuovo deploy ad ogni minima modifica. Con un browser ci basta invece salvare il file HTML e premere F5 per vedere subito i risultati. Bisogna però tenere ben presente due cose:

  • Il testing sul browser può essere una buona alternativa, ma non può mai sostituire il test con l’emulatore o su un device reale: in alcuni casi PhoneGap si comporta diversamente rispetto ad un browser, anche solo per il fatto che viene utilizzata una libreria Javascript specifica che non funziona su un browser tradizionale.
  • Se aprite con un browser la pagina che abbiamo realizzato in questo post non funzionerà: questo perchè la funzione click legata al pulsante viene registrata in seguito all’evento deviceready, che però in un browser non viene mai invocato. Per farla funzionare dobbiamo perciò spostare la funzione al di fuori dell’evento deviceready e racchiuderla all’interno della funzione jQuery $(document).ready(), che viene invocata nel momento in cui il caricamento della pagina da parte del browser è completato, in questo modo

$(document).ready(function () {
    $("#btnCall").click(function () {
        $.support.cors = true;
        $.getJSON("http://baconipsum.com/api/?type=meat-and-filler&callback=?", function (data) {
            $.each(data, function (index, element) {
                $("#result").append(element);
            });
        });
    });
});
A questo punto possiamo aprire la pagina HTML con il nostro browser oppure, ancora meglio, hostarla tramite un web server per verificarne il funzionamento. Se avete Visual Studio 2010 SP1 con IIS Express installato, vi segnalo questo utile tip che mi ha girato il buon Ugo, che vi permette di hostare al volo il contenuto di una cartella su IIS Express tramite un’opzione nel menu contestuale di Windows. Una volta fatte le modifiche al registro spiegate nel post, vi basta fare clic con il tasto destro sulla cartella www del progetto PhoneGap e scegliere la voce IIS Express Here: verrà attivato IIS Express e il sito sarà disponibile all’indirizzo http://localhost:8080. In più, fintanto che l’istanza sarà attiva rimarrà aperto un prompt dei comandi che vi mostrerà tutto il traffico generato.

Nel prossimo post

In questo post abbiamo visto come consumare un servizio già esistente: nel prossimo vedremo come crearne uno nostro sfruttando MVC e come visualizzare meglio i dati a video, grazie ai template. Di seguito il link per scaricare il codice sorgente.


Windows Phone , Microsoft , PhoneGap , HTML 5

0 comments

I primi passi con PhoneGap: accesso ai dati tramite un servizio REST – Parte 1

Print Content | More

Dopo aver visto qualche semplice esempio di utilizzo di PhoneGap, vediamo ora qualcosa di più complesso ma anche più utile: come importare dati esposti da un servizio. In questo post non andremo ad utilizzare le funzionalità specifiche di PhoneGap: quello che faremo sarà consumare un servizio REST, esattamente come faremmo con un’applicazione web tradizionale. C’è però qualche accorgimento da adottare per far si che il tutto funzioni anche su Windows Phone, a causa di qualche problemino di compatibilità tra jQuery e PhoneGap per Windows Phone.

Ma andiamo per gradi.

I servizi REST

I servizi di tipo REST sono una realtà sempre più diffusa, grazie anche alla semplicità di utilizzo indipendentemente dalla tecnologia utilizzata per “consumarli”. Al contrario dei web service tradizionali (basati su SOAP), i servizi REST si basano sul solo protocollo HTTP e si rifanno al concetto di risorsa più che di operazione. Cosa significa? Che un web service tipicamente espone una serie di operazioni, le quali vengono interpretate e utilizzate dal client grazie al protocollo SOAP; i servizi REST invece mappano questa richiesta sotto forma di risorsa, usando la normale notazione degli URL del protocollo HTTP. Ecco perciò che un’ipotetica funzione per recuperare le informazioni di un utente specifico verrebbe tradotta in un web service con il metodo getUser(int id), mentre in un servizio REST si tratterebbe semplicemente di richiamare l’URL /User/5 (dove 5 è l’ipotetico id di un utente).

Il vantaggio di questo meccanismo è evidente: lato client per consumare un web service è necessaria una libreria che sia in grado di tradurre la chiamata SOAP in un qualcosa di comprensibile per il linguaggio che stiamo utilizzando, a meno che non vogliamo elaborare manualmente le chiamate SOAP di richiesta e di risposta. E’ il caso ad esempio di Visual Studio: quando importiamo un servizio tramite l’opzione Add Service Reference viene generata una classe proxy, che non è altro che la rappresentazione sotto forma di classe in C# o VB.NET del servizio.

Con i servizi REST tutto ciò non è necessario: è sufficiente chiamare l’URL ed elaborare la risposta (tipicamente un XML o un JSON). Proprio per questo motivo, i servizi REST sono sicuramente la scelta più utilizzata nel mondo Javascript, in quanto non richiedono nessun tool o libreria particolari per essere utilizzati. E’ sufficiente effettuare una semplice chiamata HTTP verso l’URL ed elaborare la risposta (operazione resa ancora più semplice da librerie come jQuery, come vedremo tra poco).

Per il nostro esempio utilizzeremo un servizio JSON già pronto, nei prossimi post vedremo invece come crearne uno sfruttando ASP.NET MVC. Il servizio scelto per questo tutorial è quello offerto da, rullo di tamburi, Bacon Ipsum, fantastico sito che ho scoperto grazie ad un tweet di Lorenzo. Avete presente Lorem Ipsum, celebre sito utilizzato per la generazione di testi casuali? Questi testi solitamente vengono utilizzati in fase di montaggio di un prototipo o di un sito Internet, per dare l’idea dell’ingombro che occuperanno i testi. Bacon Ipsum fa la stessa cosa, ma sostituendo alle parole latine i nomi di vari tipi e tagli di carne (come steak, bacon, beef, ecc.). Smile

Al di là della goliardia, questo sito fa al caso nostro perchè espone proprio un servizio REST che permette di recuperare testi generati a caso in formato JSON.

Creiamo il progetto

Non sto qui a ripetere punto per punto i passi per creare un progetto PhoneGap per Windows Phone, dato che li abbiamo già visti nel post precedente: ne approfitto solamente per segnalarvi che, rispetto al post precedente, è stata rilasciata una nuova versione di PhoneGap, la 1.4.1 per la precisione. Il procedimento per installarla è sempre lo stesso: scaricate il pacchetto e copiate il file PhoneGapStarter.zip nella cartella dei template di Visual Studio. Dopo aver creato un nuovo progetto PhoneGap, vi ritroverete la struttura che ormai dovrebbe esservi famigliare: andremo ad agire all’interno della cartella www per consumare il servizio e mostrare a video i testi generati a caso.

La prima cosa da fare è includere jQuery, la celebre libreria che semplifica la vita a chi sviluppa in Javascript, offrendo una sintassi più semplice e il supporto nativo per alcune delle funzionalità più utilizzate con questo linguaggio, come le chiamate asincrone e il parsing di dati JSON. Abbiamo due possibilità:

  • Utilizzare una CDN (Content Delivery Network), ovvero appoggiarci ad uno dei tanti servizi che ospitano in maniera distribuita jQuery. Microsoft stessa ci offre questa opportunità, mettendoci a disposizione sia la versione tradizionale per lo sviluppo che quella minificata per la distribuzione.
  • Scaricare jQuery dal sito ufficiale http://www.jquery.com e includere la libreria all’interno della cartella www di PhoneGap.

L’unico vantaggio di utilizzare una versione locale di jQuery è che saremo in grado di utilizzarla anche in assenza di connettività: dato che però la nostra demo ruota attorno all’utilizzo di un servizio REST esposto su Internet, direi che possiamo tranquillamente utilizzare la CDN di Microsoft tramite l’URL http://ajax.aspnetcdn.com/ajax/jQuery/jquery-1.7.1.js

Ci basta perciò inserire nella sezione <head> del file index.html la seguente riga:

<script type="text/javascript" src="http://ajax.aspnetcdn.com/ajax/jQuery/jquery-1.7.1.js"></script>

Aggiornamento: il buon Marco De Sanctis mi ha fatto giustamente notare che l’utilizzo di una CDN su un’applicazione mobile non è consigliata, in quanto se per un problema di sicurezza un hacker dovesse riuscire a “mettersi” in mezzo alla CDN sarebbe poi in grado, grazie alle API di PhoneGap, di accedere ai dati del vostro telefono. Il consiglio è quindi quello di scaricare jQuery in locale (tramite NuGet o direttamente dal sito ufficiale) e includerlo nella cartella www, dopodichè aggiungere una referenza alla copia locale invece che alla CDN, come nell’esempio:

<script type="text/javascript" src="scripts/jquery-1.7.1.js"></script>

A questo punto siamo pronti per sfruttare le feature di jQuery per interagire con il servizio REST di Bacon Ipsum. Nel prossimo post vedremo come fare!


Windows Phone , PhoneGap , Microsoft , JQuery , HTML 5

0 comments

I primi passi con PhoneGap per Windows Phone: creiamo il primo progetto

Print Content | More

Nel post precedente abbiamo iniziato a capire che cos’è PhoneGap e cosa significa al giorno d’oggi sviluppare un’applicazione mobile cross-platform. Ora iniziamo a “sporcarci le mani” e vediamo come iniziare a lavorare con PhoneGap, creando il nostro primo progetto e scrivendo qualche riga di codice.

Installare PhoneGap

Innanzitutto occorre scaricare il pacchetto di PhoneGap dal sito ufficiale all’indirizzo http://phonegap.com/. Il package contiene le librerie per tutte le principali piattaforme: la versione Windows Phone si presenta come un template per Visual Studio, incluso nel file PhoneGapStarter.zip, da copiare all’interno della cartella C:\Users\[USERNAME]\Documents\Visual Studio 2010\Templates\ProjectTemplates\Silverlight for Windows Phone, dove [USERNAME] è ovviamente il nome del vostro account utente.

Una volta fatta questa operazione, se avviate Visual Studio e scegliete di creare un nuovo progetto, nella sezione Visual C# (sia per le versioni Express che per le versioni a pagamento) troverete un nuovo template chiamato PhoneGapStarter: date un nome al progetto, premete Ok e Visual Studio inizierà la creazione includendo tutti i file necessari a PhoneGap.

SNAGHTML53b5d18

La struttura di un progetto PhoneGap

Il progetto PhoneGap, rispetto ad un progetto tradizionale Windows Phone, include una serie di file e cartelle in più, che sono quelle utilizzate da PhoneGap. Quella più importante è la cartella www, che contiene l’applicazione web e propria e, di default, contiene:

  • il file index.html, che è la pagina che viene caricata all’avvio
  • il file master.css, che è il foglio di stile di default che viene utilizzato
  • il file phonegap-1-3-0.js, che è la libreria Javascript che funge da wrapper verso le chiamate native della piattaforma e con la quale andrete ad interagire per sfruttare le funzionalità native del device.

L’applicazione PhoneGap è a tutti gli effetti una vera e propria applicazione web, per cui all’interno  di questa cartella potete inserire tutte le risorse che volete, incluse librerie come jQuery o Knockout.js, molto conosciute nell’ambito dello sviluppo web. In automatico, all’avvio, PhoneGap compilerà un file chiamato GapSourceDictionary.xml includendo i riferimenti a tutte queste risorse, per poi poterle utilizzare.

La struttura della pagina index.html

Il file index.html non è nient’altro che una normalissima pagina HTML5 (lo riconoscete dal doctype), con già inclusi al suo interno gli script e i fogli di stile standard di PhoneGap che vi ho elencato prima.

In più, la pagina include la sottoscrizione, tramite un event listener di Javascript, all’evento deviceready, che viene invocato da PhoneGap nel momento in cui l’applicazione è stata inizializzata ed è pronta a interagire con l’utente. Tale sottoscrizione viene gestita dalla funzione onDeviceReady (definita poco sotto), in cui potete includere il codice che volete eseguire all’avvio dell’applicazione. Di default, questa funzione contiene semplicemente due righe di codice Javascript per:

  • Mostrare il classico Hello World indicando anche la versione di PhoneGap in uso sfruttando la funzione window.device.phonegap
  • Dato che fare debug di Javascript in una pagina che gira all’interno di un browser mobile non è così agevole come con un browser tradizionale, PhoneGap include una funzione Javascript che permette di scrivere nella Output Window di Visual Studio, che si chiama console.log. Di default, il progetto di PhoneGap include la scrittura di un messaggio di prova nella Output Window.

Mostriamo una MessageBox

Iniziamo a mettere mano al progetto con un esempio molto semplice: mostriamo a video una MessageBox nel momento in cui l’utente fa click su un pulsante. La parte di rendering del pulsante e di gestione del click viene affidata ad HTML e Javascript standard; la visualizzazione dell’alert invece verrà fatta utilizzando una funzione proprietaria di PhoneGap.

Vediamo l’HTML.

<body>
    <input onclick="onClick()" type="button" value="Click me" />
</body>

La pagina è composta da un semplice div, a cui abbiamo dato l’id welcomeMsg per poterlo identificare in Javascript, e un tag input, che rappresenta il nostro bottone, del quale gestiremo l’evento onclick tramite la funzione onClick(), che è così definita:

<script type="text/javascript">
    function onClick() {
        navigator.notification.alert("This is a message box");
    }
</script>

Qui entra in gioco PhoneGap: la funzione navigator.notification.alert provvede a interfacciarsi con le API native di Windows Phone e a mostrare una MessageBox con il testo che viene passato come parametro della funzione. Lanciamo l’applicazione tramite il debugger di Visual Studio, facciamo clic sul pulsante e vedrete comparire la MessageBox nativa di Windows Phone con il testo che avete scelto.

In conclusione

In questo post abbiamo visto un esempio molto semplice: nel prossimo post vedremo qualcosa di più approfondito, che ci permettà di sfruttare più a fondo le potenzialità di Windows Phone. In allegato, trovate il codice sorgente del semplice esempio realizzato in questo post.


Windows Phone , Microsoft , PhoneGap , Javascript , HTML 5

6 comments

I primi passi con PhoneGap per Windows Phone

Print Content | More

Vi ho già parlato un po’ di tempo fa di PhoneGap, un framework sviluppato da Nitobi (società recentemente acquisita da Adobe) con uno scopo decisamente ambizioso: realizzare applicazione cross – platform in grado di girare su qualunque dispositivo mobile. L’approccio è lo stesso utilizzato dalle applicazioni web mobile (HTML + Javascript), ma con una marcia in più: PhoneGap infatti espone tramite una libreria Javascript una serie di funzioni che vanno a interagire direttamente con il device, permettendo di utilizzare funzionalità native (come i servizi di geolocalizzazione, i sensori, ecc.) che altrimenti non sarebbero utilizzabili solamente tramite HTML / JS standard. Queste funzioni sono univoche, ma “sotto il cofano” PhoneGap si preoccupa di mapparle sulle chiamate native della piattaforma specifica: ecco perciò che, ad esempio, per mostrare un alert utilizzeremo sempre la funzione Javascript navigator.notification.alert, la quale verrà poi declinata da PhoneGap per mostrare la MessageBox di Windows Phone, di iOS o di Android.

Per questo motivo un progetto PhoneGap non è una generica applicazione web, ma viene creato un progetto specifico per ogni piattaforma, da aprire e manipolare con i tool di sviluppo specifici (Visual Studio per Windows Phone, XCode per iOS e Eclipse per Android).

E dove sta l’interoperabilità, direte voi? Ogni progetto PhoneGap include una cartella, chiamata www, che include tutti i file necessari della vera e propria applicazione web: è quello il progetto su cui andremo a lavorare, che poi andremo a duplicare per ogni piattaforma (anche se in realtà c’è una soluzione alternativa, di cui vi parlerò più avanti). Questa applicazione web viene poi inclusa all’interno dell’app nativa tramite il controllo browser che è disponibile per ogni piattaforma (ad esempio, WebBrowser in Windows Phone).

Applicazioni native vs applicazioni cross – platform

Il dibattito sull’utilizzo di applicazioni cross – platform rispetto a quelle native è molto acceso tutt’oggi. Ma quali sono i vantaggi e gli svantaggi di questo approccio?

I vantaggi

Con l’aumentare del numero di piattaforme mobile disponibili sul mercato molte società si sono trovate davanti un problema non indifferente: sviluppare un’applicazione per ogni piattaforma ha un costo non trascurabile e il gioco può non valere la candela, soprattutto nel caso in cui il mobile non sia il core business della società.

In più, una delle cose che incide maggiormente sui costi è la difficoltà ad acquisire le conoscenze necessaria: HTML e Javascript sono tecnologie molto diffuse e non sono una prerogativa degli sviluppatori, al contrario dei linguaggi nativi come C#, Objective-C e Java.

Strumenti come PhoneGap permettono di prendere due piccioni con una fava: l’applicazione viene sviluppata una volta sola ed è possibile demandare il compito anche ad uno sviluppatore web, senza necessità di cercare uno sviluppatore mobile ad hoc per ogni piattaforma (e, date le differenze, è molto difficile trovare una persona con piena conoscenza di ognuna di esse).

Gli svantaggi

Lo svantaggio principale è che l’interoperabilità in certi casi è una chimera, a causa delle grandi differenze nella User Experience proposta da ogni piattaforma: è praticamente impossibile realizzare un’applicazione che offra una user experience e abbia una grafica che si adatti bene ad ogni singola piattaforma. Prendete un’applicazione iPhone e una Windows Phone: le differenze sono numerosissime, a partire dalla grafica, passando per alcuni paradigmi di navigazione (pensiamo al Panorama di Windows Phone).

In più, non si tratta solo di UX ma anche di sfruttare appieno le funzionalità della piattaforma: pensiamo alle Live Tile, forse la caratteristica più particolare delle applicazioni Windows Phone. Si tratta di una feature che non ha un corrispettivo sulle altre piattaforme: se vogliamo sfruttarla, dovremo perciò scrivere del codice non interoperabile. L’alternativa è quella di non usare questa caratteristica, ma ciò si traduce in un abbassamento della qualità: a parità di funzioni dell’applicazione, l’utente finale ne sceglierà sicuramente una in grado di sfruttare le Live Tile.

Infine è importante considerare il discorso performance: un’applicazione cross – platform non sarà mai performante quanto un’applicazione nativa. Inoltre, tanto più c’è la necessità di interagire con il device, tanto più soluzioni di questo tipo diventano complesse da realizzare.

Credo inoltre che, dal punto di vista grafico, Windows Phone sia la piattaforma più difficile: iOS, ad esempio, ha un tipo di interfaccia molto semplice e pulita, facilmente replicabile da un’applicazione web (tanto che con librerie come jQuery Mobile è possibile realizzare applicazioni web mobile praticamente indistinguibili da un’applicazione nativa). Windows Phone ha invece un’interfaccia più particolare e che fa uso di paradigmi come Panorama e Pivot che sono più difficili da ricreare in HTML.

Il rischio perciò è di realizzare applicazioni con un look & feel lontano dalle guidelines di Metro e quindi in grado di attrarre meno gli utenti rispetto ad un’app nativa, facendo nascere così la necessità di dover sviluppare comunque un’interfaccia diversa per ogni sistema.

E quindi?

Non c’è un vincitore in realtà: tutto dipende dal tipo di applicazione che dovete sviluppare, dalle funzionalità del device che volete sfruttare e dal budget che avete a disposizione. Le applicazioni native hanno e avranno sempre comunque una marcia in più, perlomeno fino a quando HTML e Javascript non saranno supportati nativamente (un po’ come sta avvenendo per le applicazioni Metro style di Windows 8).

Chiudo questa “introduzione teorica” con il link ad un bell’articolo di Marco De Sanctis di ASPItalia, che traccia un quadro molto preciso della situazione attuale per quanto riguarda lo sviluppo di applicazioni cross platform.

PhoneGap e Windows Phone

Il matrimonio tra PhoneGap e Windows Phone risale all’uscita di Windows Phone 7.5: questo perchè PhoneGap si appoggia alla tripletta HTML5 / CSS 3 / Javascript, supportata pienamente da Internet Explorer solo a partire dalla versione 9 (vi ricordo che Windows Phone 7 era basato invece su una versione intermedia tra la 7 e la 8).

La versione 1.3 di PhoneGap (che è anche la release più recente) è stata la prima a supportare pienamente Windows Phone, come potete vedere da questa tabella: PhoneGap supporta numerosi altri OS mobile (come Symbian o Bada), ma Windows Phone, iOS (a partire dall’iPhone 3GS in poi) e Android sono le uniche 3 piattaforme alle quali è fornito un supporto completo.

Come già anticipato, tale applicazione viene poi renderizzata attraverso un controllo WebBrowser, il quale è in grado di interagire con il sistema tramite alcune feature messe a disposizione dal controllo (una su tutte, la possibilità di intercettare una funzione Javascript in una pagina e gestirla all’interno dell’applicazione). Se volete approfondire l’argomento, vi consiglio questo articolo del mio amico Ugo pubblicato sul blog di MSDN Italia, dedicato proprio al controllo WebBrowser e alle sue potenzialità.

Nel prossimo post

Dopo questa introduzione teorica, nel prossimo post inizieremo a vedere come usare concretamente PhoneGap: scaricheremo il pacchetto, lo installeremo e inizieremo a lavorare con Visual Studio per creare una semplice applicazione.


Windows Phone , Microsoft , PhoneGap , HTML 5 , Javascript , IOS , Android

0 comments

Slide e demo dell’evento Intel App Day

Print Content | More

Come vi avevo segnalato qualche settimana fa, ieri si è tenuto ad Assago, nella sede di Intel, il primo Intel App Day, una giornata completamente dedicata allo sviluppo di applicazioni con tecnologie Microsoft, con un occhio di riguardo alla distribuzione delle stesse tramite l’Intel AppUp Center, uno store di applicazioni per Windows. Tramite AppUp potete distribuire in maniera semplice e centralizzata applicazioni sviluppate con le tecnologie più disparate: si va da Java a .NET, passando per Adobe Air e persino HTML e Javascript, tramite un meccanismo che crea una sorta di pacchetto eseguibile a partire da un progetto Web.

I punti di forza di questo store sono gli stessi dei principali store sul mercato, come il Marketplace di Windows Phone: maggiore semplicità nel processo di installazione e aggiornamento, maggiori garanzie per l’utente sulla qualità tecnica dell’applicazione grazie al processo di certificazione, ecc.

Vi rimando al sito ufficiale dove potete trovare tutte le informazioni principali.

La giornata è stata molto piacevole e la formula dell’evento “istituzionale” organizzato in collaborazione con le community è stata vincente: la semplicità e il “calore” degli eventi community ha incontrato una organizzazione di prim’ordine, a partire dalla qualità del catering offerto da Intel per i coffee break e per il pranzo. Peccato solo per il gran numero di persone che si sono iscritte e non si sono presentate: purtroppo è un vizio un po’ tutto italiano di iscriversi in massa agli eventi gratuiti e poi non disdire la propria partecipazione in caso di impedimenti; dispiace soprattutto perchè l’evento aveva raggiunto il “sold out” e quindi diverse persone hanno dovuto rinunciare a partecipare.

E’ doveroso un ringraziamento ad Intel per la collaborazione e l’organizzazione, a tutti gli speaker per il loro contributo e ai partecipanti per aver dimostrato attenzione e interesse sino alla fine!

Come di consueto, di seguito trovate i link per scaricare il materiale della mia sessione: chi era presente sa che, dopo una breve introduzione alla piattaforma, ho dato la possibilità ai partecipanti di scegliere un argomento a piacere tra quelli che avevo proposto. La sessione vincente è stata quella introduttiva allo sviluppo, in cui ho fatto una panoramica generale su cosa significa sviluppare un’applicazione per Windows Phone. Nel materiale che trovate da scaricare ho però incluso tutte le slide e le demo che avevo preparato anche per gli argomenti che non ho potuto affrontare.

Buon download e, per qualsiasi feedback o dubbio, potete contattarmi attraverso il form apposito!

Scarica le slide

Scarica le demo


Windows Phone , Microsoft , .NET , Intel , DotNetLombardia

0 comments

Creare tile secondarie personalizzate per la nostra applicazione – Seconda parte

Print Content | More

Nel post precedente abbiamo visto come utilizzare una libreria open source chiamata Reel7 Tile Toolkit per creare tile secondarie più accattivanti e personalizzabili rispetto a quelle realizzabili utilizzando le API standard. Nell’esempio avevamo realizzato una tile utilizzando il template di default offerto dalla libreria, che permette di creare tile con lo stesso look & feel di quelle native come l’hub Messages o Outlook. In questo post vedremo come realizzare una tile dall’aspetto completamente personalizzato.

Il template

Il punto di partenza del template personalizzato non è altro che un semplice controllo in XAML: la libreria non farà altro, dietro le quinte, che “scattare” uno screenshot del controllo e utilizzare l’immagine risultante come background della nostra libreria.

Facciamo perciò clic con il tasto destro sul nostro progetto, selezioniamo Add, New Item e scegliamo Windows Phone User Control. Diamogli un nome a nostro piacimento (ad esempio, Tile.xaml) e scegliamo Ok. Uno user control non è nient’altro che un controllo XAML che è possibile inserire all’interno di una paginae che “vive” di vita propria: a tutti gli effetti si comporta come se fosse una pagina, essendo composto da UI (lo XAML) e da codice (il code behind). Gli user control (analogamente a quanto avviene per i custom control di ASP.NET) servono sostanzialmente quando abbiamo una parte della nostra applicazione (magari dotata di una sua logica) che dobbiamo inserire in più pagine: in questo modo, possiamo mantenere un solo controllo e non doverlo duplicare in ogni punto in cui è richiesto.

Il nostro controllo in realtà non avrà logica: sfrutteremo infatti solamente l’aspetto visuale. La prima cosa da fare è andare nello XAML e ridimensionare la Grid inserita di default alla risoluzione delle tile, ovvero 173x173:

<UserControl x:Class="TileHelper.Tile"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
    xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
    mc:Ignorable="d"
    FontFamily="{StaticResource PhoneFontFamilyNormal}"
    FontSize="{StaticResource PhoneFontSizeNormal}"
    Foreground="{StaticResource PhoneForegroundBrush}"
    d:DesignHeight="173" d:DesignWidth="173">
    
    <Grid x:Name="LayoutRoot" Width="173" Height="173">
        <StackPanel>
           //inserisci qui i controlli della tile
        </StackPanel>
    </Grid>
</UserControl>

A questo punto all’interno della Grid possiamo inserire tutti i controlli che vogliamo per personalizzare la nostra tile. Ad esempio, possiamo inserire due TextBlock come nell’esempio:

<Grid x:Name="LayoutRoot" Width="173" Height="173">
    <StackPanel Margin="5, 0, 0, 0">
        <TextBlock Text="This is a text" />
        <TextBlock Text="This is another text" />
    </StackPanel>
</Grid>

Come facciamo ora ad utilizzare questo controllo come tile? Il codice è lo stesso che abbiamo visto nel post precedente, con la differenza che invece di andare a creare un’istanza della classe NativeCountTileTemplate andremo a creare una nuova istanza del nostro controllo, come nell’esempio:

public void Create()
{
    Tile customTemplate = new Tile();

    CustomTile tile = CustomTileFactory.GetTemplatedTile("SampleTile", customTemplate, TileSize.Standard);
    ShellTile.Create(new Uri("/MainPage.xaml?ID=1", UriKind.Relative), tile.GetShellTileData());
}

Il risultato sarà il seguente:

image

Personalizzare il contenuto

L’esempio che abbiamo visto è però puramente didattico e ci è servito per capire il meccanismo dei template: così com’è infatti ci serve a ben poco, dato che tipicamente le tile secondarie sono dinamiche, ovvero il contenuto varia a seconda dell’informazione da mostrare.

Vediamo perciò ora come possiamo fare per modificare a runtime il valore delle due TextBlock che abbiamo inserite. Innanzitutto dobbiamo valorizzarne la proprietà x:Name, così da dargli un ID univoco:

<Grid x:Name="LayoutRoot" Width="173" Height="173">
    <StackPanel Margin="5, 0, 0, 0">
        <TextBlock Text="This is a text" x:Name="txtFirst" />
        <TextBlock Text="This is another text" x:Name="txtSecond" />
    </StackPanel>
</Grid>

Tutti i controlli di Silverlight (incluso perciò il nostro controllo custom) espongono il metodo FindName, che ci permette di recuperare un controllo specifico figlio del controllo corrente dato il suo ID univoco. Usando questo metodo possiamo recuperare i riferimenti ai due TextBlock che abbiamo inserito e cambiarne il valore dinamicamente, come nell’esempio:

public void Create()
{
    Tile customTemplate = new Tile();
    TextBlock first = customTemplate.FindName("txtFirst") as TextBlock;
    TextBlock second = customTemplate.FindName("txtSecond") as TextBlock;
    
    first.Text = "Hello";
    second.Text = "World";

    CustomTile tile = CustomTileFactory.GetTemplatedTile("SampleTile", customTemplate, TileSize.Standard);
    ShellTile.Create(new Uri("/MainPage.xaml?ID=1", UriKind.Relative), tile.GetShellTileData());
}

Per accedere alla proprietà Text esposta dal controllo TextBlock dobbiamo prima fare una cast del risultato del metodo FindName a TextBlock: questo perchè il metodo FindName potrebbe restituire un controllo qualsiasi, perciò ritorna un generico object.

Una volta che abbiamo i riferimenti al controllo, non dobbiamo far altro che valorizzare la proprietà Text a nostro piacimento, ottenendo un risultato come questo:

image

In conclusione

In questo esempio abbiamo lavorato con dei TextBlock inseriti nella nostra tile: nulla vieta però di inserire qualsiasi altro controllo (ad esempio, di tipo Image) e con lo stesso meccansimo recuperarne il riferimento e andarne poi a valorizzare le proprietà. Occhio però a non “strafare”: è bene che le tile abbiano comunque un layout semplice e pulito, che aderisca il più possibile alle linee guida di Metro.

Di seguito trovate il link per scaricare il progetto di esempio utilizzato in questo post e in quello precedente.


Windows Phone , Tile

2 comments

Creare tile secondarie personalizzate nelle nostre applicazioni

Print Content | More

Abbiamo già trattato in passato l’argomento tile secondarie: in questo post (e negli approfondimenti successivi) avevamo visto come crearle, gestirle e aggiornarle utilizzando i background agent o direttamente dall’applicazione.

Le API a disposizione per creare le tile secondarie sono molto semplici da utilizzare, ma non sono molto potenti: finchè si tratta di mostrare poche e semplici informazioni (un’immagine, un testo, un contatore) vanno benissimo, ma se vogliamo personalizzarle un po’ di più (banalmente, vogliamo inserire un testo disposto su due linee) ci scontriamo con qualche limite.

La stessa Microsoft diverso tempo fa, tramite un post su un blog MSDN, ha proposto una soluzione alternativa: la creazione della tile tramite XAML. Questo approccio prevede la creazione di un controllo all’interno del nostro progetto, da personalizzare a nostro piacimento: in fase di creazione della tile secondaria, quello che viene fatto è, da codice, “scattare” uno screenshot del controllo e usare l’immagine risultante come background della tile.

Il vantaggio di questo approccio è che all’interno del nostro controllo possiamo inserire tutti gli elementi che vogliamo e, a runtime, direttamente da codice, andare a personalizzarli: ad esempio, possiamo inserire un TextBlock e andare a valorizzarne la proprietà Text in base alle nostre esigenze.

Da poco è però disponibile una libreria su Codeplex, chiamata Ree7 Tile Toolkit for Windows Phone 7, che ci semplifica la vita: l’approccio rimane lo stesso, però non saremo più costretti a creare lo screenshot e salvarlo nello storage perchè le API incluse in questa libreria supportano direttamente la creazione di una tile partendo da un oggetto di tipo UIElement (ovvero la classe base da cui derivano tutti i controlli visuali di Silverlight, user control inclusi). In realtà, dietro le quinte il funzionamento sarà lo stesso: verrà creata una immagine PNG partendo dallo XAML e verrà utilizzato come background della tile.

Ma vediamola nel dettaglio per capire come utilizzarla.

Potete scaricare la libreria direttamente dalla pagina ufficiale su Codeplex oppure tramite NuGet, cercando la libreria Ree7 Tile Toolkit for Windows Phone 7.

I template

La creazione di una libreria sfruttando questa libreria passa attraverso il concetto di template, ovvero il layout grafico che verrà utilizzato per la tile. Sono due gli approcci possibili:

  • La libreria include già un template predefinito, che permette di creare tile con lo stesso look & feel di quelle native che fanno uso di un contatore (pensiamo a quella dell’hub Messages o di Outlook). Questo è l’approccio di cui parleremo in dettaglio in questo post.
  • Qualsiasi user control può diventare un template per la nostra tile: nel prossimo post vedremo come creare un template personalizzato.

Il template standard

Come anticipato poco fa, entriamo nel dettaglio di come sfruttare questa libreria per creare un’icona sfruttando il template standard composto da:

  • un background
  • un testo
  • un’icona
  • un contatore

Il risultato finale sarà qualcosa di molto simile a quello dell’hub Messages di Windows Phone: un testo con un’icona centrale affiancata da un numero (come potete vedere nello screenshot seguente, dove ho utilizzato una delle icone facente parti del progetto di esempio che accompagna la libreria).

image

Vediamo il codice con cui ho ottenuto questo risultato:

public void Create()
{
    NativeCountTileTemplate template = new NativeCountTileTemplate
        {
            AppName = "Sample app",
            Count = "10",
            Icon = new BitmapImage(new Uri("/SampleTileIcon.png", UriKind.Relative)),
            Background = null
        };

    CustomTile tile = CustomTileFactory.GetTemplatedTile("SampleTile", template, TileSize.Standard);
    ShellTile.Create(new Uri("/MainPage.xaml?ID=1", UriKind.Relative), tile.GetShellTileData());
}

Il primo passo è quello di definire il nostro template: per questo esempio abbiamo detto che utilizzeremo quello standard incluso nella libreria, identificato dalla classe NativeCountTemplate. Quello che facciamo è perciò creare una nuova istanza di questa classe e valorizzare le quattro proprietà che rappresentano la nostra tile:

  • AppName, che rappresenta il titolo
  • Count: che rappresenta il contatore
  • Icon: che rappresenta l’immagine
  • Background: che rappresenta lo sfondo. Attenzione che questa proprietà, analogamente a quella disponibile per tutti i controlli Windows Phone, è di tipo Brush. Questo significa che possiamo assegnarli un colore (SolidColorBrush), un’immagine (ImageBrush), un gradiente (LinearGradientBrush o RadialGradientBrush), ecc. Se non la impostiamo (o se la forziamo a null, come in questo caso) verrà utilizzato automaticamente il colore del tema corrente.

Dopodichè andiamo a utilizzare la CustomTileFactory, che ci permette di ottenere una CustomTile partendo dal nostro template grazie al metodo GetTemplatedTile, che accetta come parametri:

  • Il nome della tile (che è quello con cui verrà salvato nello storage, quindi occhio a non dare a tile diverse lo stesso nome)
  • Il template
  • La dimensione (al momento è supportato solamente TileSize.Standard, che corrisponde a 173x173)

A questo punto il gioco è fatto: l’oggetto di tipo CustomTile espone infatti il metodo GetShellTileData che ci restituisce un oggetto di tipo StandardTileData, che dovrebbe esserci famigliare. E’ infatti uno dei parametri richiesti dal metodo ShellTile.Create, che serve per creare la tile secondaria nella home del device. Vi ricordo che il primo parametro è invece il deep link a cui punterà la tile, che deve essere univoco e non utilizzato da altre tile secondarie.

In conclusione

Come vedete l’utilizzo di questa libreria semplifica molto la creazione di una tile personalizzata, dato che la parte di rendering del template e di generazione dell’immagine avviene dietro le quinte e ci permette di lavorare con un’API molto simile a quella nativa dell’SDK per la generazione delle tile.

Nel prossimo post vedremo un’esempio ancora più interessante: come generare una tile secondaria basata su un template personalizzato.


Windows Phone , Tile

0 comments