Windows Phone 7 Programming

Windows Phone 7 PROGRAMMING

Il corso per imparare a programmare con il S.O. Microsoft

dedicato agli smartphonea programmare con il S.O. Microsoft a programmare con il S.O. Microsoft a programmare con il S.O. Microsoft a programmare con il S.O. Microsoft a programmare con il S.O. Microsoft a programmare con il S.O. Microsoft a programmare con il S.O. Microsoft a programmare con il S.O. Microsoft a programmare con il S.O. Microsoft

dedicato agli smartphonededicato agli smartphonea programmare con il S.O. Microsoft

dedicato agli smartphone

Approfondimenti tematiciApprofondimenti tematici

Il mobile è il futuro. E Windows Phone 7 sarà sicura-mente uno dei protagonisti del film che verrà proiet-tato sul mercato.Questo approfondimento tematico è stato pensato per chi vuole scoprire tutti i segreti del nuovo siste-ma operativo di Redmond; è stato concepito per chi desidera imparare a programmare e creare software per smartphone.La prima parte funge da introduzione e mette in evi-denza tutte le caratteristiche di base del software. La seconda mostra come operare con l’ambiente ope-rativo del sistema: gestire la rubrica e le telefonate, interagire con la video/fotocamera, avviare browser e ricerche. Infine, la terza parte spiega come creare da zero un progetto pratico e sviluppare software e videogame.

WindowsPhone 7 programming

SVILUPPARE PER WINDOWS PHONE 7 . . . . . . . . . . . . . 4 La proposta microsoft nel mondo della telefonia mobile rompe gli schemi con il passato e si presenta come una vera rivoluzione per quanto riguarda la user experience e il modello di sviluppo basato su silverlight e sul runtime XNA

WINDOWS PHONE 7: API E SENSORI . . . . . . . . . . . . . 13La proposta microsoft nel mondo della telefonia mobile è pronta al lancio. In questo articolo vedremo le api esposte per interagire con l’hardware e il software della piattaforma, utilizzando il runtime di silverlight

IL TELEFONO “LEGGE” I TUOI MOVIMENTI . . . . . . . . 22In questo articolo ci concentriamo sulle librerie native che consentono di interagire con l’accelerometro. realizzaremo un progetto per approfittare della eccellente interazione con il mondo reale offerta da windows phone 7

METRO: L’INNOVATIVO LINGUAGGIO DI DESIGN . . . 29Metro definisce le linee guida relative alla progettazione di user interface per windows phone 7. la sua filosofia, attuale e moderna, si adatta perfettamente anche ad applicazioni desktop e web di nuova generazione

XNA MOBILE PER I VIDEOGAME . . . . . . . . . . . . . . . . . 35Windows Phone 7 si presenta con una user interface completamente nuova e con un ambiente di sviluppo basato su Silverlight e XNA. in questo articolo introduciamo XNA e le sue grandi potenzialità in ambito mobile

UN VIDEOGIOCO PER WINDOWS PHONE 7 . . . . . . . . 40Lo sviluppo di un videogioco per gli smartphone dotati di windows phone 7 è ora semplice ed immediato grazie al framework xna. in questa prima parte impareremo a conoscerne e sfruttarne le potenzialità di base

UN VIDEOGIOCO PER WINDOWS PHONE 7 - 2° PARTE . . . . . . . . . . . . . . . . . . . . . . . . . . . 46La seconda parte dell’articolo dedicato allo sviluppo di un videogioco per gli smartphone Windows Phone 7 tramite il framework xna. in questo articolo vedremo come aggiungere al gioco, scrolling, nemici, proiettili e riproduzione di suoni

Windows Phone 7 programming 4

Windows Phone 7 programming SVILUPPARE PER WINDOWS PHONE 7 COVER STORY Introduzione all’ambiente di sviluppo per Win Phone 7

Ottobre 2010 / 15 http://www.ioprogrammo.it

NOTA

ARCHITETTURA APPLICAZIONIWindows Phone 7, nella sua prima versione, offre uno spazio per la memo-rizzazione dei dati deno-minato Isolated Storage. Il codice per utilizzare l’Isolated Storage segue le stesse tecniche di qualunque applicazione Silverlight. Nelle versioni successive potremmo avere supporti locali più evoluti, quindi, per evitare di riprogettare l’applica-zione o modi� carla pesan-temente, è consigliabile utilizzare una forma di disaccoppiamento fra la user interface, lo strato di logica di business e l’accesso ai dati. Questo disaccoppiamento con-sente di sostituire un singolo componente, nel nostro caso ad esempio l’accesso al supporto di memorizzazione, senza dover modi� care una sola riga nello stato UI o nel Business Layer. Si veda il blog (http://blogs.devleap.com/rob) per informazioni sull’architettura delle applicazioni.

faccia mirata allo schermo e alla user expe-rience con Windows Phone 7. Sempre a partire dal link indicato, troveremo altre due “cose” utilissime: la prima è la documentazione sulla piattaforma che andremmo a introdurre da subito e la seconda, sono gli strumenti, gratuiti, per sviluppare applicazioni.

LA PIATTAFORMAPer piattaforma si intende l’insieme delle carat-teristiche hardware e software che compongo-no il device: l’utente finale utilizzerà il telefono sfruttando le caratteristiche hardware (si pensi alla fotocamera digitale o al sistema GPS) e utilizzando il software presente sul device. Il sistema operativo del telefono è, come accen-nato all’inizio dell’articolo, una versione di Windows CE su cui è installata una versione del .NET Compact Framework. Il .NET Compact Framework non è però utiliz-zabile direttamente dagli strumenti di svilup-po, in quanto il codice si appoggia, tramite le classiche reference nei progetti, alle librerie di Silverlight o del Framework XNA. Da quando è stato presentato Windows Phone 7, Silverlight non è più soltanto il potente runtime per appli-cazioni web, ma è diventato anche l’ambiente di programmazione per le applicazioni mobile oltre al runtime che farà girare il codice sul device. Rispetto all’ambiente Silverlight tra-dizionale, in cui le applicazioni vengono rag-giunte dall’utente da un browser e possono poi essere installate in locale e fatte girare fuori dal browser stesso, nell’ambiente Windows Phone 7 le applicazioni si installano dal Marketplace. Il software che sviluppiamo deve essere infatti inviato al Marketplace (come accadeva per Windows Mobile nel caso di applicazioni da distribuire al pubblico), che ne controlla la validità e l’aderenza alle specifiche per poi renderlo disponibile all’acquisto o al semplice download nel caso di applicazioni gratuite o versioni trial, gestendo tutti gli aspetti di com-mercializzazione, compresa l’eventuale pub-blicità e le statistiche di vendita.Le nostre applicazioni possono sfruttare le librerie messe a disposizione dalla piattaforma di sviluppo per interagire con la piattaforma stessa. Ad esempio è possibile utilizzare le clas-si della libreria System.Net in quanto esposte dal runtime di Silverlight per effettuare richie-ste HTTP, così come è possibile interagire con i dispositivi hardware come il GPS o l’accele-rometro tramite, rispettivamente, la libreria System.Device e System.Device.Sensors. Se non avete a disposizione un device, cosa

probabile all’uscita di questo articolo, vi con-sigliamo di fare una passeggiata su Channel 9 (channel9.msdn.com), dove sono disponibili vari filmati introduttivi che mostrano pratica-mente quasi tutte le funzionalità del telefono e l’interazione dell’utente con la stessa. L’insieme delle funzionalità hardware e sof-tware esposte allo sviluppatore è riassunto in Fig.1, presa direttamente dalla documentazio-ne installabile a partire dal link indicato.Come abbiamo accennato, nella parte in alto a sinistra, troviamo i due runtime, il primo dei quali, Silverlight, è destinato ad applica-zioni “tradizionali”, ovvero applicazioni la cui interfaccia utente sia basata sul classico para-digma di pagine che l’utente può navigare e su cui interagisce tramite controlli quali TextBox, ListBox e così via. Il runtime di XNA nasce invece per sviluppare giochi, ma non è da sot-tovalutare per gestire animazioni complesse o interazioni complesse dell’utente con il device. In realtà sarebbe possibile creare un gioco in Silverlight (ne troviamo diversi sul web) e una applicazione più tradizionale in XNA, ma le librerie e soprattutto il modo di sviluppare dei due ambienti si adattano meglio per servire il compito per cui sono nate.Come si può notare sempre dal riquadro in blu, entrambi gli ambienti hanno a disposizione una serie di librerie comuni come i sensori del telefono, il supporto alle notifiche push e pos-sono utilizzare le API della libreria Microsoft.Phone per interagire con le funzionalità del telefono.Nel riguadro verde, troviamo invece strumenti di sviluppo già disponibili da tempo in ambien-te Desktop: Visual Studio, destinato agli svi-luppatori ed Expression Blend, destinato ai designer.Visual Studio non ha bisogno di presentazioni, così come Blend è ormai il prodotto con cui si realizzano le interfacce utente per applicazioni WPF e Silverlight da qualche anno.

Fig. 1: Quadro riassuntivo della piattaforma di sviluppo

COVER STORY Introduzione all’ambiente di sviluppo per Win Phone 7

http://www.ioprogrammo.it 14 / Ottobre 2010

Questo articolo ha l’obiettivo di intro-durre tutti coloro che vogliono esse-re parte della rivoluzione Microsoft

nel mondo della telefonia mobile al nuovo ambiente di programmazione. Inizieremo con una descrizione delle caratteristiche hardwa-re del dispositivo per poi concentrarci sulle feature del telefono stesso, prima di affronta-re l’argomento principale, ovvero lo sviluppo di una semplice applicazione utilizzando gli strumenti di sviluppo, gratuiti, e il runtime di Silverlight. Nel corso dell’articolo vedremo insieme alcune specifiche per lo sviluppo di applicazioni.

IL DEVICEA febbraio 2010, Microsoft ha reso pubbliche le sue intenzioni nel mondo della telefonia mobile e nei mesi successivi ha reso disponi-bili, gratuitamente, varie versioni CTP e Beta dell’ambiente di sviluppo. Il nome finale del prodotto è Windows Phone 7 e, da tutti i punti di vista, il nuovo dispositivo rompe gli schemi con il passato, sia rispetto ai prodotti Microsoft stessi come Windows Mobile 6.5, sia rispetto ai diretti concorrenti. Anche il modo di pre-sentare il prodotto nelle varie conferenze è diverso rispetto al passato. Seguiamo lo svilup-po mobile dal 1997 quando acquistammo un device con a bordo Windows CE 1.0 in occa-sione della Microsoft Professional Developer Conference 97 a San Diego: neanche allora, quando, veniva lanciato un prodotto destinato ad un successo strepitoso e che tutt’oggi fa da base per il nuovo device era stata data così tanta enfasi alla presentazione come oggi acca-de per Windows Phone 7.Del nuovo device è fondamentale comprender-ne la filosofia di progettazione e le linee guida che hanno ispirato la nascita di questa nuova user experience. Con il termine user experien-

ce, da qualche anno, si fa riferimento proprio all’esperienza che l’utente vive durante l’utiliz-zo di un prodotto software. La user interface è una delle componenti più importanti della user experience, e non è un suo sinonimo. La user experience (UX) riguarda il feeling dell’utente con un sistema e comprende l’esperienza, l’af-fetto, il significato e il valore dell’interazione uomo-macchina e della proprietà del prodotto stesso; inoltre, la percezione degli aspetti pra-tici e dell’efficienza fanno parte dell’esperienza dell’utente.Il primo errore che può fare lo sviluppatore di applicazioni per Windows Phone 7 è ignorare queste linee guida, raccolte nel documento “Application Phone UI Design and Interaction Guide”, e progettare la user experience per la propria applicazione non in sintonia con il resto del device: non stiamo affermando che non possiamo avere fantasia e che le applica-zioni saranno tutte uguali, anzi, stiamo affer-mando il contrario: le linee guida servono per evitare che l’utente disperda il suo tempo alla ricerca di un tasto o di una funzionalità, ser-vono per dare una base comune per facilitare l’utilizzo delle applicazioni, riducendo i tempi di apprendimento e la dimensione dell’even-tuale testo di help. Le applicazioni mobile sono utilizzate in contesti diversi rispetto alle applicazioni tradizionali. L’esempio più classi-co è: se l’utente sta camminando e intanto usa il telefono, non possiamo fargli interrompere la passeggiata per farlo entrare in una opzione complicata da trovare o per costringerlo a leg-gere venti righe di testo di aiuto; se l’utente si deve fermare non abbiamo scritto una buona applicazione e se invece l’utente si distrae e attraversa la strada mentre legge... abbiamo fatto ancora peggio!Le linee guida si scaricano a partire da questo link http://developer.windowsphone.com/windows-phone-7/, dove si trova anche una guida per la costruzione di siti web con inter-

REQUISITI

Conoscenze richiesteConoscenza di .NET e Visual Studio

SoftwareÈ necessario installare i Windows Phone Developer Tools, sca-ricabili gratuitamente a partire dall’indirizzo http://tinyurl.com/winp7dev

Impegno

Tempo di realizzazione

❑ CD ❑ WEBThinkAhead.IoProgrammo.zip

cdrom.ioprogrammo.it

SVILUPPARE PER WINDOWS PHONE 7LA PROPOSTA MICROSOFT NEL MONDO DELLA TELEFONIA MOBILE ROMPE GLI SCHEMI CON IL PASSATO E SI PRESENTA COME UNA VERA RIVOLUZIONE PER QUANTO RIGUARDA LA USER EXPERIENCE E IL MODELLO DI SVILUPPO BASATO SU SILVERLIGHT E SUL RUNTIME XNA

5 Windows Phone 7 programming

Windows Phone 7 programmingSVILUPPARE PER WINDOWS PHONE 7 COVER STORY Introduzione all’ambiente di sviluppo per Win Phone 7


NOTA

ARCHITETTURA APPLICAZIONIWindows Phone 7, nella sua prima versione, offre uno spazio per la memo-rizzazione dei dati deno-minato Isolated Storage. Il codice per utilizzare l’Isolated Storage segue le stesse tecniche di qualunque applicazione Silverlight. Nelle versioni successive potremmo avere supporti locali più evoluti, quindi, per evitare di riprogettare l’applica-zione o modi� carla pesan-temente, è consigliabile utilizzare una forma di disaccoppiamento fra la user interface, lo strato di logica di business e l’accesso ai dati. Questo disaccoppiamento con-sente di sostituire un singolo componente, nel nostro caso ad esempio l’accesso al supporto di memorizzazione, senza dover modi� care una sola riga nello stato UI o nel Business Layer. Si veda il blog (http://blogs.devleap.com/rob) per informazioni sull’architettura delle applicazioni.

faccia mirata allo schermo e alla user expe-rience con Windows Phone 7. Sempre a partire dal link indicato, troveremo altre due “cose” utilissime: la prima è la documentazione sulla piattaforma che andremmo a introdurre da subito e la seconda, sono gli strumenti, gratuiti, per sviluppare applicazioni.

LA PIATTAFORMAPer piattaforma si intende l’insieme delle carat-teristiche hardware e software che compongo-no il device: l’utente finale utilizzerà il telefono sfruttando le caratteristiche hardware (si pensi alla fotocamera digitale o al sistema GPS) e utilizzando il software presente sul device. Il sistema operativo del telefono è, come accen-nato all’inizio dell’articolo, una versione di Windows CE su cui è installata una versione del .NET Compact Framework. Il .NET Compact Framework non è però utiliz-zabile direttamente dagli strumenti di svilup-po, in quanto il codice si appoggia, tramite le classiche reference nei progetti, alle librerie di Silverlight o del Framework XNA. Da quando è stato presentato Windows Phone 7, Silverlight non è più soltanto il potente runtime per appli-cazioni web, ma è diventato anche l’ambiente di programmazione per le applicazioni mobile oltre al runtime che farà girare il codice sul device. Rispetto all’ambiente Silverlight tra-dizionale, in cui le applicazioni vengono rag-giunte dall’utente da un browser e possono poi essere installate in locale e fatte girare fuori dal browser stesso, nell’ambiente Windows Phone 7 le applicazioni si installano dal Marketplace. Il software che sviluppiamo deve essere infatti inviato al Marketplace (come accadeva per Windows Mobile nel caso di applicazioni da distribuire al pubblico), che ne controlla la validità e l’aderenza alle specifiche per poi renderlo disponibile all’acquisto o al semplice download nel caso di applicazioni gratuite o versioni trial, gestendo tutti gli aspetti di com-mercializzazione, compresa l’eventuale pub-blicità e le statistiche di vendita.Le nostre applicazioni possono sfruttare le librerie messe a disposizione dalla piattaforma di sviluppo per interagire con la piattaforma stessa. Ad esempio è possibile utilizzare le clas-si della libreria System.Net in quanto esposte dal runtime di Silverlight per effettuare richie-ste HTTP, così come è possibile interagire con i dispositivi hardware come il GPS o l’accele-rometro tramite, rispettivamente, la libreria System.Device e System.Device.Sensors. Se non avete a disposizione un device, cosa

probabile all’uscita di questo articolo, vi con-sigliamo di fare una passeggiata su Channel 9 (channel9.msdn.com), dove sono disponibili vari filmati introduttivi che mostrano pratica-mente quasi tutte le funzionalità del telefono e l’interazione dell’utente con la stessa. L’insieme delle funzionalità hardware e sof-tware esposte allo sviluppatore è riassunto in Fig.1, presa direttamente dalla documentazio-ne installabile a partire dal link indicato.Come abbiamo accennato, nella parte in alto a sinistra, troviamo i due runtime, il primo dei quali, Silverlight, è destinato ad applica-zioni “tradizionali”, ovvero applicazioni la cui interfaccia utente sia basata sul classico para-digma di pagine che l’utente può navigare e su cui interagisce tramite controlli quali TextBox, ListBox e così via. Il runtime di XNA nasce invece per sviluppare giochi, ma non è da sot-tovalutare per gestire animazioni complesse o interazioni complesse dell’utente con il device. In realtà sarebbe possibile creare un gioco in Silverlight (ne troviamo diversi sul web) e una applicazione più tradizionale in XNA, ma le librerie e soprattutto il modo di sviluppare dei due ambienti si adattano meglio per servire il compito per cui sono nate.Come si può notare sempre dal riquadro in blu, entrambi gli ambienti hanno a disposizione una serie di librerie comuni come i sensori del telefono, il supporto alle notifiche push e pos-sono utilizzare le API della libreria Microsoft.Phone per interagire con le funzionalità del telefono.Nel riguadro verde, troviamo invece strumenti di sviluppo già disponibili da tempo in ambien-te Desktop: Visual Studio, destinato agli svi-luppatori ed Expression Blend, destinato ai designer.Visual Studio non ha bisogno di presentazioni, così come Blend è ormai il prodotto con cui si realizzano le interfacce utente per applicazioni WPF e Silverlight da qualche anno.

Fig. 1: Quadro riassuntivo della piattaforma di sviluppo



Questo articolo ha l’obiettivo di intro-durre tutti coloro che vogliono esse-re parte della rivoluzione Microsoft

nel mondo della telefonia mobile al nuovo ambiente di programmazione. Inizieremo con una descrizione delle caratteristiche hardwa-re del dispositivo per poi concentrarci sulle feature del telefono stesso, prima di affronta-re l’argomento principale, ovvero lo sviluppo di una semplice applicazione utilizzando gli strumenti di sviluppo, gratuiti, e il runtime di Silverlight. Nel corso dell’articolo vedremo insieme alcune specifiche per lo sviluppo di applicazioni.

IL DEVICEA febbraio 2010, Microsoft ha reso pubbliche le sue intenzioni nel mondo della telefonia mobile e nei mesi successivi ha reso disponi-bili, gratuitamente, varie versioni CTP e Beta dell’ambiente di sviluppo. Il nome finale del prodotto è Windows Phone 7 e, da tutti i punti di vista, il nuovo dispositivo rompe gli schemi con il passato, sia rispetto ai prodotti Microsoft stessi come Windows Mobile 6.5, sia rispetto ai diretti concorrenti. Anche il modo di pre-sentare il prodotto nelle varie conferenze è diverso rispetto al passato. Seguiamo lo svilup-po mobile dal 1997 quando acquistammo un device con a bordo Windows CE 1.0 in occa-sione della Microsoft Professional Developer Conference 97 a San Diego: neanche allora, quando, veniva lanciato un prodotto destinato ad un successo strepitoso e che tutt’oggi fa da base per il nuovo device era stata data così tanta enfasi alla presentazione come oggi acca-de per Windows Phone 7.Del nuovo device è fondamentale comprender-ne la filosofia di progettazione e le linee guida che hanno ispirato la nascita di questa nuova user experience. Con il termine user experien-

ce, da qualche anno, si fa riferimento proprio all’esperienza che l’utente vive durante l’utiliz-zo di un prodotto software. La user interface è una delle componenti più importanti della user experience, e non è un suo sinonimo. La user experience (UX) riguarda il feeling dell’utente con un sistema e comprende l’esperienza, l’af-fetto, il significato e il valore dell’interazione uomo-macchina e della proprietà del prodotto stesso; inoltre, la percezione degli aspetti pra-tici e dell’efficienza fanno parte dell’esperienza dell’utente.Il primo errore che può fare lo sviluppatore di applicazioni per Windows Phone 7 è ignorare queste linee guida, raccolte nel documento “Application Phone UI Design and Interaction Guide”, e progettare la user experience per la propria applicazione non in sintonia con il resto del device: non stiamo affermando che non possiamo avere fantasia e che le applica-zioni saranno tutte uguali, anzi, stiamo affer-mando il contrario: le linee guida servono per evitare che l’utente disperda il suo tempo alla ricerca di un tasto o di una funzionalità, ser-vono per dare una base comune per facilitare l’utilizzo delle applicazioni, riducendo i tempi di apprendimento e la dimensione dell’even-tuale testo di help. Le applicazioni mobile sono utilizzate in contesti diversi rispetto alle applicazioni tradizionali. L’esempio più classi-co è: se l’utente sta camminando e intanto usa il telefono, non possiamo fargli interrompere la passeggiata per farlo entrare in una opzione complicata da trovare o per costringerlo a leg-gere venti righe di testo di aiuto; se l’utente si deve fermare non abbiamo scritto una buona applicazione e se invece l’utente si distrae e attraversa la strada mentre legge... abbiamo fatto ancora peggio!Le linee guida si scaricano a partire da questo link http://developer.windowsphone.com/windows-phone-7/, dove si trova anche una guida per la costruzione di siti web con inter-

REQUISITI


SoftwareÈ necessario installare i Windows Phone Developer Tools, sca-ricabili gratuitamente a partire dall’indirizzo http://tinyurl.com/winp7dev

Impegno


❑ CD ❑ WEBThinkAhead.IoProgrammo.zip


SVILUPPARE PER WINDOWS PHONE 7LA PROPOSTA MICROSOFT NEL MONDO DELLA TELEFONIA MOBILE ROMPE GLI SCHEMI CON IL PASSATO E SI PRESENTA COME UNA VERA RIVOLUZIONE PER QUANTO RIGUARDA LA USER EXPERIENCE E IL MODELLO DI SVILUPPO BASATO SU SILVERLIGHT E SUL RUNTIME XNA




che vi consigliamo di controllare dopo l’usci-ta della versione finale degli strumenti che, essendo prevista per il 16 settembre, dovreb-bero già essere disponibili quando leggerete questo articolo.Iniziamo a costruire una semplice applicazio-ne e poi proveremo ad utilizzare qualche API esposta dalla piattaforma.

GLI STRUMENTIDI SVILUPPOSe avete una versione di Visual Studio 2010 già presente sulla macchina, l’installazio-ne degli strumenti di sviluppo aggiunge una serie di template per la creazione di appli-cazioni Windows Phone 7 sia per il runti-me di Silverlight che per l’ambiente XNA. Se non avete una versione di Visual Studio 2010 installata, nessun problema, verrà installata contestualmente la versione gratuita, demo-ninata Express for Windows Phone 2010 che comprende tutto il necessario per sviluppare. Ovviamente la versione Express non ha gli stru-menti della versione Ultimate di Visual Studio, ma consente di sviluppare con le stesse feature della versione Express tradizionale applicazio-ni Silverlight e XNA per Windows Phone 7.L’installazione degli strumenti di sviluppo in entrambe le forme, attiva anche l’interazione con l’emulatore su cui è possibile testare le applicazioni tramite il classico “F5” da Visual Studio.Gli strumenti installati prevedono anche, oltre alla versione Express di Blend 4 per la parte di disegno delle applicazioni, anche l’Application Deployment, in grado di installare su emulatore o device fisico una applicazione compilata nel classico package XAP, e il Phone Registration Tool che consente di sbloccare un device fisico per l’installazione di applicazioni in test.Negli esempi che seguono costruiremo una semplice applicazione Silverlight per Windows Phone 7 e poi vedremo all’opera il controllo Panorama. Per prima cosa occorre creare un progetto scegliendo uno dei template Windows Phone nella sezione Silverlight for Windows Phone. Nella versione attuale, i progetti disponibili prevedono una applicazione Portrait o una applicazione Landscape (il supporto alla rota-zione è poi gestibile all’interno dell’applica-zione), una dll per Windows Phone, ovvero il classico assembly .NET dove inserire il codice riutilizzabile da più applicazioni, e due appli-cazioni basate su due nuovi controlli specifici della piattaforma: Panorama e Pivot.

PARTIRECON IL PIEDE GIUSTOI vari template creano un classico progetto Visual Studio 2010 contenente una serie di refe-rence verso le librerie che abbiamo inquadrato nella prima parte dell’articolo, una pagina principale denominata MainPage.xaml, il clas-sico file App.xaml e relativo code-behind per la definizione delle risorse e del codice dell’appli-cazione e, non ultime, tre immagini.La prima immagine, ApplicationIcon.png con-sente di definire l’icona dell’applicazione, Background.png è invece, a discapito del suo nome, l’icona per la defizione del Tile dell’ap-plicazione (ovvero l’icona più grande da uti-lizzare nella schermata principale se l’uten-te decide di inserire l’applicazione nel menu start), SplashScreen.png è invece la scherma-ta che viene utilizzata durante la partenza dell’applicazione stessa. Per darvi una idea, in Fig.2 ci sono due scre-enshot dell’emulatore: a destra la schermata iniziale, dove sono ospitate tre applicazioni reali che stiamo sviluppando, e a sinistra la schermata di riepilogo di tutte le applicazioni installate. L’utente può decidere di spostare una appli-cazione nella schermata principale, effettuan-do il tap sull’applicazione e scegliendo “pin to start” dal menu contestuale. ThinkAhead.IoProgrammo è invece l’esempio che stiamo costruendo in questo articolo.Tornando subito al codice creato dal template di progetto, oltre alle pagine che ospiteranno la definizione della user interface, nella directory Properties viene inserito un file fondamentale per l’applicazione stessa. La definizione dei nomi delle risorse, come le immagini appena descritte, del titolo dell’ap-plicazione, del tile da usare nella scherma-ta principale sono infatti ospitate nel file WMAppManifest.xml. Questo file contiene anche le “capabilities” dell’applicazione, ovvero le feature del telefo-no che l’applicazione desidera utilizzare. Ogni applicazione deve dichiarare se accede alla rete oppure ai servizi di notifiche o ancora se utilizza il “phone dialer”.

<?xml version=”1.0” encoding=”utf-8”?>

<Deployment xmlns=”http://schemas.

microsoft.com/windowsphone/2009/deployment”

AppPlatformVersion=”7.0”>

<App xmlns=”” ProductID=”{c0aeef79-341e-

4485-9e60-87edee5fbdfb}”

Title=”ThinkAhead.IoProgrammo”

RuntimeType=”Silverlight” Version=”1.0.0.0”

NOTA

BLOG, FORUM E ESEMPILa community www.think-mobile.it, nata in occasione della prima conferenza italiana sullo sviluppo mobile nel luglio di cinque anni fa, da aprile 2010 ha aperto una nuova sezione dedicata a Windows Phone 7: sono disponibili forum speci� ci per trattare lo sviluppo, vari blog che for-niscono informazioni con-tinue sulle novità per gli sviluppatori e nella sezione media si trovano numerosi esempi sull’utilizzo dei sensori e delle varie fun-zionalità del device.

Fig. 3: Visual Studio Designer: l’interfaccia delle applicazioni segue la metafora della navi-gazione Web, per cui si può sempre tornare alla schermata precedente con un tap sul pulsante back



Gli strumenti di sviluppo comprendono anche un emulatore e una tonnellata di esempi com-pleti o esempi da costruire passo passo, e la documentazione sull’intera piattaforma.Sul device (e sull’emulatore) è ovviamente presente un browser internet, per la precisio-ne una versione di Internet Explorer allineata alle funzionalità della versione 7 presente sul desktop, quindi è possibile optare anche per la scrittura di applicazioni web, magari ospitate su una piattaforma di cloud computing come Windows Azure di cui abbiamo avuto modo di parlare in vari articoli apparsi nei numeri precedenti.Le varie possibilità offerte dalla nuova piatta-forma comprendono :

1. Silverlight 3 (con alcune feature della ver-sione 4) per la creazione di moderne user interface basate su eventi

2. XNA per realizzare giochi e animazioni com-plesse

3. HTML/XHTML/AJAX/JQuery per applicazio-ni web basate su Internet Explorer

4. Applicazioni miste in cui, ad esempio, la parte principale è scritta in Silverlight, ma sfrutta alcune animazioni fatte con XNA e per alcuni contenuti web sfrutta il controllo Web Browser.

Tranne nel caso di applicazioni basate su browser, è possibile utilizzare le API presenti sul telefono e una serie di servizi esposti da

Microsoft su internet, per la precisione trami-te applicazioni basate su Windows Azure che consentono di utilizzare il sistema di gestione degli utenti, le mappe, i servizi di localizzazio-ne, meccanismi per inviare notifiche all’utente e, non ultimi, i servizi esposti da Xbox Live.

IL MERCATO DI RIFERIMENTOLa distribuzione delle applicazioni viene fatta tramite Windows Phone Marketplace che, da svariati anni, è il contenitore in cui pubblicare e pubblicizzare le applicazioni rivolte al pub-blico. Non è possibile, almeno per adesso, installare una applicazione direttamente su un devi-ce, se non per portarne avanti lo sviluppo. L’approccio è molto simile a Windows Mobile, dove, da sempre è necessario firmare le appli-cazioni con il certificato del marketplace per renderle “sicure” e installabili senza blocchi di security sui vari device. Si possono fare parago-ni anche con le piattaforme concorrenti come iPhone e Android.Ogni applicazione installata gira in modo isola-to dalle altre con lo stesso paradigma utilizzato da Silverlight su piattaforma web: è possibi-le appoggiare dati e impostazioni applicative sull’Isolated Storage senza doversi preoccu-pare di gestire lo spazio dati su disco per le varie applicazioni. Isolated Storage consente di memorizzare settaggi applicativi persistenti e temporanei.Le caratteristiche hardware possono essere diverse da device a device in base alle scelte del produttore, ma è necessario che il device rispetti l’insieme delle caratteristiche minime definite dalle specifiche per poter essere consi-derato un device Windows Phone 7. Microsoft ha scelto infatti una strada più aperta rispetto a Apple che fornisce anche l’hardware. Ad oggi sono previsti (e su internet si trovano varie immagini) device LG, Samsung e HTC. Avremo quindi la possibilità di scegliere il device che più ci piace o che si adatta mag-giormente alle nostre esigenze (con tastiera o senza, con più storage o meno), ma dal punto di vista dello sviluppatore, avremo a disposi-zione un’insieme di caratteristiche comuni su cui poter contare. Ad esempio lo schermo sarà sempre 480x800 (dimesioni in Portrait), avremmo a disposizio-ne una quantità di RAM che farebbe impallidi-re un classico notebook di 3 anni fa, una foto-camera digitale, un servizio GPS, una scheda Wi-Fi, l’accelerometro e altre caratteristiche

NOTA

USER EXPERIENCESpesso lo sviluppatore sot-tovaluta molti degli aspetti legati alla user interface e alla user experience: non intendiamo dire che non sia in grado di costruire

user interface carine o accattivanti, ma che

sottovaluti l’importanza di aderire alle linee guida della piattaforma. Su una interfaccia di dimensioni

ridotte e su un dispositivo che fa della user experien-ce un suo punto di forza è fondamentale rispettare le linee guida: vi consigliamo

caldamente di leggere la “UI Design & Interaction

Guide” che trovate a parti-re dalla home page per gli sviluppatori http://develo-per.windowsphone.com/

windows-phone-7/.

Fig. 2: Applicazioni in fase di sviluppo: menu start e menu programmi

</Grid>





</phone:PhoneApplicationPage>

Molti sono gli elementi da comprendere nel codice della maschera prima di iniziare a costruire la nostra user interface: per prima cosa è importante notare che ci troviamo all’in-terno di una PhoneApplicationPage. Questa classe si trova nell’assembly Microsoft.Phone e rappresenta il contenitore di controlli per que-sta maschera: ogni maschera viene rappresen-tata da una pagina, in quanto l’utente si muove da una pagina all’altra e ha la possibilità, come ormai ci ha abituato il web, di ripercorrere la sua navigazione all’indietro tramite il pul-

sante back, rappresentato in basso a sinistra anche nella finestra di design di Visual Studio 2010 mostrata in Fig. 3. La seconda infor-mazione importante che si evince dal codice della pagina principale è l’utilizzo del costrutto StaticResource per le varie impostazioni gra-fiche della pagina. Ogni elemento proposto dal template viene rappresentato secondo uno stile; lo stile ha lo scopo di centralizzare la

Fig. 6: Codice reale XAML del controllo Panorama

Fig. 7: Il controllo Panorama in una applicazione reale



Genre=”apps.normal”

Author=”ThinkAhead”

Description=”Sample description”

Publisher=”ThinkAhead”>

<IconPath IsRelative=”true” IsResource=”false”>

ApplicationIcon.png</IconPath>

<Capabilities>

<Capability Name=”ID_CAP_GAMERSERVICES”/>

<Capability Name=”ID_CAP_IDENTITY_DEVICE”/>

<Capability Name=”ID_CAP_IDENTITY_USER”/>

<Capability Name=”ID_CAP_LOCATION”/>

<Capability Name=”ID_CAP_MEDIALIB”/>

<Capability Name=”ID_CAP_MICROPHONE”/>

<Capability Name=”ID_CAP_NETWORKING”/>

<Capability Name=”ID_CAP_PHONEDIALER”/>

<Capability Name=”ID_CAP_PUSH_

NOTIFICATION”/>

<Capability Name=”ID_CAP_SENSORS”/>

<Capability Name=”ID_CAP_

WEBBROWSERCOMPONENT”/>

</Capabilities>

<Tasks>

<DefaultTask Name =”_default”

NavigationPage=”MainPage.xaml”/>

</Tasks>

<Tokens>

<PrimaryToken TokenID=”ThinkAhead.

IoProgrammoToken” TaskName=”_default”>

<TemplateType5>

<BackgroundImageURI IsRelative=”true”

IsResource=”false”>Background.png</

BackgroundImageURI>

<Count>0</Count>

<Title>ThinkAhead.IoProgrammo</Title>

</TemplateType5>

</PrimaryToken>

</Tokens>

</App>

</Deployment>

Nel codice precedente è possibile notare la definizione dell’applicazione ThinkAhead.IoProgrammo, il runtime di tipo Silverlight, la versione e il tipo di applicazione, alcune infor-mazioni su autore, descrizione e publisher. L’icona applicativa è definita immediatamente sotto la definizione dell’applicazione e precede a sua volta la definizione, lasciata ai valori di default, delle capabilities. Nella sezione Task vediamo il puntatore alla pagina di default (MainPage.xaml) che è stata creata all’interno del progetto e che andremo a descrivere fra un attimo. Chiude il file la definizione del Tile di default, ovvero il puntatore al titolo, all’immagine e ad un eventuale contatore di notifiche che il dispositivo utilizzerà quando l’utente decide di effettuare il “pin to start” dell’applicazione.

DEFINIRE L’ASPETTOIl nuovo progetto, appena aperto, presenta il designer Silverlight che, come per le applica-zioni web, divide il codice XAML dal designer visuale. Abbiamo solamente modificato il titolo dell’applicazione e il titolo della pagina prin-cipale (MainPage.xaml) nell’estratto di codice seguente:

<phone:PhoneApplicationPage

x:Class=”ThinkAhead.IoProgrammo.MainPage”

xmlns=”http://schemas.microsoft.com/winfx/2006/

xaml/presentation”

xmlns:x=”http://schemas.microsoft.com/winfx/2006/

xaml”

xmlns:phone=”clr-namespace:Microsoft.Phone.

Controls;assembly=Microsoft.Phone”

xmlns:shell=”clr-namespace:Microsoft.Phone.

Shell;assembly=Microsoft.Phone”

xmlns:d=”http://schemas.microsoft.com/expression/

blend/2008”

xmlns:mc=”http://schemas.openxmlformats.org/

markup-compatibility/2006”

mc:Ignorable=”d” d:DesignWidth=”480”

d:DesignHeight=”768”

FontFamily=”{StaticResource

PhoneFontFamilyNormal}”

FontSize=”{StaticResource PhoneFontSizeNormal}”

Foreground=”{StaticResource

PhoneForegroundBrush}”

SupportedOrientations=”Portrait”

Orientation=”Portrait”

shell:SystemTray.IsVisible=”True”>



<Grid x:Name=”LayoutRoot”

Background=”Transparent”>

<Grid.RowDefi nitions>

<RowDefi nition Height=”Auto”/>

<RowDefi nition Height=”*”/>

</Grid.RowDefi nitions>



<StackPanel x:Name=”TitlePanel” Grid.Row=”0”

Margin=”12,16,0,27”>

<TextBlock x:Name=”ApplicationTitle”

Text=”THINKAHEAD FOR IOPROGRAMMO”

Style=”{StaticResource PhoneTextNormalStyle}”/>

<TextBlock x:Name=”PageTitle” Text=”main”

Margin=”9,-8,0,0” Style=”{StaticResource

PhoneTextTitle1Style}”/>

</StackPanel>



<Grid x:Name=”ContentPanel” Grid.Row=”1”

Margin=”12,0,12,0”/>

Fig. 4: Il primo test della nostra nuova app

Fig. 5: Software Input Panel (SIP)

</Grid>





</phone:PhoneApplicationPage>

Molti sono gli elementi da comprendere nel codice della maschera prima di iniziare a costruire la nostra user interface: per prima cosa è importante notare che ci troviamo all’in-terno di una PhoneApplicationPage. Questa classe si trova nell’assembly Microsoft.Phone e rappresenta il contenitore di controlli per que-sta maschera: ogni maschera viene rappresen-tata da una pagina, in quanto l’utente si muove da una pagina all’altra e ha la possibilità, come ormai ci ha abituato il web, di ripercorrere la sua navigazione all’indietro tramite il pul-

sante back, rappresentato in basso a sinistra anche nella finestra di design di Visual Studio 2010 mostrata in Fig. 3. La seconda infor-mazione importante che si evince dal codice della pagina principale è l’utilizzo del costrutto StaticResource per le varie impostazioni gra-fiche della pagina. Ogni elemento proposto dal template viene rappresentato secondo uno stile; lo stile ha lo scopo di centralizzare la

Fig. 6: Codice reale XAML del controllo Panorama

Fig. 7: Il controllo Panorama in una applicazione reale



Genre=”apps.normal”

Author=”ThinkAhead”

Description=”Sample description”

Publisher=”ThinkAhead”>

<IconPath IsRelative=”true” IsResource=”false”>

ApplicationIcon.png</IconPath>

<Capabilities>










NOTIFICATION”/>




</Capabilities>

<Tasks>

<DefaultTask Name =”_default”

NavigationPage=”MainPage.xaml”/>

</Tasks>

<Tokens>

<PrimaryToken TokenID=”ThinkAhead.

IoProgrammoToken” TaskName=”_default”>

<TemplateType5>

<BackgroundImageURI IsRelative=”true”

IsResource=”false”>Background.png</

BackgroundImageURI>

<Count>0</Count>

<Title>ThinkAhead.IoProgrammo</Title>

</TemplateType5>

</PrimaryToken>

</Tokens>

</App>

</Deployment>

Nel codice precedente è possibile notare la definizione dell’applicazione ThinkAhead.IoProgrammo, il runtime di tipo Silverlight, la versione e il tipo di applicazione, alcune infor-mazioni su autore, descrizione e publisher. L’icona applicativa è definita immediatamente sotto la definizione dell’applicazione e precede a sua volta la definizione, lasciata ai valori di default, delle capabilities. Nella sezione Task vediamo il puntatore alla pagina di default (MainPage.xaml) che è stata creata all’interno del progetto e che andremo a descrivere fra un attimo. Chiude il file la definizione del Tile di default, ovvero il puntatore al titolo, all’immagine e ad un eventuale contatore di notifiche che il dispositivo utilizzerà quando l’utente decide di effettuare il “pin to start” dell’applicazione.

DEFINIRE L’ASPETTOIl nuovo progetto, appena aperto, presenta il designer Silverlight che, come per le applica-zioni web, divide il codice XAML dal designer visuale. Abbiamo solamente modificato il titolo dell’applicazione e il titolo della pagina prin-cipale (MainPage.xaml) nell’estratto di codice seguente:

<phone:PhoneApplicationPage

x:Class=”ThinkAhead.IoProgrammo.MainPage”

xmlns=”http://schemas.microsoft.com/winfx/2006/

xaml/presentation”

xmlns:x=”http://schemas.microsoft.com/winfx/2006/

xaml”

xmlns:phone=”clr-namespace:Microsoft.Phone.

Controls;assembly=Microsoft.Phone”

xmlns:shell=”clr-namespace:Microsoft.Phone.

Shell;assembly=Microsoft.Phone”

xmlns:d=”http://schemas.microsoft.com/expression/

blend/2008”

xmlns:mc=”http://schemas.openxmlformats.org/

markup-compatibility/2006”

mc:Ignorable=”d” d:DesignWidth=”480”

d:DesignHeight=”768”

FontFamily=”{StaticResource

PhoneFontFamilyNormal}”

FontSize=”{StaticResource PhoneFontSizeNormal}”

Foreground=”{StaticResource

PhoneForegroundBrush}”

SupportedOrientations=”Portrait”

Orientation=”Portrait”

shell:SystemTray.IsVisible=”True”>





<Grid.RowDefi nitions>

<RowDefi nition Height=”Auto”/>

<RowDefi nition Height=”*”/>

</Grid.RowDefi nitions>



<StackPanel x:Name=”TitlePanel” Grid.Row=”0”

Margin=”12,16,0,27”>

<TextBlock x:Name=”ApplicationTitle”

Text=”THINKAHEAD FOR IOPROGRAMMO”


<TextBlock x:Name=”PageTitle” Text=”main”

Margin=”9,-8,0,0” Style=”{StaticResource


</StackPanel>




Margin=”12,0,12,0”/>

Fig. 4: Il primo test della nostra nuova app

Fig. 5: Software Input Panel (SIP)




using System.Windows.Shapes;

using Microsoft.Phone.Controls;

namespace ThinkAhead.IoProgrammo

{

public partial class MainPage : PhoneApplicationPage

{

// Constructor

public MainPage()

{

InitializeComponent();

}

private void addButton_Click(object sender,

RoutedEventArgs e)

{

appListBox.Items.Add(textBox1.Text);

}

}

}

COSA SUCCEDE DIETRO LE QUINTEIl code behind è semplice e, come Visual Studio ci ha abituati sin dalla versione 2002, prevede una derivazione dalla classe base del form, in questo caso una page rappresentata dalla clas-se PhoneApplicationPage (la stessa indicata nel file MainPage.xaml che abbiamo analizza-to in precedenza), l’utilizzo di un costruttore che verrà autogenerato nel file mainpage.g.cs, oltre al codice del metodo addButton_Click che abbiamo inserito noi per gestire l’inserimento dell’elemento nella listbox.Provando a digitare la keyword override note-rete vari metodi utilizzabili per entrare nel ciclo di vita di una pagina, come ad esempio OnNavigatingFrom e OnNavigatedFrom per intercettare la navigazione verso altre pagine, OnNavigatedTo per intercettare la navigazio-ne verso questa pagina, OnBackKeyPress per intercettare la pressione del tasto back, tasto che sarà presente obbligatoriamente su tutti i device Windows Phone 7.Non ci resta che premere F5 per vedere il nostro lavoro sull’emulatore: Visual Studio si preoccupa di attivare l’emulatore, effettuare il deploy dell’applicazione e il debug dell’appli-cazione stessa (provare a metttere un break-point per verificarne il funzionamento). A destra, in verticale, sono rappresentate una serie di informazioni di debug rispetto alla user interface. L’applicazione dovrebbe presentarsi (pixel più, pixel meno) come in Fig. 4. Abbiamo aggiunto “Office” fra le applicazioni tramite la TextBox e la pressione del nostro pulsante per

verificare il funzionamento del codice intro-dotto nella pagina. Come abbiamo accennato, le librerie Microsoft offrono una serie di risorse per indicare lo stile di default dei vari controlli che possiamo utilizzare nella user interface. Selezionando ad esempio un elemento nella listbox, questa assume lo stile di default che riprende lo stile che l’utente ha scelto per il suo device.Tutti i campi in cui l’utente può inserire del testo, quando ottengono il focus, presentano il Software Input Panel (SIP) che, chi lavora in ambiente mobile conosce molto bene sin dai tempi di Embedded Visual Basic (eVB). L’idea è semplificare la digitazione dei dati visto che l’utente usa spesso il device in condizioni di movimento o mentre può essere distratto delle condizioni dell’ambiente in cui si trova. La Fig. 6 mostra l’emulatore durante la scrittura del testo in un campo textbox. L’emulatore consente di eseguire altre opera-zioni come la rotazione dello schermo, l’avvio di Internet Explorer, lo zoom e, come vedremo nei prossimi articoli, molte funzionalità nasco-ste dai menu della interfaccia utente.Questo semplice esempio ha messo in eviden-za l’interfaccia proposta per una applicazione fatta di varie pagine in cui l’utente naviga attraverso le funzionalità applicative. A fianco a questa modalità di navigazione sono stati proposti su CodePlex sin dalle prime beta e previsti per la versione RTM all’interno del prodotto, due controlli che gli esperti di user experience definiscono come “killer control”. Si tratta di Panorama e Pivot. Il primo, Panorama, come indica il termine stesso, viene usato per presentare all’utente un panorama: si pensi al panorama nel più classico dei significati, dove presentare vari scorci, ognuno delle quali presenta informa-zioni all’utente e fa parte del panorama stesso. L’utente può interagire con i vari scorci effet-tuando lo scrolling direttamente dall’interfac-cia.

LA BELLEZZA DEL PANORAMAVisto che l’applicazione è localizzata in più lingue, abbiamo utilizzato il binding verso le nostre risorse localizzate (con un classico con-verter Silverlight) per le intestazioni e i vari TextBlock inseriti nel primo PanoramaItem.Il controllo Panorama consente di impostare un titolo per l’applicazione visto che il con-trollo occupa l’intera superficie dello scher-mo, consente di intercettare tramite l’even-



definizione delle informazioni di layout e pre-sentazione in modo da renderne più semplice la modifica a posteriori. Nel caso del template base di Visual Studio, le risorse, contraria-mente alle prime beta di cui abbiamo parlato in articoli precedenti, vengono centralizzate all’interno delle librerie referenziate, ma è possibile modificarle all’interno, ad esempio, del file App.xaml. Una successiva modifica al file App.xaml si riflette in tutte le pagine della nostra applicazione. La terza cosa da notare nel listato di codi-ce XAML è la presenza di un controllo Grid per definire il layout della pagina. La griglia divide il contenuto in due righe, la prima delle quali è destinata al titolo e sottotitolo della pagina stessa; anche queste informazio-ni sono posizionate all’interno di una griglia (TitleGrid) che si posiziona a sua volta nella prima riga sfruttando la proprietà Row della Grid “LayoutRoot”. La griglia posizionata nella seconda riga della griglia principale è a nostra disposizione per il disegno della pagina.Chiude il listato una parte commentata in cui viene proposta la Application Bar, ovvero, la modalità con cui presentare all’utente le azioni da fare sulla pagina corrente. La Application Bar rappresenta il menu contestuale della pagi-na dove proporre all’utente le azioni possibili.Utilizzando il designer di Visual Studio, oppure direttamente il codice XAML, o anco-

ra Microsoft Expression Blend 4 (incluso nel setup degli strumenti), possiamo posizionare qualche controllo nella pagina per provare a verificarne il funzionamento sull’emulatore. Tralasciamo in questo primo articolo qua-lunque elemento grafico o di impaginazione, andando a posizionare i controlli direttamente nella griglia. Aggiungiamo, come esempio, il codice seguente per preparare una listbox con le applicazioni che stiamo sviluppando.


Margin=”12,0,12,0”>

<ListBox Height=”244” HorizontalAlignment=”Left”

Margin=”14,31,0,0” Name=”appListBox”

VerticalAlignment=”Top” Width=”460”>

<ListBoxItem Content=”kiss and hug” />

<ListBoxItem Content=”kind love” />

<ListBoxItem Content=”save the planet” />

</ListBox>

</Grid>

Immediatamente sotto la listbox inseriamo un TextBox e un pulsante per aggiungere altre applicazioni alla lista:

<Button Content=”Aggiungi”

HorizontalAlignment=”Left” Margin=”1,344,0,0”

Name=”addButton” VerticalAlignment=”Top”

Width=”445” />

<TextBox HorizontalAlignment=”Left”

Margin=”6,266,0,0” Name=”applicationTextBox”

Text=”” VerticalAlignment=”Top” Width=”440” />

Facendo doppio clic sul pulsante aggiungi (addButton) Visual Studio o Blend ci prepara-no l’event handler nel code behind della pagi-na xaml dove aggiungeremo un nuovo elemen-to a appListBox con il contenuto della proprietà Text del controllo applicationTextBox. È possibile generare gli event handler anche dal designer del codice XAML semplicemente digitando “Click=” per poi premere il tasto Tab che, come suggerisce l’intellisense, consente di creare tutto il necessario per agganciare l’evento con il metodo che scriveremo nel code behind.

using System;

using System.Collections.Generic;

using System.Linq;

using System.Net;

using System.Windows;

using System.Windows.Controls;

using System.Windows.Documents;

using System.Windows.Input;

using System.Windows.Media;

using System.Windows.Media.Animation;

Fig. 8: Phone Callda codice

Fig. 9: Interfaccia in azione con il Phone Number Chooser






namespace ThinkAhead.IoProgrammo

{


{

// Constructor

public MainPage()

{


}

private void addButton_Click(object sender,

RoutedEventArgs e)

{

appListBox.Items.Add(textBox1.Text);

}

}

}

COSA SUCCEDE DIETRO LE QUINTEIl code behind è semplice e, come Visual Studio ci ha abituati sin dalla versione 2002, prevede una derivazione dalla classe base del form, in questo caso una page rappresentata dalla clas-se PhoneApplicationPage (la stessa indicata nel file MainPage.xaml che abbiamo analizza-to in precedenza), l’utilizzo di un costruttore che verrà autogenerato nel file mainpage.g.cs, oltre al codice del metodo addButton_Click che abbiamo inserito noi per gestire l’inserimento dell’elemento nella listbox.Provando a digitare la keyword override note-rete vari metodi utilizzabili per entrare nel ciclo di vita di una pagina, come ad esempio OnNavigatingFrom e OnNavigatedFrom per intercettare la navigazione verso altre pagine, OnNavigatedTo per intercettare la navigazio-ne verso questa pagina, OnBackKeyPress per intercettare la pressione del tasto back, tasto che sarà presente obbligatoriamente su tutti i device Windows Phone 7.Non ci resta che premere F5 per vedere il nostro lavoro sull’emulatore: Visual Studio si preoccupa di attivare l’emulatore, effettuare il deploy dell’applicazione e il debug dell’appli-cazione stessa (provare a metttere un break-point per verificarne il funzionamento). A destra, in verticale, sono rappresentate una serie di informazioni di debug rispetto alla user interface. L’applicazione dovrebbe presentarsi (pixel più, pixel meno) come in Fig. 4. Abbiamo aggiunto “Office” fra le applicazioni tramite la TextBox e la pressione del nostro pulsante per

verificare il funzionamento del codice intro-dotto nella pagina. Come abbiamo accennato, le librerie Microsoft offrono una serie di risorse per indicare lo stile di default dei vari controlli che possiamo utilizzare nella user interface. Selezionando ad esempio un elemento nella listbox, questa assume lo stile di default che riprende lo stile che l’utente ha scelto per il suo device.Tutti i campi in cui l’utente può inserire del testo, quando ottengono il focus, presentano il Software Input Panel (SIP) che, chi lavora in ambiente mobile conosce molto bene sin dai tempi di Embedded Visual Basic (eVB). L’idea è semplificare la digitazione dei dati visto che l’utente usa spesso il device in condizioni di movimento o mentre può essere distratto delle condizioni dell’ambiente in cui si trova. La Fig. 6 mostra l’emulatore durante la scrittura del testo in un campo textbox. L’emulatore consente di eseguire altre opera-zioni come la rotazione dello schermo, l’avvio di Internet Explorer, lo zoom e, come vedremo nei prossimi articoli, molte funzionalità nasco-ste dai menu della interfaccia utente.Questo semplice esempio ha messo in eviden-za l’interfaccia proposta per una applicazione fatta di varie pagine in cui l’utente naviga attraverso le funzionalità applicative. A fianco a questa modalità di navigazione sono stati proposti su CodePlex sin dalle prime beta e previsti per la versione RTM all’interno del prodotto, due controlli che gli esperti di user experience definiscono come “killer control”. Si tratta di Panorama e Pivot. Il primo, Panorama, come indica il termine stesso, viene usato per presentare all’utente un panorama: si pensi al panorama nel più classico dei significati, dove presentare vari scorci, ognuno delle quali presenta informa-zioni all’utente e fa parte del panorama stesso. L’utente può interagire con i vari scorci effet-tuando lo scrolling direttamente dall’interfac-cia.

LA BELLEZZA DEL PANORAMAVisto che l’applicazione è localizzata in più lingue, abbiamo utilizzato il binding verso le nostre risorse localizzate (con un classico con-verter Silverlight) per le intestazioni e i vari TextBlock inseriti nel primo PanoramaItem.Il controllo Panorama consente di impostare un titolo per l’applicazione visto che il con-trollo occupa l’intera superficie dello scher-mo, consente di intercettare tramite l’even-



definizione delle informazioni di layout e pre-sentazione in modo da renderne più semplice la modifica a posteriori. Nel caso del template base di Visual Studio, le risorse, contraria-mente alle prime beta di cui abbiamo parlato in articoli precedenti, vengono centralizzate all’interno delle librerie referenziate, ma è possibile modificarle all’interno, ad esempio, del file App.xaml. Una successiva modifica al file App.xaml si riflette in tutte le pagine della nostra applicazione. La terza cosa da notare nel listato di codi-ce XAML è la presenza di un controllo Grid per definire il layout della pagina. La griglia divide il contenuto in due righe, la prima delle quali è destinata al titolo e sottotitolo della pagina stessa; anche queste informazio-ni sono posizionate all’interno di una griglia (TitleGrid) che si posiziona a sua volta nella prima riga sfruttando la proprietà Row della Grid “LayoutRoot”. La griglia posizionata nella seconda riga della griglia principale è a nostra disposizione per il disegno della pagina.Chiude il listato una parte commentata in cui viene proposta la Application Bar, ovvero, la modalità con cui presentare all’utente le azioni da fare sulla pagina corrente. La Application Bar rappresenta il menu contestuale della pagi-na dove proporre all’utente le azioni possibili.Utilizzando il designer di Visual Studio, oppure direttamente il codice XAML, o anco-

ra Microsoft Expression Blend 4 (incluso nel setup degli strumenti), possiamo posizionare qualche controllo nella pagina per provare a verificarne il funzionamento sull’emulatore. Tralasciamo in questo primo articolo qua-lunque elemento grafico o di impaginazione, andando a posizionare i controlli direttamente nella griglia. Aggiungiamo, come esempio, il codice seguente per preparare una listbox con le applicazioni che stiamo sviluppando.


Margin=”12,0,12,0”>

<ListBox Height=”244” HorizontalAlignment=”Left”

Margin=”14,31,0,0” Name=”appListBox”

VerticalAlignment=”Top” Width=”460”>

<ListBoxItem Content=”kiss and hug” />

<ListBoxItem Content=”kind love” />

<ListBoxItem Content=”save the planet” />

</ListBox>

</Grid>

Immediatamente sotto la listbox inseriamo un TextBox e un pulsante per aggiungere altre applicazioni alla lista:

<Button Content=”Aggiungi”


Name=”addButton” VerticalAlignment=”Top”

Width=”445” />

<TextBox HorizontalAlignment=”Left”

Margin=”6,266,0,0” Name=”applicationTextBox”

Text=”” VerticalAlignment=”Top” Width=”440” />

Facendo doppio clic sul pulsante aggiungi (addButton) Visual Studio o Blend ci prepara-no l’event handler nel code behind della pagi-na xaml dove aggiungeremo un nuovo elemen-to a appListBox con il contenuto della proprietà Text del controllo applicationTextBox. È possibile generare gli event handler anche dal designer del codice XAML semplicemente digitando “Click=” per poi premere il tasto Tab che, come suggerisce l’intellisense, consente di creare tutto il necessario per agganciare l’evento con il metodo che scriveremo nel code behind.

using System;


using System.Linq;

using System.Net;







Fig. 8: Phone Callda codice

Fig. 9: Interfaccia in azione con il Phone Number Chooser


Windows Phone 7 programming MOBILE Windows Phone 7

http://www.ioprogrammo.it 50 / Novembre 2010

Questo articolo introduce le API esposte allo sviluppatore di applicazioni Windows Phone 7 che consentono di interagire sia

con l’hardware presente sul device, come ad esem-pio la fotocamera o il dialer, sia con il software esposto dalla piattaforma come il Media Player oppure i contatti presenti.Ricordiamo che gli strumenti di sviluppo in ver-sione finale si possono scaricare gratuitamente da http://developer.windowsphone.com.

LA PIATTAFORMAIl sistema operativo alla base di Windows Phone 7 è una nuova versione di Windows CE, il siste-ma operativo nato nel 1997 e che ha fatto da base, nelle sue varie versioni, a decine di dispo-sitivi diversi, che vanno da device impiegati in campo industriale alla serie di device orientati all’utente finale, da device subacquei impiegati anche in campo militare a headless device che controllano macchine a controllo numerico o gli stessi navigatori di molte auto.Sopra il sistema operativo troviamo una nuova versione del famoso .NET Compact Framework, inaccessibile, almeno in questa prima versione, al codice delle applicazioni. Il .NET Compact Framework fornisce, quindi, API e servizi, non direttamente alle applicazioni, ma ai due ambienti con cui possiamo scrivere le nostre

applicazioni ovvero Silverlight e XNA. Il codi-ce delle applicazioni si appoggia al runtime di Silverlight o al runtime di XNA e “vede” solo le API esposte da questi ambienti: è impossibile, ripeto, in questa versione, accedere direttamen-te alle API sottostanti.Lo schema architetturale cui faremo riferimento in questo articolo è quello illustrato in Fig.1: “.NET Framework managed code sandbox” rap-presenta il framework di base che espone fun-zionalità ai tutti i compo librerie referenziabili.

La libreria, referenziata per default, Microsoft.Phone, contiene gran parte delle funzionalità del dispositivo come ad esempio le classi base

REQUISITI


SoftwareÈ necessario installare i Windows Phone Developer Tools, sca-ricabili gratuitamente a partire dall’indirizzo http://developer.win-dowsphone.com.

Impegno


WINDOWS PHONE 7: API E SENSORILA PROPOSTA MICROSOFT NEL MONDO DELLA TELEFONIA MOBILE È PRONTA AL LANCIO. IN QUESTO ARTICOLO VEDREMO LE API ESPOSTE PER INTERAGIRE CON L’HARDWARE E IL SOFTWARE DELLA PIATTAFORMA, UTILIZZANDO IL RUNTIME DI SILVERLIGHT

❑ CD ❑ WEBThinkAhead.PhoneAPI.zip


Fig.1: Schema riassuntivo della piattaforma

Fig.2: Un’occhiata all’assembly

SVILUPPARE PER WINDOWS PHONE 7COVER STORY Introduzione all’ambiente di sviluppo per Win Phone 7


Roberto e Luca sono consulenti che operano

nel mondo .NET sin dalla presentazione dell’ambiente nel luglio 2000. Luca è spe-

cializzato nella de� nizione della user interface, mentre Roberto si dedica all’archi-

tettura e prestazioni della soluzione. La loro azienda, we.ThinkAhead.it, società

del gruppo DevLeap, è spe-cializzata nella realizzazione

di soluzioni cloud-based su Windows Azure, appli-cazioni WPF/Silverlight e

applicazioni mobile sia per Windows Mobile 6.5 che

per Windows Phone 7. Sul sito si trovano i riferimenti ai progetti e alle aree tec-

nologiche coperte.

GLI AUTORI

to SelectionChanged lo scrolling dell’utente, e ha una immagine di sfondo denominata PanoramaBackground.png. Nel nostro caso l’immagine è alta 800 pixel, come lo schermo del telefono, e larga 1850 pixel in modo da formare il panorama in cui l’utente può spostarsi. I cinque elementi interni (da 0 a 4) contengono le varie interfacce dei 5 “scorci” di panorama, come si nota nella Fig. 7 dove sono state affian-cate la pagina 4 (ovvero l’ultima) alla pagina 0 (ovvero la prima).Come si può notare, la pagina a sinistra pre-senta il suo contenuto, ha il titolo dell’applica-zione allineato in alto, e, lascia intendere che esiste un secondo scorcio del panorama alla sua destra. Quando l’utente trascina la pagina verso sini-stra, cosa possibile anche con l’emulatore nel caso in cui si utilizzi un PC con schermo touch, il panorama scorre e mostra lo scorcio a destra, dal titolo “summary”, togliendo lo scorcio “set-tings” dalla vista dell’utente. A sua volta la pagi-na “summary” e lascia intendere la presenza a destra di uno scorcio successivo. L’utente può anche tornare indietro ripercorrendo il pano-rama scoperto.Il controllo Pivot è invece il classico Tab Control in chiave moderna: è utilizzabile sfruttando le stesse “gesture” del controllo Panorama e, in più, consente di cliccare sul tab per scegliere una voce: ne parleremo in un prossimo articolo.Chiudiamo vedendo alcune API che consen-tono di interagire con le feature del telefono. Non occorrono reference aggiuntive in questa versione.

private void dialButton_Click(object sender,

RoutedEventArgs e)

{

PhoneCallTask task = new PhoneCallTask();

task.DisplayName = “From ThinkAheadApp”;

task.PhoneNumber = “055-1111111”;

task.Show();

}

Non è possibile attivare la chiamata diretta-mente da una applicazione, almeno in questa prima release. Il PhoneCallTask consente di attivare la maschera nativa che l’utente utiliz-zerebbe per effettuare una chiamata precompi-lata con le due informazioni che appaiono nor-malmente. Un secondo Task, che come si nota dal codice seguente, ha il suffisso Chooser con-sente invece di attivare la scelta di un contatto dalla maschera nativa del device, far scegliere all’utente (da qui il nome Chooser) un contatto e ottenere il numero di telefono.

private void numberChooser_Click(object sender,

RoutedEventArgs e)

{

PhoneNumberChooserTask task = new

PhoneNumberChooserTask();

task.Show();

}

Altre Task consentono di memorizzare informazioni sul telefono, come ad esempio un numero di telefo-no, attraverso gli oggetti relativi. Nel codice seguente il salvataggio di un numero di telefono da una applicazione e in Fig. 10 lo screen-shot relativo.

private void savePhone_Click(object sender,

RoutedEventArgs e)

{

SavePhoneNumberTask task = new

SavePhoneNumberTask();


task.Show();

}

Sul sito www.thinkmobile.it sono disponibili esempi monotematici sull’utilizzo di Acceletometro, ApplicationBar, InputScope, IsolatedStorage, Location Service, PushNoti� cation e Manipulation. Sul sito trovate anche mini-articoli di una solo pagina con esempi mirati e forum per scambiare informazioni sullo sviluppo mobile.In questo primo articolo abbiamo cercato di eviden-ziare da una parte le caratteristiche più importanti del nuovo Windows Phone 7 e dall’altra cercato di fornire i passi per la creazione di una semplice applicazione.

CONCLUSIONI, E AVVERTENZE...Ribadiamo il consiglio che abbiamo dato qualche mese fa sulla prima beta degli strumenti: chiunque arrivi da Windows Mobile 6.x o da Windows CE e ha lavorato per anni con Windows Forms, di capire a fondo XAML e Silverlight prima di scrivere la prima vera applicazione. Silverlight in realtà riprende una serie di idee e concetti venuti alla luce con Windows Presentation Foundation (WPF) nel lontano 2006, quando, a novembre, fu rilasciata la prima versione; senza fare il salto mentale verso questi ambienti si rischia di usare un ambiente estremamente potente come Silverlight al 10 percento delle sue possibilità, potenzialità e manutenibilità.

Roberto Brunetti e Luca Regnicoli

Fig. 10: Save Phone Num-ber Task


Windows Phone 7 programmingWINDOWS PHONE 7: API E SENSORIMOBILE Windows Phone 7


Questo articolo introduce le API esposte allo sviluppatore di applicazioni Windows Phone 7 che consentono di interagire sia

con l’hardware presente sul device, come ad esem-pio la fotocamera o il dialer, sia con il software esposto dalla piattaforma come il Media Player oppure i contatti presenti.Ricordiamo che gli strumenti di sviluppo in ver-sione finale si possono scaricare gratuitamente da http://developer.windowsphone.com.

LA PIATTAFORMAIl sistema operativo alla base di Windows Phone 7 è una nuova versione di Windows CE, il siste-ma operativo nato nel 1997 e che ha fatto da base, nelle sue varie versioni, a decine di dispo-sitivi diversi, che vanno da device impiegati in campo industriale alla serie di device orientati all’utente finale, da device subacquei impiegati anche in campo militare a headless device che controllano macchine a controllo numerico o gli stessi navigatori di molte auto.Sopra il sistema operativo troviamo una nuova versione del famoso .NET Compact Framework, inaccessibile, almeno in questa prima versione, al codice delle applicazioni. Il .NET Compact Framework fornisce, quindi, API e servizi, non direttamente alle applicazioni, ma ai due ambienti con cui possiamo scrivere le nostre

applicazioni ovvero Silverlight e XNA. Il codi-ce delle applicazioni si appoggia al runtime di Silverlight o al runtime di XNA e “vede” solo le API esposte da questi ambienti: è impossibile, ripeto, in questa versione, accedere direttamen-te alle API sottostanti.Lo schema architetturale cui faremo riferimento in questo articolo è quello illustrato in Fig.1: “.NET Framework managed code sandbox” rap-presenta il framework di base che espone fun-zionalità ai tutti i compo librerie referenziabili.

La libreria, referenziata per default, Microsoft.Phone, contiene gran parte delle funzionalità del dispositivo come ad esempio le classi base

REQUISITI



Impegno


WINDOWS PHONE 7: API E SENSORILA PROPOSTA MICROSOFT NEL MONDO DELLA TELEFONIA MOBILE È PRONTA AL LANCIO. IN QUESTO ARTICOLO VEDREMO LE API ESPOSTE PER INTERAGIRE CON L’HARDWARE E IL SOFTWARE DELLA PIATTAFORMA, UTILIZZANDO IL RUNTIME DI SILVERLIGHT

❑ CD ❑ WEBThinkAhead.PhoneAPI.zip


Fig.1: Schema riassuntivo della piattaforma

Fig.2: Un’occhiata all’assembly





cializzato nella de� nizione della user interface, mentre Roberto si dedica all’archi-

tettura e prestazioni della soluzione. La loro azienda, we.ThinkAhead.it, società

del gruppo DevLeap, è spe-cializzata nella realizzazione

di soluzioni cloud-based su Windows Azure, appli-cazioni WPF/Silverlight e

applicazioni mobile sia per Windows Mobile 6.5 che

per Windows Phone 7. Sul sito si trovano i riferimenti ai progetti e alle aree tec-

nologiche coperte.

GLI AUTORI

to SelectionChanged lo scrolling dell’utente, e ha una immagine di sfondo denominata PanoramaBackground.png. Nel nostro caso l’immagine è alta 800 pixel, come lo schermo del telefono, e larga 1850 pixel in modo da formare il panorama in cui l’utente può spostarsi. I cinque elementi interni (da 0 a 4) contengono le varie interfacce dei 5 “scorci” di panorama, come si nota nella Fig. 7 dove sono state affian-cate la pagina 4 (ovvero l’ultima) alla pagina 0 (ovvero la prima).Come si può notare, la pagina a sinistra pre-senta il suo contenuto, ha il titolo dell’applica-zione allineato in alto, e, lascia intendere che esiste un secondo scorcio del panorama alla sua destra. Quando l’utente trascina la pagina verso sini-stra, cosa possibile anche con l’emulatore nel caso in cui si utilizzi un PC con schermo touch, il panorama scorre e mostra lo scorcio a destra, dal titolo “summary”, togliendo lo scorcio “set-tings” dalla vista dell’utente. A sua volta la pagi-na “summary” e lascia intendere la presenza a destra di uno scorcio successivo. L’utente può anche tornare indietro ripercorrendo il pano-rama scoperto.Il controllo Pivot è invece il classico Tab Control in chiave moderna: è utilizzabile sfruttando le stesse “gesture” del controllo Panorama e, in più, consente di cliccare sul tab per scegliere una voce: ne parleremo in un prossimo articolo.Chiudiamo vedendo alcune API che consen-tono di interagire con le feature del telefono. Non occorrono reference aggiuntive in questa versione.

private void dialButton_Click(object sender,

RoutedEventArgs e)

{


task.DisplayName = “From ThinkAheadApp”;


task.Show();

}

Non è possibile attivare la chiamata diretta-mente da una applicazione, almeno in questa prima release. Il PhoneCallTask consente di attivare la maschera nativa che l’utente utiliz-zerebbe per effettuare una chiamata precompi-lata con le due informazioni che appaiono nor-malmente. Un secondo Task, che come si nota dal codice seguente, ha il suffisso Chooser con-sente invece di attivare la scelta di un contatto dalla maschera nativa del device, far scegliere all’utente (da qui il nome Chooser) un contatto e ottenere il numero di telefono.

private void numberChooser_Click(object sender,

RoutedEventArgs e)

{

PhoneNumberChooserTask task = new

PhoneNumberChooserTask();

task.Show();

}

Altre Task consentono di memorizzare informazioni sul telefono, come ad esempio un numero di telefo-no, attraverso gli oggetti relativi. Nel codice seguente il salvataggio di un numero di telefono da una applicazione e in Fig. 10 lo screen-shot relativo.

private void savePhone_Click(object sender,

RoutedEventArgs e)

{

SavePhoneNumberTask task = new



task.Show();

}

Sul sito www.thinkmobile.it sono disponibili esempi monotematici sull’utilizzo di Acceletometro, ApplicationBar, InputScope, IsolatedStorage, Location Service, PushNoti� cation e Manipulation. Sul sito trovate anche mini-articoli di una solo pagina con esempi mirati e forum per scambiare informazioni sullo sviluppo mobile.In questo primo articolo abbiamo cercato di eviden-ziare da una parte le caratteristiche più importanti del nuovo Windows Phone 7 e dall’altra cercato di fornire i passi per la creazione di una semplice applicazione.

CONCLUSIONI, E AVVERTENZE...Ribadiamo il consiglio che abbiamo dato qualche mese fa sulla prima beta degli strumenti: chiunque arrivi da Windows Mobile 6.x o da Windows CE e ha lavorato per anni con Windows Forms, di capire a fondo XAML e Silverlight prima di scrivere la prima vera applicazione. Silverlight in realtà riprende una serie di idee e concetti venuti alla luce con Windows Presentation Foundation (WPF) nel lontano 2006, quando, a novembre, fu rilasciata la prima versione; senza fare il salto mentale verso questi ambienti si rischia di usare un ambiente estremamente potente come Silverlight al 10 percento delle sue possibilità, potenzialità e manutenibilità.

Roberto Brunetti e Luca Regnicoli

Fig. 10: Save Phone Num-ber Task


Windows Phone 7 programming WINDOWS PHONE 7: API E SENSORI MOBILE Windows Phone 7


SmsComposeTask task = new

SmsComposeTask();

task.Body = “Messaggio da ThinkAhead”;

task.To = “123-456”;

task.Show();

}

Anche in questo caso il controllo passa al telefono per l’invio dell’SMS: maschera dalla quale l’utente, come si può notare nell’immagine centrale della Fig. 4, può aggiungere allegati prima di inviare il messaggio. Per tornare all’applicazione l’utente deve premere il pulsante Back del telefono. Il comportamento è quindi in realtà diverso dal Phone Dialer, dove l’applicazione riprende il con-trollo non appena l’utente ha terminato la chiamata (o se ha rinunciato a effettuarla). Questa differenza introduce un argomento che tratteremo meglio nei prossimi articoli: quando l’applicazione richiede alcune funzionalità al telefono, viene disattivata (tombstoned nella documentazione) per essere poi riattivata quando l’utente torna ad essa premendo il tasto back. Questa disattivazione sull’applicazione corrente avviene normalmente quando un utente preme il pulsante Start, come si può verificare dalla documentazione ufficiale. Nel codice allega-to abbiamo inserito una Message Box nell’evento Deactivate e nell’evento Activate dell’applicazione proprio per aiutare a comprendere questo compor-tamento. L’immagine 4 mostra le tre fasi, disattiva-zione, maschera di invio sms esterna all’applicazio-ne, riattivazione.È importante sottolineare che una applicazione disattivata deve essere considerata terminata e, infatti, è molto probabile che il sistema opera-tivo termini il processo che la ospita. Riattivare una applicazione non significa necessariamente riprendere l’istanza precedente anzi, spesso, com-

porta la creazione di una nuova istanza: il servizio di riattivazione ricarica automaticamente la pagi-na xaml in cui l’uente si trovava, ma su una nuova istanza applicativa. Torniamo sulla rotta tracciata all’inizio di questo articolo: è possibile salvare un numero di telefono nella rubrica dei contatti; il processo segue quan-do abbiamo appena accennato. Il metodo show, asincrono, attiva la maschera di salvataggio nei contatti: questa operazione disattiva l’applica-zione, e, quando l’utente termina l’operazione di salvataggio, l’applicazione viene riattivata. Il task SavePhoneNumberTask, inoltre, scatena un even-to che possiamo intercettare, non appena l’appli-cazione viene riattivata, per ottenere il risultato del salvataggio. Il codice è quindi un attimo più complesso dei precedenti:

private SavePhoneNumberTask _savePhoneTask;

public MainPage()

{


this._savePhoneTask = new


this._savePhoneTask.Completed += new

EventHandler<TaskEventArgs>(savePhoneNumberTa

sk_Completed);

}

private void saveContact_Click(object sender,

RoutedEventArgs e)

{

this._savePhoneTask.PhoneNumber = “123-

456”;

this._savePhoneTask.Show();

}

void savePhoneNumberTask_Completed(object

sender, TaskEventArgs e)

{

if (e.TaskResult == TaskResult.OK)

{

MessageBox.Show(“Salvato”);

}

}

Il codice del metodo saveContact_Click è semplicis-simo, ma sfrutta un oggetto definito all’interno della pagina in modo da poterlo istanziare nel costruttore e utilizzarlo per abbonarsi all’evento di completa-mento del task. È fondamentale abbonarsi a questo evento nel costruttore in quanto, come abbiamo evidenziato, l’applicazione, quando viene riattivata, potrebbe essere una nuova istanza. L’evento savePhoneNumberTask_Completed, veri-Fig.4: Interfaccia per la gestione degli Sms

MOBILEWindows Phone 7

Novembre 2010 / 51 http://www.ioprogrammo.it

per le pagine e l’applicazione, la vibrazione, il controllo per gestire la radio FM e i servizi generali. Il namespace System.Windows contie-ne tutti i controlli base come TextBox, ListBox, Image e le classi per effettuare richieste in rete. Aggiungendo anche Microsoft.Device.Sensors e System.Device possiamo utilizzare anche le API dell’accelerometro e dei servizi di Location.Molte di queste funzionalità possono essere testate anche sull’emulatore, macchina fotogra-fica compresa, oppure possono essere simulate usando le Reactive Extension o delle classi pro-prietarie. Sulla communitiy italiana dedicata allo sviluppo mobile, raggiungible all’indirizzo www.thinkmobile.it, abbiamo pubblicato due componenti per simulare l’accelerometro via mouse/touchscreen e il servizio di location via mouse. Quando una applicazione utilizza i ser-vizi esposti dal telefono è necessario indicare la relativa “capability” nel file WMAppManifest.xaml. Le impostazioni possibili all’interno del file di manifest sono le seguenti:

<Capabilities>










NOTIFICATION”/>




</Capabilities>

Ad esempio, se l’applicazione utilizza, come fare-mo fra un attimo, il Phone Dialer per attivare una telefonata occorre aggiungere la prima riga mostrata nel codice precedente all’elenco delle feature del telefono. Ogni progetto Visual Studio presenta per default l’elenco completo delle featu-re, quindi, è sufficiente rimuovere quelle che non usiamo. In ogni caso, durante la verifica effettuata dal marketplace per firmare l’applicazione, saran-no ricontrollate le funzionalità e il file di manifest finale viene ricreato direttamente dal personale del marketplace stesso.Il codice dell’articolo verrà allegato alla rivista: non abbiamo usato nessuna finezza grafica nell’esem-pio e, ad ogni pulsante, corrisponde un esempio che vedremo nel corso dell’articolo.

AL TELEFONO!Il primo esempio che costruiremo insieme riguarda l’interazione con il telefono. L’interfaccia presenta, nella pagina principale, quattro pulsanti a questo scopo: il primo per comporre un numero, il secondo per inviare un SMS, il terzo per salvare un numero nella rubrica dei contatti, il quarto per recuperare un numero dalla rubrica.Il codice per comporre un numero di telefono è il seguente:

private void callButton_Click(object sender,

RoutedEventArgs e)

{


task.DisplayName = “Roberto Brunetti”;


task.Show();

}

In questo caso stiamo componendo un numero non presente nella rubrica: l’interfaccia si presenta come mostrato a sinistra in Fig. 3. L’utente ha la possibilità di accettare o rifiutare l’inizio della chia-mata. La Fig. 3 mostra a destra la chiamata in corso.

Il metodo Show è asincrono: attiva il task per ese-guire la chiamata e restituisce immediatamente il controllo all’applicazione, il cui codice prosegue. Non è quindi possibile sapere se l’utente ha portato a termine la chiamata o meno.Il secondo estratto di codice mostra come compor-re un sms, da inviare anche in questo caso, ad un numero non presente in rubrica. Il codice è molto semplice e soprattutto simile al precedente:

private void smsButton_Click(object sender,

RoutedEventArgs e)

{

Fig.3: L’interfaccia del Phone Dialer

MARKETPLACEUna applicazione può utilizzare il marketplace in varie modalità. Ad esempio un’applicazione può atti-vare un task di ricerca di applicazioni o brani musi-cali in base ad un criterio di ricerca testuale oppure richiedere l’apertura sui dettagli di un’applicazione o di un brano musicale così come invocare l’aper-tura della pagina di valu-tazione dell’applicazione stessa.

NOTA




SmsComposeTask task = new

SmsComposeTask();

task.Body = “Messaggio da ThinkAhead”;

task.To = “123-456”;

task.Show();

}

Anche in questo caso il controllo passa al telefono per l’invio dell’SMS: maschera dalla quale l’utente, come si può notare nell’immagine centrale della Fig. 4, può aggiungere allegati prima di inviare il messaggio. Per tornare all’applicazione l’utente deve premere il pulsante Back del telefono. Il comportamento è quindi in realtà diverso dal Phone Dialer, dove l’applicazione riprende il con-trollo non appena l’utente ha terminato la chiamata (o se ha rinunciato a effettuarla). Questa differenza introduce un argomento che tratteremo meglio nei prossimi articoli: quando l’applicazione richiede alcune funzionalità al telefono, viene disattivata (tombstoned nella documentazione) per essere poi riattivata quando l’utente torna ad essa premendo il tasto back. Questa disattivazione sull’applicazione corrente avviene normalmente quando un utente preme il pulsante Start, come si può verificare dalla documentazione ufficiale. Nel codice allega-to abbiamo inserito una Message Box nell’evento Deactivate e nell’evento Activate dell’applicazione proprio per aiutare a comprendere questo compor-tamento. L’immagine 4 mostra le tre fasi, disattiva-zione, maschera di invio sms esterna all’applicazio-ne, riattivazione.È importante sottolineare che una applicazione disattivata deve essere considerata terminata e, infatti, è molto probabile che il sistema opera-tivo termini il processo che la ospita. Riattivare una applicazione non significa necessariamente riprendere l’istanza precedente anzi, spesso, com-

porta la creazione di una nuova istanza: il servizio di riattivazione ricarica automaticamente la pagi-na xaml in cui l’uente si trovava, ma su una nuova istanza applicativa. Torniamo sulla rotta tracciata all’inizio di questo articolo: è possibile salvare un numero di telefono nella rubrica dei contatti; il processo segue quan-do abbiamo appena accennato. Il metodo show, asincrono, attiva la maschera di salvataggio nei contatti: questa operazione disattiva l’applica-zione, e, quando l’utente termina l’operazione di salvataggio, l’applicazione viene riattivata. Il task SavePhoneNumberTask, inoltre, scatena un even-to che possiamo intercettare, non appena l’appli-cazione viene riattivata, per ottenere il risultato del salvataggio. Il codice è quindi un attimo più complesso dei precedenti:

private SavePhoneNumberTask _savePhoneTask;

public MainPage()

{






sk_Completed);

}

private void saveContact_Click(object sender,

RoutedEventArgs e)

{

this._savePhoneTask.PhoneNumber = “123-

456”;

this._savePhoneTask.Show();

}

void savePhoneNumberTask_Completed(object

sender, TaskEventArgs e)

{


{

MessageBox.Show(“Salvato”);

}

}

Il codice del metodo saveContact_Click è semplicis-simo, ma sfrutta un oggetto definito all’interno della pagina in modo da poterlo istanziare nel costruttore e utilizzarlo per abbonarsi all’evento di completa-mento del task. È fondamentale abbonarsi a questo evento nel costruttore in quanto, come abbiamo evidenziato, l’applicazione, quando viene riattivata, potrebbe essere una nuova istanza. L’evento savePhoneNumberTask_Completed, veri-Fig.4: Interfaccia per la gestione degli Sms



per le pagine e l’applicazione, la vibrazione, il controllo per gestire la radio FM e i servizi generali. Il namespace System.Windows contie-ne tutti i controlli base come TextBox, ListBox, Image e le classi per effettuare richieste in rete. Aggiungendo anche Microsoft.Device.Sensors e System.Device possiamo utilizzare anche le API dell’accelerometro e dei servizi di Location.Molte di queste funzionalità possono essere testate anche sull’emulatore, macchina fotogra-fica compresa, oppure possono essere simulate usando le Reactive Extension o delle classi pro-prietarie. Sulla communitiy italiana dedicata allo sviluppo mobile, raggiungible all’indirizzo www.thinkmobile.it, abbiamo pubblicato due componenti per simulare l’accelerometro via mouse/touchscreen e il servizio di location via mouse. Quando una applicazione utilizza i ser-vizi esposti dal telefono è necessario indicare la relativa “capability” nel file WMAppManifest.xaml. Le impostazioni possibili all’interno del file di manifest sono le seguenti:

<Capabilities>










NOTIFICATION”/>




</Capabilities>

Ad esempio, se l’applicazione utilizza, come fare-mo fra un attimo, il Phone Dialer per attivare una telefonata occorre aggiungere la prima riga mostrata nel codice precedente all’elenco delle feature del telefono. Ogni progetto Visual Studio presenta per default l’elenco completo delle featu-re, quindi, è sufficiente rimuovere quelle che non usiamo. In ogni caso, durante la verifica effettuata dal marketplace per firmare l’applicazione, saran-no ricontrollate le funzionalità e il file di manifest finale viene ricreato direttamente dal personale del marketplace stesso.Il codice dell’articolo verrà allegato alla rivista: non abbiamo usato nessuna finezza grafica nell’esem-pio e, ad ogni pulsante, corrisponde un esempio che vedremo nel corso dell’articolo.

AL TELEFONO!Il primo esempio che costruiremo insieme riguarda l’interazione con il telefono. L’interfaccia presenta, nella pagina principale, quattro pulsanti a questo scopo: il primo per comporre un numero, il secondo per inviare un SMS, il terzo per salvare un numero nella rubrica dei contatti, il quarto per recuperare un numero dalla rubrica.Il codice per comporre un numero di telefono è il seguente:

private void callButton_Click(object sender,

RoutedEventArgs e)

{


task.DisplayName = “Roberto Brunetti”;


task.Show();

}

In questo caso stiamo componendo un numero non presente nella rubrica: l’interfaccia si presenta come mostrato a sinistra in Fig. 3. L’utente ha la possibilità di accettare o rifiutare l’inizio della chia-mata. La Fig. 3 mostra a destra la chiamata in corso.

Il metodo Show è asincrono: attiva il task per ese-guire la chiamata e restituisce immediatamente il controllo all’applicazione, il cui codice prosegue. Non è quindi possibile sapere se l’utente ha portato a termine la chiamata o meno.Il secondo estratto di codice mostra come compor-re un sms, da inviare anche in questo caso, ad un numero non presente in rubrica. Il codice è molto semplice e soprattutto simile al precedente:

private void smsButton_Click(object sender,

RoutedEventArgs e)

{

Fig.3: L’interfaccia del Phone Dialer

MARKETPLACEUna applicazione può utilizzare il marketplace in varie modalità. Ad esempio un’applicazione può atti-vare un task di ricerca di applicazioni o brani musi-cali in base ad un criterio di ricerca testuale oppure richiedere l’apertura sui dettagli di un’applicazione o di un brano musicale così come invocare l’aper-tura della pagina di valu-tazione dell’applicazione stessa.

NOTA




SUL WEB

UN BLOG DA SEGUIRE

La community www.think-mobile.it, nata in occasione

della prima conferenza italiana sullo sviluppo

mobile nel luglio di cinque anni fa, da Aprile 2010 ha aperto una nuova sezione

dedicata a Windows Phone 7: sono disponibili forum

specifici per trattare lo sviluppo, vari blog che for-niscono informazioni con-

tinue sulle novità per gli sviluppatori e nella sezione media si trovano numerosi

esempi sull’utilizzo dei sensori e delle varie fun-

zionalità del device.

recuperiamo il numero di telefono dall’instanza della classe PhoneNumberResult ricevuta come argomento e, nel nostro esempio, visualizziamo il numero in una TextBlock della pagina. Il risultato a video è mostrato in Fig. 6: sto recuperando il con-tatto salvato con l’esempio precedente a cui avevo assegnato il mio nome.

CAMERA E IMMAGINIGli stessi concetti esposti nella sezione preceden-te, si applicano anche all’utilizzo delle immagini, sia quelle già presenti negli album dell’utente, sia le immagini richieste direttamente alla fotocame-ra, ovvero scattate al volo. Per quanto riguarda la ricerca e selezione di immagini presenti sul device, utilizzeremo un Chooser, che, come abbiamo capi-to, sospenderà l’applicazione corrente (che verrà tombstoned dal sistema ed eventualmente termina-ta) per attivare la selezione delle immagini nei vari album dell’utente. Quando l’utente avrà eseguito la sua scelta oppure avrà annullato l’operazione, il sistema riattiverà l’applicazione inviando un evento in cui è possibile conoscere l’operazione effettuata dall’utente. Nella pagina principale della nostra applicazione abbiamo inserito altri due pulsanti e un controllo Image per accogliere l’eventuale sele-zione. Come per il resto dell’articolo non ci occupe-remo di creare una user interface accattivante, ma ci concentriamo sul codice necessario:

private PhotoChooserTask _photoChooserTask;

public MainPage()

{


this._photoChooserTask = new

PhotoChooserTask();

this._photoChooserTask.Completed += new

EventHandler<PhotoResult>(photoTask_Completed);

private void photoButton_Click(object sender,

RoutedEventArgs e)

{

this._photoChooserTask.Show();

}

void photoTask_Completed(object sender,

PhotoResult e)

{


{

BitmapImage bmp = new BitmapImage();

bmp.SetSource(e.ChosenPhoto);

photoImage.Source = bmp;

}

}

Il codice definisce l’oggetto _photoChooserTask all’interno della classe che rappresenta la pagina di default della nostra applicazione, ne crea una istanza nel costruttore per poi abbonarsi al relativo evento di scelta da parte dell’utente. Il codice dell’event hander, dopo aver controlla-to se l’utente ha scelto una foto, crea un oggetto BitmapImage per “trasformare” lo stream (classe System.IO.Stream) restituito dal Photo Chooser in qualcosa di assegnabile alla sorgente dati del con-trollo photoImage. Qualunque altra tecnica di pas-saggio da un System.IO.Stream ad un ImageSource è ugualmente efficace.L’immagine 7 mostra il risultato dell’attivazione del Photo Chooser, la scel-ta della foto e la relativa visualizzazione. Nel caso si utilizzi l’emulatore, è possibile salvare immagini da Internet Explorer, eseguendo il tap prolungato sull’immagine stessa: dal menu contestuale è pos-sibile condividere l’immagine sui social network oppure, salvarla in un album locale.

SCATTIAMO UNA FOTOIl prossimo esempio, funzionante anche sull’emu-latore grazie al simulatore della macchina foto-grafica, consente di scattare una foto e restituirla all’applicazione richiedente. Il flusso è identico a quanto abbiamo ormai imparato e prevede il tom-bstoning dell’applicazione durante l’attivazione della fotocamera. Occorre quindi utilizzare la classe CameraCaptureTask definendola a livello di pagina, istanziarla nel costruttore abbonandosi al relativo evento di completamento, e definire un event han-dler. Possiamo anche utilizzare, come nell’esempio di codice seguente, lo stesso event handler utilizzato per il Photo Chooser; il risultato sarà infatti identico: una immagine di tipo System.IO.Stream da “conver-

Fig.7: La sequenza per il completamento del PhotoChooserTask



fica il risultato, affermativo se l’utente ha salvato il contatto e negativo se l’utente ha annullato l’ope-razione, e visualizza semplicemente un messaggio.Il flusso completo di aggiunta di un contatto, e salvataggio del contatto stesso è mostrato in Fig. 5 nella quale, per ragioni di spazio, non ho mostra-to l’aggiunta del nome, della foto e i messaggi Deactivate/Activate. Per ritornare all’applicazione l’utente deve premere il pulsante Back.Analogamente possiamo salvare un indirizzo

email tramite la classe SaveEmailAddressTask: il comportamento e il codice, nome della classe e relativo evento di completamento a parte, è asso-lutamente identico.Oltre all’operazione di inserimento/aggiornamen-to di un contatto, una applicazione può anche recuperare numero di telefono e/o indirizzo di email di un contatto tramite alcuni componenti denominati Chooser: il termine Chooser deriva dal fatto che il componente consente, appunto, di scegliere “qualcosa” dal telefono per restituirlo all’applicazione. Come per le Task precedenti, quando viene invo-cato un Chooser, l’applicazione viene disattivata, viene aperta la relativa applicazione e, solo quan-do l’utente ha effettuato la scelta o ha annullato la selezione, il controllo ritorna all’applicazione.Il codice per attivare il Chooser per recuperare un numero di telefono è il seguente:

using System;


using System.Linq;

using System.Net;









using Microsoft.Phone.Tasks;

namespace ThinkAhead.PhoneAPI

{


{

private PhoneNumberChooserTask _phoneNum

berChooserTask;

public MainPage()

{






sk_Completed);

}

private void readNumberButton_Click(object

sender, RoutedEventArgs e)

{

this._phoneNumberChooserTask.Show();

}

void phoneNumberChooserTask_Completed(object

sender, PhoneNumberResult e)

{


{

resultTextBlock.Text = e.PhoneNumber;

}

}

}

}

Dopo aver definito l’oggetto PhoneNumberChooser Task, il costruttore crea una istanza e si abbona al relativo evento. Nell’event handle è possibile sapere se l’utente ha effettuato la scelta control-lando la proprietà TaskResult: in caso affermativo,

Fig.5: I passaggi del SavePhoneNumberTask

Fig.6: Le tre fasi necessarie al completamento del PhoneNumberChooserTask

NOTA

USER INTERFACESpesso lo sviluppatore sot-tovaluta molti degli aspetti legati alla userinterface e alla userexperience: non intendiamo dire che non sia in grado di costruire userinterface carine o accattivanti, ma che sot-tovaluti l’importanza di aderire alle linee guida della piattaforma. Su una interfaccia di dimensioni ridotte e su un dispositivo che fa della userexperien-ce un suo punto di forza è fondamentale rispettare le linee guida: vi consigliamo caldamente di leggere la “UI Design &Interaction Guide” che trovate a parti-re dalla home page per gli sviluppatori http://develo-per.windowsphone.com/windows-phone-7/.




SUL WEB

UN BLOG DA SEGUIRE

La community www.think-mobile.it, nata in occasione

della prima conferenza italiana sullo sviluppo

mobile nel luglio di cinque anni fa, da Aprile 2010 ha aperto una nuova sezione

dedicata a Windows Phone 7: sono disponibili forum

specifici per trattare lo sviluppo, vari blog che for-niscono informazioni con-

tinue sulle novità per gli sviluppatori e nella sezione media si trovano numerosi

esempi sull’utilizzo dei sensori e delle varie fun-

zionalità del device.

recuperiamo il numero di telefono dall’instanza della classe PhoneNumberResult ricevuta come argomento e, nel nostro esempio, visualizziamo il numero in una TextBlock della pagina. Il risultato a video è mostrato in Fig. 6: sto recuperando il con-tatto salvato con l’esempio precedente a cui avevo assegnato il mio nome.

CAMERA E IMMAGINIGli stessi concetti esposti nella sezione preceden-te, si applicano anche all’utilizzo delle immagini, sia quelle già presenti negli album dell’utente, sia le immagini richieste direttamente alla fotocame-ra, ovvero scattate al volo. Per quanto riguarda la ricerca e selezione di immagini presenti sul device, utilizzeremo un Chooser, che, come abbiamo capi-to, sospenderà l’applicazione corrente (che verrà tombstoned dal sistema ed eventualmente termina-ta) per attivare la selezione delle immagini nei vari album dell’utente. Quando l’utente avrà eseguito la sua scelta oppure avrà annullato l’operazione, il sistema riattiverà l’applicazione inviando un evento in cui è possibile conoscere l’operazione effettuata dall’utente. Nella pagina principale della nostra applicazione abbiamo inserito altri due pulsanti e un controllo Image per accogliere l’eventuale sele-zione. Come per il resto dell’articolo non ci occupe-remo di creare una user interface accattivante, ma ci concentriamo sul codice necessario:

private PhotoChooserTask _photoChooserTask;

public MainPage()

{


this._photoChooserTask = new

PhotoChooserTask();

this._photoChooserTask.Completed += new


private void photoButton_Click(object sender,

RoutedEventArgs e)

{

this._photoChooserTask.Show();

}

void photoTask_Completed(object sender,

PhotoResult e)

{


{

BitmapImage bmp = new BitmapImage();

bmp.SetSource(e.ChosenPhoto);

photoImage.Source = bmp;

}

}

Il codice definisce l’oggetto _photoChooserTask all’interno della classe che rappresenta la pagina di default della nostra applicazione, ne crea una istanza nel costruttore per poi abbonarsi al relativo evento di scelta da parte dell’utente. Il codice dell’event hander, dopo aver controlla-to se l’utente ha scelto una foto, crea un oggetto BitmapImage per “trasformare” lo stream (classe System.IO.Stream) restituito dal Photo Chooser in qualcosa di assegnabile alla sorgente dati del con-trollo photoImage. Qualunque altra tecnica di pas-saggio da un System.IO.Stream ad un ImageSource è ugualmente efficace.L’immagine 7 mostra il risultato dell’attivazione del Photo Chooser, la scel-ta della foto e la relativa visualizzazione. Nel caso si utilizzi l’emulatore, è possibile salvare immagini da Internet Explorer, eseguendo il tap prolungato sull’immagine stessa: dal menu contestuale è pos-sibile condividere l’immagine sui social network oppure, salvarla in un album locale.

SCATTIAMO UNA FOTOIl prossimo esempio, funzionante anche sull’emu-latore grazie al simulatore della macchina foto-grafica, consente di scattare una foto e restituirla all’applicazione richiedente. Il flusso è identico a quanto abbiamo ormai imparato e prevede il tom-bstoning dell’applicazione durante l’attivazione della fotocamera. Occorre quindi utilizzare la classe CameraCaptureTask definendola a livello di pagina, istanziarla nel costruttore abbonandosi al relativo evento di completamento, e definire un event han-dler. Possiamo anche utilizzare, come nell’esempio di codice seguente, lo stesso event handler utilizzato per il Photo Chooser; il risultato sarà infatti identico: una immagine di tipo System.IO.Stream da “conver-

Fig.7: La sequenza per il completamento del PhotoChooserTask



fica il risultato, affermativo se l’utente ha salvato il contatto e negativo se l’utente ha annullato l’ope-razione, e visualizza semplicemente un messaggio.Il flusso completo di aggiunta di un contatto, e salvataggio del contatto stesso è mostrato in Fig. 5 nella quale, per ragioni di spazio, non ho mostra-to l’aggiunta del nome, della foto e i messaggi Deactivate/Activate. Per ritornare all’applicazione l’utente deve premere il pulsante Back.Analogamente possiamo salvare un indirizzo

email tramite la classe SaveEmailAddressTask: il comportamento e il codice, nome della classe e relativo evento di completamento a parte, è asso-lutamente identico.Oltre all’operazione di inserimento/aggiornamen-to di un contatto, una applicazione può anche recuperare numero di telefono e/o indirizzo di email di un contatto tramite alcuni componenti denominati Chooser: il termine Chooser deriva dal fatto che il componente consente, appunto, di scegliere “qualcosa” dal telefono per restituirlo all’applicazione. Come per le Task precedenti, quando viene invo-cato un Chooser, l’applicazione viene disattivata, viene aperta la relativa applicazione e, solo quan-do l’utente ha effettuato la scelta o ha annullato la selezione, il controllo ritorna all’applicazione.Il codice per attivare il Chooser per recuperare un numero di telefono è il seguente:

using System;


using System.Linq;

using System.Net;









using Microsoft.Phone.Tasks;

namespace ThinkAhead.PhoneAPI

{


{

private PhoneNumberChooserTask _phoneNum

berChooserTask;

public MainPage()

{






sk_Completed);

}

private void readNumberButton_Click(object


{

this._phoneNumberChooserTask.Show();

}

void phoneNumberChooserTask_Completed(object

sender, PhoneNumberResult e)

{


{

resultTextBlock.Text = e.PhoneNumber;

}

}

}

}

Dopo aver definito l’oggetto PhoneNumberChooser Task, il costruttore crea una istanza e si abbona al relativo evento. Nell’event handle è possibile sapere se l’utente ha effettuato la scelta control-lando la proprietà TaskResult: in caso affermativo,

Fig.5: I passaggi del SavePhoneNumberTask

Fig.6: Le tre fasi necessarie al completamento del PhoneNumberChooserTask

NOTA

USER INTERFACESpesso lo sviluppatore sot-tovaluta molti degli aspetti legati alla userinterface e alla userexperience: non intendiamo dire che non sia in grado di costruire userinterface carine o accattivanti, ma che sot-tovaluti l’importanza di aderire alle linee guida della piattaforma. Su una interfaccia di dimensioni ridotte e su un dispositivo che fa della userexperien-ce un suo punto di forza è fondamentale rispettare le linee guida: vi consigliamo caldamente di leggere la “UI Design &Interaction Guide” che trovate a parti-re dalla home page per gli sviluppatori http://develo-per.windowsphone.com/windows-phone-7/.




esperienza più personalizzata per riprodurre contenuti: è sufficiente inserire un controllo MediaElement all’interno dell’applicazione per riprodurre contenuti direttamente all’interno del controllo. Il controllo MediaElement può essere posizionato all’interno di altri controlli per fornire l’interfaccia desiderata: nell’esem-pio seguente abbiamo inserito il controllo in un Border ruotato di qualche grado in modo da darvi l’idea senza complicare l’esempio.

<Border>

<Border.RenderTransform>

<RotateTransform Angle=”32”

CenterY=”150” />

</Border.RenderTransform>

<MediaElement Height=”166”

HorizontalAlignment=

”Left” Margin=”34,33,0,0”

Name=”mediaElement”

VerticalAlignment=”Top”

Width=”401”

Source=”TA.wmv” >

</MediaElement>

</Border>

Il risultato, senza grandi pretese estetiche, è visi-bile nella Fig. 10. La terza modalità, che analiz-zeremo meglio in un articolo dedicato, consiste nell’inserire la propria applicazione nel “Music + Video Hub”: questo componente è il punto cen-tralizzato per gestire musica e video sul device. Le applicazioni integrate possono, anzi, devono, utilizzare le classi MediaHistory e MediaHistoryItem gestire la storia dei brani ascol-tati in modo da fornire all’utente una esperienza consistente con le altre applicazioni musicali integrate.

LA RADIO FMUna feature non troppo conosciuta consiste nella possibilità di controllare la radio del tele-fono. Ad esempio, il codice seguente accende e spegne la radio alla pressione del pulsante relativo:

private void radioButton_Click(object sender,

RoutedEventArgs e)

{

FMRadio radio = FMRadio.Instance;

radio.CurrentRegion = RadioRegion.Europe;

radio.Frequency = 102.50;

if (radio.PowerMode == RadioPowerMode.Off)

radio.PowerMode = RadioPowerMode.On;

else

radio.PowerMode = RadioPowerMode.Off;

}

IL CONTROLLO PER LE RICERCHEUn componente particolarmente utile nelle applica-zioni che consentono all’utente di ricercare termini, immagini e informazioni è il launcher del servizio di ricerca, che, dietro le quinte, sfrutta il motore di Bing per la ricerca. L’utente ha sempre a disposi-zione il pulsante Search del telefono, ma applica-tivamente è possibile guidare la ricerca partendo dall’applicazione. Il codice è autoesplicativo:

private void searchButton_Click(object sender,

RoutedEventArgs e)

{

SearchTask searchTask = new SearchTask();

searchTask.SearchQuery = “ThinkAhead

Firenze”;

searchTask.Show();

}

Il risultato è visibile nella Fig.11:

Fig.10: Il controllo MediaElement

Fig.11: SearchTask attivato



tire” in immagine sullo pagina applicativa.Ovviamente, alla pressione del pulsante occorre invocare il metodo Show del Task.

private CameraCaptureTask _cameraCaptureTask;

public MainPage()

{


this. _cameraCaptureTask = new

CameraCaptureTask ();

this._ _cameraCaptureTask.Completed += new


private void shotButton_Click(object sender,

RoutedEventArgs e)

{

this._cameraCaptureTask.Show();

}

Questo screenshot richiede due righe di spiegazio-ne: come si nota, nella prima e seconda immagine non si vede nessuna foto, mentre nella terza, ovve-ro nella pagina che visualizza lo “scatto”, appare uno sfondo bianco con un quadratino nero. Vi invitiamo a provare l’esempio per capire meglio il funzionamento della fotocamera simulata. Durante l’attivazione della fotocamera, l’emulatore “muove” un rettangolo nero su sfondo bianco in modo da simulare l’immagine inquadrata dal finto obiettivo. Alla pressione del pulsante di scatto, quello in alto a destra, per un attimo si nota l’immagine scattata, che è composta di un rettangolo nero nella posizio-ne in cui è stato premuto il pulsante di scatto.

MEDIA PLAYERLe applicazioni che fanno uso di contenuti multi-mediali possono interagire con le feature del tele-fono in tre modalità. La prima è invocare il task per l’attivazione del Media Player, che, come abbiamo imparato in questo articolo, “prenderà il controllo” del telefono fino a quando l’utente non preme Back per tornare sull’applicazione. Il codice per attivare il media player dall’applicazio-ne è il seguente:

private void mediaPlayerButton_Click(object


{

MediaPlayerLauncher mediaPlayerLauncher =

new MediaPlayerLauncher();

mediaPlayerLauncher.Controls =

MediaPlaybackControls.All;

mediaPlayerLauncher.Media = new Uri(“

http://mschannel9.vo.msecnd.net/

o9/mix/09/wmv/

key01.wmv”, UriKind.Absolute);

// Se contenuti nello XAP

//mediaPlayerLauncher.Location =

MediaLocationType.Install;

mediaPlayerLauncher.Show();

}

Dopo aver instanziato il Launcher, ovvero il task che attiva il Media Player del device, disattivando (ed eventualmente terminando la nostra applicazione), possiamo decidere quali controlli visualizzare. La proprietà Media indica al Media Player il path com-pleto verso il video che, come nell’esempio di codice precedente può essere recuperato via http, oppure il path può puntare ad un video in locale. La proprietà, di tipo Uri, può essere relativa o asso-luta come da tradizione. Nel caso che il video sia locale è possibile utilizzare la riga che assegna la proprietà Location per indicare al Media Player se il video è fornito con l’installazione oppure è un video salvato precedentemente nell’Isolated Storage del device.Il Media Player, attivato dall’applicazione, si presen-ta esattamente come se fosse stato aperto dall’inter-faccia del telefono: si faccia riferimento alla Fig. 9.La seconda modalità consente di fornire una

Fig.8: Le tre schermate del CameraCaptureTask

Fig.9: Ecco il risultato del MediaPlayerLauncher




private void marketplaceSearchTaskButton_

Click(object sender, RoutedEventArgs e)

{

MarketplaceSearchTask marketplaceSearchTask

= new MarketplaceSearchTask();

marketplaceSearchTask.SearchTerms = “thin

kahead”;

marketplaceSearchTask.ContentType =

MarketplaceContentType.Applications;

marketplaceSearchTask.Show();

}

Il risultato della ricerca, sul marketplace beta, disponibile alla scrittura di questo articolo (18 settembre 2010) lo potete vedere in Fig.13:Tenete presente che l’immagine e l’interazione sul Marketplace non è definitiva ed è inserita nell’articolo a scopo illustrativo. Le due appli-cazioni mostrate sono reali e di nostra pro-prietà, ma il contesto in cui sono elencate, può cambiare nel tempo.Una applicazione può richiedere altre tre ope-razioni sul Marketplace: la prima, Marketplace DetailTask consente di aprire il dettaglio di un contenuto, sia esse un brano musicale, sia

esso una applicazione: è sufficiente passare il ContentIdentifier per attivare la task. Il codice è il seguente:

MarketplaceDetailTask marketplaceDetailTask = new

MarketplaceDetailTask();

// Default su Application

marketplaceDetailTask.ContentIdentifier = “<ID>”;

marketplaceDetailTask.Show();

// Alternativa per contenuti musicali



marketplaceDetailTask.ContentType =

MarketplaceContentType.Music;



La seconda operazione riguarda la richiesta di utilizzo dell’applicazione client denomina-ta Marketplace hub tramite la relativa classe MarketplaceHubTask. È sufficiente impostare il tipo di contenuto e invocare il metodo Show:

MarketplaceHubTask marketplaceHubTask = new

MarketplaceHubTask();

marketplaceHubTask.ContentType =


marketplaceHubTask.Show();

La terza e ultima operazione, almeno nella ver-sione RTM degli strumenti di sviluppo, è la possibilità di attivare l’applicazione client sulla pagina della revisione dell’applicazione corren-te in modo da consentire all’utente. Il codice è autodescrittivo:

MarketplaceReviewTask marketplaceReviewTask = new

MarketplaceReviewTask();

marketplaceReviewTask.Show();

Una applicazione può interagire con Accelerometro, Location Service ovvero il servizio di posiziona-mento via GPS, Wi-Fi o Cellulare e, non ultimo i canali Push per l’invio di notifiche al client. Vista la complessità dell’argomento, tratteremo le API relative ai tre servizi in un articolo dedicato.Alla prossima

Roberto Brunetti e Luca RegnicoliFig.13: Ed ecco il MarketplaceTask



cializzato nella definizione della user interface, mentre Roberto si dedica all’archi-

tettura e prestazioni della soluzione. La loro azienda,

we.ThinkAhead.it, socie-tà del gruppo DevLeap, è

specializzata nella realiz-zazione di soluzioni cloud-based su Windows Azure,

applicazioni WPF/Silverlight e applicazioni mobile sia per Windows Mobile 6.5

che per Windows Phone 7. Sul sito si trovano i riferi-

menti ai progetti e alle aree tecnologiche coperte.

GLI AUTORI



WEB BROWSERLe applicazioni che fanno uso di contenuti informativi reperiti attraverso internet, pos-sono sfruttare il controllo Web Browser diret-tamente all’interno delle pagine applicative. Il controllo, come da tradizione, può essere pilotato da codice oppure può essere configu-rato nel codice XAML. Un esempio di codice è il seguente:

private void goButton_Click(object sender,

RoutedEventArgs e)

{

webBrowser1.Navigate(new Uri(“http://

we.thinkahead.it”));

}

Alla pressione del pulsante, il controllo deno-minato WebBrowser1, già inserito e configura-to, viene “fatto navigare” verso un sito web.In questo caso, come abbiamo visto per il MediaElement, l’utente rimane nell’applicazio-ne e ottiene una esperienza di utilizzo consi-stente con l’applicazione stessa, come si nota dalla figura seguente:In alternativa è possibile attivare il task WebBrowserTask per lanciare l’esperienza con-sistente con il resto del telefono. Se vi sembra che abbia usato troppe volte il termine espe-rienza, probabilmente avete assolutamente ragione, ma volevo stressare uno dei concetti base di Windows Phone 7. Per chi non ha letto l’articolo di copertina del numero precedente, con il termine user experience, da qualche anno, si fa riferimento proprio all’esperienza che l’utente vive durante l’utilizzo di un prodotto software. La user interface è una delle compo-nenti più importanti della user experience, e non è un suo sinonimo. Da Wikipedia, la user experience (UX) riguarda il feeling dell’utente con un sistema e comprende l’esperienza, l’af-fetto, il significato e il valore dell’interazione uomo-macchina e della proprietà del prodotto stesso; inoltre, la percezione degli aspetti prati-ci e dell’efficienza fanno parte dell’esperienza dell’utente. Il termine è usato abbondante-mente in tutta la documentazione di Windows Phone 7 dove si trova, ad esempio, la frase “far partire una nuova esperienza per l’utente” intendendo la partenza di una applicazione.Torniamo agli aspetti tecnici: il codice per attivare il task di apertura del browser è il seguente.

private void webBrowserTaskButton_Click(object


{

WebBrowserTask webBrowserTask = new

WebBrowserTask();

webBrowserTask.URL = “http://we.thinkahead.

it”;

webBrowserTask.Show();

}

Il risultato è una finestra di Internet Explorer aperta sull’indirizzo indicato. Ricordatevi che, anche in questo caso, l’applicazione viene disattivata per essere riattivata solo e se l’utente preme Back fino a tornare alla nostra applica-zione.

IL MARKETPLACEUna applicazione può utilizzare il marketpla-ce in varie modalità. Il marketplace verrà poi trattato in un articolo separato. Ad esempio un’applicazione può attivare un task di ricerca di applicazioni o musica in base ad un criterio di ricerca testuale:

Fig.12: Il controllo WebBrowser in azione

USER EXPERIENCECon la locuzione user experience, da qualche anno, si fa riferimento proprio all’esperienza che l’utente vive durante l’utilizzo di un prodotto software. La user interface è una delle componenti più importanti della user experience e non è un suo sinonimo. La userexperien-ce (UX) riguarda il feeling dell’utente con un sistema e comprende l’esperienza, l’affetto, il significato e il valore dell’interazione uomo-macchina e della proprietà del prodotto stesso; inoltre, la perce-zione degli aspetti pratici e dell’efficienza fanno parte dell’esperienza dell’utente.

NOTA




private void marketplaceSearchTaskButton_

Click(object sender, RoutedEventArgs e)

{

MarketplaceSearchTask marketplaceSearchTask

= new MarketplaceSearchTask();

marketplaceSearchTask.SearchTerms = “thin

kahead”;

marketplaceSearchTask.ContentType =

MarketplaceContentType.Applications;

marketplaceSearchTask.Show();

}

Il risultato della ricerca, sul marketplace beta, disponibile alla scrittura di questo articolo (18 settembre 2010) lo potete vedere in Fig.13:Tenete presente che l’immagine e l’interazione sul Marketplace non è definitiva ed è inserita nell’articolo a scopo illustrativo. Le due appli-cazioni mostrate sono reali e di nostra pro-prietà, ma il contesto in cui sono elencate, può cambiare nel tempo.Una applicazione può richiedere altre tre ope-razioni sul Marketplace: la prima, Marketplace DetailTask consente di aprire il dettaglio di un contenuto, sia esse un brano musicale, sia

esso una applicazione: è sufficiente passare il ContentIdentifier per attivare la task. Il codice è il seguente:



// Default su Application



// Alternativa per contenuti musicali



marketplaceDetailTask.ContentType =




La seconda operazione riguarda la richiesta di utilizzo dell’applicazione client denomina-ta Marketplace hub tramite la relativa classe MarketplaceHubTask. È sufficiente impostare il tipo di contenuto e invocare il metodo Show:

MarketplaceHubTask marketplaceHubTask = new

MarketplaceHubTask();

marketplaceHubTask.ContentType =


marketplaceHubTask.Show();

La terza e ultima operazione, almeno nella ver-sione RTM degli strumenti di sviluppo, è la possibilità di attivare l’applicazione client sulla pagina della revisione dell’applicazione corren-te in modo da consentire all’utente. Il codice è autodescrittivo:

MarketplaceReviewTask marketplaceReviewTask = new

MarketplaceReviewTask();

marketplaceReviewTask.Show();

Una applicazione può interagire con Accelerometro, Location Service ovvero il servizio di posiziona-mento via GPS, Wi-Fi o Cellulare e, non ultimo i canali Push per l’invio di notifiche al client. Vista la complessità dell’argomento, tratteremo le API relative ai tre servizi in un articolo dedicato.Alla prossima

Roberto Brunetti e Luca RegnicoliFig.13: Ed ecco il MarketplaceTask



cializzato nella definizione della user interface, mentre Roberto si dedica all’archi-

tettura e prestazioni della soluzione. La loro azienda,

we.ThinkAhead.it, socie-tà del gruppo DevLeap, è

specializzata nella realiz-zazione di soluzioni cloud-based su Windows Azure,

applicazioni WPF/Silverlight e applicazioni mobile sia per Windows Mobile 6.5

che per Windows Phone 7. Sul sito si trovano i riferi-

menti ai progetti e alle aree tecnologiche coperte.

GLI AUTORI



WEB BROWSERLe applicazioni che fanno uso di contenuti informativi reperiti attraverso internet, pos-sono sfruttare il controllo Web Browser diret-tamente all’interno delle pagine applicative. Il controllo, come da tradizione, può essere pilotato da codice oppure può essere configu-rato nel codice XAML. Un esempio di codice è il seguente:

private void goButton_Click(object sender,

RoutedEventArgs e)

{

webBrowser1.Navigate(new Uri(“http://

we.thinkahead.it”));

}

Alla pressione del pulsante, il controllo deno-minato WebBrowser1, già inserito e configura-to, viene “fatto navigare” verso un sito web.In questo caso, come abbiamo visto per il MediaElement, l’utente rimane nell’applicazio-ne e ottiene una esperienza di utilizzo consi-stente con l’applicazione stessa, come si nota dalla figura seguente:In alternativa è possibile attivare il task WebBrowserTask per lanciare l’esperienza con-sistente con il resto del telefono. Se vi sembra che abbia usato troppe volte il termine espe-rienza, probabilmente avete assolutamente ragione, ma volevo stressare uno dei concetti base di Windows Phone 7. Per chi non ha letto l’articolo di copertina del numero precedente, con il termine user experience, da qualche anno, si fa riferimento proprio all’esperienza che l’utente vive durante l’utilizzo di un prodotto software. La user interface è una delle compo-nenti più importanti della user experience, e non è un suo sinonimo. Da Wikipedia, la user experience (UX) riguarda il feeling dell’utente con un sistema e comprende l’esperienza, l’af-fetto, il significato e il valore dell’interazione uomo-macchina e della proprietà del prodotto stesso; inoltre, la percezione degli aspetti prati-ci e dell’efficienza fanno parte dell’esperienza dell’utente. Il termine è usato abbondante-mente in tutta la documentazione di Windows Phone 7 dove si trova, ad esempio, la frase “far partire una nuova esperienza per l’utente” intendendo la partenza di una applicazione.Torniamo agli aspetti tecnici: il codice per attivare il task di apertura del browser è il seguente.

private void webBrowserTaskButton_Click(object


{

WebBrowserTask webBrowserTask = new

WebBrowserTask();

webBrowserTask.URL = “http://we.thinkahead.

it”;

webBrowserTask.Show();

}

Il risultato è una finestra di Internet Explorer aperta sull’indirizzo indicato. Ricordatevi che, anche in questo caso, l’applicazione viene disattivata per essere riattivata solo e se l’utente preme Back fino a tornare alla nostra applica-zione.

IL MARKETPLACEUna applicazione può utilizzare il marketpla-ce in varie modalità. Il marketplace verrà poi trattato in un articolo separato. Ad esempio un’applicazione può attivare un task di ricerca di applicazioni o musica in base ad un criterio di ricerca testuale:

Fig.12: Il controllo WebBrowser in azione

USER EXPERIENCECon la locuzione user experience, da qualche anno, si fa riferimento proprio all’esperienza che l’utente vive durante l’utilizzo di un prodotto software. La user interface è una delle componenti più importanti della user experience e non è un suo sinonimo. La userexperien-ce (UX) riguarda il feeling dell’utente con un sistema e comprende l’esperienza, l’affetto, il significato e il valore dell’interazione uomo-macchina e della proprietà del prodotto stesso; inoltre, la perce-zione degli aspetti pratici e dell’efficienza fanno parte dell’esperienza dell’utente.

NOTA

Windows Phone 7 programming IL TELEFONO “LEGGE” I TUOI MOVIMENTI MOBILEL’accelerometro di Windows Phone 7

Dicembre 2010 / 49 http://www.ioprogrammo.it

ad esempio la nostra scrivania, l’accelerometro rivela comunque una accelerazione verticale.Ogni dispositivo Windows Phone 7 ha almeno un sensore di accelerazione a bordo. Il sensore viene “ascoltato” da una semplice API che può fornire ad una applicazione i dati sulle forze che governano il device. Visto che spesso una applicazione viene testata sull’emulatore, vedremo, dopo aver capito bene come il nostro codice può “sentire” queste forze, la costruzionee di un simulatore di accele-rometro che senta gli spostamenti del mouse del personal computer. È ovvio che poi andranno fatte prove reali su un device per calibrare bene il codice rispetto ai dati che le API forniscono.La classe esposta alle applicazioni Silverlight e XNA è inclusa nella piattaforma quindi è sufficiente refe-renziare il relativo assembly senza dover distribuire librerie aggiuntive.Nella versione finale degli strumenti di sviluppo le API disponibili sono evidenziate in Fig.2. La freccia in Fig.2 indica la libreria che contiene le seguenti classi direttamente collegate con l’accelerometro:

namespace Microsoft.Devices.Sensors

{

public sealed class Accelerometer : IDisposable

public class AccelerometerFailedException : Exception

[StructLayout(LayoutKind.Sequential)]

internal struct AccelerometerNativeSample

public class AccelerometerReadingEventArgs :

EventArgs

[SecurityCritical]

internal static class NativeMethods

public enum SensorState

internal static class TimeUtil

}

Come si può immaginare, la classe Accelerometer rappresenta l’accelerometro, l’eccezione AccelerometerFailedException ci consente di intercettare le eccezioni relative al suo fun-zionamento, l’enum SensorState indicherà lo stato del sensore dell’accelerometro, e la classe AccelerometerReadingEventArgs contiene le infor-mazioni sulle forze di accelerazione che il sensore rileva. Vediamo subito un esempio di codice che attiva e spegne l’accelerometro per poi tornare a introdurre alcuni concetti teorici importanti alla comprensione del codice successivo.

PRIMI PASSI NEL PROGETTOPer iniziare con il nostro esempio, occorre creare un progetto Silverlight per Windows Phone 7 il cui tem-plate diventa disponibile dopo l’installazione degli strumenti di sviluppo. Al progetto Visual Studio

andremo ad aggiungere una reference all’assembly indicato in modo che il progetto stesso si presenti come in Fig. 3.

All’interno del form principale inseriamo una TextBlock che verrà pilotata da codice per mostra-re le informazioni di stato dell’accelerometro e due pulsanti per avviare e fermare l’accelerometro stesso. Nel prosieguo dell’articolo visualizzeremo anche tre informazioni che rappresentano le forze di accelerazione “captate” dal sensore: inseriamo da subito, quindi, altre tre TextBlock aldl’interno della griglia assegnando il ralativo name a XText, YText e ZText. In pratica il codice della pagina principale (MainPage.xaml) si presenta così all’interno della griglia proposta per default:



<Grid.RowDefinitions>

<RowDefinition Height=”Auto”/>

<RowDefinition Height=”*”/>

</Grid.RowDefinitions>

<Grid x:Name=”TitleGrid” Grid.Row=”0”>

<TextBlock Text=”ThinkAhead &

Pialorsi Sistemi” x:Name=”textBlockPageTitle”


<TextBlock Text=”Accelerometer”

x:Name=”textBlockListTitle” Style=”{StaticResource


</Grid>



<Grid x:Name=”ContentGrid” Grid.Row=”1”>

<Button Content=”Start” Height=”70”

Fig.3: I reference necessari alla nostra solution

MARKETPLACEAl momento in cui questo articolo arriverà in edicola, il marketplace sarà ufficial-mente aperto. Sarà possi-bile pubblicare applicazioni aprendo una sottoscrizio-ne. Ogni sottoscrizione aziendale o privata (gli studenti hanno particolari privilegi) consente di pub-blicare un numero illimitato di applicazioni a pagamen-to e fino ad un massimo di 5 applicazioni gratuite. È possibile inoltre pubbli-care applicazioni in versio-ne trial così come utilizzare il Microsoft Advertising SDK per inserire banner pubblicitari dentro le appli-cazioni ricevendo una fee corrispondente.

NOTA

MOBILE L’accelerometro di Windows Phone 7

http://www.ioprogrammo.it 48 / Dicembre 2010

Questo articolo introduce le API che consen-tono di lavorare con una importante fun-zionalità hardware e software di Windows

Phone 7: l’accelerometro. Come per gli articoli precedenti, il testo sarà accompagnato dal codice per dimostrare in pratica come utilizzare delle classi e il relativo risultato. Ricordo che gli strumenti di sviluppo in versione finale si possono scaricare gra-tuitamente da http://developer.windowsphone.com.Prima di iniziare è bene ricordare che Windows Phone 7 consente allo sviluppatore di realizzare applicazioni Silverlight e applicazioni XNA. In que-sti esempi utilizzeremo Silverlight per interagire con le classi esposte dalla piattaforma, ma, il codice per utilizzare l’accelerometro risulta identico: sarà invece profondamente diverso il codice di gestione dell’applicazione.Le relative classi si appoggiano alla sandbox in cui viene fatto girare il codice del .NET Framework (più precisamente del .NET Compact Framework). La Fig. seguente mostra lo schema architetturale:

COME FUNZIONA L’ACCELEROMETROIl termine accelerometro è stato utilizzato in modo improprio in molti blog e articoli su internet, quindi prima di vedere all’opera il sensore, di simularne il comportamento su un personal computer e analiz-

zarne le relative API, dobbiamo spendere qualche riga per capire bene il suo funzionamento.Un accelerometro è un sensore che misura le forze di accelerazione: una forza di accelerazione può essere rappresentata dal movimento di un device con a bordo un accelerometro, ma il punto fonda-mentale è rappresentato dal fatto che l’accelerome-tro non misura lo spostamento in quanto tale, ma la forza di accelerazione dello spostamento stesso. Una seconda forza di accelerazione è rappresentata semplicemente dalla forza di gravità terrestre: que-sto significa che l’accelerometro “sente” sempre una accelerazione quando viene usato sul nostro pianeta; anche se il device è tenuto saldamente in una mano oppure è appoggiato su un piano, come

REQUISITI



Impegno


IL TELEFONO “LEGGE” I TUOI MOVIMENTIIN QUESTO ARTICOLO CI CONCENTRIAMO SULLE LIBRERIE NATIVE CHE CONSENTONO DI INTERAGIRE CON L’ACCELEROMETRO. REALIZZAREMO UN PROGETTO PER APPROFITTARE DELLA ECCELLENTE INTERAZIONE CON IL MONDO REALE OFFERTA DA WINDOWS PHONE 7

❑ CD ❑ WEBDemo.zip


Fig.1: I diversi layer della piattaforma”

Fig.2: L’Assembly di riferimento per questo articolo

Windows Phone 7 programmingIL TELEFONO “LEGGE” I TUOI MOVIMENTI MOBILEL’accelerometro di Windows Phone 7


ad esempio la nostra scrivania, l’accelerometro rivela comunque una accelerazione verticale.Ogni dispositivo Windows Phone 7 ha almeno un sensore di accelerazione a bordo. Il sensore viene “ascoltato” da una semplice API che può fornire ad una applicazione i dati sulle forze che governano il device. Visto che spesso una applicazione viene testata sull’emulatore, vedremo, dopo aver capito bene come il nostro codice può “sentire” queste forze, la costruzionee di un simulatore di accele-rometro che senta gli spostamenti del mouse del personal computer. È ovvio che poi andranno fatte prove reali su un device per calibrare bene il codice rispetto ai dati che le API forniscono.La classe esposta alle applicazioni Silverlight e XNA è inclusa nella piattaforma quindi è sufficiente refe-renziare il relativo assembly senza dover distribuire librerie aggiuntive.Nella versione finale degli strumenti di sviluppo le API disponibili sono evidenziate in Fig.2. La freccia in Fig.2 indica la libreria che contiene le seguenti classi direttamente collegate con l’accelerometro:

namespace Microsoft.Devices.Sensors

{

public sealed class Accelerometer : IDisposable

public class AccelerometerFailedException : Exception

[StructLayout(LayoutKind.Sequential)]

internal struct AccelerometerNativeSample

public class AccelerometerReadingEventArgs :

EventArgs

[SecurityCritical]

internal static class NativeMethods

public enum SensorState

internal static class TimeUtil

}

Come si può immaginare, la classe Accelerometer rappresenta l’accelerometro, l’eccezione AccelerometerFailedException ci consente di intercettare le eccezioni relative al suo fun-zionamento, l’enum SensorState indicherà lo stato del sensore dell’accelerometro, e la classe AccelerometerReadingEventArgs contiene le infor-mazioni sulle forze di accelerazione che il sensore rileva. Vediamo subito un esempio di codice che attiva e spegne l’accelerometro per poi tornare a introdurre alcuni concetti teorici importanti alla comprensione del codice successivo.

PRIMI PASSI NEL PROGETTOPer iniziare con il nostro esempio, occorre creare un progetto Silverlight per Windows Phone 7 il cui tem-plate diventa disponibile dopo l’installazione degli strumenti di sviluppo. Al progetto Visual Studio

andremo ad aggiungere una reference all’assembly indicato in modo che il progetto stesso si presenti come in Fig. 3.

All’interno del form principale inseriamo una TextBlock che verrà pilotata da codice per mostra-re le informazioni di stato dell’accelerometro e due pulsanti per avviare e fermare l’accelerometro stesso. Nel prosieguo dell’articolo visualizzeremo anche tre informazioni che rappresentano le forze di accelerazione “captate” dal sensore: inseriamo da subito, quindi, altre tre TextBlock aldl’interno della griglia assegnando il ralativo name a XText, YText e ZText. In pratica il codice della pagina principale (MainPage.xaml) si presenta così all’interno della griglia proposta per default:



<Grid.RowDefinitions>

<RowDefinition Height=”Auto”/>

<RowDefinition Height=”*”/>

</Grid.RowDefinitions>

<Grid x:Name=”TitleGrid” Grid.Row=”0”>

<TextBlock Text=”ThinkAhead &

Pialorsi Sistemi” x:Name=”textBlockPageTitle”


<TextBlock Text=”Accelerometer”

x:Name=”textBlockListTitle” Style=”{StaticResource


</Grid>



<Grid x:Name=”ContentGrid” Grid.Row=”1”>

<Button Content=”Start” Height=”70”

Fig.3: I reference necessari alla nostra solution

MARKETPLACEAl momento in cui questo articolo arriverà in edicola, il marketplace sarà ufficial-mente aperto. Sarà possi-bile pubblicare applicazioni aprendo una sottoscrizio-ne. Ogni sottoscrizione aziendale o privata (gli studenti hanno particolari privilegi) consente di pub-blicare un numero illimitato di applicazioni a pagamen-to e fino ad un massimo di 5 applicazioni gratuite. È possibile inoltre pubbli-care applicazioni in versio-ne trial così come utilizzare il Microsoft Advertising SDK per inserire banner pubblicitari dentro le appli-cazioni ricevendo una fee corrispondente.

NOTA



Questo articolo introduce le API che consen-tono di lavorare con una importante fun-zionalità hardware e software di Windows

Phone 7: l’accelerometro. Come per gli articoli precedenti, il testo sarà accompagnato dal codice per dimostrare in pratica come utilizzare delle classi e il relativo risultato. Ricordo che gli strumenti di sviluppo in versione finale si possono scaricare gra-tuitamente da http://developer.windowsphone.com.Prima di iniziare è bene ricordare che Windows Phone 7 consente allo sviluppatore di realizzare applicazioni Silverlight e applicazioni XNA. In que-sti esempi utilizzeremo Silverlight per interagire con le classi esposte dalla piattaforma, ma, il codice per utilizzare l’accelerometro risulta identico: sarà invece profondamente diverso il codice di gestione dell’applicazione.Le relative classi si appoggiano alla sandbox in cui viene fatto girare il codice del .NET Framework (più precisamente del .NET Compact Framework). La Fig. seguente mostra lo schema architetturale:

COME FUNZIONA L’ACCELEROMETROIl termine accelerometro è stato utilizzato in modo improprio in molti blog e articoli su internet, quindi prima di vedere all’opera il sensore, di simularne il comportamento su un personal computer e analiz-

zarne le relative API, dobbiamo spendere qualche riga per capire bene il suo funzionamento.Un accelerometro è un sensore che misura le forze di accelerazione: una forza di accelerazione può essere rappresentata dal movimento di un device con a bordo un accelerometro, ma il punto fonda-mentale è rappresentato dal fatto che l’accelerome-tro non misura lo spostamento in quanto tale, ma la forza di accelerazione dello spostamento stesso. Una seconda forza di accelerazione è rappresentata semplicemente dalla forza di gravità terrestre: que-sto significa che l’accelerometro “sente” sempre una accelerazione quando viene usato sul nostro pianeta; anche se il device è tenuto saldamente in una mano oppure è appoggiato su un piano, come

REQUISITI



Impegno


IL TELEFONO “LEGGE” I TUOI MOVIMENTIIN QUESTO ARTICOLO CI CONCENTRIAMO SULLE LIBRERIE NATIVE CHE CONSENTONO DI INTERAGIRE CON L’ACCELEROMETRO. REALIZZAREMO UN PROGETTO PER APPROFITTARE DELLA ECCELLENTE INTERAZIONE CON IL MONDO REALE OFFERTA DA WINDOWS PHONE 7

❑ CD ❑ WEBDemo.zip


Fig.1: I diversi layer della piattaforma”

Fig.2: L’Assembly di riferimento per questo articolo




[CompilerGenerated] get; [CompilerGenerated] private

set; }

public double X { get; }

public double Y { get; }

public double Z { get; }

}

La proprietà Timestamp fornisce l’offset temporale (sotto forma di DateTimeOffset) ovvero indica il momento in cui è stata presa la rilevazione sul sen-sore, mentre X,Y,Z sono i valori che rappresentano la forza di accelerazione sui vari assi.È bene rimarcare che questi tre valori non rappre-sentano lo spostamento sull’asse X, Y o Z, ma la forza di accelerazione percepita dal device sui tre assi. I valori di queste tre proprietà che riceviamo negli argomenti del nostro metodo rappresentano infatti valori di tipo double che indicano la direzione dell’accelerazione per ogni asse in unità gravitazio-nali comprese fra -2 e 2. In pratica se riceviamo il valore 1 nell’asse X vuol dire che il device ha sentito una forza gravitazionale pari a 1 ovvero l’utente ha spostato il telefono verso sinistra imprimendo una forza pari a 1. Se invece riceviamo un valore pari a -1, l’utente ha spostato il telefono con la stessa forza dell’esempio precedente, ma spostando il device verso destra.L’asse Y lavora sull’asse terrestre, ovvero “sente” l’accelerazione in avanti e indietro, mentre l’asse Z lavora sull’asse verticale ovvero “sente” l’accelera-zione verso l’alto o verso il basso. Provando l’esem-pio sull’emulatore, il valore di Z sarà -1 in quanto rappresenta la forza di gravità.Se l’utente gira il telefono con lo schermo verso il basso, gli assi restano immutati ma i valori ricevuti dovranno essere letti al contrario: un valore di -1 sull’asse X rappresenta una accelerazione sul movi-mento verso sinistra. Il codice che visualizza i valori delle forze e, se avete un device sotto mano, dimostra anche il compor-tamento del sensore, è molto semplice come si nota nell’estratto seguente. L’unica complessità, ben nota a chi ha lavorato con WPF, Silverlight, Windows Forms è la necessità di richiedere al thre-ad principale, l’owner dei controlli, l’esecuzione delle operazioni di assegnazione. Questa necessità deriva dal fatto che l’accelero-metro richiama da un thread secondario il meto-do indicato per ricevere l’evento di segnalazione dell’accelerazione captata dal sensore.

void accelerometer_ReadingChanged(object

sender, AccelerometerReadingEventArgs e)

{

Deployment.Current.Dispatcher.BeginInvoke(()

=>

{

this.statusText.Text = this.accelerometer.

State.ToString();

this.TimeStampText.Text = e.Timestamp.

ToString();

this.XText.Text = e.X.ToString();

this.YText.Text = e.Y.ToString();

this.ZText.Text = e.Z.ToString();

});

}

Il metodo BeginInvoke esposto dal Dispatcher e recuperato dal contesto di deploy corrente consen-te di eseguire l’operazione sul thread principale. Il metodo anonimo, rappresentato dalla lambda expression (caratteristica di C# 3.0 – 2008) inserisce nelle tre TextBlock della pagina principale i valo-ri del sensore. La prima riga di codice utilizza la proprietà State per visualizzare lo stato del sensore (Ready quando è stato avviato ed è pronto a lavo-rare), mentre la seconda riga di codice recupera il timestamp che indica il momento della rilevazione.Come si nota il valore della proprietà Y è -1 in quan-to l’emulatore, essendo fermo, rileva solo la forza di gravità terrestre che, in condizioni stabili, a livello del mare, e su un parallelo medio, è, appunto è 1G negativo.Lo stesso codice, lanciato su un device reale, pro-duce, con il device appoggiato sul tavolo, il risultato di Fig.6. Alla prima esecuzione, il comportamento solimente sembra ancora strano: visto che il device è appoggiato su un tavolo non dovrebbe subire nes-suno spostamento; il device in effetti non subisce nessuno spostamento in quanto è ben appoggiato sulla superficie, ma le forze gravitazionali agiscono su di esso sui vari assi e possono variare se il device si trova su una montagna oppure a livello del mare, su un parallelo vicino all’equatore oppure più vicino ai poli. Ricordate, inoltre, che la Terra ruota, come disse qualcuno quando ancora Windows Phone 7

Fig.4: Rappresentazione visuale degli assi X, Y, Z

NOTA

USER EXPERIENCECon user experience si fa riferimento proprio all’esperienza che l’utente vive durante l’utilizzo di un prodotto software. La user interface è una delle componenti più importanti della user experience, e non è un suo sinonimo. Da Wikipedia, la user experience (UX) riguarda il feeling dell’utente con un sistema e comprende l’esperienza, il significato e il valore dell’interazione uomo-macchina e della proprietà del prodotto stesso; inoltre, la perce-zione degli aspetti pratici e dell’efficienza fanno parte dell’esperienza dell’utente. Il termine è usato abbondantemente in tutta la documentazione di Windows Phone 7 dove si trova, ad esempio, la frase “far partire una nuova esperienza per l’utente” intendendo la partenza di una applicazione.




Name=”startButton” VerticalAlignment=”Top”

Width=”160” Click=”startButton_Click” />

...

Preparato il form iniziamo a vedere il codice del code behind per definire, far partire e fermare il sensore dell’accelerometro:

using System;


using System.Linq;

using System.Net;









using Microsoft.Devices.Sensors;

namespace _10_Accelerometer

{


{

private Accelerometer accelerometer;

public MainPage()

{


}

private void startButton_Click(object sender,

RoutedEventArgs e)

...

Il nome del nostro progetto, pubblicato anche sul sito www.thinkmobile.it, è 10_Accelerometer. All’interno del namespace, il template di progetto di Visual Studio ci ha preparato una classe MainPage che eredita le funzionalità dalla classe base presente nella libreria Microsoft.Phone.La riga successiva definisce il componente accelero-meter a livello di pagina in modo da poterlo utilizza-re sia nel metodo startButton_Click che nel metodo stopButton_Click. Il metodo di avvio dell’accelero-metro, dopo aver impostato la TextBlock al valore di Starting, instanzia l’accelerometro e, all’interno di un blocco try/catch prova ad avviare il sensore.Come si nota, l’accelerometro potrebbe non avviarsi correttamente, scatenando una AccelerometerFailedException. Questa eccezione, nella classica proprietà Message conterrà l’errore scatenato dal codice invocato dietro le quinte, ed espone una proprietà ErrorId che fornisce il codice di errore nativo. La stessa eccezione potrebbe veri-ficarsi anche durante la chiamata al metodo Stop.

Provando l’applicazione, a questo punto si può veri-ficare il corretto Start e Stop del sensore: nelle prime versioni beta degli strumenti di sviluppo, l’emulato-re non era in grado di avviare l’accelerometro, ma, ovviamente, nella versione finale, l’accelerometro è disponibile anche nell’emulatore: il codice prece-dente, quindi, può essere testato anche sul personal computer.La prossima operazione da eseguire è abbonarsi all’evento che abbiamo accennato all’inizio dell’ar-ticolo per ricevere sia le informazioni di stato sul sensore, sia le informazioni che riguardano le forze che agiscono su di esso. Il codice per effettuare que-sta operazione è evidenziato di seguito, e sostuisce quanto abbiamo visto per il pulsante di avvio:


RoutedEventArgs e)

{

this.statusText.Text = “Starting...”;

this.accelerometer = new Accelerometer();

this.accelerometer.ReadingChanged += new

EventHandler<AccelerometerReadingEventArgs>(acceler

ometer_ReadingChanged);

try

{

this.accelerometer.Start();

}

catch (AccelerometerFailedException)

{

this.statusText.Text = “Problema”;

}

}

L’evento denominato ReadingChanged passa una classe di tipo AccelerometerReadingEventArgs al metodo indicato (nel nostro caso accelerometer_ReadingChanged).La definizione di questa classe, decompilata con Reflector, è la seguente:

public class AccelerometerReadingEventArgs : EventArgs

{

// Fields

[CompilerGenerated]

private DateTimeOffset <Timestamp>k__

BackingField;

private double x;

private double y;

private double z;

// Methods

internal AccelerometerReadingEventArgs(Acceleromet

erNativeSample accNativeSample);

// Properties

public DateTimeOffset Timestamp

{

NOTA

ACCELEROMETROÈ importante comprendere

a fondo come funziona questo sensore che, a

prima vista, ha un compor-tamento diverso da quanto

la maggior parte delle persone pensano. Un acce-

lerometro non misura gli sponstamenti nello spazio,

ma l’accelerazione impres-sa al device durante questi

spostamenti. Il sensore non è infatti denominato

“Posizionometro”! Maggiori dettagli possono essere

recuperati dalla documen-tazione su MSDN e, una

consultazione di Wikipedia aiuta nella comprensione delle forze gravitazionali

che il sensore consente di misurare.




[CompilerGenerated] get; [CompilerGenerated] private

set; }

public double X { get; }

public double Y { get; }

public double Z { get; }

}

La proprietà Timestamp fornisce l’offset temporale (sotto forma di DateTimeOffset) ovvero indica il momento in cui è stata presa la rilevazione sul sen-sore, mentre X,Y,Z sono i valori che rappresentano la forza di accelerazione sui vari assi.È bene rimarcare che questi tre valori non rappre-sentano lo spostamento sull’asse X, Y o Z, ma la forza di accelerazione percepita dal device sui tre assi. I valori di queste tre proprietà che riceviamo negli argomenti del nostro metodo rappresentano infatti valori di tipo double che indicano la direzione dell’accelerazione per ogni asse in unità gravitazio-nali comprese fra -2 e 2. In pratica se riceviamo il valore 1 nell’asse X vuol dire che il device ha sentito una forza gravitazionale pari a 1 ovvero l’utente ha spostato il telefono verso sinistra imprimendo una forza pari a 1. Se invece riceviamo un valore pari a -1, l’utente ha spostato il telefono con la stessa forza dell’esempio precedente, ma spostando il device verso destra.L’asse Y lavora sull’asse terrestre, ovvero “sente” l’accelerazione in avanti e indietro, mentre l’asse Z lavora sull’asse verticale ovvero “sente” l’accelera-zione verso l’alto o verso il basso. Provando l’esem-pio sull’emulatore, il valore di Z sarà -1 in quanto rappresenta la forza di gravità.Se l’utente gira il telefono con lo schermo verso il basso, gli assi restano immutati ma i valori ricevuti dovranno essere letti al contrario: un valore di -1 sull’asse X rappresenta una accelerazione sul movi-mento verso sinistra. Il codice che visualizza i valori delle forze e, se avete un device sotto mano, dimostra anche il compor-tamento del sensore, è molto semplice come si nota nell’estratto seguente. L’unica complessità, ben nota a chi ha lavorato con WPF, Silverlight, Windows Forms è la necessità di richiedere al thre-ad principale, l’owner dei controlli, l’esecuzione delle operazioni di assegnazione. Questa necessità deriva dal fatto che l’accelero-metro richiama da un thread secondario il meto-do indicato per ricevere l’evento di segnalazione dell’accelerazione captata dal sensore.

void accelerometer_ReadingChanged(object

sender, AccelerometerReadingEventArgs e)

{

Deployment.Current.Dispatcher.BeginInvoke(()

=>

{

this.statusText.Text = this.accelerometer.

State.ToString();

this.TimeStampText.Text = e.Timestamp.

ToString();

this.XText.Text = e.X.ToString();

this.YText.Text = e.Y.ToString();

this.ZText.Text = e.Z.ToString();

});

}

Il metodo BeginInvoke esposto dal Dispatcher e recuperato dal contesto di deploy corrente consen-te di eseguire l’operazione sul thread principale. Il metodo anonimo, rappresentato dalla lambda expression (caratteristica di C# 3.0 – 2008) inserisce nelle tre TextBlock della pagina principale i valo-ri del sensore. La prima riga di codice utilizza la proprietà State per visualizzare lo stato del sensore (Ready quando è stato avviato ed è pronto a lavo-rare), mentre la seconda riga di codice recupera il timestamp che indica il momento della rilevazione.Come si nota il valore della proprietà Y è -1 in quan-to l’emulatore, essendo fermo, rileva solo la forza di gravità terrestre che, in condizioni stabili, a livello del mare, e su un parallelo medio, è, appunto è 1G negativo.Lo stesso codice, lanciato su un device reale, pro-duce, con il device appoggiato sul tavolo, il risultato di Fig.6. Alla prima esecuzione, il comportamento solimente sembra ancora strano: visto che il device è appoggiato su un tavolo non dovrebbe subire nes-suno spostamento; il device in effetti non subisce nessuno spostamento in quanto è ben appoggiato sulla superficie, ma le forze gravitazionali agiscono su di esso sui vari assi e possono variare se il device si trova su una montagna oppure a livello del mare, su un parallelo vicino all’equatore oppure più vicino ai poli. Ricordate, inoltre, che la Terra ruota, come disse qualcuno quando ancora Windows Phone 7

Fig.4: Rappresentazione visuale degli assi X, Y, Z

NOTA

USER EXPERIENCECon user experience si fa riferimento proprio all’esperienza che l’utente vive durante l’utilizzo di un prodotto software. La user interface è una delle componenti più importanti della user experience, e non è un suo sinonimo. Da Wikipedia, la user experience (UX) riguarda il feeling dell’utente con un sistema e comprende l’esperienza, il significato e il valore dell’interazione uomo-macchina e della proprietà del prodotto stesso; inoltre, la perce-zione degli aspetti pratici e dell’efficienza fanno parte dell’esperienza dell’utente. Il termine è usato abbondantemente in tutta la documentazione di Windows Phone 7 dove si trova, ad esempio, la frase “far partire una nuova esperienza per l’utente” intendendo la partenza di una applicazione.




Name=”startButton” VerticalAlignment=”Top”

Width=”160” Click=”startButton_Click” />

...

Preparato il form iniziamo a vedere il codice del code behind per definire, far partire e fermare il sensore dell’accelerometro:

using System;


using System.Linq;

using System.Net;









using Microsoft.Devices.Sensors;

namespace _10_Accelerometer

{


{

private Accelerometer accelerometer;

public MainPage()

{


}


RoutedEventArgs e)

...

Il nome del nostro progetto, pubblicato anche sul sito www.thinkmobile.it, è 10_Accelerometer. All’interno del namespace, il template di progetto di Visual Studio ci ha preparato una classe MainPage che eredita le funzionalità dalla classe base presente nella libreria Microsoft.Phone.La riga successiva definisce il componente accelero-meter a livello di pagina in modo da poterlo utilizza-re sia nel metodo startButton_Click che nel metodo stopButton_Click. Il metodo di avvio dell’accelero-metro, dopo aver impostato la TextBlock al valore di Starting, instanzia l’accelerometro e, all’interno di un blocco try/catch prova ad avviare il sensore.Come si nota, l’accelerometro potrebbe non avviarsi correttamente, scatenando una AccelerometerFailedException. Questa eccezione, nella classica proprietà Message conterrà l’errore scatenato dal codice invocato dietro le quinte, ed espone una proprietà ErrorId che fornisce il codice di errore nativo. La stessa eccezione potrebbe veri-ficarsi anche durante la chiamata al metodo Stop.

Provando l’applicazione, a questo punto si può veri-ficare il corretto Start e Stop del sensore: nelle prime versioni beta degli strumenti di sviluppo, l’emulato-re non era in grado di avviare l’accelerometro, ma, ovviamente, nella versione finale, l’accelerometro è disponibile anche nell’emulatore: il codice prece-dente, quindi, può essere testato anche sul personal computer.La prossima operazione da eseguire è abbonarsi all’evento che abbiamo accennato all’inizio dell’ar-ticolo per ricevere sia le informazioni di stato sul sensore, sia le informazioni che riguardano le forze che agiscono su di esso. Il codice per effettuare que-sta operazione è evidenziato di seguito, e sostuisce quanto abbiamo visto per il pulsante di avvio:


RoutedEventArgs e)

{

this.statusText.Text = “Starting...”;

this.accelerometer = new Accelerometer();

this.accelerometer.ReadingChanged += new

EventHandler<AccelerometerReadingEventArgs>(acceler

ometer_ReadingChanged);

try

{

this.accelerometer.Start();

}


{

this.statusText.Text = “Problema”;

}

}

L’evento denominato ReadingChanged passa una classe di tipo AccelerometerReadingEventArgs al metodo indicato (nel nostro caso accelerometer_ReadingChanged).La definizione di questa classe, decompilata con Reflector, è la seguente:

public class AccelerometerReadingEventArgs : EventArgs

{

// Fields

[CompilerGenerated]

private DateTimeOffset <Timestamp>k__

BackingField;

private double x;

private double y;

private double z;

// Methods

internal AccelerometerReadingEventArgs(Acceleromet

erNativeSample accNativeSample);

// Properties

public DateTimeOffset Timestamp

{

NOTA

ACCELEROMETROÈ importante comprendere

a fondo come funziona questo sensore che, a

prima vista, ha un compor-tamento diverso da quanto

la maggior parte delle persone pensano. Un acce-

lerometro non misura gli sponstamenti nello spazio,

ma l’accelerazione impres-sa al device durante questi

spostamenti. Il sensore non è infatti denominato

“Posizionometro”! Maggiori dettagli possono essere

recuperati dalla documen-tazione su MSDN e, una

consultazione di Wikipedia aiuta nella comprensione delle forze gravitazionali

che il sensore consente di misurare.




SUL WEB

BLOG/FORUM/SAMPLELa community www.think-mobile.it, nata in occasione della prima conferenza ita-liana sullo sviluppo mobile nel luglio di cinque anni fa, da Aprile 2010 ha aperto una nuova sezione dedica-ta a Windows Phone 7: sono disponibili forum specifici per trattare lo sviluppo, vari blog che for-niscono informazioni con-tinue sulle novità per gli sviluppatori e nella sezione media si trovano numerosi esempi sull’utilizzo dei sensori e delle varie fun-zionalità del device.

reading.Normalize();

// At random intervals, generate a random spike

in the data

if (random.NextDouble() > .95)

{

reading = new Vector3((float)(random.

NextDouble() * 3.0 - 1.5),

(float)(random.NextDouble() * 3.0 - 1.5),

(float)(random.NextDouble() * 3.0 - 1.5));

}

// return the vector and then sleep

yield return reading;

Thread.Sleep(100);

}

}

All’interno del loop, come si può notare, viene uti-lizzata una variabile di tipo double (theta) su cui vengono applicati seno e coseno per creare una istanza della classe Vector3 che, a sua volta, viene restituita nella colletion IEnumerable<Vector3>. Il codice chiamante può quindi costruire una ObservableCollection e invocare il metodo di lettu-ra dei dati dell’accelerometro mentre questi sono generati nella collection stessa. Non abbiamo lo spazio per approfondire questo aspetto e, soprattut-to, la documentazione ufficiale è sufficientemente completa. Vi rimandano al link indicato nel box a fianco per eventuali approfondimenti. Vi vorrei invece proporre una soluzione alternativa e, a mio avviso, più utile nel caso in cui vogliate simulare vari comportamenti dell’utente.

SIMULATORE DI ACCELEROMETROL’idea ci è venuta a giugno 2010 quando in una riunione di progetto avevamo bisogno di creare una applicazione basata sull’accelerometro e non aveva-mo ancora una device fisico. Inoltre, la necessità di avere dei dati per testare una applicazione è molto sentita in un team di sviluppo, dove non è detto che tutti i developer o i designer abbiamo un device reale per fare le prove. Con il mouse è relativamente semplice simulare dei dati che, non essendo più casuali o nella stessa sequenza come con le Reactive Extension, consentono di testare qualunque scena-rio in modo interattivo.La prima idea alla base del nostro ThinkAhead Accelerometer Simulator era non dover cambiare il codice dell’applicazione che usa le classi dell’ac-celerometro reale rispetto al simulatore e, come è bene sempre fare secondo le pratiche Agile, siamo partiti creando un simulatore semplice che, un domani potrà essere reso ancora più configurabile e pluggabile nella soluzione: a giugno gli strumenti erano ancora in CTP e non avrebbe avuto senso cre-

are un simulatore troppo raffinato con il rischio di cestinare il tutto dopo poco tempo. Questo il codice reale che abbiamo usato per qualche mese prima di far diventare il simulatore una applicazione reale com’è oggi. La prima cosa che ci interessa fare è quindi modificare una riga di codice nel chiamante per utilizzare un nostro factory che scelga l’accele-rometro in base alla configurazione e alle condizio-ni: il factory restituirà un “accelerometro reale” se esiste oppure l’accelerometro simulato.Il codice del metodo Start diventa questo:

// CHANGE: Uso nostra interfaccia

IAccelerometer accelerometer;


RoutedEventArgs e)

{

axesListBox.Items.Clear();

statusText.Text = “Starting...”;

// CHANGE: chiamo helper per avere Normal o

Mouse

accelerometer = AccelerometerHelper.

GetAccelerometer();

// CHANGE: uso evento e eventhandler

dell’interfaccia

accelerometer.ReadingChanged += new

EventHandler<AccelerometerEventArgs>

(accelerometer_ReadingChanged);

accelerometer.Start();

statusText.Text = “Started”;

}

La modifica effettuata al metodo è molto sempli-ce: richiamiamo il metodo GetAccelerometer, che restituisce un tipo IAccelerometer, interfaccia che andremo a vedere fra un attimo e che rappresen-ta, come si nota nella prima riga di codice, una definizione di accelerometro. In pratica il nostro metodo GetAccelerometer restituirà l’accelerome-tro simulato o l’accelerometro reale in base alla configurazione che scegliamo. Il resto del codice è identico a quanto visto in precedenza. Da notare che usiamo la nostra classe AccelerometerEventArgs e il nostro evento ReadingChanged che abbiamo deciso di chiamare in modo identico alle classi dell’accelerometro di default. Il codice della classe helper legge la configurazione e, in base al valore “Default” o “Mouse” crea una istanza di accelero-metro. Il metodo GetAccelerometer tenta di avviare l’accelerometro internamente in modo da restituire “l’accelerometro via mouse” se ci fossero problemi con l’accelerometro reale quando siamo in una ses-sione di debug. La nostra classe Utility non fa altro che leggere i valori di configurazione.

Namespace ThinkAhead.Library

{

public static class AccelerometerHelper



non era uscito.Se avete un device provate a tenerlo il più possibile fermo in mano e noterete che le forze diminuiscono o aumentano: diminuiscono se la vostra mano si muove contro le forze terrestri o aumentano se vi muovete nella stessa direzione. Il fatto che il valore Z sia negativo è significativo del fatto che sta resiten-do alla forza gravitazionale che lo vorrebbe invece spingere verso il pavimento.Aggiungendo una Debug.WriteLine(e.Z) all’interno del codice del metodo di visualizzazione siamo in grado di tracciare i valori continui forniti dal sensore e capire meglio il funzionamento dell’accelerome-tro stesso. Provando ad esempio ad alzare il device con una certa energia e fermandosi bruscamente dopo un breve tratto otteniamo il trace seguente:

È importante notare come l’accelerazione rilevata sia un po’ diversa da quanto ci aspettavamo e, ovvia-mente, è il sensore ad aver ragione. Quando alziamo il device notiamo uno spostamento sull’asse Z che incrementa il valore negativo fino ad accelerare a -1.80: il movimento è continuo, perché giustamente rileva una accelerazione progressiva sino al mas-simo. I valori, dopo il valore minimo, cominciano ad aumentare (nel senso che tornano verso nume-ri positivi) indicandoci che stiamo rallentando la nostra corsa. Molte persone a cui abbiamo fatto training sul device si aspettavano invece che a fron-te di una fermata il valore si fermasse: giustamente invece il sensore rileva che ci stiamo fermando in quanto è molto più sensibile di quanto possiamo aspettarci. Non solo: il sensore prima di ristabiliz-zarsi sul valore della gravità terrestre, esegue una leggera accelerazione in discesa. Infatti, anche una “frenata” ha una forza di accelerazione. Nella figura seguente, in cui ho “ribaltato” il grafico, vediamo il movimento della mano verso l’alto con una “impen-nata” del grafico (ricordatevi che un movimento verso l’alto significa andare contro la gravità).Il grafico mostra chiaramente come il nostro movi-mento verso l’alto corrisponda ad un movimento

“contro” la forza di gravità e come il momento di “stop brusco” corrisponda ad una sempre minore resistenza alla forza gravitazionale sino ad arrivare a valori leggermente positivi per poi riassestarsi sui valori di gravità iniziali.

SIMULATORE DI ACCELEROMETRO (REACTIVE EXTENSIONS)La documentazione ufficiale, sin dalle primissime versioni Beta, riporta un modo semplice e interes-sante per testare le applicazioni sull’emulatore, che, come abbiamo avuto modo di dire, non è ovviamen-te in grado di sentire le forse gravitazionali e, anche se lo fosse, sarebbe complicato muovere il PC che lo ospita con 2G di forza senza disintegrarlo contro qualcosa nella stanza.Tramite .NET Reactive Extensions (Rx), è possibile inviare una sequenza di dati simulati all’accelero-metro per eseguire test oppure è anche possibile generare dati random compresi in intervalli specifi-ci: il primo scenario è molto utile anche per eseguire unit test, mentre il secondo si avvicina di più a quanto potrebbe accadere quando un utente avrà in mano un device con il nostro codice.Il codice proposto nella documentazione ufficia-le (http://msdn.microsoft.com/en-us/library/ff637521(VS.92).aspx), nel punto più importante, si presenta così:

static IEnumerable<Vector3>

EmulateAccelerometerReading()

{

// Create a random number generator

Random random = new Random();

// Loop indefinitely

for (double theta = 0; ; theta+=.1 )

{

// Generate a Vector3 in which the values of each

axes slowly drift between -1 and 1 and

// then normalize the vector

Vector3 reading = new Vector3((float)Math.

Sin(theta), (float)Math.Cos(theta * 1.1), (float)Math.

Sin(theta * .7));

Fig.5: Lettura dati sull’emulatore

Fig.6: Grafico di un’accelerazione veloce verso l’alto

-0,88671875-0,87109375-0,87109375-0,85546875-0,88671875-1,078125-1,3046875-1,54296875-1,76171875-1,80859375-1,71875-1,55078125-1,05859375-0,5546875-0,26953125

-0,10156250,058593750,10156250,1015625-1,04296875-1,046875-1,12890625-0,90234375-1-0,98046875-0,9375-0,921875-0,89453125-0,86328125-0,90625

-0,87109375-0,84375-0,859375-0,84375-0,85546875-0,859375-0,81640625-0,828125-0,83984375-0,83203125-0,84765625-0,87890625-0,87109375


Windows Phone 7 programming

http://www.ioprogrammo. i t 52 / Aprile 2011

Conoscenze richieste

nessuna

Software

nessuna

Impegno


METRO: L’INNOVATIVO LINGUAGGIO DI DESIGNMETRO DEFINISCE LE LINEE GUIDA RELATIVE ALLA PROGETTAZIONE DI USER INTERFACE PER WINDOWS PHONE 7. LA SUA FILOSOFIA, ATTUALE E MODERNA, SI ADATTA PERFETTAMENTE ANCHE AD APPLICAZIONI DESKTOP E WEB DI NUOVA GENERAZIONE

A fine ottobre Microsoft ha lanciato ufficialmente Windows Phone 7, il nuovo device per la telefonia mobile. Il nuovo device, sin dalle sue prime apparizio-

ni di febbraio 2010, è sempre stato presentato da Microsoft calcando la mano sulla filosofia di progettazione, le linee guida che hanno ispirato la nascita di questa nuova user experience e sul valore dell’interfaccia rispetto all’utente finale. Con il termine user experience, da qualche anno, si fa riferimento proprio all’esperienza che l’utente vive durante l’utilizzo di un prodotto software. La user interface è una delle componenti più importanti della user experience, e non è un suo sinonimo. Da Wikipedia, la user experience (UX) riguarda il feeling dell’utente con un sistema e comprende l’esperienza, l’affetto, il significato e il valore dell’interazione uomo-macchina e della proprietà del prodotto stesso; inol-tre, la percezione degli aspetti pratici e dell’efficienza fanno parte dell’esperienza dell’utente.Il primo errore che può fare lo sviluppatore di applicazioni per Windows Phone 7 è ignorare queste linee guida, raccolte nel documento “Application Phone UI Design and Interaction Guide”, e progettare la user experience per la propria applica-zione non in sintonia con il resto del device: non stiamo affer-mando che non possiamo avere fantasia e che le applicazioni saranno tutte uguali, anzi, stiamo affermando il contrario: le linee guida servono per evitare che l’utente disperda il suo tempo alla ricerca di un tasto o di una funzionalità, servono per dare una base comune per facilitare l’utilizzo delle appli-cazione, riducendo i tempi di apprendimento e la dimensio-ne dell’eventuale testo di help. Le applicazioni mobile sono utilizzate in contesti diversi rispetto alle applicazioni tradizio-nali. L’esempio più classico è: se l’utente sta camminando e intanto usa il telefono, non possiamo fargli interrompere il suo cammino per farlo entrare in una opzione complicata da trovare o per costringerlo a leggere venti righe di testo di aiuto; se l’utente si deve fermare non abbiamo scritto una buona applicazione e se invece l’utente si distrae e attraversa la strada mentre legge...abbiamo fatto ancora peggio.Le linee guida si scaricano a partire da questo link http://developer.windowsphone.com/windows-phone-7/, dove si trova anche una guida per la costruzione di siti web con interfaccia mirata allo schermo e alla user experience con Windows Phone 7. Sempre a partire dal link indicato, ci sono altri due “cose” utilissime, la prima è la documentazione sulla

piattaforma che andremmo a introdurre da subito e la secon-da, sono gli strumenti, gratuiti, per sviluppare applicazioni.Con ThinkAhead, la società del gruppo DevLeap specializza-ta nello studio e realizzazione di user experience, abbiamo avuto la fortuna di partecipare al programma di early adop-tion e, durante questo periodo, siamo arrivati alla conclu-sione che sia di vitale importanza apprendere le specifiche dettate dalle linee guida prima di sviluppare le applicazioni. Le specifiche sono raccolte nella “UI Design and Interaction Guide for Windows Phone 7”, guida attualmente giunta alla versione 2.0 che comprende quanto oggi conosciamo con il termine Metro. È fondamentale conoscere i concetti base della piattaforma Silverlight: pannelli, controlli, stili, template, binding e proto-colli di comunicazione, ovviamente mixati in un’architettura flessibile, estendibile, robusta e testabile, ma è decisamente importante saper rappresentare al meglio la nostra user experience applicativa: l’usabilità di un software è importan-te quanto la sua architettura.

NON SOLO SOFTWARECorsi e ricorsi della storia, una serie di avvenimenti che si susseguono uno dopo l’altro, l’evoluzione in un campo segue una rivoluzione in un altro, ormai l’informatica è contaminata continuamente da eventi esterni, in qualunque sua forma: arte, architettura, musica e caratteristiche sociali e di costume. Questo preambolo per affermare che ormai le applicazioni devono seguire non solo l’onda tecnologica ma devono essere fedeli al concetto di attualità e modernità.Molti parlano, o parlavano, di Web 2.0, secondo noi sono gli utenti che sono diventati 2.0, non subiscono passivamente le idee grafiche di programmatori o architetti software ma ricercano interfacce utente al passo con i tempi; è importan-te, quindi, guardare non solo al codice XAML ma affacciarsi sul mondo reale e capire quali sono le idee che si stanno affermando in questi ultimi anni.Adesso la vera eleganza è fatta di essenzialità, una regola che vale per tutto, dal software all’abbigliamento, dall’architettu-ra al design passando per l’arredamento, la comunicazione e la pubblicità. Un design senza fronzoli fatto di linee pulite e leggere declinato con forme e colori che si armonizzano con

MOBILE Windows Phone 7: l’interfacciaIL TELEFONO “LEGGE” I TUOI MOVIMENTIMOBILE L’accelerometro di Windows Phone 7


{

public static IAccelerometer GetAccelerometer()

{

String accelerometer = Utility.GetAppSettings(“

Accelerometer”);

IAccelerometer sensor = null;

switch (accelerometer)

{

case “Default”:

{

// Provo a avviare l’accelerometro

sensor = new AccelerometerProxy();

#if DEBUG

try

{

sensor.Start();

sensor.Stop();

}


{

sensor = new MouseAccelerometer();

}

#endif

break;

}

case “Mouse”:

{


break;

}

}

return sensor;

} } }

Ovviamente potete modificare il codice come prefe-rite. Il codice del nostro accelerometro è il seguente:

public class MouseAccelerometer : IAccelerometer

{

public event EventHandler<AccelerometerEvent

Args> ReadingChanged;

private FrameworkElement target;

private bool isMouseLeftDown;

private bool isKeyDown;

private Point mouseDownLoc;

private double tolerance = Convert.

ToDouble(Utility.GetAppSettings(“Tolerance”));

private Double _x = 0;

private Double _y = 0;

private Double _z = 0;

private SensorState _state = SensorState.NoData;

La classe contiene una serie di informazioni pri-vate che utilizzeremo per inviare i dati all’appli-cazione. Oltre alle proprietà X,Y,Z e lo stato del sensore, abbiamo utilizzato isMouseLeftDown per sapere se l’utente sta premendo il pulsante sinistro

e isKeyDown per inviare informazioni sull’asse Z al posto dell’asse Y; il mouse in effetti ha solo due direzioni possibili: quando lo sviluppatore preme il tasto sinistro del mouse inviamo X e Y durante lo spostamento del mouse, mentre se preme anche un tasto sulla tastiera, inviamo X e Z.Nel codice seguente, il metodo HandleMouseMove, infatti, controlla la pressione del tasto sinistro e, solo in caso positivo, recupera la posizione del mouse sull’asse X per valorizzare il membro privato _x e la posizione sull’asse Y per valorizzare _y. Se invece lo sviluppatore sta premendo un tasto, valorizziamo la proprietà _z al posto della proprietà _y.Dopo aver calcolato i valori di _x, _y e _z, facciamo scattare l’evento AccelerometerEventArgs fornendo tali dati al chiamante:

private void HandleMouseMove(object sender,

MouseEventArgs e)

{

if (!this.isMouseLeftDown)

return;

Point position = e.GetPosition(this.target);

this._x = (position.X - this.mouseDownLoc.X) *

this.tolerance;

if (!isKeyDown)

this._y = -(position.Y - this.

mouseDownLoc.Y) * this.tolerance;

else

this._z = -(position.Y - this.


if (this.ReadingChanged != null)

{

AccelerometerEventArgs args = new

AccelerometerEventArgs()

{

X = this._x,

Y = this._y,

Z = this._z

};

this.ReadingChanged(this, args);

}

}

Il codice completo della nostra libreria in versione 1 è scaricabile dal sito www.thinkmobile.it, nella sezione Media: ci sono due versioni allineate agli strumenti di aprile 2010 e agli strumenti di luglio 2010. Potete ovviamente modificarle e arricchirle a vostro piacimento visto che le abbiamo rilasciate senza nessun copyright o licenza.Adesso il nostro ThinkAhead.Accelerometer ha fatto altri passi avanti ed è diventato un progetto reale insieme al progetto a cui è servito visto che, appun-to, ancora non tutti nel nostro team hanno un tele-fono a disposizione.

Roberto Brunetti

Fig.7: Lettura dati sul device


Windows Phone 7 programmingMETRO: L’INNOVATIVO LINGUAGGIO DI DESIGN



nessuna

Software

nessuna

Impegno


METRO: L’INNOVATIVO LINGUAGGIO DI DESIGNMETRO DEFINISCE LE LINEE GUIDA RELATIVE ALLA PROGETTAZIONE DI USER INTERFACE PER WINDOWS PHONE 7. LA SUA FILOSOFIA, ATTUALE E MODERNA, SI ADATTA PERFETTAMENTE ANCHE AD APPLICAZIONI DESKTOP E WEB DI NUOVA GENERAZIONE

A fine ottobre Microsoft ha lanciato ufficialmente Windows Phone 7, il nuovo device per la telefonia mobile. Il nuovo device, sin dalle sue prime apparizio-

ni di febbraio 2010, è sempre stato presentato da Microsoft calcando la mano sulla filosofia di progettazione, le linee guida che hanno ispirato la nascita di questa nuova user experience e sul valore dell’interfaccia rispetto all’utente finale. Con il termine user experience, da qualche anno, si fa riferimento proprio all’esperienza che l’utente vive durante l’utilizzo di un prodotto software. La user interface è una delle componenti più importanti della user experience, e non è un suo sinonimo. Da Wikipedia, la user experience (UX) riguarda il feeling dell’utente con un sistema e comprende l’esperienza, l’affetto, il significato e il valore dell’interazione uomo-macchina e della proprietà del prodotto stesso; inol-tre, la percezione degli aspetti pratici e dell’efficienza fanno parte dell’esperienza dell’utente.Il primo errore che può fare lo sviluppatore di applicazioni per Windows Phone 7 è ignorare queste linee guida, raccolte nel documento “Application Phone UI Design and Interaction Guide”, e progettare la user experience per la propria applica-zione non in sintonia con il resto del device: non stiamo affer-mando che non possiamo avere fantasia e che le applicazioni saranno tutte uguali, anzi, stiamo affermando il contrario: le linee guida servono per evitare che l’utente disperda il suo tempo alla ricerca di un tasto o di una funzionalità, servono per dare una base comune per facilitare l’utilizzo delle appli-cazione, riducendo i tempi di apprendimento e la dimensio-ne dell’eventuale testo di help. Le applicazioni mobile sono utilizzate in contesti diversi rispetto alle applicazioni tradizio-nali. L’esempio più classico è: se l’utente sta camminando e intanto usa il telefono, non possiamo fargli interrompere il suo cammino per farlo entrare in una opzione complicata da trovare o per costringerlo a leggere venti righe di testo di aiuto; se l’utente si deve fermare non abbiamo scritto una buona applicazione e se invece l’utente si distrae e attraversa la strada mentre legge...abbiamo fatto ancora peggio.Le linee guida si scaricano a partire da questo link http://developer.windowsphone.com/windows-phone-7/, dove si trova anche una guida per la costruzione di siti web con interfaccia mirata allo schermo e alla user experience con Windows Phone 7. Sempre a partire dal link indicato, ci sono altri due “cose” utilissime, la prima è la documentazione sulla

piattaforma che andremmo a introdurre da subito e la secon-da, sono gli strumenti, gratuiti, per sviluppare applicazioni.Con ThinkAhead, la società del gruppo DevLeap specializza-ta nello studio e realizzazione di user experience, abbiamo avuto la fortuna di partecipare al programma di early adop-tion e, durante questo periodo, siamo arrivati alla conclu-sione che sia di vitale importanza apprendere le specifiche dettate dalle linee guida prima di sviluppare le applicazioni. Le specifiche sono raccolte nella “UI Design and Interaction Guide for Windows Phone 7”, guida attualmente giunta alla versione 2.0 che comprende quanto oggi conosciamo con il termine Metro. È fondamentale conoscere i concetti base della piattaforma Silverlight: pannelli, controlli, stili, template, binding e proto-colli di comunicazione, ovviamente mixati in un’architettura flessibile, estendibile, robusta e testabile, ma è decisamente importante saper rappresentare al meglio la nostra user experience applicativa: l’usabilità di un software è importan-te quanto la sua architettura.

NON SOLO SOFTWARECorsi e ricorsi della storia, una serie di avvenimenti che si susseguono uno dopo l’altro, l’evoluzione in un campo segue una rivoluzione in un altro, ormai l’informatica è contaminata continuamente da eventi esterni, in qualunque sua forma: arte, architettura, musica e caratteristiche sociali e di costume. Questo preambolo per affermare che ormai le applicazioni devono seguire non solo l’onda tecnologica ma devono essere fedeli al concetto di attualità e modernità.Molti parlano, o parlavano, di Web 2.0, secondo noi sono gli utenti che sono diventati 2.0, non subiscono passivamente le idee grafiche di programmatori o architetti software ma ricercano interfacce utente al passo con i tempi; è importan-te, quindi, guardare non solo al codice XAML ma affacciarsi sul mondo reale e capire quali sono le idee che si stanno affermando in questi ultimi anni.Adesso la vera eleganza è fatta di essenzialità, una regola che vale per tutto, dal software all’abbigliamento, dall’architettu-ra al design passando per l’arredamento, la comunicazione e la pubblicità. Un design senza fronzoli fatto di linee pulite e leggere declinato con forme e colori che si armonizzano con

MOBILE Windows Phone 7: l’interfacciaMOBILE L’accelerometro di Windows Phone 7


{

public static IAccelerometer GetAccelerometer()

{

String accelerometer = Utility.GetAppSettings(“

Accelerometer”);

IAccelerometer sensor = null;

switch (accelerometer)

{

case “Default”:

{

// Provo a avviare l’accelerometro

sensor = new AccelerometerProxy();

#if DEBUG

try

{

sensor.Start();

sensor.Stop();

}


{


}

#endif

break;

}

case “Mouse”:

{


break;

}

}

return sensor;

} } }

Ovviamente potete modificare il codice come prefe-rite. Il codice del nostro accelerometro è il seguente:

public class MouseAccelerometer : IAccelerometer

{

public event EventHandler<AccelerometerEvent

Args> ReadingChanged;

private FrameworkElement target;

private bool isMouseLeftDown;

private bool isKeyDown;

private Point mouseDownLoc;

private double tolerance = Convert.

ToDouble(Utility.GetAppSettings(“Tolerance”));

private Double _x = 0;

private Double _y = 0;

private Double _z = 0;

private SensorState _state = SensorState.NoData;

La classe contiene una serie di informazioni pri-vate che utilizzeremo per inviare i dati all’appli-cazione. Oltre alle proprietà X,Y,Z e lo stato del sensore, abbiamo utilizzato isMouseLeftDown per sapere se l’utente sta premendo il pulsante sinistro

e isKeyDown per inviare informazioni sull’asse Z al posto dell’asse Y; il mouse in effetti ha solo due direzioni possibili: quando lo sviluppatore preme il tasto sinistro del mouse inviamo X e Y durante lo spostamento del mouse, mentre se preme anche un tasto sulla tastiera, inviamo X e Z.Nel codice seguente, il metodo HandleMouseMove, infatti, controlla la pressione del tasto sinistro e, solo in caso positivo, recupera la posizione del mouse sull’asse X per valorizzare il membro privato _x e la posizione sull’asse Y per valorizzare _y. Se invece lo sviluppatore sta premendo un tasto, valorizziamo la proprietà _z al posto della proprietà _y.Dopo aver calcolato i valori di _x, _y e _z, facciamo scattare l’evento AccelerometerEventArgs fornendo tali dati al chiamante:

private void HandleMouseMove(object sender,

MouseEventArgs e)

{

if (!this.isMouseLeftDown)

return;

Point position = e.GetPosition(this.target);

this._x = (position.X - this.mouseDownLoc.X) *

this.tolerance;

if (!isKeyDown)

this._y = -(position.Y - this.


else

this._z = -(position.Y - this.


if (this.ReadingChanged != null)

{

AccelerometerEventArgs args = new

AccelerometerEventArgs()

{

X = this._x,

Y = this._y,

Z = this._z

};

this.ReadingChanged(this, args);

}

}

Il codice completo della nostra libreria in versione 1 è scaricabile dal sito www.thinkmobile.it, nella sezione Media: ci sono due versioni allineate agli strumenti di aprile 2010 e agli strumenti di luglio 2010. Potete ovviamente modificarle e arricchirle a vostro piacimento visto che le abbiamo rilasciate senza nessun copyright o licenza.Adesso il nostro ThinkAhead.Accelerometer ha fatto altri passi avanti ed è diventato un progetto reale insieme al progetto a cui è servito visto che, appun-to, ancora non tutti nel nostro team hanno un tele-fono a disposizione.

Roberto Brunetti

Fig.7: Lettura dati sul device


Windows Phone 7 programming METRO: L’INNOVATIVO LINGUAGGIO DI DESIGN


termini di user experience ciò significa ridurre al minimo gli elementi sullo schermo. Spesso ci troviamo di fronte ad applicazioni piene zeppe di funzionalità accessorie che potrebbero essere utili solo al 2% degli utenti, mentre il rimanente 98% vivrebbe benis-simo senza; appesantire l’interfaccia utente con pulsanti o altri controlli non strettamente necessari all’applicazione ne diminiusce drasticamente l’usabilità. Questa tendenza non solo è importante per la realizzazione di applicazioni mobili ma anche per interfacce desktop o web, molto spesso infatti per accontentare quel 2% rendiamo più scomoda la fruibilità all’altro 98%. IPhone è un classico esempio di questo concet-to: le funzionalità necessarie alla maggioranza degli utenti sono esposte in modo estremamente chiaro e usabile, altre funzioni più complesse e meno utilizzate non sono state inserite nel sistema. Tornando a Metro, prendiamo ad esempio un pannello di configurazione delle impostazioni di un’applicazione, che potrebbe contenere “mille” controlli di personalizzazione e setup, ma dobbiamo scegliere con cura e inserire solo le parametrizzazioni più importanti per rendere più facile e semplice l’utilizzo da parte dell’utente.Per sostenere il concetto di leggerezza è fondamentale “non temere” gli spazi vuoti, aiutano la leggibilità dei testi, l’imme-diata comprensione delle funzionalità e danno anche risalto agli elementi chiave: è semplice capire infatti che aumentan-do la dimensione dello spazio fra due elementi, entrambi acquistano importanza sullo schermo. Nell’esempio di Fig.7, i vari radio button sono spaziati notevolmente fra di loro come suggeriscono le linee guida; questo non solo per rendere gli item facilmente “toccabili” ma anche per dargli la giusta importanza.

PRINCIPI DI TIPOGRAFIA Usare il carattere tipografico come elemento grafico, non solo come semplice testo ma sostituirlo all’utilizzo di immagi-ni iconografiche che spesso non sono comprensibili da parte dell’utente. Un bel carattere ha lo stesso impatto e la stessa forza di un’immagine e sicuramente è più esplicativo.In questo modo l’interfaccia utente non sarà un collage di testo e immagini, così frequente in ambito web, ma sarà omogenea, semplice, lineare e chiara; concetti chiave di Metro.

Microsoft per Windows Phone 7 ha progettato un nuovo font ad alti DPI in grado di supportare a pieno questo prin-cipio: Segoe WP. Consigliamo di utilizzarlo nei suoi vari pesi (bold, semibold, semilight ecc.) nelle applicazioni Silverlight che andrete a sviluppare. Mostriamo l’esempio di una dialog che consente all’utente

la scelta di un item all’interno di una listbox. In questo caso abbiamo usato una pagina separata per supportare il con-cetto di dialog, e scelto di utilizzare caratteri tipografici al posto di una cascata di icone, l’effetto finale è sicuramente più comprensibile ed elegante.Acquista quindi un’importanza fondamentale anche la scelta della dimensione del font, non solo per ovvi motivi di touch, ma anche per mettere in evidenza gli elementi principali.Nel caso della maschera del contatto, è infatti più importante l’azione di “call mobile”, che il dettaglio sul numero di tele-fono. Usando correttamente la tipografia, carattere, peso e dimensione aumenterà l’usabilità della nostra applicazione.

PRINCIPI DI MOVIMENTOLa transizione fra pagine è fondamentale come la proget-tazione delle stesse; l’utente esegue una serie di azioni fra applicazioni diverse, creando una vera e propria “storia” di navigazione, è importante quindi far comprendere chiara-mente dove si trovava e dove sta andando.Pur riducendo al minimo i pulsanti hardware, Windows Phone 7 non ha rinunciato ai pulsante hardware Start e Back che consentono all’utente una facile navigazione fra le pagi-ne di un’applicazione e fra software diversi.Il runtime di Windows Phone 7 ad ogni resume o launch delle nostre applicazioni creerà automaticamente un’ani-mazione in grado di far capire all’utente il cambiamento di contesto mantenendo uniforme la user experience. Tale animazione, oltre ad essere ottimizzata da un punto di vista dei consumi hardware, è poco invasiva e non rende

Fig. 3: Dimensione dei caratteri tipografici

Fig. 2: Navigazione fra applicazioni

MOBILE Windows Phone 7: l’interfaccia

Aprile 2011 / 53 http://www.ioprogrammo. i t

il nostro stile di vita. Proviamo a confermare queste idee con alcuni esempi reali.Anche negli allestimenti di mostre contemporanee si tende a valorizzare solo le opere e non l’allestimento stesso, si ritorna a pareti bianche che ospitano gli elementi dell’esposizione; un esempio è l’installazione Shot di Wolfgang Tillmans alla Serpentine Gallery di Londra.Sommando tutte queste considerazioni arriviamo quindi a definire un’idea di gusto, eleganza e modernità basata sulla semplicità, essenzialità e valorizzazione del contenuto rispetto al contenitore, minimizzando gli sprechi in ogni loro forma.

LA FILOSOFIAL’abitudine, anche nel mondo dell’informatica, è di riutilizza-re idee che funzionano bene e “lucidarle” per farle apparire personali, fenomeno che in campo marketing viene definito come “me too”. Nel mondo dei device mobili, dopo l’innova-zione iPhone si è assistito a una serie di interfacce utenti molti simili l’una all’altra che non hanno portato innovazione ma solo piccole evoluzioni del prodotto originale. Microsoft, nello sviluppo dell’interfaccia di Windows Phone 7 si è discostata da questa tendenza creando un nuovo modo di intendere la presentazione e la fruizione di contenuti.Migliaia di prototipi e di casi d’uso hanno portato alle attuali specifiche e linee guida, un vero e proprio linguaggio di design, nome in codice Metro. Se l’obiettivo è quello di arrivare prima possibile alle informa-zioni necessarie, mantenendo alti gli standard di eleganza e stile, non si può prescindere dalla semplicità, caratteristica fondamentale del nuovo concetto di immagine e comuni-cazione, che si sta affermando in questi anni in diversi campi quali architettura, design, arte e pubblicità, come evidenziato in precendenza in questo articolo. Segue uno screenshot dell’interfaccia utente di Windows Phone 7, nello specifico della pagina Start (l’home page del sistema), contatti e calendarioMetropolitane, aereporti, stazioni ma anche strade, diven-tano il punto di partenza per un linguaggio basato sulla semplicità e sul movimento, che prende spunto dall’imme-diatezza visiva dei codici dei luoghi metropolitani e dagli stessi ne prende il nome.Le idee di Metro, trovano una naturale collocazione anche per applicazioni desktop o web, in quanto i principi fonda-mentali non sono dipendenti da una specifico sistema o piattaforma, potremmo infatti usare gli stessi concetti sia tramite XAML che con CSS/HTML, Java, Flash ecc.In casa Microsoft troviamo Zune, applicazione desktop per la gestione di contenuti multimediali, applicazioni Windows Phone 7 e altro, realizzata adattando le linee guida di Metro a un contesto desktop.In ambiente web possiamo evidenziare la nuova interfaccia di amministrazione di Windows Azure, realizzata intera-mente in Silverlight, scontato sottolineare che i concetti di chiarezza, linearità, semplicità di Metro si applicano anche a tale scenario.

Non solo Microsoft, ma anche molte altre importanti aziende di software stanno progettando le loro interfacce utilizzando icone essenziali, semplici e definite, dando rilevanza al con-tenuto rispetto alla cornice ed eliminando immagini 3D e sfondi gradienti, in definitiva semplici. Il nuovo Skype, un’ap-plicazione di HP per la gestione del backup, l’interfaccia del nuovo TomTom sono solo alcuni degli esempi che trovere-mo con maggior frequenza sui nostri dispositivi fissi o mobili.Finora abbiamo compreso in generale le attuali tendenze in campo di user interface, l’origine e le idee che hanno inspi-rato Metro e i vari campi applicativi del nuovo linguaggio di design, passiamo adesso ad analizzare i principi su cui si basa.

PULITO, LEGGERO, APERTO E VELOCEPer realizzare un’interfaccia veloce e reattiva, dobbiamo porre un’attenzione particolare alle attività principali del sof-tware, mettendole in evidenza. Ad esempio, nel caso di una maschera di gestione contatti deve essere immediatamente riconoscibile la funzione di aggiunta di un contatto.Oppure, in un’applicazione di consultazione di blog, la fun-zione di refresh dovrà essere immediatamente riconoscibile e utilizzabileDi conseguenza, per mantenere la leggerezza dell’interfaccia è sicuramente meglio concentrarci sulle funzionalità fonda-mentali dell’applicazione senza “appesantirla” con pulsanti o controlli che distraggono l’utente dalla sua attività principale. Le funzionalità secondarie saranno poste in secondo piano, posizionate in menu alternativi o pagine specifiche. Ad esempio, la pagina di informazione del publisher sarà richiamata da un link posto in un menu secondario.In un ambiente “ristretto” come quello di un device mobile diventa fondamentale un altro principio di Metro: “fare tanto con poco”; cerchiamo quindi di nascondere dietro semplici gesture delle complesse logiche di business o applicative. Un esempio di questa tecnica è rappresentato dalla fun-zionalità di comunicazione asincrona e transazionale con i web service, sincronizzazione dei dati offline e calcolo delle statistiche online e offline con un semplice tap su una listbox.Un altro esempio è quello dell’uso di pannelli densi di logica applicativa, in grado di posizionare gli elementi in funzione del “peso” di ogni item, ma di immediata comprensione e utilizzo da parte dell’utente finale.Come abbiamo detto in precedenza Metro tende a eliminare il superfluo, quindi evitiamo gli sprechi in ogni loro forma, in

USER EXPERIENCESpesso lo sviluppatore sottova-luta molti degli aspetti legati alla user interface e alla user experience: non intendiamo che non sia in grado di costruire user interface carine o accattivanti, ma che sottovaluti l’importanza di aderire alle linee guida della piattaforma. Su una interfaccia di dimensioni ridotte e su un dispositivo che fa della user experience un suo punto di forza è fondamentale rispettare le linee guida: vi consigliamo cal-damente di leggere la “UI Design & Interaction Guide” che trovate a partire dalla home page per gli sviluppatori http://create.msdn.com.

XAMLPresentato pubblicamente a novembre 2003, il linguaggio eXtensible Application Markup Language, consente di definire tramite tag XML una gerarchia di oggetti di qualunque tipo. Attualmente XAML, viene uti-lizzato per la definizione degli elementi dell’interfaccia utente con WPF e Silverlight, per la cre-azione di documenti XPS e per la gestione di workflow creati con Workflow Foundation.

NOTA

NOTA

Fig. 1: Windows Phone 7 UI

MOBILEWindows Phone 7: l’interfaccia




termini di user experience ciò significa ridurre al minimo gli elementi sullo schermo. Spesso ci troviamo di fronte ad applicazioni piene zeppe di funzionalità accessorie che potrebbero essere utili solo al 2% degli utenti, mentre il rimanente 98% vivrebbe benis-simo senza; appesantire l’interfaccia utente con pulsanti o altri controlli non strettamente necessari all’applicazione ne diminiusce drasticamente l’usabilità. Questa tendenza non solo è importante per la realizzazione di applicazioni mobili ma anche per interfacce desktop o web, molto spesso infatti per accontentare quel 2% rendiamo più scomoda la fruibilità all’altro 98%. IPhone è un classico esempio di questo concet-to: le funzionalità necessarie alla maggioranza degli utenti sono esposte in modo estremamente chiaro e usabile, altre funzioni più complesse e meno utilizzate non sono state inserite nel sistema. Tornando a Metro, prendiamo ad esempio un pannello di configurazione delle impostazioni di un’applicazione, che potrebbe contenere “mille” controlli di personalizzazione e setup, ma dobbiamo scegliere con cura e inserire solo le parametrizzazioni più importanti per rendere più facile e semplice l’utilizzo da parte dell’utente.Per sostenere il concetto di leggerezza è fondamentale “non temere” gli spazi vuoti, aiutano la leggibilità dei testi, l’imme-diata comprensione delle funzionalità e danno anche risalto agli elementi chiave: è semplice capire infatti che aumentan-do la dimensione dello spazio fra due elementi, entrambi acquistano importanza sullo schermo. Nell’esempio di Fig.7, i vari radio button sono spaziati notevolmente fra di loro come suggeriscono le linee guida; questo non solo per rendere gli item facilmente “toccabili” ma anche per dargli la giusta importanza.

PRINCIPI DI TIPOGRAFIA Usare il carattere tipografico come elemento grafico, non solo come semplice testo ma sostituirlo all’utilizzo di immagi-ni iconografiche che spesso non sono comprensibili da parte dell’utente. Un bel carattere ha lo stesso impatto e la stessa forza di un’immagine e sicuramente è più esplicativo.In questo modo l’interfaccia utente non sarà un collage di testo e immagini, così frequente in ambito web, ma sarà omogenea, semplice, lineare e chiara; concetti chiave di Metro.

Microsoft per Windows Phone 7 ha progettato un nuovo font ad alti DPI in grado di supportare a pieno questo prin-cipio: Segoe WP. Consigliamo di utilizzarlo nei suoi vari pesi (bold, semibold, semilight ecc.) nelle applicazioni Silverlight che andrete a sviluppare. Mostriamo l’esempio di una dialog che consente all’utente

la scelta di un item all’interno di una listbox. In questo caso abbiamo usato una pagina separata per supportare il con-cetto di dialog, e scelto di utilizzare caratteri tipografici al posto di una cascata di icone, l’effetto finale è sicuramente più comprensibile ed elegante.Acquista quindi un’importanza fondamentale anche la scelta della dimensione del font, non solo per ovvi motivi di touch, ma anche per mettere in evidenza gli elementi principali.Nel caso della maschera del contatto, è infatti più importante l’azione di “call mobile”, che il dettaglio sul numero di tele-fono. Usando correttamente la tipografia, carattere, peso e dimensione aumenterà l’usabilità della nostra applicazione.

PRINCIPI DI MOVIMENTOLa transizione fra pagine è fondamentale come la proget-tazione delle stesse; l’utente esegue una serie di azioni fra applicazioni diverse, creando una vera e propria “storia” di navigazione, è importante quindi far comprendere chiara-mente dove si trovava e dove sta andando.Pur riducendo al minimo i pulsanti hardware, Windows Phone 7 non ha rinunciato ai pulsante hardware Start e Back che consentono all’utente una facile navigazione fra le pagi-ne di un’applicazione e fra software diversi.Il runtime di Windows Phone 7 ad ogni resume o launch delle nostre applicazioni creerà automaticamente un’ani-mazione in grado di far capire all’utente il cambiamento di contesto mantenendo uniforme la user experience. Tale animazione, oltre ad essere ottimizzata da un punto di vista dei consumi hardware, è poco invasiva e non rende

Fig. 3: Dimensione dei caratteri tipografici

Fig. 2: Navigazione fra applicazioni



il nostro stile di vita. Proviamo a confermare queste idee con alcuni esempi reali.Anche negli allestimenti di mostre contemporanee si tende a valorizzare solo le opere e non l’allestimento stesso, si ritorna a pareti bianche che ospitano gli elementi dell’esposizione; un esempio è l’installazione Shot di Wolfgang Tillmans alla Serpentine Gallery di Londra.Sommando tutte queste considerazioni arriviamo quindi a definire un’idea di gusto, eleganza e modernità basata sulla semplicità, essenzialità e valorizzazione del contenuto rispetto al contenitore, minimizzando gli sprechi in ogni loro forma.

LA FILOSOFIAL’abitudine, anche nel mondo dell’informatica, è di riutilizza-re idee che funzionano bene e “lucidarle” per farle apparire personali, fenomeno che in campo marketing viene definito come “me too”. Nel mondo dei device mobili, dopo l’innova-zione iPhone si è assistito a una serie di interfacce utenti molti simili l’una all’altra che non hanno portato innovazione ma solo piccole evoluzioni del prodotto originale. Microsoft, nello sviluppo dell’interfaccia di Windows Phone 7 si è discostata da questa tendenza creando un nuovo modo di intendere la presentazione e la fruizione di contenuti.Migliaia di prototipi e di casi d’uso hanno portato alle attuali specifiche e linee guida, un vero e proprio linguaggio di design, nome in codice Metro. Se l’obiettivo è quello di arrivare prima possibile alle informa-zioni necessarie, mantenendo alti gli standard di eleganza e stile, non si può prescindere dalla semplicità, caratteristica fondamentale del nuovo concetto di immagine e comuni-cazione, che si sta affermando in questi anni in diversi campi quali architettura, design, arte e pubblicità, come evidenziato in precendenza in questo articolo. Segue uno screenshot dell’interfaccia utente di Windows Phone 7, nello specifico della pagina Start (l’home page del sistema), contatti e calendarioMetropolitane, aereporti, stazioni ma anche strade, diven-tano il punto di partenza per un linguaggio basato sulla semplicità e sul movimento, che prende spunto dall’imme-diatezza visiva dei codici dei luoghi metropolitani e dagli stessi ne prende il nome.Le idee di Metro, trovano una naturale collocazione anche per applicazioni desktop o web, in quanto i principi fonda-mentali non sono dipendenti da una specifico sistema o piattaforma, potremmo infatti usare gli stessi concetti sia tramite XAML che con CSS/HTML, Java, Flash ecc.In casa Microsoft troviamo Zune, applicazione desktop per la gestione di contenuti multimediali, applicazioni Windows Phone 7 e altro, realizzata adattando le linee guida di Metro a un contesto desktop.In ambiente web possiamo evidenziare la nuova interfaccia di amministrazione di Windows Azure, realizzata intera-mente in Silverlight, scontato sottolineare che i concetti di chiarezza, linearità, semplicità di Metro si applicano anche a tale scenario.

Non solo Microsoft, ma anche molte altre importanti aziende di software stanno progettando le loro interfacce utilizzando icone essenziali, semplici e definite, dando rilevanza al con-tenuto rispetto alla cornice ed eliminando immagini 3D e sfondi gradienti, in definitiva semplici. Il nuovo Skype, un’ap-plicazione di HP per la gestione del backup, l’interfaccia del nuovo TomTom sono solo alcuni degli esempi che trovere-mo con maggior frequenza sui nostri dispositivi fissi o mobili.Finora abbiamo compreso in generale le attuali tendenze in campo di user interface, l’origine e le idee che hanno inspi-rato Metro e i vari campi applicativi del nuovo linguaggio di design, passiamo adesso ad analizzare i principi su cui si basa.

PULITO, LEGGERO, APERTO E VELOCEPer realizzare un’interfaccia veloce e reattiva, dobbiamo porre un’attenzione particolare alle attività principali del sof-tware, mettendole in evidenza. Ad esempio, nel caso di una maschera di gestione contatti deve essere immediatamente riconoscibile la funzione di aggiunta di un contatto.Oppure, in un’applicazione di consultazione di blog, la fun-zione di refresh dovrà essere immediatamente riconoscibile e utilizzabileDi conseguenza, per mantenere la leggerezza dell’interfaccia è sicuramente meglio concentrarci sulle funzionalità fonda-mentali dell’applicazione senza “appesantirla” con pulsanti o controlli che distraggono l’utente dalla sua attività principale. Le funzionalità secondarie saranno poste in secondo piano, posizionate in menu alternativi o pagine specifiche. Ad esempio, la pagina di informazione del publisher sarà richiamata da un link posto in un menu secondario.In un ambiente “ristretto” come quello di un device mobile diventa fondamentale un altro principio di Metro: “fare tanto con poco”; cerchiamo quindi di nascondere dietro semplici gesture delle complesse logiche di business o applicative. Un esempio di questa tecnica è rappresentato dalla fun-zionalità di comunicazione asincrona e transazionale con i web service, sincronizzazione dei dati offline e calcolo delle statistiche online e offline con un semplice tap su una listbox.Un altro esempio è quello dell’uso di pannelli densi di logica applicativa, in grado di posizionare gli elementi in funzione del “peso” di ogni item, ma di immediata comprensione e utilizzo da parte dell’utente finale.Come abbiamo detto in precedenza Metro tende a eliminare il superfluo, quindi evitiamo gli sprechi in ogni loro forma, in

USER EXPERIENCESpesso lo sviluppatore sottova-luta molti degli aspetti legati alla user interface e alla user experience: non intendiamo che non sia in grado di costruire user interface carine o accattivanti, ma che sottovaluti l’importanza di aderire alle linee guida della piattaforma. Su una interfaccia di dimensioni ridotte e su un dispositivo che fa della user experience un suo punto di forza è fondamentale rispettare le linee guida: vi consigliamo cal-damente di leggere la “UI Design & Interaction Guide” che trovate a partire dalla home page per gli sviluppatori http://create.msdn.com.

XAMLPresentato pubblicamente a novembre 2003, il linguaggio eXtensible Application Markup Language, consente di definire tramite tag XML una gerarchia di oggetti di qualunque tipo. Attualmente XAML, viene uti-lizzato per la definizione degli elementi dell’interfaccia utente con WPF e Silverlight, per la cre-azione di documenti XPS e per la gestione di workflow creati con Workflow Foundation.

NOTA

NOTA

Fig. 1: Windows Phone 7 UI



Windows Phone 7 programming METRO: L’INNOVATIVO LINGUAGGIO DI DESIGN


Un utente che usa il device si troverà più a suo agio con appli-cazioni basate sugli stessi concetti, ed eviterà o userà contro-voglia interfacce dispersive o “riciclate” da altri ambienti; ad esempio una user interface creata per Windows Mobile 6.5 usata su Windows Phone 7 risulterebbe obsoleta e quindi difficilmente vendibile.

COLORE DELLE APPWindows Phone 7 consente l’utilizzo di due temi: dark e light. Il primo usa come background delle applicazioni il colore nero e come colore del font il bianco. Il tema light sarà ovviamente l’opposto. Il tema di default è dark, tale scelta non è solo dettata da considerazioni stilistiche ma anche da un consumo minore della batteria, problema sentito dalla maggioranza degli utenti di smartphone. Durante la fase di sviluppo è fondamentale ricordarsi tale funzionalità, creando quindi un’interfaccia utente utilizzabile con entrambi i temi. Per le applicazioni Silverlight il runtime mette a disposizione stili già pronti in grado di cambiare il colore in base al tema scelto, in termini tecnici la piattaforma “inietterà” un ResourceDictionary a runtime che conterrà la definizione degli stili più appropriata. È sufficiente utilizzare come brush PhoneForegroundBrush. Oltre ai temi, l’utente può scegliere, da una lista predefinita, un colore in primo piano, o colore d’accento; tale colore verrà usato dal sistema e dalle nostre applicazioni per porre in evidenza contenuti specifici. Se usiamo Silverlight basta utilizzare come brush PhoneAccentBrush.

Expression Blend ha una comoda funzionalità in grado di poter cambiare al volo i temi e il colore d’accento diretta-mente dalla superficie di design, senza dover mandare in esecuzione l’applicazione.

GESTURE SUPPORTATEWindows Phone 7 utilizza solo gesture touch per comu-nicare input verso il sistema, diventa quindi importante comprendere quali sono le gesture supportate da utilizzare nelle nostre applicazioni. Per aumentare il senso di familiarità del nostro software, che ovviamente si traduce in maggior vendibilità, è importante inoltre comprendere come il dispo-sitivo utilizza tali gesture e in quali contesti. Le gesture sup-portate sono le seguenti:

1) Tap. Es: un’azione su un pulsante, checkbox, radiobutton o un item della listbox.

2) Double Tap. Es: per switchare rapidamente lo stato di zoom di un’applicazione.

3) Touch and Hold. Es: per visualizzare i menu contestuali. 4) Pan. Es: per muovere il contenuto tramite manipolazioni

dirette (il contenuto rimane “incollato” al dito e lo segue). 5) Flick. Es: per eseguire lo scrolling di una listbox.6) Pinch and Stretch. Es: per effettuare uno zoom continuo.

TOUCH DI UN OGGETTOUn elemento “toccabile dall’utente” deve avere una dimen-sione minima di 7mm, raccomandata di 9mm, lo spazio fra due elementi deve essere di almeno 2mm e la dimensione visuale di un controllo deve essere tra il 60 e il 100% della superficie toccabile dello stesso. Si consiglia di leggere il documento “UI Design and Interaction Guide for Windows Phone 7 v2.0” per maggiori dettagli sull’argomento.

I CONTROLLI A DISPOSIZIONELa piattaforma Silverlight for Windows Phone 7 mette a disposizione una serie di controlli comuni, ad esempio

Fig. 9: Applicazioni meteo a confrontoNOTA

EXPRESSION BLEND 4Se Visual Studio resta lo stru-mento principe per lo svilup-patore Silverlight e Windows

Presentation Foundation, le applicazioni moderne non possono prescindere dalla

realizzazione di interfacce utenti usabili, ricche e interattive.

Microsoft ha realizzato la suite Microsoft Expression Studio, che comprende, fra gli altri,

Expression Blend, lo strumento destinato a designer e creativi

per la realizzazione di interfacce basate su XAML.

Fig. 10: Expression Blend offre delle funzioni che permettono di cambiare al volo i temi e il colore d’accento

Fig. 11: Gesture supportate in Windows Phone 7



noiosa la transizione fra i diversi stati.È impossibile esprimere il concetto di movimento con imma-gine statiche. Le animazioni in Windows Phone 7 acquistano un ruolo importante, non solo per dare dei feedback imme-diati all’utente a fronte di gesture di touch, ma anche per mostrare cambiamenti di stato o evidenziare dei controlli di interfaccia utente.

CONTENUTO NON CONTENITORETutto quello che abbiamo visto finora, ovvero i principi di leg-gerezza, pulizia, spazio, tipografia, elementi in primo piano sono alla base del principio Metro “Content, not Chrome” (non inteso come browser), ovvero dare importanza al contenuto al posto della cornice. Il contenuto è l’interfaccia utente! Evitiamo il superfluo, ovvero evitiamo delle decorazioni che non hanno una diretta corrispondenza con le informazioni, renderemo così le nostre applicazioni non solo più utilizzabili ma anche più leggere. Ad esempio, nel caso di una playlist, è inutile utilizzare un’ico-na generica a fianco di ogni titolo, il solo testo è sufficiente per interagire con l’applicazione. Diverso però il caso di una lista di album, in cui l’immagine della copertina dell’album è più immediata del titolo.

AUTENTICAMENTE DIGITALEIn Windows Phone 7 niente è nascosto, gli elementi e le fun-zionalità sono facilmente visibili e rintracciabili e fanno solo quello per cui sono state progettate. Nel realizzare la nostra applicazione dobbiamo, non solo esplicitare gli elementi e le funzionalità senza inutili acces-sori, sia essi grafici che logici, ma anche essere autentici e coerenti con l’immagine che vogliamo trasmettere della nostra azienda.Essere diretti, questo è l’ultimo consiglio di questo importan-te principio; ad esempio, un link verso una pagina di richiesta di username/password deve avere come testo “login” o “sign in” e non un confuso “prova l’applicazione”, “inizia” o “vai” . Anche per i messaggi di errore è fondamentale essere sì

diretti, ma anche “amichevoli”, come se fosse un nostro amico a comunicarci l’eccezione. Da evitare quindi “impos-sibile connettersi al server. Errore 0x028271C”, meglio un “non posso inviare questa informazione su Internet, hai controllato se hai segnale?”. Prendiamo sempre ad esempio Save the Planet: se non si riesce a invocare il servizio di salvataggio su internet, l’applicazione presenta un messaggio utile per l’utente.

LINEE GUIDA: “FILI ROSSI”Vengono definiti “fili rossi” tre importanti concetti su cui si fonda la user experience di un device di nuova generazione come Windows Phone 7:1) Personale. Ad esempio, è l’utente che sceglie quali sono le

informazioni importanti da visualizzare nello Start, home page di Windows Phone 7.

2) Rilevante. Se prendiamo come esempio l’App Meteo, que-sta visualizza in primo piano le informazioni in base alla nostra attuale posizione GPS.

3) Connesso. La stessa applicazione meteo visualizza le infor-mazioni relative al tempo nelle città dove risiedono i nostri principali contatti.

CONSIGLI, NON IMPOSIZIONILe linee guida di Metro devono servire come traccia, come inspirazione per le nostre applicazioni, non devono essere lette però come una serie di leggi che ci impediscono di dare sfogo alla nostra creatività. Ci sono sicuramente un insieme di regole oggettive per quanto riguarda, ad esempio, la superficie minima di touch o lo spazio minimo tra controlli, l’idea di user experience, i concetti formali e stilistici sono comunque una scelta del progettista.Nel prossimo esempio vedremo due applicazioni meteo per Windows Phone 7, entrambe utilizzano completamente i concetti di Metro (tipografia, spazio fra gli elementi, sempli-cità, movimento, riduzione del superfluo ecc.) ma con scelte stilistiche diverse.Una domanda che viene spontanea a questo punto è: “se sono consigli, perchè dovrei seguirli a prescindere?” Perchè un’applicazione vincente è un’applicazione immediata, semplice, chiara e sopratutto che si integra perfettamente nell’ecosistema di Windows Phone 7.

Fig. 6: Ridurre al minimo gli elementi sullo schermo

Fig. 7: Utilizzo degli spazi vuoti

Fig. 8: Utilizzo dei caratteri tipografici

Fig. 5: Personale, rilevante e connesso: i “fili rossi” della UX

Fig. 4: Il contenuto come elemento dell’interfaccia utente





Un utente che usa il device si troverà più a suo agio con appli-cazioni basate sugli stessi concetti, ed eviterà o userà contro-voglia interfacce dispersive o “riciclate” da altri ambienti; ad esempio una user interface creata per Windows Mobile 6.5 usata su Windows Phone 7 risulterebbe obsoleta e quindi difficilmente vendibile.

COLORE DELLE APPWindows Phone 7 consente l’utilizzo di due temi: dark e light. Il primo usa come background delle applicazioni il colore nero e come colore del font il bianco. Il tema light sarà ovviamente l’opposto. Il tema di default è dark, tale scelta non è solo dettata da considerazioni stilistiche ma anche da un consumo minore della batteria, problema sentito dalla maggioranza degli utenti di smartphone. Durante la fase di sviluppo è fondamentale ricordarsi tale funzionalità, creando quindi un’interfaccia utente utilizzabile con entrambi i temi. Per le applicazioni Silverlight il runtime mette a disposizione stili già pronti in grado di cambiare il colore in base al tema scelto, in termini tecnici la piattaforma “inietterà” un ResourceDictionary a runtime che conterrà la definizione degli stili più appropriata. È sufficiente utilizzare come brush PhoneForegroundBrush. Oltre ai temi, l’utente può scegliere, da una lista predefinita, un colore in primo piano, o colore d’accento; tale colore verrà usato dal sistema e dalle nostre applicazioni per porre in evidenza contenuti specifici. Se usiamo Silverlight basta utilizzare come brush PhoneAccentBrush.

Expression Blend ha una comoda funzionalità in grado di poter cambiare al volo i temi e il colore d’accento diretta-mente dalla superficie di design, senza dover mandare in esecuzione l’applicazione.

GESTURE SUPPORTATEWindows Phone 7 utilizza solo gesture touch per comu-nicare input verso il sistema, diventa quindi importante comprendere quali sono le gesture supportate da utilizzare nelle nostre applicazioni. Per aumentare il senso di familiarità del nostro software, che ovviamente si traduce in maggior vendibilità, è importante inoltre comprendere come il dispo-sitivo utilizza tali gesture e in quali contesti. Le gesture sup-portate sono le seguenti:

1) Tap. Es: un’azione su un pulsante, checkbox, radiobutton o un item della listbox.

2) Double Tap. Es: per switchare rapidamente lo stato di zoom di un’applicazione.

3) Touch and Hold. Es: per visualizzare i menu contestuali. 4) Pan. Es: per muovere il contenuto tramite manipolazioni

dirette (il contenuto rimane “incollato” al dito e lo segue). 5) Flick. Es: per eseguire lo scrolling di una listbox.6) Pinch and Stretch. Es: per effettuare uno zoom continuo.

TOUCH DI UN OGGETTOUn elemento “toccabile dall’utente” deve avere una dimen-sione minima di 7mm, raccomandata di 9mm, lo spazio fra due elementi deve essere di almeno 2mm e la dimensione visuale di un controllo deve essere tra il 60 e il 100% della superficie toccabile dello stesso. Si consiglia di leggere il documento “UI Design and Interaction Guide for Windows Phone 7 v2.0” per maggiori dettagli sull’argomento.

I CONTROLLI A DISPOSIZIONELa piattaforma Silverlight for Windows Phone 7 mette a disposizione una serie di controlli comuni, ad esempio

Fig. 9: Applicazioni meteo a confrontoNOTA

EXPRESSION BLEND 4Se Visual Studio resta lo stru-mento principe per lo svilup-patore Silverlight e Windows

Presentation Foundation, le applicazioni moderne non possono prescindere dalla

realizzazione di interfacce utenti usabili, ricche e interattive.

Microsoft ha realizzato la suite Microsoft Expression Studio, che comprende, fra gli altri,

Expression Blend, lo strumento destinato a designer e creativi

per la realizzazione di interfacce basate su XAML.

Fig. 10: Expression Blend offre delle funzioni che permettono di cambiare al volo i temi e il colore d’accento

Fig. 11: Gesture supportate in Windows Phone 7



noiosa la transizione fra i diversi stati.È impossibile esprimere il concetto di movimento con imma-gine statiche. Le animazioni in Windows Phone 7 acquistano un ruolo importante, non solo per dare dei feedback imme-diati all’utente a fronte di gesture di touch, ma anche per mostrare cambiamenti di stato o evidenziare dei controlli di interfaccia utente.

CONTENUTO NON CONTENITORETutto quello che abbiamo visto finora, ovvero i principi di leg-gerezza, pulizia, spazio, tipografia, elementi in primo piano sono alla base del principio Metro “Content, not Chrome” (non inteso come browser), ovvero dare importanza al contenuto al posto della cornice. Il contenuto è l’interfaccia utente! Evitiamo il superfluo, ovvero evitiamo delle decorazioni che non hanno una diretta corrispondenza con le informazioni, renderemo così le nostre applicazioni non solo più utilizzabili ma anche più leggere. Ad esempio, nel caso di una playlist, è inutile utilizzare un’ico-na generica a fianco di ogni titolo, il solo testo è sufficiente per interagire con l’applicazione. Diverso però il caso di una lista di album, in cui l’immagine della copertina dell’album è più immediata del titolo.

AUTENTICAMENTE DIGITALEIn Windows Phone 7 niente è nascosto, gli elementi e le fun-zionalità sono facilmente visibili e rintracciabili e fanno solo quello per cui sono state progettate. Nel realizzare la nostra applicazione dobbiamo, non solo esplicitare gli elementi e le funzionalità senza inutili acces-sori, sia essi grafici che logici, ma anche essere autentici e coerenti con l’immagine che vogliamo trasmettere della nostra azienda.Essere diretti, questo è l’ultimo consiglio di questo importan-te principio; ad esempio, un link verso una pagina di richiesta di username/password deve avere come testo “login” o “sign in” e non un confuso “prova l’applicazione”, “inizia” o “vai” . Anche per i messaggi di errore è fondamentale essere sì

diretti, ma anche “amichevoli”, come se fosse un nostro amico a comunicarci l’eccezione. Da evitare quindi “impos-sibile connettersi al server. Errore 0x028271C”, meglio un “non posso inviare questa informazione su Internet, hai controllato se hai segnale?”. Prendiamo sempre ad esempio Save the Planet: se non si riesce a invocare il servizio di salvataggio su internet, l’applicazione presenta un messaggio utile per l’utente.

LINEE GUIDA: “FILI ROSSI”Vengono definiti “fili rossi” tre importanti concetti su cui si fonda la user experience di un device di nuova generazione come Windows Phone 7:1) Personale. Ad esempio, è l’utente che sceglie quali sono le

informazioni importanti da visualizzare nello Start, home page di Windows Phone 7.

2) Rilevante. Se prendiamo come esempio l’App Meteo, que-sta visualizza in primo piano le informazioni in base alla nostra attuale posizione GPS.

3) Connesso. La stessa applicazione meteo visualizza le infor-mazioni relative al tempo nelle città dove risiedono i nostri principali contatti.

CONSIGLI, NON IMPOSIZIONILe linee guida di Metro devono servire come traccia, come inspirazione per le nostre applicazioni, non devono essere lette però come una serie di leggi che ci impediscono di dare sfogo alla nostra creatività. Ci sono sicuramente un insieme di regole oggettive per quanto riguarda, ad esempio, la superficie minima di touch o lo spazio minimo tra controlli, l’idea di user experience, i concetti formali e stilistici sono comunque una scelta del progettista.Nel prossimo esempio vedremo due applicazioni meteo per Windows Phone 7, entrambe utilizzano completamente i concetti di Metro (tipografia, spazio fra gli elementi, sempli-cità, movimento, riduzione del superfluo ecc.) ma con scelte stilistiche diverse.Una domanda che viene spontanea a questo punto è: “se sono consigli, perchè dovrei seguirli a prescindere?” Perchè un’applicazione vincente è un’applicazione immediata, semplice, chiara e sopratutto che si integra perfettamente nell’ecosistema di Windows Phone 7.

Fig. 6: Ridurre al minimo gli elementi sullo schermo

Fig. 7: Utilizzo degli spazi vuoti

Fig. 8: Utilizzo dei caratteri tipografici

Fig. 5: Personale, rilevante e connesso: i “fili rossi” della UX

Fig. 4: Il contenuto come elemento dell’interfaccia utente



Windows Phone 7 programming MOBILEXNA sui nuovi device Windows Phone 7

Gennaio 2011 / 59 http://www.ioprogrammo.it

Grazie anche al recente debutto del nuovo sistema operativo per dispositivi mobili Windows Phone 7, che supporta unica-

mente applicazioni Silverlight e XNA, il framework nato per facilitare la vita a coloro che volevano cimentarsi nell’impresa di sviluppare un videogioco sta vivendo un rinnovato interesse da parte della comunità informatica.Tradizionalmente, programmare un videogioco non è mai stato un lavoro semplice. Prima che Microsoft rilasciasse le ormai celebri librerie DirectX, i pro-grammatori erano costretti a “sporcarsi le mani” per dialogare direttamente con le diverse schede video, schede audio, periferiche di input, e così via discor-rendo (possibilità peraltro esclusa sotto Windows 95, che imponeva severe restrizioni agli sviluppa-tori per quanto riguardava l’accesso alle risorse hardware). È solo grazie alle librerie DirectX che i programmatori hanno potuto cominciare a scrivere videogiochi in ambiente Windows che potessero andare bene su qualunque PC, a prescindere dal tipo di hardware di volta in volta presente sulla sin-gola macchina. Nel 2002, Microsoft decide di spingersi più avan-ti, rilasciando la prima API DirectX compatibile con l’allora emergente piattaforma .NET. Questa API, conosciuta con il nome di Managed DirectX (o MDX), permetteva di sfruttare le funzionalità DirectX direttamente in ambiente .NET, usandone i relativi linguaggi managed, come C# o VB.NET.Ampliata e perfezionata nella versione 2.0, questa libreria è stata tuttavia abbandonata da Microsoft nell’autunno 2006 a vantaggio di un nuovo e pro-mettente framework, appositamente dedicato allo sviluppo di videogiochi e perfettamente integrato nell’ambiente .NET: XNA, appunto.Rispetto ai suoi predecessori, XNA consente un livello di astrazione assai più elevato, consentendo agli sviluppatori di concentrarsi sul contenuto e la logica del gioco, piuttosto che sui dettagli imple-mentativi di basso livello. Allo stesso tempo, la pos-sibilità di creare propri shaders (oltre a quelli messi a disposizione dal framework) utilizzando l’High

Level Shader Language (HLSL) di casa Microsoft, consente di realizzare applicazioni 3D di grande qualità.

IL PRIMO PROGETTO IN XNAPer prendere un pò di familiarità con questo fra-mework, proviamo a creare il nostro primo progetto XNA (File New Project). Come si vede (Fig. 1), l’IDE ci permette di scegliere tra una serie predefinita di template, distinti in base alla piattaforma su cui vogliamo sviluppare (Windows Phone 7, Windows o Xbox 360) e alla natura del progetto, a seconda che ci interessi realizzare il gioco vero e proprio nella forma del classico eseguibile (per una delle tre piat-taforme disponibili), creare una libreria da referen-ziare nei nostri progetti, ovvero estendere e/o per-sonalizzare la “Content pipeline”, cioè quella parte del framework XNA che si preoccupa di importare e processare tutti i contenuti “unmanaged” (vedremo più avanti di che cosa si tratta).

Per la nostra piccola dimostrazione, scegliamo “Windows Phone Game (4.0)” come progetto inizia-le. Occorre tenere tuttavia presente che, per quanto riguarda la scelta della piattaforma di gioco, uno

REQUISITI


SoftwareÈ necessario installare i Developer Tools, scaricabili gratui-tamente a partire dall’indirizzo http://developer.windows-phone.com/windows-phone-7/

Impegno


XNA MOBILE PER I VIDEOGAMEWINDOWS PHONE 7 SI PRESENTA CON UNA USER INTERFACE COMPLETAMENTE NUOVA E CON UN AMBIENTE DI SVILUPPO BASATO SU SILVERLIGHT E XNA. IN QUESTO ARTICOLO INTRODUCIAMO XNA E LE SUE GRANDI POTENZIALITÀ IN AMBITO MOBILE

❑ CD ❑ WEBwindowsphonegame1.zip


Fig. 1: Nuovo progetto XNA

METRO: L’INNOVATIVO LINGUAGGIO DI DESIGN


Button, Slider, CheckBox, TextBox, RadioButton ecc., già aderenti alle specifiche Metro in termini di user experience, tipografia, colori e layout. Segnaliamo inoltre il toolkit messo a disposizione da Microsoft sul sito http://silverlight.code-plex.com/, che contiene un set di controlli già pronti che estendono le funzionalità di base del runtime, in tale libreria troviamo oggetti interessanti quali ContextMenu, DatePicker, TimePicker, ListPicker, LongListSelector e un semplice pattern per intercettare le gesture supportate dal sistema.Windows Phone 7 introduce il concetto di Application Bar, ovvero una toolbar applicativa in grado di contenere pul-santi e un menu. I pulsanti sono le azioni principali dell’in-terfaccia, mentre i menu, nascosti a prima vista e visibili solo dopo un’azione di espansione, contengono le operazioni secondarie dell’interfaccia, tutto questo si riallaccia al con-cetto espresso in precedenza sull’importanza di rendere immediatamente visibili solo le azioni principali.Metro consiglia di inserire nell’Application Bar fino a quattro icone. L’implementazione di un controllo tab in Metro acqui-sta il nome di Pivot, da utilizzarsi per mostrare visualizzazioni diverse della stessa entità, ad esempio e-mail lette, non lette, con flag ecc., oppure oroscopo del giorno, di domani o di ieri. Il controllo ha già abilitate le gesture di flick e tap per spostar-si da un tab all’altro. Visual Studio e Expression Blend hanno un template di progetto denominato Windows Phone Pivot Application, per realizzare facilmente applicazioni che utiliz-zano tale controllo. Windows Phone 7 e Metro introducono un nuovissimo paradigma di user experience, denomina-to Panorama application, al posto di progettare interfacce costrette all’interno dei confini dello schermo del device, le applicazioni “panoramiche” offrono un modo unico per visualizzare controlli, dati e servizi utilizzando un unico conte-nitore orizzontale che si estende oltre i confini dello schermo. Tali applicazioni dinamiche usano animazioni su layer diversi in modo da spostare fluidamente il contenuto rispetto al contenitore a velocità diverse per simulare un effetto paral-lasse. Il contesto di utilizzo di tale controllo è molteplice, si basa però sul concetto di hub, ovvero di raccoglitore/aggre-gatore di diverse fonti, ad esempio: video, musica, foto oppu-re notizie di oggi, previsioni meteo e informazioni sul traffico. Il controllo ha già abilitate le gesture di flick e pan per spo-starsi tra le varie sezioni o muovere l’area visibile.Visual Studio e Expression Blend hanno un template di pro-getto denominato Windows Phone Panorama Application, per realizzare facilmente applicazioni che utilizzano tale controllo. Di seguito mostriamo un’applicazione legata al mondo della vela in cui ogni sezione visualizza un contenuto applicativo differente: condizioni meteo, itinerari, punti di interessi e alert. Anche in questo caso, vi rimandiamo alla lettura del documento “UI Design and Interaction Guide for Windows Phone 7 v2.0” per avere maggiori dettagli in materia di controlli, pivot e panorama, sopratutto per quanto riguar-da le specifiche di dimensionamento dei vari oggetti.

ICONOGRAFIAA differenza degli altri device mobili, l’iconografia utilizzata

da Windows Phone 7, che racchiude tutti i principi di Metro è spogliata da colori e forme superflue, prende spunto come detto all’inizio dell’articolo dai codici della metropoli e si presenta all’utente con un semplice ma comprensibile segno grafico riconducibile ai cartelli stradali, alle indicazioni di metropolitane, aereporti e stazioni.È importante evidenziare che le icone dell’Application Bar cambiano di colore in base al tema utilizzato, noi dovremmo solo creare i file grafici per un tema (ad esempio foreground bianco e background nero), ci penserà il sistema a invertire i colori a runtime in base alla scelta dell’utente.All’interno dell’SDK troviamo una serie di icone già pronte all’utilizzo; Expression Blend, inoltre, ha un comodo browsing di tali immagini all’interno della dialog di personalizzazione dell’Application Bar.

CONCLUSIONIMetro è il nuovo linguaggio di design per applicazioni Windows Phone 7, oltre a contenere una serie di linee guida, suggerimenti e regole per la user experience offre diversi spunti riflessivi e creativi che possono essere trasportati anche in ambiente desktop e web su qualsiasi piattaforma.Metro si basa su concetti di semplicità, pulizia, chiarezza, evita lo spreco in ogni sua forma, mette l’utente al primo posto. La tipografia acquista un ruolo fondamentale all’in-terno dell’interfaccia utente, non semplice testi ma elementi grafici con profondità e spessore; l’uso del colore non è mai eccessivo, quindi il suo uso, relegato ad accenti applicativi, ne aumenta l’importanza. Due nuovi controlli Pivot e Panorama consentono di creare contesti applicativi che vivono in siner-gia con l’ecosistema del device dando vita a una nuova user experience decisamente moderna e innovativa.

Luca Regnicoli e Katia Egiziano

Luca Regnicoli è uno dei com-ponenti del gruppo DevLeap con il quale eroga formazione e consulenza di alto livello sulle tematiche tecniche inerenti la user experience: si occupa di WPF dal 2003 e di Silverlight dal 2006. E’ entrato nel programma beta di Windows Phone 7 a marzo 2010. Katia Egiziano collabora stabil-mente con ThinkAhead, società del gruppo DevLeap, per la realizzazione di user experience innovative. La sua esperienza pluriennale come architetto con-sente di guardare oltre i dettagli tecnici e ispirare lo sviluppo di applicazioni con influenze di altri movimenti artistici.

L’AUTORE

Fig. 12: Iconografia utilizzata in Windows Phone 7



Windows Phone 7 programmingXNA MOBILE PER I VIDEOGAME MOBILEXNA sui nuovi device Windows Phone 7


Grazie anche al recente debutto del nuovo sistema operativo per dispositivi mobili Windows Phone 7, che supporta unica-

mente applicazioni Silverlight e XNA, il framework nato per facilitare la vita a coloro che volevano cimentarsi nell’impresa di sviluppare un videogioco sta vivendo un rinnovato interesse da parte della comunità informatica.Tradizionalmente, programmare un videogioco non è mai stato un lavoro semplice. Prima che Microsoft rilasciasse le ormai celebri librerie DirectX, i pro-grammatori erano costretti a “sporcarsi le mani” per dialogare direttamente con le diverse schede video, schede audio, periferiche di input, e così via discor-rendo (possibilità peraltro esclusa sotto Windows 95, che imponeva severe restrizioni agli sviluppa-tori per quanto riguardava l’accesso alle risorse hardware). È solo grazie alle librerie DirectX che i programmatori hanno potuto cominciare a scrivere videogiochi in ambiente Windows che potessero andare bene su qualunque PC, a prescindere dal tipo di hardware di volta in volta presente sulla sin-gola macchina. Nel 2002, Microsoft decide di spingersi più avan-ti, rilasciando la prima API DirectX compatibile con l’allora emergente piattaforma .NET. Questa API, conosciuta con il nome di Managed DirectX (o MDX), permetteva di sfruttare le funzionalità DirectX direttamente in ambiente .NET, usandone i relativi linguaggi managed, come C# o VB.NET.Ampliata e perfezionata nella versione 2.0, questa libreria è stata tuttavia abbandonata da Microsoft nell’autunno 2006 a vantaggio di un nuovo e pro-mettente framework, appositamente dedicato allo sviluppo di videogiochi e perfettamente integrato nell’ambiente .NET: XNA, appunto.Rispetto ai suoi predecessori, XNA consente un livello di astrazione assai più elevato, consentendo agli sviluppatori di concentrarsi sul contenuto e la logica del gioco, piuttosto che sui dettagli imple-mentativi di basso livello. Allo stesso tempo, la pos-sibilità di creare propri shaders (oltre a quelli messi a disposizione dal framework) utilizzando l’High

Level Shader Language (HLSL) di casa Microsoft, consente di realizzare applicazioni 3D di grande qualità.

IL PRIMO PROGETTO IN XNAPer prendere un pò di familiarità con questo fra-mework, proviamo a creare il nostro primo progetto XNA (File New Project). Come si vede (Fig. 1), l’IDE ci permette di scegliere tra una serie predefinita di template, distinti in base alla piattaforma su cui vogliamo sviluppare (Windows Phone 7, Windows o Xbox 360) e alla natura del progetto, a seconda che ci interessi realizzare il gioco vero e proprio nella forma del classico eseguibile (per una delle tre piat-taforme disponibili), creare una libreria da referen-ziare nei nostri progetti, ovvero estendere e/o per-sonalizzare la “Content pipeline”, cioè quella parte del framework XNA che si preoccupa di importare e processare tutti i contenuti “unmanaged” (vedremo più avanti di che cosa si tratta).

Per la nostra piccola dimostrazione, scegliamo “Windows Phone Game (4.0)” come progetto inizia-le. Occorre tenere tuttavia presente che, per quanto riguarda la scelta della piattaforma di gioco, uno

REQUISITI


SoftwareÈ necessario installare i Developer Tools, scaricabili gratui-tamente a partire dall’indirizzo http://developer.windows-phone.com/windows-phone-7/

Impegno


XNA MOBILE PER I VIDEOGAMEWINDOWS PHONE 7 SI PRESENTA CON UNA USER INTERFACE COMPLETAMENTE NUOVA E CON UN AMBIENTE DI SVILUPPO BASATO SU SILVERLIGHT E XNA. IN QUESTO ARTICOLO INTRODUCIAMO XNA E LE SUE GRANDI POTENZIALITÀ IN AMBITO MOBILE

❑ CD ❑ WEBwindowsphonegame1.zip


Fig. 1: Nuovo progetto XNA


Button, Slider, CheckBox, TextBox, RadioButton ecc., già aderenti alle specifiche Metro in termini di user experience, tipografia, colori e layout. Segnaliamo inoltre il toolkit messo a disposizione da Microsoft sul sito http://silverlight.code-plex.com/, che contiene un set di controlli già pronti che estendono le funzionalità di base del runtime, in tale libreria troviamo oggetti interessanti quali ContextMenu, DatePicker, TimePicker, ListPicker, LongListSelector e un semplice pattern per intercettare le gesture supportate dal sistema.Windows Phone 7 introduce il concetto di Application Bar, ovvero una toolbar applicativa in grado di contenere pul-santi e un menu. I pulsanti sono le azioni principali dell’in-terfaccia, mentre i menu, nascosti a prima vista e visibili solo dopo un’azione di espansione, contengono le operazioni secondarie dell’interfaccia, tutto questo si riallaccia al con-cetto espresso in precedenza sull’importanza di rendere immediatamente visibili solo le azioni principali.Metro consiglia di inserire nell’Application Bar fino a quattro icone. L’implementazione di un controllo tab in Metro acqui-sta il nome di Pivot, da utilizzarsi per mostrare visualizzazioni diverse della stessa entità, ad esempio e-mail lette, non lette, con flag ecc., oppure oroscopo del giorno, di domani o di ieri. Il controllo ha già abilitate le gesture di flick e tap per spostar-si da un tab all’altro. Visual Studio e Expression Blend hanno un template di progetto denominato Windows Phone Pivot Application, per realizzare facilmente applicazioni che utiliz-zano tale controllo. Windows Phone 7 e Metro introducono un nuovissimo paradigma di user experience, denomina-to Panorama application, al posto di progettare interfacce costrette all’interno dei confini dello schermo del device, le applicazioni “panoramiche” offrono un modo unico per visualizzare controlli, dati e servizi utilizzando un unico conte-nitore orizzontale che si estende oltre i confini dello schermo. Tali applicazioni dinamiche usano animazioni su layer diversi in modo da spostare fluidamente il contenuto rispetto al contenitore a velocità diverse per simulare un effetto paral-lasse. Il contesto di utilizzo di tale controllo è molteplice, si basa però sul concetto di hub, ovvero di raccoglitore/aggre-gatore di diverse fonti, ad esempio: video, musica, foto oppu-re notizie di oggi, previsioni meteo e informazioni sul traffico. Il controllo ha già abilitate le gesture di flick e pan per spo-starsi tra le varie sezioni o muovere l’area visibile.Visual Studio e Expression Blend hanno un template di pro-getto denominato Windows Phone Panorama Application, per realizzare facilmente applicazioni che utilizzano tale controllo. Di seguito mostriamo un’applicazione legata al mondo della vela in cui ogni sezione visualizza un contenuto applicativo differente: condizioni meteo, itinerari, punti di interessi e alert. Anche in questo caso, vi rimandiamo alla lettura del documento “UI Design and Interaction Guide for Windows Phone 7 v2.0” per avere maggiori dettagli in materia di controlli, pivot e panorama, sopratutto per quanto riguar-da le specifiche di dimensionamento dei vari oggetti.

ICONOGRAFIAA differenza degli altri device mobili, l’iconografia utilizzata

da Windows Phone 7, che racchiude tutti i principi di Metro è spogliata da colori e forme superflue, prende spunto come detto all’inizio dell’articolo dai codici della metropoli e si presenta all’utente con un semplice ma comprensibile segno grafico riconducibile ai cartelli stradali, alle indicazioni di metropolitane, aereporti e stazioni.È importante evidenziare che le icone dell’Application Bar cambiano di colore in base al tema utilizzato, noi dovremmo solo creare i file grafici per un tema (ad esempio foreground bianco e background nero), ci penserà il sistema a invertire i colori a runtime in base alla scelta dell’utente.All’interno dell’SDK troviamo una serie di icone già pronte all’utilizzo; Expression Blend, inoltre, ha un comodo browsing di tali immagini all’interno della dialog di personalizzazione dell’Application Bar.

CONCLUSIONIMetro è il nuovo linguaggio di design per applicazioni Windows Phone 7, oltre a contenere una serie di linee guida, suggerimenti e regole per la user experience offre diversi spunti riflessivi e creativi che possono essere trasportati anche in ambiente desktop e web su qualsiasi piattaforma.Metro si basa su concetti di semplicità, pulizia, chiarezza, evita lo spreco in ogni sua forma, mette l’utente al primo posto. La tipografia acquista un ruolo fondamentale all’in-terno dell’interfaccia utente, non semplice testi ma elementi grafici con profondità e spessore; l’uso del colore non è mai eccessivo, quindi il suo uso, relegato ad accenti applicativi, ne aumenta l’importanza. Due nuovi controlli Pivot e Panorama consentono di creare contesti applicativi che vivono in siner-gia con l’ecosistema del device dando vita a una nuova user experience decisamente moderna e innovativa.

Luca Regnicoli e Katia Egiziano

Luca Regnicoli è uno dei com-ponenti del gruppo DevLeap con il quale eroga formazione e consulenza di alto livello sulle tematiche tecniche inerenti la user experience: si occupa di WPF dal 2003 e di Silverlight dal 2006. E’ entrato nel programma beta di Windows Phone 7 a marzo 2010. Katia Egiziano collabora stabil-mente con ThinkAhead, società del gruppo DevLeap, per la realizzazione di user experience innovative. La sua esperienza pluriennale come architetto con-sente di guardare oltre i dettagli tecnici e ispirare lo sviluppo di applicazioni con influenze di altri movimenti artistici.

L’AUTORE

Fig. 12: Iconografia utilizzata in Windows Phone 7



Windows Phone 7 programming XNA MOBILE PER I VIDEOGAME MOBILEXNA sui nuovi device Windows Phone 7


ne, istanziando la classe Game1 (creata di default dal framework e definita nel file Game1.cs) e invo-cando il relativo metodo Run.Chiariti gli aspetti per così dire “di contorno” del nostro progetto XNA, vediamo più da vicino quella che costituisce la vera e propria architrave desti-nata a sorreggere l’intera struttura di gioco, ossia la classe Game1, a sua volta derivata dalla classe base Microsoft.Xna.Framework.Game. Ed è proprio qui che emerge la differenza fondamentale rispetto ad altri ambiti di programmazione in ambiente .NET. Mentre infatti questi ultimi sono generalmen-te basati su controlli in grado di scatenare eventi, in XNA il concetto chiave è rappresentato dal “game loop”, ossia dalla continua iterazione fra l’aggior-namento della logica di gioco (come, ad esempio, la posizione e lo stato del giocatore e dei nemici, la posizione e l’orientamento della telecamera, la ricerca di eventuali input da parte dell’utente, etc.) e le operazioni di disegno a schermo. Questa struttu-ra ciclica, a ben vedere, è connaturata con l’essenza stessa di gioco, che deve potersi svolgere anche a prescindere da (o addirittura in assenza di) input da parte dell’utente. In XNA, il compito di iterare continuamente tra i diversi momenti di gioco (in particolare quello della logica e quello del disegno) è interamente demandato al framework, che vi provvede invocan-do i diversi metodi esposti dalla classe base Game secondo un preciso ordine, i cui passaggi principali

possono essere così riassunti (Fig. 5):Questi sono gli stessi metodi che trovate anche nella classe Game1, che provvede alla loro con-creta implementazione (tramite ovveride). I meto-di Initialize, LoadContent e UnloadContent sono invocati una sola volta, all’inizio o subito prima dell’uscita dal gioco. Il loop vero e proprio riguarda dunque due soli metodi: Update e Draw, chiama-ti ininterrottamente dal framework a intervalli di tempo più o meno regolari. Per l’esattezza, XNA ci lascia scegliere se preferiamo chiamare i due meto-di “a passo fisso” o “a passo variabile” (con risultati che possono influire significativamente sull’espe-rienza di gioco) semplicemente impostando la pro-prietà IsFixedTimeStep (di default true). Nel primo caso, i due metodi verranno chiamati a intervalli di tempo il più possibile regolari (che è possible specificare tramite la proprietà TargetElapsedTime). In questo caso, se il carico di lavoro dovessere ren-dere impossibile rispettare l’intervallo prefissato, XNA provvederà per noi a regolare l’iterazione tra i due metodi (saltando, ad esempio, alcune ope-razioni di disegno a schermo). Nel secondo caso, i due metodi verranno chiamati alternativamente nel mimimo intervallo di tempo possibile rispetto alla configurazione hardware della nostra macchina (e con conseguente fluttuazione del framerate in base al carico di lavoro di CPU e scheda grafica). Vediamo adesso la funzione dei suindicati metodi nel relativo ordine. Per prima cosa viene chiamato il costruttore di Game1, che si occupa di inizializzare l’oggetto GraphicsDeviceManager, cui compete la gestione della grafica del nostro device, di indicare la root in cui andare a cercare le risorse multimediali aggiun-te al nostro progetto Content e, nel caso di un’appli-cazione per Windows Phone 7, di fissare il framerate a 30 frame per secondo (fps) tramite la proprietà TargetElapsedTime:

public Game1()

{

graphics = new GraphicsDeviceManager(this);

Content.RootDirectory = “Content”;

// Frame rate is 30 fps by default for

Windows Phone.

TargetElapsedTime = TimeSpan.

FromTicks(333333);

}

Subito dopo è la volta del metodo Initialize, nel quale trova posto l’inizalizzazione di una serie di risorse utili ai fini del nostro gioco, come compo-nenti e servizi:

protected override void Initialize()

{

NOTA

ACRONIMO XNAIl nome XNA rappresenta un caso particolare di acronimo ricorsivo (molto in voga nel campo infor-matico), vale a dire un acronimo che, al suo inter-no, continene se stesso. XNA sta infatti per “XNA’s Not Acronymed”. A parte i giochi di parole (un acro-nimo che sta per qualcosa che “is not acronymed”), la sua particolarità nasce dal fatto che nel logo di XNA la parte arancione rappresenta la parola XNA in codice morse (linea – punto – punto – linea).

Fig. 5: Schema di funzionamento del Game Loop

Logo XNA

MOBILE XNA sui nuovi device Windows Phone 7

http://www.ioprogrammo.it 60 / Gennaio 2011

dei vantaggi più significativi nello sviluppo in XNA è dato proprio dall’estrema portabilità di un’appli-cazione da una piattaforma ad un’altra. In pratica, è sufficiente cliccare con il tasto destro sul progetto che intendiamo convertire e scegliere la piattafor-ma su cui vogliamo “migrare” (Fig. 2), lasciando al framework il compito di apportare le necessarie modifiche.

Una volta creato il nostro progetto, se tutto è andato a buon fine nella solution troveremo non uno, ma ben due progetti (Fig. 3). Il primo (nel nostro caso denominato WindowsPhoneGame1), costituisce il gioco vero e proprio e, come tale, è destinato a ospi-tare il codice e la logica necessari alla nostra appli-cazione per funzionare; il secondo (contraddistinto dal suffisso “Content” aggiunto automaticamente al nome del nostro progetto principale) è invece fina-

lizzato a raccogliere, importare e processare (tra-mite una Content pipeline) tutte le risorse “esterne” (definite asset) che utilizzeremo nel nostro gioco, quali ad esempio immagini e texture 2D, modelli 3D, suoni e audio etc. Un progetto di tipo Content è associato al progetto principale tramite la cartella “Content References” (Fig. 4). È possibile condividere lo stesso progetto Content fra giochi diversi (consentendo il riutilizzo di sprite, modelli e suoni tra diverse applicazioni), così come è possibile avere più progetti Content per uno stesso gioco (nel caso, ad esempio, che due giochi condividano alcune risorse, ma necessitino anche di risorse ulteriori diverse per ciascun gioco).In XNA, logica e contenuti si presentano dunque nettamente separati, non solo da un punto di vista concettuale, ma anche dal punto di vista architettu-rale, dal momento che danno vita a progetti distinti e (in una certa misura) autonomi. Vediamone bre-vemente le caratteristiche salienti.

IL PROGETTO PRINCIPALEUna volta scelto su quale piattaforma vogliamo far girare la nostra applicazione, e assegnato un nome al progetto, ci troviamo di fronte a una serie di file e cartelle creati di default da Visual Studio. La cartella “Properties” contiene i file che descri-vono il tipo di applicazione e che, di conseguenza, variano a seconda della piattaforma prescelta. Nel nostro caso, avendo scelto di realizzare un gioco per Windows Phone 7, i file sono ben tre: AssemblyInfo.cs (l’unico presente in un progetto per Windows e Xbox 360), che contiene le informa-zioni sull’assembly, AppManifest.xml che descrive le caratteristiche di deploy dell’applicazione (in modo analogo a quanto avviene per un progetto Silverlight per WP7) e WMAppManifest.xml che contiene informazioni specifiche su titolo, immagi-ne dell’applicazione, immagine per il tile, la versio-ne applicativa e il tipo di runtime (XNA nel nostro caso).Nel progetto principale troviamo anche la cartella “Content references” descritta sopra, oltre a due immagini, Background.png e GameThumbnail.png, che rappresentano le icone della nostra applicazio-ne sulla piattaforma di nostra scelta.Infine, come in qualunque applicazione .NET, Program.cs costituisce l’entry point dell’applicazio-

NOTA

STRUMENTI NECESSARI

Installare il pacchetto Windows Phone Developer

Tools (http://www.micro-soft.com/downloads/ en/

details.aspx?FamilyID= 04704acf-a63a-4f97-

952c- 8b51b34b00ce& displaylang=en), il quale

include, oltre a Visual Studio Express for

Windows Phone, l’emula-tore del nostro telefonino,

Silverlight 4 Tools ed Expression Blend 4 for

Windows Phone, anche l’apposita IDE denominata XNA Game Studio, attual-

mente giunta alla versione 4.0 (per i requisiti minimi

si rinvia alla relativa docu-mentazi one MSDN).

Fig. 2: Portabilità tra piattaforme Windows e XBOX 360

Fig. 4: La cartella Content References

Fig. 3: La nuova solution




ne, istanziando la classe Game1 (creata di default dal framework e definita nel file Game1.cs) e invo-cando il relativo metodo Run.Chiariti gli aspetti per così dire “di contorno” del nostro progetto XNA, vediamo più da vicino quella che costituisce la vera e propria architrave desti-nata a sorreggere l’intera struttura di gioco, ossia la classe Game1, a sua volta derivata dalla classe base Microsoft.Xna.Framework.Game. Ed è proprio qui che emerge la differenza fondamentale rispetto ad altri ambiti di programmazione in ambiente .NET. Mentre infatti questi ultimi sono generalmen-te basati su controlli in grado di scatenare eventi, in XNA il concetto chiave è rappresentato dal “game loop”, ossia dalla continua iterazione fra l’aggior-namento della logica di gioco (come, ad esempio, la posizione e lo stato del giocatore e dei nemici, la posizione e l’orientamento della telecamera, la ricerca di eventuali input da parte dell’utente, etc.) e le operazioni di disegno a schermo. Questa struttu-ra ciclica, a ben vedere, è connaturata con l’essenza stessa di gioco, che deve potersi svolgere anche a prescindere da (o addirittura in assenza di) input da parte dell’utente. In XNA, il compito di iterare continuamente tra i diversi momenti di gioco (in particolare quello della logica e quello del disegno) è interamente demandato al framework, che vi provvede invocan-do i diversi metodi esposti dalla classe base Game secondo un preciso ordine, i cui passaggi principali

possono essere così riassunti (Fig. 5):Questi sono gli stessi metodi che trovate anche nella classe Game1, che provvede alla loro con-creta implementazione (tramite ovveride). I meto-di Initialize, LoadContent e UnloadContent sono invocati una sola volta, all’inizio o subito prima dell’uscita dal gioco. Il loop vero e proprio riguarda dunque due soli metodi: Update e Draw, chiama-ti ininterrottamente dal framework a intervalli di tempo più o meno regolari. Per l’esattezza, XNA ci lascia scegliere se preferiamo chiamare i due meto-di “a passo fisso” o “a passo variabile” (con risultati che possono influire significativamente sull’espe-rienza di gioco) semplicemente impostando la pro-prietà IsFixedTimeStep (di default true). Nel primo caso, i due metodi verranno chiamati a intervalli di tempo il più possibile regolari (che è possible specificare tramite la proprietà TargetElapsedTime). In questo caso, se il carico di lavoro dovessere ren-dere impossibile rispettare l’intervallo prefissato, XNA provvederà per noi a regolare l’iterazione tra i due metodi (saltando, ad esempio, alcune ope-razioni di disegno a schermo). Nel secondo caso, i due metodi verranno chiamati alternativamente nel mimimo intervallo di tempo possibile rispetto alla configurazione hardware della nostra macchina (e con conseguente fluttuazione del framerate in base al carico di lavoro di CPU e scheda grafica). Vediamo adesso la funzione dei suindicati metodi nel relativo ordine. Per prima cosa viene chiamato il costruttore di Game1, che si occupa di inizializzare l’oggetto GraphicsDeviceManager, cui compete la gestione della grafica del nostro device, di indicare la root in cui andare a cercare le risorse multimediali aggiun-te al nostro progetto Content e, nel caso di un’appli-cazione per Windows Phone 7, di fissare il framerate a 30 frame per secondo (fps) tramite la proprietà TargetElapsedTime:

public Game1()

{

graphics = new GraphicsDeviceManager(this);



Windows Phone.


FromTicks(333333);

}

Subito dopo è la volta del metodo Initialize, nel quale trova posto l’inizalizzazione di una serie di risorse utili ai fini del nostro gioco, come compo-nenti e servizi:

protected override void Initialize()

{

NOTA

ACRONIMO XNAIl nome XNA rappresenta un caso particolare di acronimo ricorsivo (molto in voga nel campo infor-matico), vale a dire un acronimo che, al suo inter-no, continene se stesso. XNA sta infatti per “XNA’s Not Acronymed”. A parte i giochi di parole (un acro-nimo che sta per qualcosa che “is not acronymed”), la sua particolarità nasce dal fatto che nel logo di XNA la parte arancione rappresenta la parola XNA in codice morse (linea – punto – punto – linea).

Fig. 5: Schema di funzionamento del Game Loop

Logo XNA



dei vantaggi più significativi nello sviluppo in XNA è dato proprio dall’estrema portabilità di un’appli-cazione da una piattaforma ad un’altra. In pratica, è sufficiente cliccare con il tasto destro sul progetto che intendiamo convertire e scegliere la piattafor-ma su cui vogliamo “migrare” (Fig. 2), lasciando al framework il compito di apportare le necessarie modifiche.

Una volta creato il nostro progetto, se tutto è andato a buon fine nella solution troveremo non uno, ma ben due progetti (Fig. 3). Il primo (nel nostro caso denominato WindowsPhoneGame1), costituisce il gioco vero e proprio e, come tale, è destinato a ospi-tare il codice e la logica necessari alla nostra appli-cazione per funzionare; il secondo (contraddistinto dal suffisso “Content” aggiunto automaticamente al nome del nostro progetto principale) è invece fina-

lizzato a raccogliere, importare e processare (tra-mite una Content pipeline) tutte le risorse “esterne” (definite asset) che utilizzeremo nel nostro gioco, quali ad esempio immagini e texture 2D, modelli 3D, suoni e audio etc. Un progetto di tipo Content è associato al progetto principale tramite la cartella “Content References” (Fig. 4). È possibile condividere lo stesso progetto Content fra giochi diversi (consentendo il riutilizzo di sprite, modelli e suoni tra diverse applicazioni), così come è possibile avere più progetti Content per uno stesso gioco (nel caso, ad esempio, che due giochi condividano alcune risorse, ma necessitino anche di risorse ulteriori diverse per ciascun gioco).In XNA, logica e contenuti si presentano dunque nettamente separati, non solo da un punto di vista concettuale, ma anche dal punto di vista architettu-rale, dal momento che danno vita a progetti distinti e (in una certa misura) autonomi. Vediamone bre-vemente le caratteristiche salienti.

IL PROGETTO PRINCIPALEUna volta scelto su quale piattaforma vogliamo far girare la nostra applicazione, e assegnato un nome al progetto, ci troviamo di fronte a una serie di file e cartelle creati di default da Visual Studio. La cartella “Properties” contiene i file che descri-vono il tipo di applicazione e che, di conseguenza, variano a seconda della piattaforma prescelta. Nel nostro caso, avendo scelto di realizzare un gioco per Windows Phone 7, i file sono ben tre: AssemblyInfo.cs (l’unico presente in un progetto per Windows e Xbox 360), che contiene le informa-zioni sull’assembly, AppManifest.xml che descrive le caratteristiche di deploy dell’applicazione (in modo analogo a quanto avviene per un progetto Silverlight per WP7) e WMAppManifest.xml che contiene informazioni specifiche su titolo, immagi-ne dell’applicazione, immagine per il tile, la versio-ne applicativa e il tipo di runtime (XNA nel nostro caso).Nel progetto principale troviamo anche la cartella “Content references” descritta sopra, oltre a due immagini, Background.png e GameThumbnail.png, che rappresentano le icone della nostra applicazio-ne sulla piattaforma di nostra scelta.Infine, come in qualunque applicazione .NET, Program.cs costituisce l’entry point dell’applicazio-

NOTA

STRUMENTI NECESSARI

Installare il pacchetto Windows Phone Developer

Tools (http://www.micro-soft.com/downloads/ en/

details.aspx?FamilyID= 04704acf-a63a-4f97-

952c- 8b51b34b00ce& displaylang=en), il quale

include, oltre a Visual Studio Express for

Windows Phone, l’emula-tore del nostro telefonino,

Silverlight 4 Tools ed Expression Blend 4 for

Windows Phone, anche l’apposita IDE denominata XNA Game Studio, attual-

mente giunta alla versione 4.0 (per i requisiti minimi

si rinvia alla relativa docu-mentazi one MSDN).

Fig. 2: Portabilità tra piattaforme Windows e XBOX 360

Fig. 4: La cartella Content References

Fig. 3: La nuova solution


Windows Phone 7 programming XNA MOBILE PER I VIDEOGAME MOBILEXNA sui nuovi device Windows Phone 7


LA PRIMA APP XNAOra che abbiamo capito i fondamenti di funziona-mento di XNA, proviamo a sviluppare una sempli-cissima applicazione per il nostro telefonino con Windows Phone 7. Per prima cosa, abbiamo bisogno di aggiungere al nostro progetto Content una texture per il nostro sprite 2D (possibilmente in formato png per sfruttarne la trasparenza, ove presente) e di un effetto sonoro (in formato .mp3) per rendere la nostra demo più interessante (Fig. 7).È importante notare come, una volta importati all’in-

terno del progetto, gli asset assumano come nome di default quello del file originale, ma privo della rela-tiva estensione (visto che sono stati importati e pro-cessati dalla Content Pipeline). Da questo momento in poi, sarà solo il nome dell’asset a identificare le risorse utilizzate all’interno del progetto. Adesso che i nostri asset sono stati importati, pos-siamo usarli nella nostra applicazione. A livello di classe, aggiungiamo dunque una variabile per la nostra texture a due dimensioni e una per il nostro effetto sonoro; aggiungiamo anche una variabile di tipo Vector2(float x, float y) per memorizzate le coor-dinate del nostro sprite sullo schermo (inizialmente posizionato all’origine degli assi), nonché una secon-da variabile dello stesso tipo per settare la velocità con cui muovere lo sprite:

Texture2D sprite;

SoundEffect beep;

Vector2 position = Vector2.Zero;

Vector2 speed = new Vector2(1.0f, 3.0f);

Dopodiché, nel metodo LoadContent, carichiamo in memoria i relativi asset:

sprite = Content.Load<Texture2D>(“logo”);

beep = Content.Load<SoundEffect>(“beep”);

Nell’esempio allegato, l’immagine fa riferimento alla conferenza gratuita che organizziamo come DevLeap

dedicata a studenti e aziende. Il suono invece è un file wav che produce un semplice beep.A questo punto non ci rimane altro che animare il nostro sprite. In questa semplice demo, ci limiteremo a farlo muovere lungo lo schermo a velocità costante. Nel momento in cui lo sprite raggiungerà un bordo, inoltre, lo faremo “rimbalzare” (invertendo la velo-cità lungo l’asse corrispondente) e riprodurremo un beep per indicare l’avvenuto contatto con il bordo (divertente eh?). Per fare questo sono sufficienti poche righe di codice. Innanzitutto, preoccupiamoci di definire la logica nel metodo Update come segue:

position += speed;

if (position.X <= 0 || position.X >= Graphics

Device.Viewport.Width - sprite.Width) {

speed.X *= -1; beep.Play(); }

if (position.Y <= 0 || position.Y >= Graphics

Device.Viewport.Height - sprite.Height) {

speed.Y *= -1; beep.Play(); }

Da notare l’uso della proprietà GraphicsDevice.Viewport.Width e GraphicsDevice.Viewport.Height per recuperare le dimensioni dello schermo.Ciò fatto, possiamo procedere a disegnare il nostro sprite a schermo. Per far questo ci avvarremo dello speciale metodo Draw esposto dalla classe SpriteBatch, ossia la classe del framework che si occupa proprio di disegnare sprite a due dimen-sioni (per il testo, invece, occorre usare il metodo DrawString). Come parametri passeremo la texture del nostro sprite, la sua posizione sullo schermo e il colore. Ogni chiamata al metodo spriteBatch.Draw deve essere necessariamente preceduta da una chiamata al metodo spriteBatch.Begin, che permet-te di impostare alcune importanti proprietà relative, ad esempio, alla gestione delle trasparenze e all’or-dine con il quale i nostri sprite devono essere dise-gnati (nel nostro esempio, ci limiteremo a utilizzare le impostazioni di default, senza effettuare alcun overload), e deve concludersi con una chiamata al metodo spriteBatch.End, che provvede a resettare il device al suo stato originario:

protected override void Draw(GameTime gameTime) {

GraphicsDevice.Clear(Color.CornflowerBlue);

spriteBatch.Begin ();

spriteBatch.Draw(sprite, position, Color.White);

spriteBatch.End();

base.Draw(gameTime);

}

Se adesso premete F5, vedremo il vostro sprite prendere vita (ricordatevi di inclinare il vostro emu-latore, dal momento che, di default, il nostro device assume un orientamento di tipo “landscape”):

Roberto Brunetti, Vanni Boncinelli

Fig. 7: Importiamo gli asset

NOTA

EMULATOREWINDOWS PHONE 7Questa prima versione dell’emulatore non fornisce tutte le applicazioni che troveremo sul device fisico e sulle prossime versione degli emulatori stessi. Non è quindi lo strumento ad oggi più adatto a capire come verranno disposte e gestite le applicazioni. Per avere una idea precisa fate riferimento ai video presenti sul sito Channel 9: trovate i puntatori alle informazioni a partire dall’indirizzo http://deve-loper.windowsphone.com/windows-phone-7/.



// TODO: Add your initialization logic here

base.Initialize();

}

Il terzo metodo ad essere invocato in ordine tempo-rale è LoadContent, tramite il quale viene creato un oggetto di tipo SpriteBatch (al quale sono delegate le operazioni di disegno vero e proprio) e vengono caricate in memoria tutte le risorse di cui il nostro gioco necessita per poter funzionare (sprite, modelli 3D, shader, suoni, font, ecc.). L’operazione inversa è invece affidata al metodo UnloadContent, che prov-vede a “scaricare” dalla memoria le risorse prima di uscire dal gioco.

protected override void LoadContent()

{

base.Initialize();

}


protected override void LoadContent() {

spriteBatch = new SpriteBatch(GraphicsDevice);

}

Nel metodo Update trova spazio tutto ciò che con-cerne la logica del gioco, dalla posizione degli sprite sullo schermo, al rilevamento delle collisioni fra oggetti, dall’intelligenza artificiale dei nemici sino alla gestione degli eventuali input da parte dell’utente. Nella sua forma di default, il metodo Update si limita a gestire l’input strettamente neces-sario per uscire dal gioco (la pressione del tasto “Back”, nel caso di un gioco per Windows Phone 7):

protected override void Update(GameTime gameTime) {

// Allows the game to exit

if (GamePad.GetState(PlayerIndex.One).Buttons.

Back == ButtonState.Pressed)

this.Exit();

// TODO: Add your update logic here

base.Update(gameTime);

}

Il metodo Draw, invece, si preoccupa di tutte le ope-razioni di disegno a schermo di sprite bidimensio-anli, modelli 3D e persino scritte. Di default, ad ogni chiamata il metodo provvede a cancellare lo scher-

mo (GraphicsDevice.Clear) prima di qualunque altra operazione di scrittura a video e a impostare il colore del background (di default CornflowerBlue):

protected override void Draw(GameTime gameTime)

{



}

LA CONTENT PIPELINESi è detto prima come ogni asset (immagini, modelli 3D, suoni, ecc.), per essere utilizzato nel nostro gioco, deve essere prima importato e processato tramite una content pipeline. Quest’ultima prov-vede ad associare ad ogni file aggiunto nel progetto di tipo Content due particolari classi: un importer e un processor. L’importer ha il compito di “tradurre” questi file in un formato standard, che potrà esse-re successivamente interpretato dal processor, in modo da arrivare ad una forma che sia facilmente “consumabile” dal runtime. La ragione per cui XNA ricorre ad una content pipe-line, risiede nell’incremento delle prestazioni. Senza di questa, le risorse dovrebbero essere cari-cate nel loro formato originario e il gioco, prima di poterle utilizzare, dovrebbe convertirle a runtime in una forma che possa essere utilizzata all’inter-no dell’applicazione, aumentando molto i tempi di attesa. La content pipeline rimedia appunto a questo problema, anticipando la conversione degli asset al momento della compilazione dei sorgenti.Per importare un asset nel nostro gioco è sufficien-te cliccare con il tasto destro sul progetto di tipo Content, selezionare “Add Existing Item” e scegliere il file da aggiungere (oppure, più semplicemente, possiamo trascinare il file direttamente nel nostro progetto). Sarà lo stesso framework a scegliere per noi il tipo di importer e di processor adeguati, come mostrato in Fig. 6:

Fig. 6: Content Pipeline importers

SUL WEB

FORUM SPECIFICI SU WINDOWS

PHONE 7Su www.thinkmobile.it sono disponibili forum

specifici per trattare lo svi-luppo su Windows Phone

7; due blog che forniscono informazioni continue sulle

novità per gli sviluppatori e nella sezione media si

trovano numerosi esempi sull’utilizzo dei sensori e

delle varie funzionalità del device.




LA PRIMA APP XNAOra che abbiamo capito i fondamenti di funziona-mento di XNA, proviamo a sviluppare una sempli-cissima applicazione per il nostro telefonino con Windows Phone 7. Per prima cosa, abbiamo bisogno di aggiungere al nostro progetto Content una texture per il nostro sprite 2D (possibilmente in formato png per sfruttarne la trasparenza, ove presente) e di un effetto sonoro (in formato .mp3) per rendere la nostra demo più interessante (Fig. 7).È importante notare come, una volta importati all’in-

terno del progetto, gli asset assumano come nome di default quello del file originale, ma privo della rela-tiva estensione (visto che sono stati importati e pro-cessati dalla Content Pipeline). Da questo momento in poi, sarà solo il nome dell’asset a identificare le risorse utilizzate all’interno del progetto. Adesso che i nostri asset sono stati importati, pos-siamo usarli nella nostra applicazione. A livello di classe, aggiungiamo dunque una variabile per la nostra texture a due dimensioni e una per il nostro effetto sonoro; aggiungiamo anche una variabile di tipo Vector2(float x, float y) per memorizzate le coor-dinate del nostro sprite sullo schermo (inizialmente posizionato all’origine degli assi), nonché una secon-da variabile dello stesso tipo per settare la velocità con cui muovere lo sprite:

Texture2D sprite;

SoundEffect beep;

Vector2 position = Vector2.Zero;

Vector2 speed = new Vector2(1.0f, 3.0f);

Dopodiché, nel metodo LoadContent, carichiamo in memoria i relativi asset:

sprite = Content.Load<Texture2D>(“logo”);

beep = Content.Load<SoundEffect>(“beep”);

Nell’esempio allegato, l’immagine fa riferimento alla conferenza gratuita che organizziamo come DevLeap

dedicata a studenti e aziende. Il suono invece è un file wav che produce un semplice beep.A questo punto non ci rimane altro che animare il nostro sprite. In questa semplice demo, ci limiteremo a farlo muovere lungo lo schermo a velocità costante. Nel momento in cui lo sprite raggiungerà un bordo, inoltre, lo faremo “rimbalzare” (invertendo la velo-cità lungo l’asse corrispondente) e riprodurremo un beep per indicare l’avvenuto contatto con il bordo (divertente eh?). Per fare questo sono sufficienti poche righe di codice. Innanzitutto, preoccupiamoci di definire la logica nel metodo Update come segue:

position += speed;

if (position.X <= 0 || position.X >= Graphics

Device.Viewport.Width - sprite.Width) {

speed.X *= -1; beep.Play(); }

if (position.Y <= 0 || position.Y >= Graphics

Device.Viewport.Height - sprite.Height) {

speed.Y *= -1; beep.Play(); }

Da notare l’uso della proprietà GraphicsDevice.Viewport.Width e GraphicsDevice.Viewport.Height per recuperare le dimensioni dello schermo.Ciò fatto, possiamo procedere a disegnare il nostro sprite a schermo. Per far questo ci avvarremo dello speciale metodo Draw esposto dalla classe SpriteBatch, ossia la classe del framework che si occupa proprio di disegnare sprite a due dimen-sioni (per il testo, invece, occorre usare il metodo DrawString). Come parametri passeremo la texture del nostro sprite, la sua posizione sullo schermo e il colore. Ogni chiamata al metodo spriteBatch.Draw deve essere necessariamente preceduta da una chiamata al metodo spriteBatch.Begin, che permet-te di impostare alcune importanti proprietà relative, ad esempio, alla gestione delle trasparenze e all’or-dine con il quale i nostri sprite devono essere dise-gnati (nel nostro esempio, ci limiteremo a utilizzare le impostazioni di default, senza effettuare alcun overload), e deve concludersi con una chiamata al metodo spriteBatch.End, che provvede a resettare il device al suo stato originario:

protected override void Draw(GameTime gameTime) {


spriteBatch.Begin ();

spriteBatch.Draw(sprite, position, Color.White);

spriteBatch.End();


}

Se adesso premete F5, vedremo il vostro sprite prendere vita (ricordatevi di inclinare il vostro emu-latore, dal momento che, di default, il nostro device assume un orientamento di tipo “landscape”):

Roberto Brunetti, Vanni Boncinelli

Fig. 7: Importiamo gli asset

NOTA

EMULATOREWINDOWS PHONE 7Questa prima versione dell’emulatore non fornisce tutte le applicazioni che troveremo sul device fisico e sulle prossime versione degli emulatori stessi. Non è quindi lo strumento ad oggi più adatto a capire come verranno disposte e gestite le applicazioni. Per avere una idea precisa fate riferimento ai video presenti sul sito Channel 9: trovate i puntatori alle informazioni a partire dall’indirizzo http://deve-loper.windowsphone.com/windows-phone-7/.



// TODO: Add your initialization logic here

base.Initialize();

}



{

base.Initialize();

}


protected override void LoadContent() {


}

Nel metodo Update trova spazio tutto ciò che con-cerne la logica del gioco, dalla posizione degli sprite sullo schermo, al rilevamento delle collisioni fra oggetti, dall’intelligenza artificiale dei nemici sino alla gestione degli eventuali input da parte dell’utente. Nella sua forma di default, il metodo Update si limita a gestire l’input strettamente neces-sario per uscire dal gioco (la pressione del tasto “Back”, nel caso di un gioco per Windows Phone 7):

protected override void Update(GameTime gameTime) {


if (GamePad.GetState(PlayerIndex.One).Buttons.

Back == ButtonState.Pressed)

this.Exit();



}

Il metodo Draw, invece, si preoccupa di tutte le ope-razioni di disegno a schermo di sprite bidimensio-anli, modelli 3D e persino scritte. Di default, ad ogni chiamata il metodo provvede a cancellare lo scher-

mo (GraphicsDevice.Clear) prima di qualunque altra operazione di scrittura a video e a impostare il colore del background (di default CornflowerBlue):

protected override void Draw(GameTime gameTime)

{



}

LA CONTENT PIPELINESi è detto prima come ogni asset (immagini, modelli 3D, suoni, ecc.), per essere utilizzato nel nostro gioco, deve essere prima importato e processato tramite una content pipeline. Quest’ultima prov-vede ad associare ad ogni file aggiunto nel progetto di tipo Content due particolari classi: un importer e un processor. L’importer ha il compito di “tradurre” questi file in un formato standard, che potrà esse-re successivamente interpretato dal processor, in modo da arrivare ad una forma che sia facilmente “consumabile” dal runtime. La ragione per cui XNA ricorre ad una content pipe-line, risiede nell’incremento delle prestazioni. Senza di questa, le risorse dovrebbero essere cari-cate nel loro formato originario e il gioco, prima di poterle utilizzare, dovrebbe convertirle a runtime in una forma che possa essere utilizzata all’inter-no dell’applicazione, aumentando molto i tempi di attesa. La content pipeline rimedia appunto a questo problema, anticipando la conversione degli asset al momento della compilazione dei sorgenti.Per importare un asset nel nostro gioco è sufficien-te cliccare con il tasto destro sul progetto di tipo Content, selezionare “Add Existing Item” e scegliere il file da aggiungere (oppure, più semplicemente, possiamo trascinare il file direttamente nel nostro progetto). Sarà lo stesso framework a scegliere per noi il tipo di importer e di processor adeguati, come mostrato in Fig. 6:

Fig. 6: Content Pipeline importers

SUL WEB

FORUM SPECIFICI SU WINDOWS

PHONE 7Su www.thinkmobile.it sono disponibili forum

specifici per trattare lo svi-luppo su Windows Phone

7; due blog che forniscono informazioni continue sulle

novità per gli sviluppatori e nella sezione media si

trovano numerosi esempi sull’utilizzo dei sensori e

delle varie funzionalità del device.


Windows Phone 7 programming UN VIDEOGIOCO PER WINDOWS PHONE 7

Marzo 2011 / 67 http://www.ioprogrammo. i t

scelto un originale ShootemUp per l’esempio), e quindi confermate con un clic sul pulsante OK. Visual Studio 2010 si occuperà di creare per noi una soluzione contenente diversi file e ci mostre-rà subito una finestra con il codice della classe Game1. Potete subito provare a eseguire il gioco, per verificare che tutto funzioni. Avviando il gioco in modalità Debug (premete F5) infatti verrà avviato l’emulatore di Windows Phone e dopo qualche secondo sarà mostrata sullo schermo vir-tuale del dispositivo una schermata interamente blu. Al momento inutile, ma che confermerà la corretta esecuzione del tutto.

Il file game1.cs, è la classe in esso contenuta Game1, è al momento il cuore del nostro pro-getto. Anzi, al momento contiene tutto il codice necessario all’esecuzione del gioco. La classe Game1 deriva infatti dalla classe Microsoft.Xna.Framework.Game, che fornisce i metodi base per l’inizializzazione delle funzioni grafiche del dispo-sitivo, per la gestione della logica del gioco e per il codice che si occuperà del rendering grafico.Il framework XNA, se si esegue l’applicazione su Windows Phone, va alla ricerca di una classe del

progetto che derivi da Game, quindi essa rappre-senta il punto di ingresso dell’applicazione stessa, in questo caso del videogioco.Per porre delle solide fondamenta alla conoscen-za del Framework e al suo funzionamento, analiz-zeremo ora la struttura della classe Game1, così come è stata creata per noi dal template. La classe inizia con una sezione dichiarativa contenente due campi:

GraphicsDeviceManager graphics;

SpriteBatch spriteBatch;

L’oggetto graphics fornisce l’accesso alle funzio-nalità video, mentre l’oggetto di classe SpriteBatch permetterà di disegnare sullo schermo immagini 2D (dette sprite) in maniera molto rapida ed effi-ciente.Il costruttore della classe si occupa di istanziare l’oggetto graphics ed imposta la directory di default per l’oggetto Content, che sarà utilizzato per caricare immagini, suoni e altri contenuti necessari per l’esecuzione del gioco. Infine imposta la velocità di aggiornamento del gioco, cioè l’intervallo di tempo utilizzato per invocare il metodo Update, che di default è di 30 frame/secondo per Windows Phone:

public Game1()

{

graphics = new

GraphicsDeviceManager(this);



Windows Phone.


FromTicks(333333);

}

Dopo l’esecuzione del costruttore verrà invocato il metodo Initialize, all’interno del quale è possi-bile inizializzare ogni oggetto necessario all’ese-cuzione, per esempio verificando la presenza di servizi esterni o caricando risorse grafiche e non. Il metodo Initialize invocherà implicitamente anche il metodo LoadContent, che si occupa di recuperare e caricare tutti gli elementi multime-diali del gioco. All’interno del metodo LoadContent viene inizia-lizzato l’oggetto SpriteBatch che sarà utilizzato per disegnare gli oggetto del gioco sullo schermo nel metodo Draw che vedremo a breve.Una volta che il metodo LoadContent termina il suo compito, il videogame entra in un ciclo infini-to, nel quale verrà tentato di invocare un metodo di aggiornamento a intervalli regolari, stabiliti dal valore di TargetElapsedTime impostato nel

WINDOWS PHONE DEVELOPER TOOLSPer preparare la propria piatta-forma di sviluppo in maniera da poter immediatamente iniziare a sviluppare per i dispositivi dotati di Windows Phone 7, occorre scaricare e installare i Windows Phone Developer Tools. Basta visitare il sito dedicato http://create.msdn.com/en-us/home/getting_started e quindi cliccare il link Install Now nella sezione download the free tools. L’installer è intelligente e instal-lerà solo i componenti mancanti. Per esempio, se non si possiede una versione di Visual Studio 2010, verrà installata la versione Express, così come se non si ha a disposizione Expression Blend, verrà installato Expression Blend for Windows Phone. Gli altri componenti necessari e che verranno eventualmente instal-lati sono il .NET Framework 4.0, Silverlight, XNA Game Studio 4.0 ed il Windows Phone Emulator.

NOTA

Fig. 2 L’emulatore di Windows Phone 7 in azione

MOBILEXNA e Windows Phone 7

http://www.ioprogrammo. i t 66 / Marzo 2011


Conoscenza di base del .NET Framework e di C#

Software

Visual Studio 2010, Windows Phone Developer Tools

Impegno


❑ CD ❑ WEBvideogame_xna_parte1.zipcdrom.ioprogrammo.it

UN VIDEOGIOCO PER WINDOWS PHONE 7LO SVILUPPO DI UN VIDEOGIOCO PER GLI SMARTPHONE DOTATI DI WINDOWS PHONE 7 È ORA SEMPLICE ED IMMEDIATO GRAZIE AL FRAMEWORK XNA. IN QUESTA PRIMA PARTE IMPAREREMO A CONOSCERNE E SFRUTTARNE LE POTENZIALITÀ DI BASE

L’ultimo sistema operativo dedicato al mondo mobile di casa Microsoft ha apportato novi-tà significative rispetto ai suoi predecessori,

quelli della serie Windows Mobile. L’interfaccia è stata totalmente ridisegnata, così come è nuovo il modo di utilizzare il dispositivo, di conseguenza anche gli strumenti per lo sviluppo di software sono totalmente nuovi. Per sviluppare su Windows Phone 7 è necessario installare innanzitutto il pacchetto denominato Windows Phone Developer Tools (vedi box) e poi utilizzare l’IDE di casa Microsoft, Visual Studio 2010, anche nella versione Express. I tool suddetti aggiungono a Visual Studio una serie di template, dedicati alla programmazione Silverlight oppure a quella XNA, oltre a permettere di simulare perfet-tamente l’esecuzione di applicazioni o videogame mediante un nuovo emulatore.Questo articolo ha l’obiettivo di introdurre il lettore allo sviluppo di videogiochi per i dispo-sitivi basati su Windows Phone 7 mediante il framework XNA, mostrando innanzitutto quali sono le caratteristiche e le possibilità messe a nostra disposizione, fino ad arrivare a creare un vero e proprio videogame, semplice ma completo e pronto ad essere eventualmente pubblicato sul portale Microsoft.

COS’È XNALa piattaforma di sviluppo Windows Phone forni-sce due differenti framework per svilupapre appli-cazioni per i nuovi dispositivi dotati del nuovo sistema operativo:Il Silverlight Framework per applicazioni event-driven e basate su XAML, che consente di creare qualunque tipo di applicazioni e XNA Framework per lo sviluppo di videogiochi loop-based, con grafica, animazioni, suoni, che permettano di immergere il giocatore in una nuova esperienza di intrattenimento e divertimento.Il secondo è logicamente la scelta che faremo

nel seguito di questo articolo (anche se lo stesso Silverlight consentirebbe lo sviluppo di un vide-ogame con meno requisiti grafici). XNA tenta di semplificare la maggior parte dei compiti neces-sari nello sviluppo di un videogioco, fornendo le classi per gestire il ciclo di vita del gioco, l’ag-giornamento del suo stato e la visualizzazione ed interazione con gli oggetti grafici sullo schermo.Naturalmente, tutte le caratteristiche del dispo-sitivo sono disponibili e utilizzabili all’interno di un videogame: pensate ad esempio cosa potreste fare sfruttando il display multitouch e l’accelero-metro.

CREIAMO IL PROGETTODopo aver installato i Windows Phone Developer Tools, l’ambiente di sviluppo Visual Studio 2010 sarà arricchito da nuove caratteristiche e funzio-nalità che ci permetteranno facilmente di entrare nel mondo dello sviluppo Windows Phone in generale.Creare un progetto per un videogame a questo punto è semplicissimo. Basta utilizzare il menu File -> New Project, quindi dalla sezione XNA Game Studio 4.0, scegliere il template Windows Phone Game. Date un nome al vostro videogame, (abbiamo

Fig. 1: I template per creare applicazioni Windows Phone 7

MOBILE XNA e Windows Phone 7


Windows Phone 7 programmingUN VIDEOGIOCO PER WINDOWS PHONE 7


scelto un originale ShootemUp per l’esempio), e quindi confermate con un clic sul pulsante OK. Visual Studio 2010 si occuperà di creare per noi una soluzione contenente diversi file e ci mostre-rà subito una finestra con il codice della classe Game1. Potete subito provare a eseguire il gioco, per verificare che tutto funzioni. Avviando il gioco in modalità Debug (premete F5) infatti verrà avviato l’emulatore di Windows Phone e dopo qualche secondo sarà mostrata sullo schermo vir-tuale del dispositivo una schermata interamente blu. Al momento inutile, ma che confermerà la corretta esecuzione del tutto.

Il file game1.cs, è la classe in esso contenuta Game1, è al momento il cuore del nostro pro-getto. Anzi, al momento contiene tutto il codice necessario all’esecuzione del gioco. La classe Game1 deriva infatti dalla classe Microsoft.Xna.Framework.Game, che fornisce i metodi base per l’inizializzazione delle funzioni grafiche del dispo-sitivo, per la gestione della logica del gioco e per il codice che si occuperà del rendering grafico.Il framework XNA, se si esegue l’applicazione su Windows Phone, va alla ricerca di una classe del

progetto che derivi da Game, quindi essa rappre-senta il punto di ingresso dell’applicazione stessa, in questo caso del videogioco.Per porre delle solide fondamenta alla conoscen-za del Framework e al suo funzionamento, analiz-zeremo ora la struttura della classe Game1, così come è stata creata per noi dal template. La classe inizia con una sezione dichiarativa contenente due campi:

GraphicsDeviceManager graphics;

SpriteBatch spriteBatch;

L’oggetto graphics fornisce l’accesso alle funzio-nalità video, mentre l’oggetto di classe SpriteBatch permetterà di disegnare sullo schermo immagini 2D (dette sprite) in maniera molto rapida ed effi-ciente.Il costruttore della classe si occupa di istanziare l’oggetto graphics ed imposta la directory di default per l’oggetto Content, che sarà utilizzato per caricare immagini, suoni e altri contenuti necessari per l’esecuzione del gioco. Infine imposta la velocità di aggiornamento del gioco, cioè l’intervallo di tempo utilizzato per invocare il metodo Update, che di default è di 30 frame/secondo per Windows Phone:

public Game1()

{

graphics = new

GraphicsDeviceManager(this);



Windows Phone.


FromTicks(333333);

}

Dopo l’esecuzione del costruttore verrà invocato il metodo Initialize, all’interno del quale è possi-bile inizializzare ogni oggetto necessario all’ese-cuzione, per esempio verificando la presenza di servizi esterni o caricando risorse grafiche e non. Il metodo Initialize invocherà implicitamente anche il metodo LoadContent, che si occupa di recuperare e caricare tutti gli elementi multime-diali del gioco. All’interno del metodo LoadContent viene inizia-lizzato l’oggetto SpriteBatch che sarà utilizzato per disegnare gli oggetto del gioco sullo schermo nel metodo Draw che vedremo a breve.Una volta che il metodo LoadContent termina il suo compito, il videogame entra in un ciclo infini-to, nel quale verrà tentato di invocare un metodo di aggiornamento a intervalli regolari, stabiliti dal valore di TargetElapsedTime impostato nel

WINDOWS PHONE DEVELOPER TOOLSPer preparare la propria piatta-forma di sviluppo in maniera da poter immediatamente iniziare a sviluppare per i dispositivi dotati di Windows Phone 7, occorre scaricare e installare i Windows Phone Developer Tools. Basta visitare il sito dedicato http://create.msdn.com/en-us/home/getting_started e quindi cliccare il link Install Now nella sezione download the free tools. L’installer è intelligente e instal-lerà solo i componenti mancanti. Per esempio, se non si possiede una versione di Visual Studio 2010, verrà installata la versione Express, così come se non si ha a disposizione Expression Blend, verrà installato Expression Blend for Windows Phone. Gli altri componenti necessari e che verranno eventualmente instal-lati sono il .NET Framework 4.0, Silverlight, XNA Game Studio 4.0 ed il Windows Phone Emulator.

NOTA

Fig. 2 L’emulatore di Windows Phone 7 in azione




Conoscenza di base del .NET Framework e di C#

Software


Impegno



UN VIDEOGIOCO PER WINDOWS PHONE 7LO SVILUPPO DI UN VIDEOGIOCO PER GLI SMARTPHONE DOTATI DI WINDOWS PHONE 7 È ORA SEMPLICE ED IMMEDIATO GRAZIE AL FRAMEWORK XNA. IN QUESTA PRIMA PARTE IMPAREREMO A CONOSCERNE E SFRUTTARNE LE POTENZIALITÀ DI BASE

L’ultimo sistema operativo dedicato al mondo mobile di casa Microsoft ha apportato novi-tà significative rispetto ai suoi predecessori,

quelli della serie Windows Mobile. L’interfaccia è stata totalmente ridisegnata, così come è nuovo il modo di utilizzare il dispositivo, di conseguenza anche gli strumenti per lo sviluppo di software sono totalmente nuovi. Per sviluppare su Windows Phone 7 è necessario installare innanzitutto il pacchetto denominato Windows Phone Developer Tools (vedi box) e poi utilizzare l’IDE di casa Microsoft, Visual Studio 2010, anche nella versione Express. I tool suddetti aggiungono a Visual Studio una serie di template, dedicati alla programmazione Silverlight oppure a quella XNA, oltre a permettere di simulare perfet-tamente l’esecuzione di applicazioni o videogame mediante un nuovo emulatore.Questo articolo ha l’obiettivo di introdurre il lettore allo sviluppo di videogiochi per i dispo-sitivi basati su Windows Phone 7 mediante il framework XNA, mostrando innanzitutto quali sono le caratteristiche e le possibilità messe a nostra disposizione, fino ad arrivare a creare un vero e proprio videogame, semplice ma completo e pronto ad essere eventualmente pubblicato sul portale Microsoft.

COS’È XNALa piattaforma di sviluppo Windows Phone forni-sce due differenti framework per svilupapre appli-cazioni per i nuovi dispositivi dotati del nuovo sistema operativo:Il Silverlight Framework per applicazioni event-driven e basate su XAML, che consente di creare qualunque tipo di applicazioni e XNA Framework per lo sviluppo di videogiochi loop-based, con grafica, animazioni, suoni, che permettano di immergere il giocatore in una nuova esperienza di intrattenimento e divertimento.Il secondo è logicamente la scelta che faremo

nel seguito di questo articolo (anche se lo stesso Silverlight consentirebbe lo sviluppo di un vide-ogame con meno requisiti grafici). XNA tenta di semplificare la maggior parte dei compiti neces-sari nello sviluppo di un videogioco, fornendo le classi per gestire il ciclo di vita del gioco, l’ag-giornamento del suo stato e la visualizzazione ed interazione con gli oggetti grafici sullo schermo.Naturalmente, tutte le caratteristiche del dispo-sitivo sono disponibili e utilizzabili all’interno di un videogame: pensate ad esempio cosa potreste fare sfruttando il display multitouch e l’accelero-metro.

CREIAMO IL PROGETTODopo aver installato i Windows Phone Developer Tools, l’ambiente di sviluppo Visual Studio 2010 sarà arricchito da nuove caratteristiche e funzio-nalità che ci permetteranno facilmente di entrare nel mondo dello sviluppo Windows Phone in generale.Creare un progetto per un videogame a questo punto è semplicissimo. Basta utilizzare il menu File -> New Project, quindi dalla sezione XNA Game Studio 4.0, scegliere il template Windows Phone Game. Date un nome al vostro videogame, (abbiamo

Fig. 1: I template per creare applicazioni Windows Phone 7






Tale valore corrisponde a quello impostato nella finestra delle proprietà, selezionando il nodo del progetto Content nel Solution Explorer di Visual Studio 2010.In tal modo è possibile creare delle sottocartelle nel progetto Content e caricarne i contenuti a partire dalla directory Root.Proviamo subito a importare un’immagine e uti-lizzarla nel nostro gioco, disegnandola sullo sfon-do blu. Supponiamo di voler creare un classico sparatutto a scorrimento verticale, cioè il classico videogame con una navicella o un aereo che spara e distrugge tutto quello che si muove, mentre il paesaggio scorre verso il basso. Intanto è necessa-rio procurarsi o creare una immagine che rappre-senti il nostro velivolo. Se non avete voglia di farlo o non riuscite a trovarne una, potete sempre apri-re il codice in allegato e cercare il file player.png.Per aggiungere l’immagine al progetto Content, fate clic con il tasto destro sul progetto e poi scegliete dal menu contestuale il comando Add Existing Item, cercate l’immagine sull’hard disk e confermate l’importazione nel progetto.

DISEGNARE IMMAGINI E INSERIRE TESTO NELL’AREA DI GIOCOUna volta importato il file immagine, esso può essere referenziato mediante la stringa impostata nella proprietà Asset Name, che di default sarà uguale al nome del file senza estensione, per esempio player.Nella nostra classe Game1 aggiungiamo ora un campo di tipo Texture2D:

Texture2D player;

Ora è possibile utilizzare il metodo Load all’inter-no di LoadContent, per caricare la risorsa:

player = this.Content.

Load<Texture2D>(“Graphics/player”);

Come noterete dal codice proposto, per cari-care l’immagine dal progetto Content, bisogna necessariamente utilizzare l’Asset Name, indican-do anche il percorso rispetto alla directory radice.Nel metodo Draw della classe Game1 è ora possi-bile disegnare il nostro aereo sullo schermo:

spriteBatch.Begin();

spriteBatch.Draw(player, new Vector2(0, 100),

Color.White);

spriteBatch.End();

Il metodo Draw di SpriteBatch ha diversi overload, in questo caso si è usato quello che permette di indicare l’oggetto da disegnare, cioè l’oggetto Texture2D contenente l’immagine, le coordinate della posizione di disegno, e il colore da utilizzare per il disegno dell’oggetto (se si vuol mantenere la colorazione originale basta utilizzare il bianco, cioè Color.White).La posizione dell’oggetto da disegnare viene indi-cata mediante un vettore a due dimensioni, su un sistema di coordinate cartesiane, che ha come origine prefissata quella in alto a sinistra, con le ascisse che crescono verso destra e le ordinate crescenti verso il basso.All’interno del metodo Draw di Game1 è possi-bile disegnare diversi elementi grafici, quindi le chiamate al metodo SpriteBatch.Draw vengono raggruppate all’interno di un blocco, che inizia con la chiamata al metodo Begin e termina con il metodo End.Naturalmente, la posizione dell’oggetto sarà dina-mica e controllata esclusivamente dal giocatore interessato, ma per il momento abbiamo visto come disegnare l’oggetto in una posizione pre-definita. Dando però un’occhiata a quanto proposto nell’immagine di Fig. 5, noterete come l’imma-gine venga disegnata in una posizione diversa, a seconda dell’orientamento dello schermo, ed in particolare, come comportamento predefinito, XNA presenta ogni gioco in modalità Landscape, cioè con orientamento di tipo orizzontale.Se invece si preferisce utilizzare l’orientamento verticale, che sarebbe forse più adatto per un gioco a scrolling verticale, è possibile fissare le nuove dimensioni all’interno del metodo Initialize o del costruttore, procedendo indicando una altezza di 800 pixel ed una larghezza di 480. Questo avviene utilizzando le seguenti due proprietà PreferredBackBufferWidth e PreferredBackBufferHeight:

Fig. 5 L’immagine disegnata sullo schermo



costruttore.Il metodo di aggiornamento è il metodo Update, che serve per esempio per verificare e gestire lo stato, leggere l’eventuale input dell’utente, cal-colare punteggi, riprodurre effetti sonori, rilevare collisioni fra gli oggetti, o altre cose del genere:

protected override void Update(GameTime game

Time)

{


if (GamePad.GetState(PlayerIndex.

One).Buttons.Back == ButtonState.Pressed)

this.Exit();



}

Il codice creato da Visual Studio verifica se il gio-catore ha premuto il tasto Back del dispositivo, ed in questo caso interrompe il gioco. Mediante il parametro gameTime è possibile determinare l’intervallo di tempo trascorso dal precedente Update o dall’inizio del gioco, e quindi intraprendere azioni come uscire dal gioco se il tempo a disposizione del giocatore fosse esaurito.Il metodo Draw infine si occupa naturalmente didisegnare sullo schermo del dispositivo tutti gli oggetti grafici. Nel nostro caso come abbiamo già visto, disegna solo uno sfondo blu, anzi esatta-mente CornflowerBlue:

protected override void Draw(GameTime game

Time)

{


// TODO: Add your drawing code here


}

Generalmente, il metodo Draw viene invocato subito dopo il metodo Update, a meno che per qualunque motivo sia necessario velocizzare il tutto saltando il metodo Draw, invocando più volte Update.

TUTTE LE RISORSE DEL NOSTRO GIOCO Anche i più distratti si saranno accorti che la soluzione Visual Studio 2010 creata dal template, comprende un secondo progetto, denominato nel nostro caso ShootemUpContent. Questo progetto è inizialmente vuoto ma è destinato a contenere

tutti i file di contenuti che verranno utilizzati nel gioco: immagini, suoni e così via. Il progetto Content è referenziato dall’altro pro-getto, all’interno della sezione Content References, ed abbiamo già visto come all’interno del costrut-tore della classe Game1 venga impostata la pro-prietà RootDirectory dell’oggetto Content:

SUL WEB

LINEE GUIDA E RISORSE

All’interno del sito dedicato allo sviluppo Windows Phone, http://

create.msdn.com, è possibile trovare diversa documentazione

da cui partire per iniziare a sviluppare per la nuova piatta-forma mobile. In particolare vi

consigliamo di dare un’occhiata al Windows Phone 7 Developer

Training kit, i video della sezione Windows Phone 7 Jump Start, e di non trascurare le linee guida

dettate da Microsoft per la progettazione dell’interfaccia

utente, raccolte nel documento UI Design and Interaction Guide

for Windows Phone 7 v2.0.

Fig. 4 L’immagine utilizzata come sprite del giocatore

Fig. 3 La proprietà Content Root directory del progetto Content






Tale valore corrisponde a quello impostato nella finestra delle proprietà, selezionando il nodo del progetto Content nel Solution Explorer di Visual Studio 2010.In tal modo è possibile creare delle sottocartelle nel progetto Content e caricarne i contenuti a partire dalla directory Root.Proviamo subito a importare un’immagine e uti-lizzarla nel nostro gioco, disegnandola sullo sfon-do blu. Supponiamo di voler creare un classico sparatutto a scorrimento verticale, cioè il classico videogame con una navicella o un aereo che spara e distrugge tutto quello che si muove, mentre il paesaggio scorre verso il basso. Intanto è necessa-rio procurarsi o creare una immagine che rappre-senti il nostro velivolo. Se non avete voglia di farlo o non riuscite a trovarne una, potete sempre apri-re il codice in allegato e cercare il file player.png.Per aggiungere l’immagine al progetto Content, fate clic con il tasto destro sul progetto e poi scegliete dal menu contestuale il comando Add Existing Item, cercate l’immagine sull’hard disk e confermate l’importazione nel progetto.

DISEGNARE IMMAGINI E INSERIRE TESTO NELL’AREA DI GIOCOUna volta importato il file immagine, esso può essere referenziato mediante la stringa impostata nella proprietà Asset Name, che di default sarà uguale al nome del file senza estensione, per esempio player.Nella nostra classe Game1 aggiungiamo ora un campo di tipo Texture2D:

Texture2D player;

Ora è possibile utilizzare il metodo Load all’inter-no di LoadContent, per caricare la risorsa:

player = this.Content.

Load<Texture2D>(“Graphics/player”);

Come noterete dal codice proposto, per cari-care l’immagine dal progetto Content, bisogna necessariamente utilizzare l’Asset Name, indican-do anche il percorso rispetto alla directory radice.Nel metodo Draw della classe Game1 è ora possi-bile disegnare il nostro aereo sullo schermo:


spriteBatch.Draw(player, new Vector2(0, 100),

Color.White);

spriteBatch.End();

Il metodo Draw di SpriteBatch ha diversi overload, in questo caso si è usato quello che permette di indicare l’oggetto da disegnare, cioè l’oggetto Texture2D contenente l’immagine, le coordinate della posizione di disegno, e il colore da utilizzare per il disegno dell’oggetto (se si vuol mantenere la colorazione originale basta utilizzare il bianco, cioè Color.White).La posizione dell’oggetto da disegnare viene indi-cata mediante un vettore a due dimensioni, su un sistema di coordinate cartesiane, che ha come origine prefissata quella in alto a sinistra, con le ascisse che crescono verso destra e le ordinate crescenti verso il basso.All’interno del metodo Draw di Game1 è possi-bile disegnare diversi elementi grafici, quindi le chiamate al metodo SpriteBatch.Draw vengono raggruppate all’interno di un blocco, che inizia con la chiamata al metodo Begin e termina con il metodo End.Naturalmente, la posizione dell’oggetto sarà dina-mica e controllata esclusivamente dal giocatore interessato, ma per il momento abbiamo visto come disegnare l’oggetto in una posizione pre-definita. Dando però un’occhiata a quanto proposto nell’immagine di Fig. 5, noterete come l’imma-gine venga disegnata in una posizione diversa, a seconda dell’orientamento dello schermo, ed in particolare, come comportamento predefinito, XNA presenta ogni gioco in modalità Landscape, cioè con orientamento di tipo orizzontale.Se invece si preferisce utilizzare l’orientamento verticale, che sarebbe forse più adatto per un gioco a scrolling verticale, è possibile fissare le nuove dimensioni all’interno del metodo Initialize o del costruttore, procedendo indicando una altezza di 800 pixel ed una larghezza di 480. Questo avviene utilizzando le seguenti due proprietà PreferredBackBufferWidth e PreferredBackBufferHeight:

Fig. 5 L’immagine disegnata sullo schermo



costruttore.Il metodo di aggiornamento è il metodo Update, che serve per esempio per verificare e gestire lo stato, leggere l’eventuale input dell’utente, cal-colare punteggi, riprodurre effetti sonori, rilevare collisioni fra gli oggetti, o altre cose del genere:

protected override void Update(GameTime game

Time)

{


if (GamePad.GetState(PlayerIndex.

One).Buttons.Back == ButtonState.Pressed)

this.Exit();



}

Il codice creato da Visual Studio verifica se il gio-catore ha premuto il tasto Back del dispositivo, ed in questo caso interrompe il gioco. Mediante il parametro gameTime è possibile determinare l’intervallo di tempo trascorso dal precedente Update o dall’inizio del gioco, e quindi intraprendere azioni come uscire dal gioco se il tempo a disposizione del giocatore fosse esaurito.Il metodo Draw infine si occupa naturalmente didisegnare sullo schermo del dispositivo tutti gli oggetti grafici. Nel nostro caso come abbiamo già visto, disegna solo uno sfondo blu, anzi esatta-mente CornflowerBlue:

protected override void Draw(GameTime game

Time)

{


// TODO: Add your drawing code here


}

Generalmente, il metodo Draw viene invocato subito dopo il metodo Update, a meno che per qualunque motivo sia necessario velocizzare il tutto saltando il metodo Draw, invocando più volte Update.

TUTTE LE RISORSE DEL NOSTRO GIOCO Anche i più distratti si saranno accorti che la soluzione Visual Studio 2010 creata dal template, comprende un secondo progetto, denominato nel nostro caso ShootemUpContent. Questo progetto è inizialmente vuoto ma è destinato a contenere

tutti i file di contenuti che verranno utilizzati nel gioco: immagini, suoni e così via. Il progetto Content è referenziato dall’altro pro-getto, all’interno della sezione Content References, ed abbiamo già visto come all’interno del costrut-tore della classe Game1 venga impostata la pro-prietà RootDirectory dell’oggetto Content:

SUL WEB









for Windows Phone 7 v2.0.

Fig. 4 L’immagine utilizzata come sprite del giocatore

Fig. 3 La proprietà Content Root directory del progetto Content





{

playerPosition.Y += 5;

}

if (Keyboard.GetState().IsKeyDown(Keys.Left))

{

playerPosition.X -= 5;

}

if (Keyboard.GetState().IsKeyDown(Keys.Right))

{

playerPosition.X += 5;

}

Bisogna però controllare che la posizione sia all’interno del rettangolo di gioco, cioè dello schermo, ed eventualmente correggerla, quindi subito dopo scriveremo:

if (playerPosition.X < 0)

playerPosition.X = 0;

if (playerPosition.X > graphics.

PreferredBackBufferWidth- player.Width)

playerPosition.X = graphics.

PreferredBackBufferWidth - player.Width;

if (playerPosition.Y < 0)

playerPosition.Y = 0;

if (playerPosition.Y > graphics.

PreferredBackBufferHeight - player.Height)

playerPosition.Y= graphics.

PreferredBackBufferHeight - player.Height;

In tal modo, per esempio, si evita che l’aereo vada troppo a sinistra o a destra e troppo in alto o in basso.Come detto, però, non tutti i dispositivi avranno una tastiera, quindi è meglio assicurarsi che anche con il solo touch screen sia possibile giocare.In questo caso la classe messa a disposizione da XNA si chiama TouchPanel, che fornisce due diver-se modalità per leggere l’input: la prima permette di sapere il punto toccato dall’utente, la seconda di interpretare movimenti più articolati, come il trascinamento, il multi touch e così via. Sull’emulatore non sarà possibile utilizzare questa seconda modalità, a meno di non possedere un monitor touch screen e Windows 7.Per il momento, quindi, ci limiteremo a leggere i punti “toccati” mediante il mouse e aggiornare come prima il valore di playerPosition.La classe TouchPanel mette anch’essa a disposi-zione il metodo GetState, che restituisce la colle-zione dei punti toccati. In questo caso verifiche-remo che essa ne contenga almeno uno e quindi, tramite la proprietà Position verificheremo la sua posizione rispetto a quella attuale dell’aereo:

TouchCollection tc = TouchPanel.GetState();

if (tc.Count == 1)

{

if (tc[0].Position.X - playerPosition.X < -5)

{


}

else if (tc[0].Position.X - playerPosition.X > 5)

{


}

if (tc[0].Position.Y - playerPosition.Y < -5)

{

playerPosition.Y -= 5;

}

else if (tc[0].Position.Y - playerPosition.Y > 5)

{


}

}

A questo punto, calcolata la posizione, nel meto-do Draw potremo posizionare l’aereo utilizzando il campo playerPosition:

spriteBatch.Draw(player, playerPosition, Color.

White);

Per testare il funzionamento con l’emulatore biso-gna abilitare l’input da tastiera, dopo l’avvio del gioco premete il tasto Pag Su (per disabilitarlo è possibile utilizzare invece Pag Giù). A questo punto potete usare le frecce per muove-re l’aereo. Si noti che un altro requisito obbligato-rio dei telefoni Windows Phone è l’accelerometro, che si potrebbe usare come ulteriore metodo di input, per esempio muovendo l’aereo a destra o sinistra a seconda dell’inclinazione del dispositi-vo. Ma per il momento ne possiamo fare a meno.

CONCLUSIONIIn questa prima parte dell’articolo abbiamo posto le basi per iniziare a sviluppare un semplice vide-ogame, di genere sparatutto, per Windows Phone 7. Per giungere a tale scopo abbiamo fatto uso del Framework XNA. Nella seconda e conclusiva parte dedicata all’ar-gomento, continueremo lo sviluppo del nostro progetto, aggiungendo questa volta tutto il codi-ce necessario a rendere il gioco quanto più gio-cabile possibile. A titolo di esempio, vedremo come sarà possibile aggiungere i nemici e rilevare eventuali collisioni con i proiettili o altri oggetti, calcolando i punti guadagnati dalla distruzione degli aerei nemici.

Antonio Pelleriti

Antonio Pelleriti, ingegnere informatico, sviluppa software da più di dieci anni e si occupa di .NET sin dalla prima versione Beta. È chief software architect di DynamiCode s.r.l., software factory in cui progetta e svi-luppa soluzioni custom ed in outsourcing (www.dynamicode.it). Può essere contattato per suggerimenti, critiche o chiari-menti all’indirizzo e-mail [email protected]

L’AUTORE



graphics.PreferredBackBufferWidth = 480;

graphics.PreferredBackBufferHeight = 800;

Inoltre, è possibile eseguire il gioco a schermo intero (senza alcuna barra del titolo, così come avverrebbe in una normale applicazione) impo-stando a true la proprietà IsFullScreen.

graphics.IsFullScreen = true;

Analogamente a quanto visto per le immagini, è possibile anche scrivere del testo, cosa utile per esempio per scrivere in un videogioco il tempo rimanente oppure i punti guadagnati o le vite a disposizione. A differenza di una normale applicazione per Windows, XNA non può utilizzare i font instal-lati. Bisogna prima creare un oggetto di classe SpriteFont che è una rappresentazione grafica del carattere.Per creare ed aggiungere un oggetto SpriteFont, fate clic con il tasto destro sul progetto Content e scegliete la voce Add New Item. Quindi assegnate un nome che sia riconducibile al font originale e premete OK. Verrà creato un file con estensione .spritefont, che è in realtà un file XML.Basta ora modificare le caratteristiche del caratte-re da importare, quindi essenzialmente il nome e la dimensione. Per esempio, per creare un ogget-to SpriteFont per il font Courier New, di dimensione 20, basterà modificare come segue le corrispon-denti sezioni del file:

<FontName>Courier New</FontName>

<Size>

20

</Size>

Ricordate che molti font sono sottoposti a licenza commerciale, quindi non sono liberamente utiliz-zabili in un videogame XNA. Microsoft ha messo a disposizione diversi font

redistribuibili liberamente con i vostri giochi.A questo punto per utilizzare il carattere così defi-nito basta creare un oggetto SpriteFont mediante il già visto metodo LoadContent:

SpriteFont font = Content.

Load<SpriteFont>(@”Fonts\CourierNew”);

Per scrivere una stringa sullo schermo, si utilizzerà invece il metodo DrawString di SpriteBatch:

string gameTime= String.Format(“time

{0:00}:{1:00}”, gameTime.TotalGameTime.

TotalMinutes, gameTime.TotalGameTime.

TotalSeconds);

spriteBatch.DrawString(font, gameTime,

new Vector2(10,10), Color.Red);

In questo caso verranno mostrati i minuti e i secondi trascorsi dall’inizio.

GESTIONE DELL’INPUT DA PARTE DELL’UTENTEL’interazione dell’utente è una componente fon-damentale di qualsiasi videogame. I dispositivi dotati di Windows Phone 7 sono tutti dotati di pannello touch screen ed è quindi questo il princi-pale meccanismo di input usato dall’utente.Inoltre, alcuni dispositivi potrebbero essere dotati anche di tastiera, che permetterebbero per esem-pio di usare dei tasti come le frecce direzionali per interagire con il gioco.Cominciamo a vedere come gestire la posizione dell’aereo. Innanzitutto è conveniente aggiun-gere un campo di tipo Vector2D che manterrà la posizione corrente:

private Vector2 playerPosition;

All’interno del metodo Update potremo impostare i valore delle coordinate X e Y, in base all’input, in maniera che la seguente chiamata a Draw disegni l’aereo in una nuova posizione, quella voluta dal giocatore.Cominciamo con l’usare la classe Keyboard che permette di leggere i tasti premuti, mediante il suo unico metodo GetState. Per verificare che il tasto premuto sia uno delle freccie, e aggiornare di conseguenza le coordinate, scriveremo qualco-sa del tipo:

if (Keyboard.GetState().IsKeyDown(Keys.Up))

{


}

if (Keyboard.GetState().IsKeyDown(Keys.Down))Fig. 6 Creazione di un elemento SpriteFont





{


}

if (Keyboard.GetState().IsKeyDown(Keys.Left))

{


}

if (Keyboard.GetState().IsKeyDown(Keys.Right))

{


}

Bisogna però controllare che la posizione sia all’interno del rettangolo di gioco, cioè dello schermo, ed eventualmente correggerla, quindi subito dopo scriveremo:

if (playerPosition.X < 0)

playerPosition.X = 0;

if (playerPosition.X > graphics.

PreferredBackBufferWidth- player.Width)

playerPosition.X = graphics.

PreferredBackBufferWidth - player.Width;

if (playerPosition.Y < 0)

playerPosition.Y = 0;

if (playerPosition.Y > graphics.

PreferredBackBufferHeight - player.Height)

playerPosition.Y= graphics.

PreferredBackBufferHeight - player.Height;

In tal modo, per esempio, si evita che l’aereo vada troppo a sinistra o a destra e troppo in alto o in basso.Come detto, però, non tutti i dispositivi avranno una tastiera, quindi è meglio assicurarsi che anche con il solo touch screen sia possibile giocare.In questo caso la classe messa a disposizione da XNA si chiama TouchPanel, che fornisce due diver-se modalità per leggere l’input: la prima permette di sapere il punto toccato dall’utente, la seconda di interpretare movimenti più articolati, come il trascinamento, il multi touch e così via. Sull’emulatore non sarà possibile utilizzare questa seconda modalità, a meno di non possedere un monitor touch screen e Windows 7.Per il momento, quindi, ci limiteremo a leggere i punti “toccati” mediante il mouse e aggiornare come prima il valore di playerPosition.La classe TouchPanel mette anch’essa a disposi-zione il metodo GetState, che restituisce la colle-zione dei punti toccati. In questo caso verifiche-remo che essa ne contenga almeno uno e quindi, tramite la proprietà Position verificheremo la sua posizione rispetto a quella attuale dell’aereo:

TouchCollection tc = TouchPanel.GetState();

if (tc.Count == 1)

{

if (tc[0].Position.X - playerPosition.X < -5)

{


}

else if (tc[0].Position.X - playerPosition.X > 5)

{


}

if (tc[0].Position.Y - playerPosition.Y < -5)

{


}

else if (tc[0].Position.Y - playerPosition.Y > 5)

{


}

}

A questo punto, calcolata la posizione, nel meto-do Draw potremo posizionare l’aereo utilizzando il campo playerPosition:

spriteBatch.Draw(player, playerPosition, Color.

White);

Per testare il funzionamento con l’emulatore biso-gna abilitare l’input da tastiera, dopo l’avvio del gioco premete il tasto Pag Su (per disabilitarlo è possibile utilizzare invece Pag Giù). A questo punto potete usare le frecce per muove-re l’aereo. Si noti che un altro requisito obbligato-rio dei telefoni Windows Phone è l’accelerometro, che si potrebbe usare come ulteriore metodo di input, per esempio muovendo l’aereo a destra o sinistra a seconda dell’inclinazione del dispositi-vo. Ma per il momento ne possiamo fare a meno.

CONCLUSIONIIn questa prima parte dell’articolo abbiamo posto le basi per iniziare a sviluppare un semplice vide-ogame, di genere sparatutto, per Windows Phone 7. Per giungere a tale scopo abbiamo fatto uso del Framework XNA. Nella seconda e conclusiva parte dedicata all’ar-gomento, continueremo lo sviluppo del nostro progetto, aggiungendo questa volta tutto il codi-ce necessario a rendere il gioco quanto più gio-cabile possibile. A titolo di esempio, vedremo come sarà possibile aggiungere i nemici e rilevare eventuali collisioni con i proiettili o altri oggetti, calcolando i punti guadagnati dalla distruzione degli aerei nemici.

Antonio Pelleriti

Antonio Pelleriti, ingegnere informatico, sviluppa software da più di dieci anni e si occupa di .NET sin dalla prima versione Beta. È chief software architect di DynamiCode s.r.l., software factory in cui progetta e svi-luppa soluzioni custom ed in outsourcing (www.dynamicode.it). Può essere contattato per suggerimenti, critiche o chiari-menti all’indirizzo e-mail [email protected]

L’AUTORE



graphics.PreferredBackBufferWidth = 480;

graphics.PreferredBackBufferHeight = 800;

Inoltre, è possibile eseguire il gioco a schermo intero (senza alcuna barra del titolo, così come avverrebbe in una normale applicazione) impo-stando a true la proprietà IsFullScreen.

graphics.IsFullScreen = true;

Analogamente a quanto visto per le immagini, è possibile anche scrivere del testo, cosa utile per esempio per scrivere in un videogioco il tempo rimanente oppure i punti guadagnati o le vite a disposizione. A differenza di una normale applicazione per Windows, XNA non può utilizzare i font instal-lati. Bisogna prima creare un oggetto di classe SpriteFont che è una rappresentazione grafica del carattere.Per creare ed aggiungere un oggetto SpriteFont, fate clic con il tasto destro sul progetto Content e scegliete la voce Add New Item. Quindi assegnate un nome che sia riconducibile al font originale e premete OK. Verrà creato un file con estensione .spritefont, che è in realtà un file XML.Basta ora modificare le caratteristiche del caratte-re da importare, quindi essenzialmente il nome e la dimensione. Per esempio, per creare un ogget-to SpriteFont per il font Courier New, di dimensione 20, basterà modificare come segue le corrispon-denti sezioni del file:

<FontName>Courier New</FontName>

<Size>

20

</Size>

Ricordate che molti font sono sottoposti a licenza commerciale, quindi non sono liberamente utiliz-zabili in un videogame XNA. Microsoft ha messo a disposizione diversi font

redistribuibili liberamente con i vostri giochi.A questo punto per utilizzare il carattere così defi-nito basta creare un oggetto SpriteFont mediante il già visto metodo LoadContent:

SpriteFont font = Content.

Load<SpriteFont>(@”Fonts\CourierNew”);

Per scrivere una stringa sullo schermo, si utilizzerà invece il metodo DrawString di SpriteBatch:

string gameTime= String.Format(“time

{0:00}:{1:00}”, gameTime.TotalGameTime.

TotalMinutes, gameTime.TotalGameTime.

TotalSeconds);

spriteBatch.DrawString(font, gameTime,

new Vector2(10,10), Color.Red);

In questo caso verranno mostrati i minuti e i secondi trascorsi dall’inizio.

GESTIONE DELL’INPUT DA PARTE DELL’UTENTEL’interazione dell’utente è una componente fon-damentale di qualsiasi videogame. I dispositivi dotati di Windows Phone 7 sono tutti dotati di pannello touch screen ed è quindi questo il princi-pale meccanismo di input usato dall’utente.Inoltre, alcuni dispositivi potrebbero essere dotati anche di tastiera, che permetterebbero per esem-pio di usare dei tasti come le frecce direzionali per interagire con il gioco.Cominciamo a vedere come gestire la posizione dell’aereo. Innanzitutto è conveniente aggiun-gere un campo di tipo Vector2D che manterrà la posizione corrente:

private Vector2 playerPosition;

All’interno del metodo Update potremo impostare i valore delle coordinate X e Y, in base all’input, in maniera che la seguente chiamata a Draw disegni l’aereo in una nuova posizione, quella voluta dal giocatore.Cominciamo con l’usare la classe Keyboard che permette di leggere i tasti premuti, mediante il suo unico metodo GetState. Per verificare che il tasto premuto sia uno delle freccie, e aggiornare di conseguenza le coordinate, scriveremo qualco-sa del tipo:

if (Keyboard.GetState().IsKeyDown(Keys.Up))

{


}

if (Keyboard.GetState().IsKeyDown(Keys.Down))Fig. 6 Creazione di un elemento SpriteFont



Windows Phone 7 programming UN VIDEOGIOCO PER WINDOWS PHONE 7- 2° PARTE

Maggio 2011 / 63 http://www.ioprogrammo. i t

backgroundSpriteOffsetY + 2048), background

TexturePosSource, Color.White);

}

if (backgroundSpriteOffsetY > 0)//ricomincia a

disegnare lo sfondo {

backgroundSpriteA.Draw(backgroundTextureA,

backGroundPosition = new Vector2(0, back

groundSpriteOffsetY - 2048), backgroundTexture

PosSource, Color.White);

}

//ricomincia da zero

if (backgroundSpriteOffsetY > this.graphics.

PreferredBackBufferHeight)

{

backgroundSpriteOffsetY = -4096 + this.graphics.

PreferredBackBufferHeight;

}

backgroundSpriteA.End();

La classe SpriteBatch si occupa, poi, del disegno vero e pro-prio, prima indicando l’inizio delle operazioni con il metodo Begin, poi posizionando le immagini mediante il metodo Draw, nel quale possono essere indicati più sprite da rende-rizzare, ed infine mandando il tutto allo schermo mediante il metodo End. Da notare che le istruzioni di disegno dello sfondo devono avvenire prima di qualunque altra, perchè, altrimenti, le immagini del nostro aereo e dei nemici o dei proiettili non verranno visualizzate, o meglio sarebbero

sovrascritte dallo sfondo stesso.

ARRIVA IL NEMICOIl nostro aereo è attualmente l’unico elemento nel mondo del videogioco. Se non aggiungiamo dei nemici sare-

be tutto di una noia mortale oltre che un gioco troppo semplice da finire!. Supponiamo, quindi, che il nemico sia rappresentato da aerei russi e dopo esserci procurati delle immagini appropriate, cominciamo a strutturare una classe Mig51 derivandola da DrawableGameComponent, che rappresenta un componente di gioco che necessita di essere disegnato sullo schermo. Tale classe consente di eseguire gli override dei metodi Initialize, Draw, Update e LoadContent:

public class Mig51 : Microsoft.Xna.Framework.

DrawableGameComponent {

private Vector2 spriteOrigin;

Texture2D texture;

Vector2 position; Vector2 direction;

float speed; int startTime;

public Mig51(Game game)

: base(game) {

this.position = new Vector2(GameHelper.

RandomNext(10, game.Window.ClientBounds.

Width-10),-100);

this.direction = new Vector2(GameHelper.

RandomNext(-0.5f, 0.5f), GameHelper.

RandomNext(0.5f, 1.0f));

this.direction.Normalize();

speed = GameHelper.RandomNext(4,6);

}

public Mig51(Game game, Vector2 position,

Vector2 direction, float speed, int secondsAfter)

: base(game) {

this.position = position;

this.direction = direction;


this.speed = speed;

startTime = secondsAfter;

}

La classe dispone di due costruttori, di questi uno per posi-zionare l’aereo nemico in maniera casuale sullo schermo, e con una direzione e una velocità altrettanto casuali, ma limitando i possibili valori. Per ottenere dei numeri casuali si utilizza la classe GameHelper (il cui codice è presente nel supporto Cd-Rom allegato) che, per esempio, possiede il metodo RandomNext, a cui possono essere passati due valori rappresentanti l’intervallo minimo e massimo all’in-terno del quale generare un numero a caso appunto.

private static Random _rand;

public static float RandomNext(float minValue, float

maxValue) {

if (_rand == null)

_rand = new Random();

return (float)_rand.NextDouble() * (maxValue

- minValue) + minValue;

}

Nel primo costruttore per esempio la velocità dell’aereo (rappresentata mediante un numero intero) viene genera-

WINDOWS PHONE DEVELOPER TOOLSPer preparare la propria piatta-forma di sviluppo, in maniera da poter immediatamente iniziare a sviluppare per i dispositivi dotati di Windows Phone 7, occorre scaricare ed installare i Windows Phone Developer Tools. Basta visitare il sito dedicato http://create.msdn.com/en-us/home/getting_started e quindi cliccare il link Install Now nella sezione download the free tools. L’installer è intelligente, ed installerà solo i componenti mancanti. Per esempio, se non si possiede una versione di Visual Studio 2010, verrà installata la versione Express, così come se non si ha a disposizione Expression Blend, verrà installato Expression Blend for Windows Phone. Gli altri componenti necessari, e che verranno even-tualmente installati, sono il .NET Framework 4.0, Silverlight, XNA Game Studio 4.0 e il Windows Phone Emulator.

NOTA

Fig. 1: Scrolling dello sfondo di gioco

MOBILEXNA e Windows Phone 7. Lo sviluppo di un videogame

http://www.ioprogrammo. i t 62 / Maggio 2011


Conoscenza di base di .NET Framework e C#

Software


Impegno


UN VIDEOGIOCO PER WINDOWS PHONE 7 2° parteLA SECONDA PARTE DELL’ARTICOLO DEDICATO ALLO SVILUPPO DI UN VIDEOGIOCO PER GLI SMARTPHONE WINDOWS PHONE 7 TRAMITE IL FRAMEWORK XNA. IN QUESTO ARTICOLO VEDREMO COME AGGIUNGERE AL GIOCO, SCROLLING, NEMICI, PROIETTILI E RIPRODUZIONE DI SUONI


Nella prima parte dell’articolo, pubblicata in ioPro-rammo 160, abbiamo avuto modo di introdurre il lettore nel mondo dello sviluppo di videogiochi

per Windows Phone e di XNA in particolare; XNA è il fra-mework di programmazione creato da Microsoft e messo a disposizione degli sviluppatori di videogame e non, per Windows Phone, ma anche per XBOX e Windows.Continuiamo ora lo sviluppo del videogioco, un semplice shoot’em up (o sparatutto), partendo dallo sfondo di gioco, che al momento è un desolato rettangolo bianco, che rap-presenta il mondo su cui volava il nostro protagonista, un aereo da combattimento.

SCROLLING DELLO SFONDOGli sparatutto utilizzano molto spesso uno sfondo che si muove al di sotto del personaggio principale e degli altri protagonisti del gioco: nemici e missili per esempio.Innanzitutto abbiamo bisogno di qualche immagine, che, per comodità, abbiamo recuperato in giro su Internet da alcune immagini satellitari, siete liberi di scegliere o creare le vostre immagini.Supponiamo, intanto, di avere due sole immagini, che mostreremo una dopo l’altra, di dimensioni 480x2048. 480 pixel è la larghezza dello schermo del dispositivo, men-tre l’altezza di 2048 pixel è maggiore di quella standard dello schermo di 800 pixel, quindi lo sfondo scorrerà in altezza per un totale di 4096 pixel e poi ricomincerà dalla prima immagine.Per utilizzare le due immagini di sfondo, dobbiamo innan-zitutto inserirle nel progetto Content e poi caricarle come già abbiamo avuto modo di imparare nella scorsa puntata, basta invocare il metodo Content.Load e salvarle in due campi della classe Game di tipo Texture2D.

backgroundTextureA = Content.

Load<Texture2D>(@”Graphics\background_a”);

backgroundTextureB = Content.

Load<Texture2D>(@”Graphics\background_b”);

Il metodo che si occupa del disegno del gioco è Draw. Non ci resta che fare due conti per poter disegnare prima

una e poi l’altra immagine, dando l’illusione di movimento mediante la variazione della posizione Y.Il campo backgroundSpriteOffsetY, quindi, manterrà tale posizione e sarà incrementata durante l’update del gioco, all’interno del metodo ScrollBackground:

private void ScrollBackground() {

if (scroll)

{ backgroundSpriteOffsetY++; }

}

Il metodo incrementa il campo backgroundSpriteOffsetY di una unità per volta, ma solo se il campo booleano scroll è true. In questo modo potremo, per esempio, fermare lo scorrimento in determinate occasioni di gioco, per esem-pio quando il giocatore ha ultimato le “vite”, oppure quan-do verrà visualizzato un nemico di fine livello.All’interno del Draw faremo i conti per posizionare le imma-gini di sfondo: il valore di backgroundSpriteOffsetY parte da un valore pari a -4096 + 800, cioè il totale delle due altezze più l’altezza dello schermo.In questa maniera i due sfondi vengono disegnati con-temporaneamente, ma uno ricadrà fuori dallo schermo, e solo quando il primo sta uscendo dallo schermo in basso, il secondo inizierà ad apparire dall’alto:

backgroundSpriteA.Begin();

//i due background da disegnare contemporaneamente

//disegna lo sfondo b

if (backgroundSpriteOffsetY > -2048 ){

backgroundSpriteA.Draw(backgroundTextureB,

backGroundPosition =

new Vector2(0, backgroundSpriteOffsetY ),

backgroundTexturePosSource, Color.White);

}

//disegna lo sfondo a

if (backgroundSpriteOffsetY > -4096 + this.graphics.

PreferredBackBufferHeight && backgroundSpriteOffsetY

< -2048 + this.graphics.PreferredBackBufferHeight)//

verifica se ha raggiunto la fine

{


backGroundPosition = new Vector2(0,

MOBILE XNA e Windows Phone 7. Lo sviluppo di un videogame


Windows Phone 7 programmingUN VIDEOGIOCO PER WINDOWS PHONE 7- 2° PARTE


backgroundSpriteOffsetY + 2048), background

TexturePosSource, Color.White);

}

if (backgroundSpriteOffsetY > 0)//ricomincia a

disegnare lo sfondo {


backGroundPosition = new Vector2(0, back

groundSpriteOffsetY - 2048), backgroundTexture

PosSource, Color.White);

}

//ricomincia da zero

if (backgroundSpriteOffsetY > this.graphics.

PreferredBackBufferHeight)

{

backgroundSpriteOffsetY = -4096 + this.graphics.

PreferredBackBufferHeight;

}

backgroundSpriteA.End();

La classe SpriteBatch si occupa, poi, del disegno vero e pro-prio, prima indicando l’inizio delle operazioni con il metodo Begin, poi posizionando le immagini mediante il metodo Draw, nel quale possono essere indicati più sprite da rende-rizzare, ed infine mandando il tutto allo schermo mediante il metodo End. Da notare che le istruzioni di disegno dello sfondo devono avvenire prima di qualunque altra, perchè, altrimenti, le immagini del nostro aereo e dei nemici o dei proiettili non verranno visualizzate, o meglio sarebbero

sovrascritte dallo sfondo stesso.

ARRIVA IL NEMICOIl nostro aereo è attualmente l’unico elemento nel mondo del videogioco. Se non aggiungiamo dei nemici sare-

be tutto di una noia mortale oltre che un gioco troppo semplice da finire!. Supponiamo, quindi, che il nemico sia rappresentato da aerei russi e dopo esserci procurati delle immagini appropriate, cominciamo a strutturare una classe Mig51 derivandola da DrawableGameComponent, che rappresenta un componente di gioco che necessita di essere disegnato sullo schermo. Tale classe consente di eseguire gli override dei metodi Initialize, Draw, Update e LoadContent:

public class Mig51 : Microsoft.Xna.Framework.

DrawableGameComponent {

private Vector2 spriteOrigin;

Texture2D texture;

Vector2 position; Vector2 direction;

float speed; int startTime;

public Mig51(Game game)

: base(game) {

this.position = new Vector2(GameHelper.

RandomNext(10, game.Window.ClientBounds.

Width-10),-100);

this.direction = new Vector2(GameHelper.

RandomNext(-0.5f, 0.5f), GameHelper.

RandomNext(0.5f, 1.0f));



}

public Mig51(Game game, Vector2 position,

Vector2 direction, float speed, int secondsAfter)

: base(game) {

this.position = position;

this.direction = direction;


this.speed = speed;

startTime = secondsAfter;

}

La classe dispone di due costruttori, di questi uno per posi-zionare l’aereo nemico in maniera casuale sullo schermo, e con una direzione e una velocità altrettanto casuali, ma limitando i possibili valori. Per ottenere dei numeri casuali si utilizza la classe GameHelper (il cui codice è presente nel supporto Cd-Rom allegato) che, per esempio, possiede il metodo RandomNext, a cui possono essere passati due valori rappresentanti l’intervallo minimo e massimo all’in-terno del quale generare un numero a caso appunto.

private static Random _rand;

public static float RandomNext(float minValue, float

maxValue) {

if (_rand == null)

_rand = new Random();

return (float)_rand.NextDouble() * (maxValue

- minValue) + minValue;

}

Nel primo costruttore per esempio la velocità dell’aereo (rappresentata mediante un numero intero) viene genera-

WINDOWS PHONE DEVELOPER TOOLSPer preparare la propria piatta-forma di sviluppo, in maniera da poter immediatamente iniziare a sviluppare per i dispositivi dotati di Windows Phone 7, occorre scaricare ed installare i Windows Phone Developer Tools. Basta visitare il sito dedicato http://create.msdn.com/en-us/home/getting_started e quindi cliccare il link Install Now nella sezione download the free tools. L’installer è intelligente, ed installerà solo i componenti mancanti. Per esempio, se non si possiede una versione di Visual Studio 2010, verrà installata la versione Express, così come se non si ha a disposizione Expression Blend, verrà installato Expression Blend for Windows Phone. Gli altri componenti necessari, e che verranno even-tualmente installati, sono il .NET Framework 4.0, Silverlight, XNA Game Studio 4.0 e il Windows Phone Emulator.

NOTA

Fig. 1: Scrolling dello sfondo di gioco




Conoscenza di base di .NET Framework e C#

Software


Impegno


UN VIDEOGIOCO PER WINDOWS PHONE 7 2° parteLA SECONDA PARTE DELL’ARTICOLO DEDICATO ALLO SVILUPPO DI UN VIDEOGIOCO PER GLI SMARTPHONE WINDOWS PHONE 7 TRAMITE IL FRAMEWORK XNA. IN QUESTO ARTICOLO VEDREMO COME AGGIUNGERE AL GIOCO, SCROLLING, NEMICI, PROIETTILI E RIPRODUZIONE DI SUONI


Nella prima parte dell’articolo, pubblicata in ioPro-rammo 160, abbiamo avuto modo di introdurre il lettore nel mondo dello sviluppo di videogiochi

per Windows Phone e di XNA in particolare; XNA è il fra-mework di programmazione creato da Microsoft e messo a disposizione degli sviluppatori di videogame e non, per Windows Phone, ma anche per XBOX e Windows.Continuiamo ora lo sviluppo del videogioco, un semplice shoot’em up (o sparatutto), partendo dallo sfondo di gioco, che al momento è un desolato rettangolo bianco, che rap-presenta il mondo su cui volava il nostro protagonista, un aereo da combattimento.

SCROLLING DELLO SFONDOGli sparatutto utilizzano molto spesso uno sfondo che si muove al di sotto del personaggio principale e degli altri protagonisti del gioco: nemici e missili per esempio.Innanzitutto abbiamo bisogno di qualche immagine, che, per comodità, abbiamo recuperato in giro su Internet da alcune immagini satellitari, siete liberi di scegliere o creare le vostre immagini.Supponiamo, intanto, di avere due sole immagini, che mostreremo una dopo l’altra, di dimensioni 480x2048. 480 pixel è la larghezza dello schermo del dispositivo, men-tre l’altezza di 2048 pixel è maggiore di quella standard dello schermo di 800 pixel, quindi lo sfondo scorrerà in altezza per un totale di 4096 pixel e poi ricomincerà dalla prima immagine.Per utilizzare le due immagini di sfondo, dobbiamo innan-zitutto inserirle nel progetto Content e poi caricarle come già abbiamo avuto modo di imparare nella scorsa puntata, basta invocare il metodo Content.Load e salvarle in due campi della classe Game di tipo Texture2D.

backgroundTextureA = Content.

Load<Texture2D>(@”Graphics\background_a”);

backgroundTextureB = Content.

Load<Texture2D>(@”Graphics\background_b”);

Il metodo che si occupa del disegno del gioco è Draw. Non ci resta che fare due conti per poter disegnare prima

una e poi l’altra immagine, dando l’illusione di movimento mediante la variazione della posizione Y.Il campo backgroundSpriteOffsetY, quindi, manterrà tale posizione e sarà incrementata durante l’update del gioco, all’interno del metodo ScrollBackground:

private void ScrollBackground() {

if (scroll)

{ backgroundSpriteOffsetY++; }

}

Il metodo incrementa il campo backgroundSpriteOffsetY di una unità per volta, ma solo se il campo booleano scroll è true. In questo modo potremo, per esempio, fermare lo scorrimento in determinate occasioni di gioco, per esem-pio quando il giocatore ha ultimato le “vite”, oppure quan-do verrà visualizzato un nemico di fine livello.All’interno del Draw faremo i conti per posizionare le imma-gini di sfondo: il valore di backgroundSpriteOffsetY parte da un valore pari a -4096 + 800, cioè il totale delle due altezze più l’altezza dello schermo.In questa maniera i due sfondi vengono disegnati con-temporaneamente, ma uno ricadrà fuori dallo schermo, e solo quando il primo sta uscendo dallo schermo in basso, il secondo inizierà ad apparire dall’alto:

backgroundSpriteA.Begin();

//i due background da disegnare contemporaneamente

//disegna lo sfondo b

if (backgroundSpriteOffsetY > -2048 ){

backgroundSpriteA.Draw(backgroundTextureB,

backGroundPosition =

new Vector2(0, backgroundSpriteOffsetY ),

backgroundTexturePosSource, Color.White);

}

//disegna lo sfondo a

if (backgroundSpriteOffsetY > -4096 + this.graphics.

PreferredBackBufferHeight && backgroundSpriteOffsetY

< -2048 + this.graphics.PreferredBackBufferHeight)//

verifica se ha raggiunto la fine

{


backGroundPosition = new Vector2(0,





crea un numero variabile, per esempio il metodo seguente, verifica quanti secondi sono passati dall’inizio del gioco stesso, e dopo 3 secondi (vedi ultimo else if) crea due oggetti Mig51 conservandoli nell’array enemies, che poi si potrà utilizzare nel resto del gioco per verificare il numero di nemici in volo, quelli esplosi e così via.

private void UpdateEnemies(GameTime gameTime) {

//ondata di nemici con 5 aerei in fila

if (gameTime.TotalGameTime.TotalSeconds >=

60 && NoEnemies()) {

enemies = new Mig51[10];

enemies[0] = new Mig51(this, new

Vector2(100, -100), new Vector2(0,1), 4, 5);


Vector2(150, -100), new Vector2(0, 1), 4, 6);







}

else if (gameTime.TotalGameTime.

TotalSeconds >= 3 && NoEnemies()) {


enemies[0] = new Mig51(this);


}

for (int i = 0; i < enemies.Length; i++) {

if (enemies[i] != null) {

enemies[i].Update(gameTime);

if (enemies[i].Removed)

{ enemies[i] = null; }

}

}

}

Il for finale invoca il metodo Update su ogni oggetto, e nel caso in cui la proprietà Removed sia true (evento che si verifica dopo che l’aereo è esploso o dopo che esce dallo schermo), rimuove l’oggetto impostando a null la rispettiva locazione del vettore. Il metodo UpdateEnemies verrà invo-cato nell’update generale della classe Game1.

RISPONDERE AL FUOCODopo aver creato la classe per rappresentare i nostri nemici, dobbiamo essere in grado di rispondere al fuoco spa-rando dei missili. L’implementazione della classe Missile è molto simile a quella di Mig51, derivandola sempre da DrawableGameComponent, ma per mostrare qualcosa di diverso, mostreremo come gestire oggetti di tipo Missile e trattarli come componenti di gioco da aggiungere alla col-lezione Components della classe Game. Dopo aver creato la classe, e implementato i metodi Update, Draw, Initialize e LoadContent (date un’occhiata al codice in allegato), per

sparare dei missili basta avere un metodo tipo il seguente, FireMissile, in cui intanto si determina la posizione di par-tenza del proiettile, sparandone uno da destra e uno da sinistra, e poi, creata l’istanza di Missile, la si aggiunge alla collezione Components. In tal modo i metodi della clas-se DrawableGameComponent saranno automaticamente invocati quando necessario:

private void FireMissile() {

for (int i = 0; i < MAX_MISSILI; i++) {

if (missili[i] == null) {

Vector2 pos= new Vector2(playerPosition.X+player.

Width/2, playerPosition.Y);

if (i % 2 == 0)

{ pos.X += player.Width / 2; }

else pos.X -= player.Width / 2;

Missile missile = new Missile(this, pos);

this.Components.Add(missile);

missili[i]=missile;

break;}

}

}

La costante MAX_MISSILI consente di gestire un nume-ro massimo di missili che si possono sparare e avere contemporaneamente in volo. Perché sia possibi-le disegnare un missile sullo schermo è però sempre necessario avere a disposizione uno SpriteBatch. Ecco qui di seguito come gestire comodamente tale neces-sità senza creare una nuova istanza.Nella classe Game1, ad esempio dopo la creazione dello spriteBatch principale nel metodo Initialize, aggiungiamo un “servizio” al GameServiceContainer ricavabile mediante la proprietà Services:


Services.AddService(typeof(SpriteBatch), spriteBatch);

All’interno della classe Missile, invece, possiamo utilizzare il servizio per ricavare l’oggetto SpriteBatch. Operiamo semplicemente così:

spriteBatch = this.Game.Services.

GetService(typeof(SpriteBatch)) as SpriteBatch;

RILEVARE LE EVENTUALI COLLISIONI DI GIOCOL’aereo protagonista principale del gioco può ora sparare dei missili, ma se non rileviamo in qualche maniera le col-lisioni fra gli oggetti del gioco, nessun aereo nemico verrà mai abbattuto, e certamente nessuno potrà colpirci! Per rilevare se un missile ha colpito un aereo nemico, è neces-sario intanto stabilire quali sono le aree da considerare “col-pite”, ed il modo più semplice è sicuramente quello di con-siderare i rettangoli contenenti gli oggetti, quindi rilevare la loro intersecazione; questo lo si fa mediante il metodo



ta invocando così il metodo:


Per caricare l’immagine da utilizzare come sprite dell’aereo nemico, utilizziamo ancora una volta il metodo Content.Load, e poi impostiamo il valore del campo spriteOrigin, che rappresenterà il centro di rotazione dell’aereo stesso, nel caso in cui la sua direzione non sia proprio verticale:


{

texture = this.Game.Content.

Load<Texture2D>(“Graphics/mig-51S”);

spriteOrigin = new Vector2(texture.Width /2,

texture.Height / 2);

}

La Fig.2 mostra l’immagine utilizzata come aereo nemico. Si noti come essa sia rivolta verso l’alto, mentre nel gioco sarà opportunamente ruotata in base al valore di direction.All’interno del metodo Update, viene calcolata la posizione dell’aereo e quindi creato il suo movimento nel mondo virtuale. Il campo initTime, che al momento potete anche trascurare, viene eventualmente inizializzato nel costrut-tore per indicare l’istante di partenza in secondi del nuovo aereo nemico, in tal modo possiamo per esempio creare più aerei da mandare all’attacco in diversi istanti. Nel metodo viene poi controllato il valore della ordinata Y di position, che indica il punto in cui si trova l’aereo, ed eventualmente la posizione stessa viene aggiornata, uti-lizzando il valore ricavato dal prodotto di direction * speed (cioè un vettore per uno scalare). In tal modo si ottengono le nuove coordinate del punto in cui si ridisegnerà lo sprite.

public override void Update(GameTime gameTime) {

if (initTime == null)

initTime = gameTime.TotalGameTime;

if ((gameTime.TotalGameTime - initTime.

Value).TotalSeconds >= startTime) {

if (position.Y < this.Game.Window.

ClientBounds.Height + texture.Height)

{ position += direction * speed; }

else Removed = true;


}

}

Per rendere più avvincente il gioco, e non avere soltanto aerei che scendono dall’alto in verticale, abbiamo previsto la gestione di una direzione diversa dall’angolo di 180° (che indica appunto la verticale verso il basso). Con un po’ di trigonometria, che esula dagli scopi di quest’articolo, ma niente di trascendentale, possiamo calcolarci l’angolo di rotazione con cui disegnare lo sprite. Si noti che, nel caso di direzione perfettamente verticale, quindi con direction= (0,1), si avrà un angolo di rotazione di 180°, che è quello che

vogliamo data l’immagine originale in Fig. 2:

private float Rotation {

get {

float angle = (float)(180 - MathHelper.

ToDegrees((float)Math.Atan(direction.X/direction.Y)));

return angle; }

}

A questo punto, per disegnare l’aereo sullo schermo, basta utilizzare nel metodo Draw i classici metodi della classe SpriteBatch.

public override void Draw(GameTime gameTime) {


if (Removed || position.Y<100)

return;

SpriteBatch spriteBatch = new SpriteBatch(this.

GraphicsDevice);


if (Exploded)

spriteBatch.Draw(texture, position, null, Color.

White, MathHelper.ToRadians(Rotation),

spriteOrigin,1,SpriteEffects.None, 0);

spriteBatch.End();

}

Nei metodi precedenti avrete notato l’utilizzo di una classe MathHelper, che contiene diversi metodi utili per fare dei calcoli matematici molto comuni nei videogame.Ad esempio, la classe contiene il metodo ToRadians, che consente di trasformare l’angolo in gradi calcolato nella proprietà Rotation, nell’angolo in radianti che è voluto dal metodo Draw di SpriteBatch.Per visualizzare sullo schermo delle ondate di aerei nemici, creeremo un metodo che, in base al tempo di gioco, ne

SUL WEB









for Windows Phone 7 v2.0. Per quanto riguarda invece XNA

consigliamo la lettura e lo studio dell’apposita sezione su MSDN

(http://msdn.microsoft.com/en-us/library/bb200104.aspx).

Fig. 2: L’immagine originale e ingrandita, utilizzata come aereo nemico



Windows Phone 7 programmingUN VIDEOGIOCO PER WINDOWS PHONE 7- 2° PARTE


crea un numero variabile, per esempio il metodo seguente, verifica quanti secondi sono passati dall’inizio del gioco stesso, e dopo 3 secondi (vedi ultimo else if) crea due oggetti Mig51 conservandoli nell’array enemies, che poi si potrà utilizzare nel resto del gioco per verificare il numero di nemici in volo, quelli esplosi e così via.

private void UpdateEnemies(GameTime gameTime) {

//ondata di nemici con 5 aerei in fila

if (gameTime.TotalGameTime.TotalSeconds >=

60 && NoEnemies()) {



Vector2(100, -100), new Vector2(0,1), 4, 5);









}

else if (gameTime.TotalGameTime.

TotalSeconds >= 3 && NoEnemies()) {




}

for (int i = 0; i < enemies.Length; i++) {

if (enemies[i] != null) {

enemies[i].Update(gameTime);

if (enemies[i].Removed)

{ enemies[i] = null; }

}

}

}

Il for finale invoca il metodo Update su ogni oggetto, e nel caso in cui la proprietà Removed sia true (evento che si verifica dopo che l’aereo è esploso o dopo che esce dallo schermo), rimuove l’oggetto impostando a null la rispettiva locazione del vettore. Il metodo UpdateEnemies verrà invo-cato nell’update generale della classe Game1.

RISPONDERE AL FUOCODopo aver creato la classe per rappresentare i nostri nemici, dobbiamo essere in grado di rispondere al fuoco spa-rando dei missili. L’implementazione della classe Missile è molto simile a quella di Mig51, derivandola sempre da DrawableGameComponent, ma per mostrare qualcosa di diverso, mostreremo come gestire oggetti di tipo Missile e trattarli come componenti di gioco da aggiungere alla col-lezione Components della classe Game. Dopo aver creato la classe, e implementato i metodi Update, Draw, Initialize e LoadContent (date un’occhiata al codice in allegato), per

sparare dei missili basta avere un metodo tipo il seguente, FireMissile, in cui intanto si determina la posizione di par-tenza del proiettile, sparandone uno da destra e uno da sinistra, e poi, creata l’istanza di Missile, la si aggiunge alla collezione Components. In tal modo i metodi della clas-se DrawableGameComponent saranno automaticamente invocati quando necessario:

private void FireMissile() {

for (int i = 0; i < MAX_MISSILI; i++) {

if (missili[i] == null) {

Vector2 pos= new Vector2(playerPosition.X+player.

Width/2, playerPosition.Y);

if (i % 2 == 0)

{ pos.X += player.Width / 2; }

else pos.X -= player.Width / 2;

Missile missile = new Missile(this, pos);

this.Components.Add(missile);

missili[i]=missile;

break;}

}

}

La costante MAX_MISSILI consente di gestire un nume-ro massimo di missili che si possono sparare e avere contemporaneamente in volo. Perché sia possibi-le disegnare un missile sullo schermo è però sempre necessario avere a disposizione uno SpriteBatch. Ecco qui di seguito come gestire comodamente tale neces-sità senza creare una nuova istanza.Nella classe Game1, ad esempio dopo la creazione dello spriteBatch principale nel metodo Initialize, aggiungiamo un “servizio” al GameServiceContainer ricavabile mediante la proprietà Services:


Services.AddService(typeof(SpriteBatch), spriteBatch);

All’interno della classe Missile, invece, possiamo utilizzare il servizio per ricavare l’oggetto SpriteBatch. Operiamo semplicemente così:

spriteBatch = this.Game.Services.

GetService(typeof(SpriteBatch)) as SpriteBatch;

RILEVARE LE EVENTUALI COLLISIONI DI GIOCOL’aereo protagonista principale del gioco può ora sparare dei missili, ma se non rileviamo in qualche maniera le col-lisioni fra gli oggetti del gioco, nessun aereo nemico verrà mai abbattuto, e certamente nessuno potrà colpirci! Per rilevare se un missile ha colpito un aereo nemico, è neces-sario intanto stabilire quali sono le aree da considerare “col-pite”, ed il modo più semplice è sicuramente quello di con-siderare i rettangoli contenenti gli oggetti, quindi rilevare la loro intersecazione; questo lo si fa mediante il metodo



ta invocando così il metodo:


Per caricare l’immagine da utilizzare come sprite dell’aereo nemico, utilizziamo ancora una volta il metodo Content.Load, e poi impostiamo il valore del campo spriteOrigin, che rappresenterà il centro di rotazione dell’aereo stesso, nel caso in cui la sua direzione non sia proprio verticale:


{

texture = this.Game.Content.

Load<Texture2D>(“Graphics/mig-51S”);

spriteOrigin = new Vector2(texture.Width /2,

texture.Height / 2);

}

La Fig.2 mostra l’immagine utilizzata come aereo nemico. Si noti come essa sia rivolta verso l’alto, mentre nel gioco sarà opportunamente ruotata in base al valore di direction.All’interno del metodo Update, viene calcolata la posizione dell’aereo e quindi creato il suo movimento nel mondo virtuale. Il campo initTime, che al momento potete anche trascurare, viene eventualmente inizializzato nel costrut-tore per indicare l’istante di partenza in secondi del nuovo aereo nemico, in tal modo possiamo per esempio creare più aerei da mandare all’attacco in diversi istanti. Nel metodo viene poi controllato il valore della ordinata Y di position, che indica il punto in cui si trova l’aereo, ed eventualmente la posizione stessa viene aggiornata, uti-lizzando il valore ricavato dal prodotto di direction * speed (cioè un vettore per uno scalare). In tal modo si ottengono le nuove coordinate del punto in cui si ridisegnerà lo sprite.

public override void Update(GameTime gameTime) {

if (initTime == null)

initTime = gameTime.TotalGameTime;

if ((gameTime.TotalGameTime - initTime.

Value).TotalSeconds >= startTime) {

if (position.Y < this.Game.Window.

ClientBounds.Height + texture.Height)

{ position += direction * speed; }

else Removed = true;


}

}

Per rendere più avvincente il gioco, e non avere soltanto aerei che scendono dall’alto in verticale, abbiamo previsto la gestione di una direzione diversa dall’angolo di 180° (che indica appunto la verticale verso il basso). Con un po’ di trigonometria, che esula dagli scopi di quest’articolo, ma niente di trascendentale, possiamo calcolarci l’angolo di rotazione con cui disegnare lo sprite. Si noti che, nel caso di direzione perfettamente verticale, quindi con direction= (0,1), si avrà un angolo di rotazione di 180°, che è quello che

vogliamo data l’immagine originale in Fig. 2:

private float Rotation {

get {

float angle = (float)(180 - MathHelper.

ToDegrees((float)Math.Atan(direction.X/direction.Y)));

return angle; }

}

A questo punto, per disegnare l’aereo sullo schermo, basta utilizzare nel metodo Draw i classici metodi della classe SpriteBatch.

public override void Draw(GameTime gameTime) {


if (Removed || position.Y<100)

return;

SpriteBatch spriteBatch = new SpriteBatch(this.

GraphicsDevice);


if (Exploded)

spriteBatch.Draw(texture, position, null, Color.

White, MathHelper.ToRadians(Rotation),

spriteOrigin,1,SpriteEffects.None, 0);

spriteBatch.End();

}

Nei metodi precedenti avrete notato l’utilizzo di una classe MathHelper, che contiene diversi metodi utili per fare dei calcoli matematici molto comuni nei videogame.Ad esempio, la classe contiene il metodo ToRadians, che consente di trasformare l’angolo in gradi calcolato nella proprietà Rotation, nell’angolo in radianti che è voluto dal metodo Draw di SpriteBatch.Per visualizzare sullo schermo delle ondate di aerei nemici, creeremo un metodo che, in base al tempo di gioco, ne

SUL WEB









for Windows Phone 7 v2.0. Per quanto riguarda invece XNA

consigliamo la lettura e lo studio dell’apposita sezione su MSDN

(http://msdn.microsoft.com/en-us/library/bb200104.aspx).

Fig. 2: L’immagine originale e ingrandita, utilizzata come aereo nemico





Intersects della classe Rectangle. Il seguente metodo della classe Mig51, cicla tutti gli oggetti registrati nella collezione Components, verifica se sono di classe Missile, quindi chia-ma il metodo Intersects per verificarne la collisione:

public DrawableGameComponent HasCollided()

{

if (!this.Exploded)

{

foreach (GameComponent comp in Game.Components) {

if (comp is Missile) {

Missile missile = comp as Missile;

if (!missile.Removed) {

if (this.Bounds.Intersects(missile.Bounds)) {

missile.Explode();

return missile;

}

}}

}}

return null;

}

La rilevazione delle collisioni non è così precisa, soprattutto nel caso di sprite ruotati, come possono essere quelli degli aerei nemici.Un altro metodo, sicuramente più pesante ma anche infi-nitamente più preciso, prevede, invece, la verifica pixel per pixel, in tal caso vengono ricavati i colori di tutti i pixel e poi si verifica se ci sono dei pixel non trasparenti sovrapposti. La classe GameHelper già citata, implementa un apposito metodo IntersectPixels, che verifica l’intersezione di due pixel, inoltre considera anche le eventuali trasformazioni di rotazione applicate agli oggetti. Suggeriamo, ancora una volta, di aprire il codice in allegato e magari eseguirlo in debug, con Visual Studio 2010.La Fig. 3 mostra il gioco quasi completo, perlomeno per gli scopi di quest’articolo, con degli aerei in volo, e un paio di esplosioni.

GESTIONE DEI SUONI E DELLE ESPLOSIONIUn videogame senza suoni e musiche non è il massimo della vita; XNA permette di caricare e gestire tali risorse con la stessa semplicità ed efficacia vista per le immagini. Per esempio, basta caricare dei file .wav nel progetto Content, e poi utilizzare ancora una volta il metodo Content.Load per creare degli oggetti SoundEffect:

SoundEffects.Add(“Missile”, this.Content.

Load<SoundEffect>(@”Sounds\MissileSound”));

Per riprodurre il suono si utilizza il metodo Play , che per-mette di determinare il volume, l’altezza del suono, e il bilanciamento stereo. Ad esempio, all’interno del già visto metodo FireMissile, al lancio di un missile, possiamo ese-guire il suono semplicemente così scrivendo la seguente

riga di codice:

SoundEffects[“Missile”].Play(0.75f, 0.2f, 0.0f);

Il primo parametro rappresenta il volume, variabile fra 0 e 1, ed indica il livello percentuale rispetto al volume Master. Il secondo è il pitch del suono, e può essere variato fra -1 (1 ottava in basso) e 1 (1 ottava in alto), mentre il terzo è il bilanciamento e varia anch’esso fra -1 (sinistra) e +1 (destra).

MIGLIORIE DA APPORTARE AL NOSTRO VIDEOGAMEDato l’esiguo spazio rimasto, indichiamo alcune possibili migliorie che potrete apportare, e che serviranno per studiare ancora più a fondo il framework XNA. Manca sicu-ramente nel gioco la gestione delle “vite” a disposizione, un menu da cui selezionare l’avvio di una nuova partita, la visualizzazione dei punteggi, e altri tanti dettagli che tutti gli appassionati di videogame non faranno fatica a immaginare.

Antonio Pelleriti

Fig. 3: Il gioco in esecuzione sull’emulatoreAntonio Pelleriti, ingegnere

informatico, sviluppa software da più di dieci anni e si occupa

di .NET sin dalla prima ver-sione Beta. È chief software

architect di DynamiCode s.r.l., software factory in cui progetta

e sviluppa soluzioni custom ed in outsourcing (www.

dynamicode.it), ed è autore del libro “Silverlight 4 Guida alla

programmazione”, Edizioni FAG. Può essere contattato per sug-

gerimenti, critiche o chiarimenti tramite il sito www.antoniopel-

leriti.it.

L’AUTORE


www.punto-informatico.it

Il mobile è il futuro. E Windows Phone 7 sarà sicuramente uno dei protagonisti del film che verrà proiettato sul mercato.Questo approfondimento tematico è stato pensato per chi vuole scoprire tutti i segreti del nuovo sistema operativo di Redmond; è stato concepito per chi desidera imparare a programmare e creare software per smartphone.La prima parte funge da introduzione e mette in evidenza tutte le caratteristiche di base del software. La seconda mostra come operare con l’ambiente operativo del sistema: gestire la rubrica e le telefonate, interagire con la video/fotocamera, avviare browser e ricerche. Infine, la terza parte spiega come creare da zero un progetto pratico e sviluppare software e videogame.

www.punto-informatico.it

Windows Phone 7 Programming

Documents

Transcript of Windows Phone 7 Programming