Tesi di Laurea Magistrale - Javeriana

POLITECNICO DI TORINO

III Facoltà di Ingegneria

Corso di Laurea in Ingegneria del Cinema e dei Mezzi di

Comunicazione

Tesi di Laurea Magistrale

Tecnologia Multitouch: ActionScript come

strumento di sviluppo di applicazioni interattive

Relatore

Prof. Giovanni Malnati

Correlatore

Porf.ssa Sara Comai

Candidato

Juan Pablo Varón T.

Novembre 2010

2

Indice INTRODUZIONE ................................................................................................................... 1

Capitolo 1 ................................................................................................................................ 5

TECNOLOGIA MULTITOUCH............................................................................................ 5

1.1 La storia .................................................................................................................... 5

1.2 Parti basici di un sistema Touchscreen ..................................................................... 6

1.3 Descrizione delle diverse tecniche per la costruzione dei dispositivi ottici ............. 7

1.3.1 Tecnologia ottica – L‟uso della luce infrarossa ................................................ 7

1.4 Descrizione Generale del Sistema .......................................................................... 13

1.4.1 CCV – Il Tracker ............................................................................................. 13

1.4.2 FLASH – Uno strumento per applicazioni Interattive .................................... 15

Capitolo 2 .............................................................................................................................. 17

TUIO ..................................................................................................................................... 17

2.1 Specifica del protocollo TUIO 1.1 ......................................................................... 17

2.1.1 Implementazione, efficienza ed affidabilità del protocollo............................. 18

2.1.2 Profili ed i suoi attributi .................................................................................. 20

2.2 Touchlib .................................................................................................................. 21

2.2.1 Classe TUIO .................................................................................................... 21

2.2.2 Classe TUIOCursor ......................................................................................... 22

2.2.3 Classe TUIOEvent .......................................................................................... 23

2.2.4 Classe TUIOObject ......................................................................................... 23

Capitolo 3 .............................................................................................................................. 26

Componenti di FLASH ......................................................................................................... 26

3.1 Cos‟è un componente? ........................................................................................... 26

3.2 Struttura dei Componenti ....................................................................................... 28

3.3 Il codice interno dei componenti – L‟elemento componentShim .......................... 29

3.4 Struttura a due frame dei componenti .................................................................... 31

3.5 Struttura interna di Flash per l‟uso dei componenti ............................................... 34

3.5.1 La classe base dei componenti: fl.core.UIComponent .................................... 35

3.5.2 Il metodo configUI e l‟uso degli Stili ............................................................. 36

3.5.3 Il metodo draw() ed il modello d‟invalidazione .............................................. 40

3.5.4 Metadati dei componenti ................................................................................. 43

3

3.5.5 Creazione del componentShim per i componenti personalizzati .................... 44

3.5.6 Definizione di un componente e creazione dell‟anteprima ............................ 47

Capitolo 4.............................................................................................................................. 50

Gesti ...................................................................................................................................... 50

4.1 Caratteristiche delle interfacce gestuali ................................................................. 50

4.1.1 Attributi dei gesti ............................................................................................ 52

4.1.2 Gesti basici/Pattern per i touchscreen ........................................................... 53

4.2 Gesti tattili non convenzionali ............................................................................... 55

4.2.1 Tecnica “$1 Recognizer” per il riconoscimento dei gesti touchscreen .......... 55

Capitolo 5.............................................................................................................................. 62

Sviluppo di strumenti basi di ActionScript per applicazioni Multitouch ............................. 62

5.1 Sviluppo di componenti tattili ................................................................................ 62

5.1.1 Componente: TouchButton ............................................................................. 62

5.1.2 Componente: TouchNumericStepper ............................................................. 69

5.1.3 Componente:TouchSlider ............................................................................... 75

5.1.4 Componente:TouchKeyboard ......................................................................... 79

5.1.5 Errori nei componenti rilevati nel processo di sviluppo ................................. 93

5.1.6 Importando i componenti in FLASH .............................................................. 94

5.2 Creazione di classi di AS3 per l‟interazione con i Gesti........................................ 95

5.2.1 Classificazione dei gesti ................................................................................. 95

5.2.2 Classi di ActionScript 3.0 sviluppate.............................................................. 95

5.2.3 Applicazione di test per le classi dei gesti .................................................... 107

CONCLUSIONI ................................................................................................................. 109

BIBLIOGRAFIA ................................................................................................................ 113

ALLEGATO A ................................................................................................................... 116

1

INTRODUZIONE

Lo sviluppo delle tecnologie informatiche non solo ha comportato una crescita esponenziale

delle capacità di calcolo dei singoli elaboratori, ma ha permesso la creazione di interfacce

uomo-macchina sempre più sofisticate, in grado di semplificare in modo sostanziale la

comunicazione verso l‟elaboratore, rendendo sempre più invisibile la sua presenza

all‟interno di un ambiente. Inizialmente l‟unico dispositivo di input era la tastiera, man

mano altri dispositivi sono stati sviluppati ed aggiunti arricchendo il modo in cui è possibile

interagire con il computer: il mouse che con i movimenti della mano permette di spostare

un oggetto sullo schermo; la video camera che rileva delle immagini che possono essere

inserite successivamente nel computer per modificarle. Al giorno d‟oggi è persino possibile

trovare alcuni dispositivi in ambienti che possono sembrare insolti, come un bagno

pubblico dove per usare i lavandini non bisogna più utilizzare le mani e basta solo metterle

sotto il rubinetto per far uscire l‟acqua. Appare evidente come l‟introduzione di nuovi

dispositivi d‟input e di nuove tecnologie sta portando piano piano ad un cambiamento delle

abitudini e delle modalità d‟interazione delle persone con l‟ambiente che le circonda.

Tutti i dispositivi di ultima generazione in ambito tecnologico aumentano sempre le loro

capacità di elaborare le informazioni, permettendo così di fare operazioni ogni volta più

complesse. Una tecnologia che ha cominciato a diffondersi ampiamente è quella

touchscreen, e si vede implementata su un numero sempre crescente di dispositivi che

integrano questo tipo d‟interfacce. I cellulari, i dispositivi elettrodomestici, e tutti i

dispositivi elettronici in generale utilizzano le interfacce touchscreen per il loro

funzionamento. In generale questi dispositivi riescono a ricevere soltanto un segnale

d‟input alla volta, però negli ultimi anni ci sono stati grandi passi avanti nell‟ambito di

questa tecnologia ed ora è possibile trovare alcuni dispositivi che riescono a rilevare ed

interagire con più segnali d‟input contemporaneamente. Questo tipo d‟interfacce tattili sono

note come interfacce multitouch e le loro prestazioni offrono la possibilità di creare nuovi

modi di interagire con gli utenti e nuove maniere di realizzare applicazioni molto più

interattive.

Tutti i dispositivi che rispondono a dei gesti, come il tocco nei dispositivi touchscreen,

devono avere come minimo tre parti fondamentali: la prima è un sensore che si occupa di

Introduzione

2

misurare gli input del sistema; la seconda è un comparatore che elabora i dati misurati per

rilevare se gli input sono validi o no; la terza è l‟attuatore che realizza un‟azione in risposta

agli input che sono stati considerati validi dal comparatore. Inoltre, sempre nell‟ambito

delle interfacce touchscreen, ci deve essere almeno una parte fisica, l‟hardware, con la

quale l‟utente può interagire. Nei sistemi interattivi di tipo touchscreen è l‟hardware ad

occuparsi di rilevare la presenza di input, e quindi l‟hardware è il sensore del sistema. Per la

costruzione del dispositivo d‟input ci sono tanti tipi diversi di tecnologie: è possibile usare

tecnologie Resistive1, che rilevano il tocco sul touchscreen usando due lamine resistive che

entrano in contatto nel punto di appoggio del dito; tecnologie Capacitive2, che misurano la

variazione di tensione causata dal cambiamento di capacità dei condensatori posti sullo

schermo dovuta al contatto del dito; e sarebbe ancora possibile elencare altre tecnologie3.

Nell‟ambito di questa tesi è stata utilizzata la tecnologia ottica. Questa fa uso della luce

infrarossa per il rilevamento degli oggetti sullo schermo e di una video camera che è

sensibile a questa parte dello spettro della luce. Le diverse tecniche esistenti per questa

tecnologia sono illustrate nella sezione 1.2.

Il passo successivo è l‟elaborazione, da parte del sistema, dei dati appena ricavati e questo è

possibile sia con altri dispositivi hardware sia con un software. Per la tecnologia ottica le

informazioni rilevate sono sotto forma d‟immagini, le quali possono essere elaborate con un

software adatto. Questo software deve essere in grado di ricavare sufficente informazione

dalle immagini per individuare le aree, note come blob, in cui l‟utente è entrato in contatto

con lo schermo. Questi tipi di software sono anche conosciuti come tracker poichè

elaborano le immagini per individuare le posizioni dei blob presenti sullo schermo. Inoltre,

i tracker possono ricavare altre informazioni, come per esempio la velocità oppure

l‟orientamento dei blob. Poiché è possibile individuare contemporaneamente un insieme di

blob, questo tipo di software è anche utilizzato per le interfacce multitouch. Per le

interfacce touchscreen, quindi, questi software sono i comparatori del sistema, e la loro

capacità di elaborazione dell‟informazione è molto importante per un sistema interattivo:

più informazioni riesce a rilevare il comparatore più azioni sarà possibile fare per reagire

agli input dell‟utente.

Il tipo d‟informazione che deve essere ricavata per poterla utilizzare nelle applicazioni

interattive ed il modo in cui deve essere comunicata all‟attuatore del sistema sono descritti

da un protocollo, TUIO, che permettere di standardizzare la comunicazione esistente tra il

tracker e le applicazioni, e la sua descrizione si può trovare nel capitolo 2 del presente

lavoro. Le applicazioni interattive che fanno uso delle informazioni descritte dal protocollo

TUIO possono essere scritte in diversi linguaggi, come Python, C++, ovvero ActionScript

(utilizzato nella programmazione con Flash), quindi è necessario tradurre i dati inviati dal

tracker nel linguaggio con il quale si vuole lavorare per lo sviluppo dell‟applicazione. Per il

1 Resistive Touch Screen <http://resistivetouchscreen.org/>

2 Baxter, L. K. “Capacitive Sensors: Design and applications” pg 138.

3 Henderson, H. “Encyclopedia of computer science and technology” pg 478.

http://resistivetouchscreen.org/

http://www.google.com/search?tbs=bks:1&tbo=p&q=+inauthor:%22Larry+K.+Baxter%22

Introduzione

3

linguaggio ActionScript 3.0 esiste già una libreria di programmazione, Touchlib, che è in

grado d‟interpretare i messaggi inviati col protocollo TUIO e tradurli in linguaggio

ActionScript, però nel farlo questa libreria elabora ancora di più questi dati per riuscire a

comunicare le azioni fatte dall‟utente in un modo più specifico, come per esempio quando

l‟utente appoggia il dito sullo schermo, quando lo sposta, oppure quando lo alza. Le classi

di questa libreria quindi estendono le funzioni del comparatore generando degli eventi, a

partire dai dati inviati dal tracker, che possono essere utilizzati nelle applicazioni

interattive. Dunque capire il funzionamento di questa libreria, per poi sfruttarne le sue

capacità, è stato un punto fondamentale di questa tesi, poichè non c‟era nessuna

documentazione formale relativa al suo funzionamento, alle sue proprietà ed ai suoi metodi.

Questo studio si può trovare nella sezione 2.2.

Una volta che sono state ricavate informazioni più dettagliate sulle azioni dell‟utente è

possibile utilizzarle nelle applicazioni touchscreen. Queste applicazioni, che costituiscono

l‟attuatore del sistema, prendono i dati inviati dal comparatore e li elaborano in modo tale

da reagire in maniera logica alle azioni fatti dall‟utente. Le informazioni degli eventi inviati

dalla libreria touchlib si possono utilizzare con il programma Adobe Flash. Questo

programma utilizza degli elementi, i componenti, per sviluppare applicazioni in un modo

modulare e più veloce. Utilizzare i componenti, quindi, offre un risparmio di tempo e di

logica di programmazione, e le ragioni di ciò sono descritte in dettaglio nel capitolo 3.

Tuttavia questi componenti non possono essere utilizzati per lo sviluppo di applicazioni

touchscreen perché non sono in grado di elaborare le informazioni a esse relative. Perciò

capire il processo che porta alla loro creazione per poi sviluppare dei componenti che siano

in grado di reagire alle azioni dell‟utente è fondamentale per poter sfruttare i vantaggi che i

componenti offrono. Dunque lo sviluppo di alcuni componenti di Flash che possano essere

implementati in interfacce touchscreen è stato uno degli scopi di questa tesi.

Oltre ad interagire con i componenti l‟utente può avere la possibilità di realizzare dei

movimenti che possono essere interpretati come delle azioni specifiche a cui deve reagire

l‟applicazione. Questi tipi di movimenti sono i gesti e, ora come ora, li si può trovare su

molti dispositivi touchscreen, come per esempio l‟Iphone. La descrizione dei gesti e delle

loro caratteristiche viene fatta nel capitolo 4. Grazie all‟uso comune dei dispositivi

touchscreen è possibile parlare ora di alcuni gesti standard, come per esempio „drag‟,

„rotate‟, „scale/zoom‟, i quali vengono applicati a un elemento presente nello schermo. Però

è anche possibile parlare di gesti che non hanno una definizione univoca: un cerchio,

oppure un‟onda, possono far partire delle azioni specifiche a seconda dell‟applicazione.

Individuare quando un gesto è stato fatto è compito del comparatore, ma fino ad ora esso è

stato unicamente in grado di rilevare degli eventi semplici. Perciò un‟altro scopo di questa

tesi è stata la creazione di classi di ActionScript che estendano le funzioni del comparatore

e che possano rilevare dei gesti fatti su uno schermo touchscreen, siano gesti semplici o

standard, o gesti complessi che non hanno una definizione specifica. Questo porterà ad

avere ancora più scelta nel modo di interazione dell‟utente con l‟interfacca touchscreen.

Introduzione

4

Nell‟ambito di questa tesi si vogliono creare degli strumenti che servano come base per lo

sviluppo delle applicazioni con componenti con cui l‟utente possa interagire, e che siano in

grado di reagire agli eventi semplici ed ai gesti. Inoltre grazie alle caratteristiche dello

schermo con tecnologia ottica, che è in grado di rilevare contemporaneamente più di un

blob, questi strumenti diventano anche una base per lo sviluppo d‟interfacce interattive

multitouch.

5

Capitolo 1

TECNOLOGIA MULTITOUCH

1.1 La storia

La tecnologia tattile è nata molto prima dell‟esistenza dei computer. I primi dispositivi

tattili sono stati elaborati da Hugh LeCain e Bob Moog, nella seconda metà degli anni „404.

Il suo lavoro è stato basato sui sintetizzatori e sull‟uso di condensatori sensibili al tatto che,

variando la loro tensione, permettevano di controllare il suono prodotto dallo strumento.

Successivamente lo studio e lo sviluppo di alcuni schermi tattili sono stati fatti dall‟IBM e

dalla CERN (l‟Organizzazione Europea per la Ricerca Nucleare), la quale ha implementato

dei schermi che lavoravano con la capacità dei condensatori, studio basato sul lavoro di Ben

Stumpe5. Contemporaneamente, la compagnia Elographics lavora su schermi di tipo

resistivo, e nel anno 1977 fa un brevetto per la tecnologia che aveva sviluppata6. Dopo di

che, nell‟anno 1982, Nimish Mehta, dell‟università di Toronto, ha sviluppato un‟interfaccia

multitouch per la sua tesi di grado7. Mentre che la compagnia Hewlett-Packard, nell‟anno

1983, costruisce il HP-150, che funzionava con tecnologia ottica: degli emettitori e

rilevatori di luce infrarossa disposti nel bordo dello schermo che servivano per rilevare gli

oggetti che si avvicinavano allo schermo.8

Altri studi sono stati eseguiti da diverse persone e aziende, questa volta cercando

d‟implementare il touchscreen sui cellulari, come per esempio il cellulare „Simon‟9

prodotto dalla IBM e Bell South nell‟anno 1994, oppure l‟onyx della compagnia

4 Hugh LeCain “ELECTRONIC SACKBUT” <http://www.hughlecaine.com/en/sackbut.html>

5 CERN, “The first capacitative touch screens at CERN” <http://cerncourier.com/cws/article/cern/42092>

6 Saffer, D. “Designing Gestural Interfaces” Pg.7

7 Idem. Pg 8.

8 Idem Pg. 9.

9 Idem Pg. 10.

http://www.hughlecaine.com/en/sackbut.html

http://cerncourier.com/cws/article/cern/42092

Capitolo 1 – Tecnologia Multitouch

6

Synaptics10

. Però è stata finalmente la Apple con i suoi prodotti: l‟iPod nel 2007 (modello

multitouch)11

, e l‟iPhone nel 200712

, a rendere questo tipo di tecnologia popolare e d‟uso

comune.

1.2 Parti basici di un sistema Touchscreen

Sia che si sta lavorando con un sistema di tocchi semplici oppure con un sistema

multitouch, ci devono essere un numero minimo di componenti basici per il suo

corretto funzionamento. Ogni sistema di questo tipo deve essere composto di tre

parti: un sensore, un comparatore ed un attuatore. Nella Figura 1 è possibile vedere

com‟è il funzionamento generali ed il rapporto esistente tra questi tre parti. Il

diagramma è stato presso dal libro di Saffer, “Designing gestural interfaces”.

Figura 1.Funzionamento e le parti basici di un sistema touchscreen (tocco semplice oppure

multitouch.)

Un sensore è un dispositivo elettronico o elettrico che è in grado di rilevare dei

cambiamenti che possono essere interni del sistema oppure esterni dell‟ambiente che lo

circonda13

, e dipendendo del tipo di gesto che si vuole rilevare, esistono diversi tipi di

sensori: di luce, di pressione, di prossimità, acustici, di movimento, ecc. Quindi la scelta di

utilizzarne uno e non un‟altro è di molta importanza poichè il tipo di sensore determina il

tipo di gesti che si possono utilizzare con il sistema: se il sensore non è in grado di rilevare

un gesto sarebbe come se l‟utente non avessi fatto nessuna azione. Da un‟altra parte, il

comparatore è la parte del sistema che riceve l‟informazione dal sensore per elaborarla. Si

occupa di comparare lo stato attuale sia conuno stato precedente oppure con uno stato

„scopo‟ del sistema per fare un giudizio ed individuare l‟esistenza di un gesto. Per ultimo si

trova l‟attuatore il quale si occupa di realizzare un‟azione oppure un comando d‟accordo al

10

Synaptics <http://www.synaptics.com/about/press/press-releases/synaptics-and-pilotfish-collaborate-

develop-next-generation-mobile-phone-> 11

Apple “Apple Unveils iPod touch” <http://www.apple.com/pr/library/2007/09/05touch.html> 12

Apple “Apple Reinvents the Phone with iPhone”

<http://www.apple.com/pr/library/2007/01/09iphone.html> 13

Saffer, D. “Designing Gestural Interfaces” pg.13

http://www.synaptics.com/about/press/press-releases/synaptics-and-pilotfish-collaborate-develop-next-generation-mobile-phone-


http://www.apple.com/pr/library/2007/09/05touch.html

http://www.apple.com/pr/library/2007/01/09iphone.html


7

giudizio fatto dal comparatore. Quindi l‟attuatore può essere per esempio il software che

decide che azione fare, una volta il comparatore ha individuato un gesto

A continuazione si farà una breve descrizione delle diverse tecniche per la costruizione

alcuni tipi di sensori. Queste la sua descrizione è importante perchè permette di capire le

prestazioni del tipo di sensore, di cos‟è capace di individuare e quindi di sapere com‟è

possibile utilizzarne.

1.3 Descrizione delle diverse tecniche per la costruzione dei

dispositivi ottici

Le tecniche descritte qui di seguito si utilizzano per la costruzione di schermi tattili di tipo

ottico. L‟hardware che verrà descritto in questa sezione è quello utilizzato da parte della

NUI-group, che vuole sopratutto creare sistemi open-source a basso costo. Queste

tecnologie hanno una caratteristica in comune che è l‟utilizzo della luce infrarossa, sebbene

esistano altri tipi di tecnologie, scegliere d‟implementare queste tecniche risulta meno

costoso che implementare gli altri tecnologie (Resistive, Capacitive, ecc.). In seguito si fa

una descrizione delle tecnologie ottiche. L‟ultima tecnica descritta , l‟illuminazione diffusa

superficiale, è quella utilizzata nell‟ambito di questa tesi.

1.3.1 Tecnologia ottica – L‟uso della luce infrarossa

La tecnologia ottica è basata sull‟utilizzo di dispositivi che siano in grado di rilevare dei

cambiamenti sullo schermo del computer. Questi fanno uso di sensori che sono in grado di

rilevare la presenza di sorgenti di luce. Un tipo di sensore di questo tipo è la video camera.

In questo caso le informazioni che si devono elaborare sono le immagini rilevate dalla

camera. Di solito questi tipi di dispositivi basati sulle tecniche ottiche sono più graditi dalle

altre tecniche perchè sono scalabili, di basso costo e di bassa difficoltà per la sua

costruzione.

Le tecniche ottiche sono sistemi composti da un sensore ottico, i.e. la video camera, una

sorgente di luce infrarossa e un feedback visivo. L‟uso della lunghezza d‟onda della luce

infrarossa è una ottima scelta innanzitutto per il fatto che, non facendo parte dello spettro di

luce visibile, e poiché molti sensori delle camere sono sensibili a questa lunghezza d‟onda,

ciò permette di rilevare unicamente alcuni tipi di dati specifici. Infatti solitamente le

telecamere hanno un filtro che non permette di far passare le lunghezze d‟onda infrarossa,

togliendo però questo filtro, ed aggiungendo invece un‟altro che tolga lo spettro visibile, si

ottiene che la video camera rilevi unicamente la luce infrarossa, è quindi possibile sfruttare

questa caratteristica per il tracking dei tocchi e degli oggetti sulla superficie.

La luce infrarossa permette di fare una distinzione tra l‟immagine visuale, gli oggetti o le

dita che vengono rilevate dalla superficie. Sebbene lo schermo sia utilizzato sia per il


8

feedback visuale che come dispositivo d‟interazione per l‟utente, è importante che la video

camera non catturi l‟immagine proiettata al momento di fare il tracking degli oggetti, ed è

questa la ragione per cui viene inserito un filtro per la luce visibile. Togliendo

dall‟immagine queste lunghezze d‟onda, gli unici oggetti che sono rilevati dalla video

camera sono gli oggetti e le dita che vengono illuminati con la luce infrarossa.

Tra la moltitudine di tecniche ottiche esistenti quella a LED Infrarossi è la maggiormente

utilizzata. Anche se i LED-IR non sono l‟unica sorgente possibile di luce IR, esistono altri

tipi di sorgenti come i Laser IR i quali sono più efficienti ed efficaci nel fornire questo

spettro di luce. La scelta del tipo di LED da utilizzare dipende dalla tecnica che si vuole

implementare, perciò è importante capire se le caratteristiche dei LED sono adeguate alla

tecnica utilizzata:

- La lunghezza d‟onda della luce emessa di solito si trova nello spettro IR che le

camere possono vedere, ma più è bassa la lunghezza maggiore sarà la sensibilità14

.

- E‟ preferibile che l‟intensità di radiazione sia la più alta possibile.

- E‟ preferibile che l‟angolo d‟illuminazione sia il più ampio possibile, così che si

riesca a ottenere un‟illuminazione uniforme su tutti i punti della superficie, evitando

in questo modo delle regioni con concentrazione di luce maggiore, note come

hotspots.

Gli hotspots, sono quindi delle regione di concentrazione di luce che rappresentano un

problema poichè potrebbero portare ad un rilevamento di falsi blob sulla superficie. Per

evitarli di solito si utilizzano dei filtri passa-banda che si aggiungono alla video camera.

Infatti, le caratteristiche del dispositivo da soli possono condizionare significativamente il

tracking. Alcune di queste caratteristiche sono elencate in seguito:

- La risoluzione della video camera agisce direttamente sulla precisione del

rilevamento dei blob. Più pixel ci sono per immagine più accurato sarà il

tracking, pertanto dipendendo ciò dalle dimensioni della superficie, bisogna

capire quale sarà la risoluzione adeguata della video camera, così da ottenere la

precisione desiderata.

- Il frame rate influisce sulla quantità d‟informazioni disponibili per unità di

tempo, fatto che diviene importante quando è necessario rilevare spostamenti

veloci degli oggetti o le dita sulla superficie. Dunque un frame rate alto è più

indicato.

14

MultiTouch Technologies – Infrared Light Sources.


9

- La velocità con cui i dati vengono inviati al computer dalla video camera

dipende dal tipo d‟interfaccia utilizzata. La più economica è l‟interfaccia USB

ma, poichè dipende delle esigenze del sistema, si può optare per un‟interfaccia

più veloce come la IEEE 1394 (FireWire).

Avendo finora fatto una descrizione generale delle caratteristiche che si devono tenere in

conto nei sistemi ottici, si andrà di seguito a elencare una breve descrizione delle diverse

tecniche ottiche esistenti.

1.3.1.1 FTIR (Frustated total internal reflection)

Questa tecnica è stata sviluppata per Jeff Han nel 200515

e si basa sull‟uso del fenomeno

della riflessione totale interna: quando un raggio di luce passa attraverso mezzi con un

indice di rifrazione diverso, il raggio viene deviato. L‟angolo di deviazioni dipende sia

dagli indici di rifrazioni dei due mezzi che dall‟angolo d‟incidenza del raggio. Esiste un

angolo d‟incidenza, noto come angolo critico, per cui il raggio di luce non attraversa più il

secondo mezzo ma viene riflesso, e questo comportamento, noto come riflessione interna

totale, si ripete per qualunque angolo d‟incidenza maggiore all‟angolo critico16

.

Figura 2. Principi di funzionamento generale di FTIR

Questo fenomeno viene utilizzato per racchiudere la luce infrarossa emessa dai LED IR

all‟interno di un pezzo di materiale acrilico, utilizzato come superficie di contatto. Nel

momento in cui l‟utente tocca la superficie, i raggi di luce IR in quel punto sono deviati

15

“Multitouch Technologies” NUI Group Authors 16

Total Internal reflection and lenses – Physics Department, Boston University

<http://physics.bu.edu/~duffy/py106/Lenses.html>

http://physics.bu.edu/~duffy/py106/Lenses.html


10

verso il basso, attraversando la superficie acrilica, e venendo quindi catturati dalla video

camera. Nella Figura 2 s‟illustra uno schema generale del funzionamento della tecnica.

1.3.1.2 Diffused Illumination (DI)

Questa tecnica ha due modi diversi d‟applicazione, ed entrambi usano lo stesso principio: il

contrasto tra un‟immagine base e l‟oggetto che entra in contatto con la superficie.

Il primo modo di applicare la tecnica porta il nome di Front Diffused Illumination. Lo

schermo viene illuminato dall‟ambiente con luce visibile e un diffusore è allocato sia nella

parte superiore che in quella inferiore della superficie. Nell‟istante in cui l‟utente appoggia

il dito sulla superficie si crea un‟ombra nella posizione di contatto che viene rilevata dalla

video camera.

Il secondo modo, noto come Rear Diffused Illumination, ha un montaggio un po‟ più

complesso. Innanzitutto la superficie deve essere illuminata uniformemente con luce IR

dalla parte posteriore dello schermo, ma illuminando di questo modo è però inevitabile

l‟esistenza di regioni più scure, non illuminate bene, dove non sarà facile poi individuare i

tocchi. Per correggere quest‟ errore si può provare modificare la parte hardware

ridistribuendo in un maniera migliore la luce sulla superficie, questo si può fare sia

utilizzando un diffusore di luce che modificando la posizione delle sorgente di luce IR,

oppure si possono applicare dei filtri a livello software che agiscono soltanto sulle regioni

dell‟immagine dove si trovano le zone più scure.

Figura 3. Schema di funzionamento della tecnica Rear DI


11

Dopo di ché quando l‟utente tocca lo schermo, la luce in quel punto riflette maggiormente

rispetto al resto dello schermo, ed i raggi di luce che vengono deviati sono catturati dalla

video camera. Con questa tecnica, e grazie al diffusore, è possibile individuare perfino

oggetti che sono sospesi sopra la superficie. Lo schema di funzionamento di questa tecnica

viene illustrata nella Figura 3.

1.3.1.3 LLP (Laser Light Plane)

In questa tecnica, alcuni laser di luce infrarossa sono messi in modo tale da illuminare solo

sopra la superficie dello schermo, creando un piano con uno spessore di circa 1mm. In

seguito, quando l‟utente prova a toccare lo schermo, tocca anche il piano di luce IR e in tal

maniera viene individuato il blob (Figura 4).

Figura 4. Principio di funzionamento del Laser Light Plane

1.3.1.4 LED-LP (LED- Light Plane)

Il montaggio per questa tecnica è molto simile a quello di LLP eccetto per il fatto che,

invece di utilizzare luce IR emessa da un laser, si usano dei LED. I LED vengono così

disposti lungo il perimetro dello schermo dando luogo ad un piano di luce uniforme.

Nonostante il piano sia uniforme, il cono di luce emesso dai LED illumina oggetti che sono

vicini alla superficie che però non l‟hanno ancora raggiunta, rilevandoli così in anticipo sul

tocco. Questo problema si può correggere con l‟utilizzo di un filtro, che è necessario tarare

adeguatamente, scegliendo le soglie giuste per rilevare gli oggetti unicamente quando sono

veramente vicini alla superficie, tanto da potere considerare l‟evento come un tocco. Si può

anche correggere a livello meccanico con l‟utilizzo di un schermo paraluce che non


12

permetta che i raggi luminosi vengano emessi al di sopra del piano orizzontale, come si può

vedere nella Figura 5.

Figura 5. Schema per la tecnica LED-LP

1.3.1.5 DSI (Diffused Surface Illumination)

Questa tecnica utilizza un principio simile alla FTIR ma ha bisogno per il suo montaggio di

un tipo di materiale acrilico speciale - Plexiglass endlighten-. Questo materiale acrilico ha

al suo interno piccole particelle che funzionano come specchi, e quando la luce IR viene

emessa dal perimetro dello schermo, ridireziona i raggi verso la superficie dello schermo,

ottenendo un effetto simile alla tecnica DI, con un‟illuminazione uniforme e senza hotspots

(Figura 6).

Figura 6. Principi di funzionamento DSI


13

1.4 Descrizione Generale del Sistema

Come già affermato il sistema è diviso in due parti, una hardware e una software, e ogni

parte è ulteriormente divisa in altre due parti (Figura 7). La parte hardware ha due

dispositivi principali, uno è lo schermo dove l‟utente può „toccare‟ gli oggetti visualizzati in

cui è stata implementata la tecnica DSI, mentre l‟altra è la video camera infrarossa messa

dietro allo schermo, che rileva l‟immagine, insieme compongono quello che sarebbe il

sensore del sistema touchscreen. Dopo di che le immagini si passano al comparatore, che in

questo sistema è un software che è stato elaborato dalla Nui-Group.

Nell‟ambito di questa tesi si è deciso di approfondire maggiormente la parte software

rispetto a quella hardware, che qui di seguito si va a illustrare, descrivendone il

funzionamento e gli elementi compositivi

Figura 7. Schema illustrativo del sistema generale. (a) L‟hardware composto dallo (a) schermo e

dalla (b) video camera, ed il sofware composto (c) dal tracker, CCV, che invia i messaggi al

programma (d) Flash.

1.4.1 CCV – Il Tracker

Il comparatore entra in funzione quando le immagini ricavate dalla video camera passano al

software e il primo programma, il Community Core Vision (CCV), analizza le immagini per

individuare e calcolare le coordinate di ogni blob. Per fare ciò l‟immagine viene elaborata

con diversi filtri, che possono essere modificati per mezzo dell‟interfaccia utente (Figura 8).

I programmi che fanno questa individuazione, di solito noti come tracker, possono

utilizzare diversi metodi oltre a quello ottico del CCV. Il programma analizza frame per

frame l‟allocazione di ogni blob e assegna a ciascuno di loro un identificativo, tenendo

sempre in considerazione di far corrispondere correttamente ogni blob da un frame all‟altro,

questa azione è nota come blob tracking. In seguito il tracker deve rilevare delle

informazioni relative ad ogni blob (coordinate, velocità, ecc.), le quali sono compatibili con

d) c) b)

a)


14

la specifica di un protocollo, noto come TUIO poichè è stato il gruppo dello stesso nombre

a fare la specifica. Questo protocollo è utilizzato nella costruzione d‟interfacce utente per

applicazioni multitouch. (La descrizione di questo protocollo si fa nel capitolo 2)

Dopo di che tutte le informazioni ricavate per ogni blob vengono messi insieme in un

messaggio ed inviate al attuatore del sistema. La struttura del messaggio è anch‟essa

specificata dal protocollo TUIO. Tutte queste informazioni sono necessarie affinché

l‟applicazione possa sapere la precisa collocazione dei blob sulla superficie e quale sono le

sue proprietà (come ad esempio la velocità, l‟ID che gli è stato assegnato, ecc…) e così

reagire adeguatamente agli input ricevuti ed eseguire i comandi che l‟utente richiede

all‟interno dell‟applicazione.

Figura 8. Interfaccia del software CCV – il tracker del sistema

Nella Figura 8 si può vedere l‟interfaccia del programma tracker. Nella parte centrale si

trovano sia l‟immagine ricavata dalla video camera, detta nome „source’, sia l‟immagine

elaborata con i blob identificati e gli identificativi assegnati, detta nome „tracked’. Nella

parte bassa si trovano quatro immagini di dimensione minore: la prima a sinistra, nota con

il nome „background‟, è l‟immagine che viene utilizzata dal software come sfondo o

immagine base e rappresenta il display quando non c‟è nessuna attività sullo schermo. Poi

quando lo schermo è toccato, i punti di contatto vengono più illuminati e quindi se

l‟immagine di background si sostrae dall‟immagine nuova , viene rilevata una differenza

nei punti di contatto. Questo processo si ripete per ogni frame rilevato dalla video camera

rilevando cosi i blob per ciascuno dei frame. Le altre tre immagini che si trovano in basso,

sono filtri che si possono attivare o rimanere inattivi a seconda della necessità: il primo

filtro è per smussare l‟immagine, il secondo è un filtro passa-alto, ed il terzo è un


15

amplificatore che serve per amplificare l‟immagine che è stata elaborata con gli altri due

filtri.

Nella parte destra dell‟interfaccia si trovano alcuni parametri del programma. Con questi

parametri è possibile cambiare alcune caratteristiche delle immagini rilevate per la video

camera, modificare il metodo in cui vengono inviati i messaggi ed alcune impostazioni

proprie del programma. Prima di utilizzare il tracker è importante calibrarlo adeguatamente

con le dimensioni dello schermo usato per fare sì che le coordinate rilevate dal tracker siano

quelle giuste. Dopo di che si fanno tutti i calcoli necessari per trovare tutte le informazioni

rispettive d‟ogni blob rilevato e si codificano in messaggi per inviarli all‟applicazione

client, che fa di attuatore, che in questo caso è un‟applicazione eseguita con flash.

Di seguito si va ad illustrare le caratteristiche ed i vantaggi che offre il programma flash nel

momento di sviluppare applicazioni interattive.

1.4.2 FLASH – Uno strumento per applicazioni Interattive

La versione del programma che è stata utilizzata è la versione Flash CS3 Professional. Il

pogramma è stato usato innanzitutto per la realizzazione di applicazioni web, ed il suo

ampio uso è dovuto a diverse ragioni principalmente perchè tanti browser sono compatibili

con l‟utilizzo del Flash Player (Tabella 1.) che è un plug-in per i browser che permette di

visualizzare le applicazioni sviluppate con Flash. Attualmente molte di queste applicazioni

si conoscono come RIA (Rich Internet application) che sono applicazioni che contengono

alcune delle caratteristiche di quelle del desktop e che permettono una maggior interazione

con l‟utente rispetto a quelle che si trovavano precedentemente reperibili sul web.

Platform Browser Player version

Windows Internet Explorer (ed altri browser che supportano i controlli ed i

plug-ins di Internet Explorer ActiveX) 10.1.85.3

Windows Firefox, Mozilla, Netscape, Opera ( ed altri browser basati

sull‟utilizzo di plug-ins) 10.1.85.3

Macintosh -

OS X Firefox, Opera, Safari 10.1.85.3

Linux Mozilla, Firefox, SeaMonkey 10.1.85.3

Solaris Mozilla 10.1.85.3

Tabella 1. Compatibilità di Flash player con diversi sistemi operativi e browser17

17

Tabella presa dal sito di Adobe - <http://www.adobe.com/software/flash/about/>

http://www.adobe.com/software/flash/about/


16

Flash permette di eseguire applicazioni per mezzo dell‟utilizzo di alcuni componenti

utilizzati per realizzare funzioni specifiche, e che hanno già al loro interno tutta la logica di

programmazione necessaria per il loro funzionamento, ne sono un semplice esempio un

pulsante oppure un checkbox. Questo implica innanzitutto un risparmio di tempo per lo

sviluppatore di applicazioni, che quindi può dedicarsi a programmare le altre parti che

compongono il programma. I componenti diventano così uno strumento molto utile per la

realizzazione di qualunque tipo di applicazione.

Attualmente lo sviluppo di applicazioni interattive è divenuto mano a mano sempre più

importante, sopratutto nell‟ambito delle applicazioni multitouch, le quali implicitamente

comportano un‟interazione con l‟utente. La creazione di queste applicazioni sarebbe

eseguibile attraverso flash con l‟uso di componenti appositi, ma attualmente non esistono

dei componenti di Flash per applicazioni multitouch, ed è questa la principale ragione per

cui c‟è l‟interesse di sviluppare questi tipi di componenti. Per farli, bisogna programmarli

con il linguaggio ActionScript, che ha avuto diverse versioni e ad oggi è reperibile nella

versione 3.0. Per fare ciò, si utilizzerà il modello di programazione basato sugli EVENTS di

Flash, che è ideale per l‟interazione con l‟utente poiché permette di capire quando l‟utente

ha fatto un‟azione e dunque poter reagire ad essa.

Per questi tipi di applicazioni esistono eventi standard che vengono generati come risposta

ad alcune singole azioni dell‟utente. Queste azioni o gesti, possono essere scomposti in

singole fasi oppure in azioni istantanee, le quali vengono interpretate come singoli eventi

all‟interno del programma. Ad esempio questi eventi possono descrivere: l‟appoggiare il

dito sullo schermo, l‟alzarlo, oppure il far scorrere il dito sul display. È anche possibile

generare eventi che descrivano un gesto, come per esempio il semplice toccare lo schermo,

che in realtà è composto da una serie di più eventi consequenziali (l‟azione di appoggiare il

dito alla quale segue quella di alzarlo); ciò comporta l‟utilizzo di una logica di

programmazione più complessa che sia in grado di interpretare la sequenza di singoli

eventi. Il programma Flash in questo ambito, attraverso Actionscript, permette la creazione

di classi apposite che definiscono gli eventi semplici oppure dei gesti.

Quindi un vantaggio di Flash è che usa il modello di eventi per poter reagire alle azioni

dell‟utente e si sa che l‟uso di componenti appositi per le applicazioni interattivi anche

sarebbero molti graditi per fare questo compito. Ma per poter svilupparli, bisogna prima

riuscire a rilevare l‟informazione individuata dal tracker, ed questo è possibile con la

libreria touchlib ed il protocollo TUIO che si illustra nel capitolo 2.

17

Capitolo 2

TUIO

TUIO è un framework che mira a di standardizzare e definire un protocollo per superfici

tattili. Questo protocollo cerca di codificare l‟informazione rilevata dal tracker, per poi

poterla inviare all‟applicazione che la richiede. Attualmente esistono sia diversi programmi

tracker, un esempio è CCV, che librerie di programmazione per diversi linguaggi, le quali

riescono a decodificare l‟informazione inviata nel protocollo TUIO. Una di queste librerie,

Touchlib, verrà analizzata nello specifico più avanti. Le librerie vengono utilizzate nelle

applicazioni per interpretare l‟informazione inviata nel messaggio TUIO e così reagire alle

azioni dell‟utente. Tutte le informazioni riguardanti questo standard si possono reperire dal

sito della comunità Tuio18

.

2.1 Specifica del protocollo TUIO 1.1

Il protocollo stabilisce un‟interfaccia di comunicazione tra i dispositivi fisici e le

applicazioni. Gli oggetti che vengono rintracciati sullo schermo possono essere classificati

in tre diversi profili, ognuno dei quali contiene delle informazioni base comuni a tutti i tre,

alle quali si aggiunge per ciascun profilo un‟informazione addizionale necessaria per la sua

descrizione. Il profilo tipo Object viene identificato con un ID, con la sua locazione e infine

con il suo orientamento sulla superficie; il profilo tipo Cursor, che di solito rappresenta i

tocchi con le dita, questo non è identificato da un ID univoco e non ha neanche

informazioni sull‟orientamento; il profilo di tipo Blob, che contiene l‟informazione per

descrivere l‟estensione approssimata di alcuni oggetti non etichettati, ovvero regioni

toccabili (touch region), con un riquadro di delimitazione (bounding box), che è

rappresentato per l‟approssimazione ellittica, compreso l‟angolo e l‟area. (Una descrizione

più dettagliata dei profili verrà fatta più avanti).

Il protocollo TUIO è stato codificato utilizzando il formato OSC (Open Sound Control), il

quale permette di codificare in linguaggio binario e in un modo efficiente l‟informazione.

Utilizzare questo formato permette anche di trasmettere i messaggi TUIO su qualunque

canale che supporti l‟implementazione di OSC. Il metodo scelto è quello di incapsulare

18

TUIO website - <http://www.tuio.org>

http://www.tuio.org/

Capitolo 2 – TUIO

18

l‟informazione OSC dentro un pacchetto UDP che si invia al <port> 3333, per default. E‟

inoltre possibile inviare l‟informazione in pacchetti TCP, a seconda della necessità e delle

condizioni del canale di trasmissione.

2.1.1 Implementazione, efficienza ed affidabilità del protocollo

Il protocollo TUIO definisce quattro tipi di messaggi che contengono diverse informazioni:

I messaggi tipo SET contengono l‟informazione sullo stato dell‟oggetto (come la posizione,

l‟orientazione e altre), invece i messaggi tipo ALIVE contengono l‟elenco degli ID di

sessione dell‟insieme di oggetti presenti sulla superficie. Per sapere se un oggetto è ancora

presente sulla superficie, si verifica la continuità tra un messaggio e l‟altro.

Ci sono anche i messaggi tipo FSEQ che etichettano in modo unico ogni passo di

aggiornamento con un ID di sequenza di frame. Facoltativamente è possibile inserire un

messaggio tipo SOURCE che identifica la sorgente TUIO permettendo il multiplexing di

sorgente dalla parte del client.

L‟utilizzo del protocollo UDP permette una latenza bassa nel trasporto dell‟informazione.

Tuttavia, con l‟utilizzo di questo protocollo esiste la possibilità di perdita dei pacchetti di

informazione, perciò l‟implementazione del protocollo TUIO include informazioni

ridondanti, prevedendo la perdita dei dati. L‟utilizzo del protocollo TCP fa più affidabile la

trasmissione però aumenta il tempo di latenza.

Per ragioni di efficienza i messaggi tipo SET sono raggruppati per l‟utilizzo dello spazio in

pacchetti tipo UDP. Ogni gruppo include anche un messaggio di tipo ALIVE che preserva

dalla perdita dei dati. Per un insieme più grande di oggetti, viene trasmesso un gruppo di

messaggi SET, ed un messaggio ALIVE. Quando non c‟è attività sulla superficie, i

messaggi ALIVE vengono inviati ad una frequenza dipendente dalla qualità del canale, così

da assicurarsi che il ricevitore ottenga le informazioni sufficienti sugli oggetti che ci sono

ancora sulla superficie. Successivamente le informazioni di ogni oggetto ancora presente

sullo schermo che non sia cambiato viene inviato attraverso diversi messaggi SET, che

contengono la stessa informazione (informazione ridondante), ma ad una frequenza minore

e che comprende soltanto un sotto insieme degli oggetti che non sono cambiati ad ogni

aggiornamento. Questo si fa per poter tenere aggiornata le informazioni di ogni blob, anche

se la sua posizione non sia cambiata.

Ad ogni pacchetto viene assegnato un ID della sequenza del frame (fseq): un numero che si

incrementa ed è uguale per tutti i pacchetti che contengono le informazioni acquisite allo

stesso tempo. Questo permette all‟applicazione client di avere un maggior controllo dei dati

dovuto al fatto che se i pacchetti arrivano in disordine, il cliente volendo può identificare

ovvero lasciarli perdere.

Capitolo 2 – TUIO

19

Figura 9. Composizione dei pacchetti di messaggi per due blob trovati sullo schermo

Per ogni pacchetto di messaggi UDP, quindi, bisogna come minimo inviare un messaggio

tipo ALIVE ed uno FSEQ, che delimitano il gruppo. Per ognuna di queste fasce si aumenta

l‟ID del FSEQ, mentre per i messaggi ridondanti l‟ID di sequenza viene assegnato il valore

-1.

Capitolo 2 – TUIO

20

2.1.2 Profili ed i suoi attributi

TUIO prevede tre tipi di profili: cursor, object e blob. Se questi profili non servono, è

possibile avere un profilo personalizzabile in cui si permette l‟invio di parametri definiti

dall‟utente. I parametri inviati per ogni profilo per una superficie 2D si possono vedere

nella Tabella 2.

Attributi Object Cursor Blob

s ID sessione X X X

i ID classe X

x, y Posizione X X X

a Angolo X X

w, h Dimensioni X

f Area X

X, Y Vettori di

velocità X X X

A Vettore velocità

di rotazione X X

m Accelerazione X X X

r Accelerazione

di rotazione X X

Tabella 2. Parametri per i diversi profili TUIO

Il parametro s, ID di sessione, è un identificatore che viene assegnato ad ogni object, cursor

o blob, questo rimane lo stesso durante la sessione. Anche se l‟ID di sessione è unico per

ogni profilo, l‟utilizzo dello stesso ID fa referenza alla stessa istanza. Questo permette di

utilizzare un profilo che contiene più informazioni, come il profilo blob, per l‟invio di dati

addizionali per altri tipi di istanze per le quali i profili object o cursor risultano essere

sufficienti.

Il profilo blob, serve a descrivere la geometria dell‟istanza rilevata. I messaggi di questo

profilo contengono la descrizione dell‟ellisse interna del riquadro di delimitazione, il punto

centrale, l‟angolo dell‟asse maggiore, le due dimensioni e l‟area (Figura 10.), la quale viene

normalizzata in pixel/larghezza*lunghezza. Anche la lunghezza e la larghezza del blob

sono normalizzati.

Capitolo 2 – TUIO

21

Figura 10. Rappresentazione grafica del riquadro di delimitazione e l‟ellisse interna calcolato per un blob19

2.2 Touchlib

Touchlib è una libreria di programmazione in linguaggio ActionScript 3.0, che gestisce il

tracking dei blob per poi inviare una notifica degli eventi alle applicazioni. Questa libreria

ha un‟interfaccia che può stabilire una comunicazione con diversi tipi di webcam e di

dispositivi di cattura del video, e per fare ciò utilizza un pacchetto di classi noto come le

classi TUIO. Queste gestiscono gli oggetti rilevati, la generazione degli eventi e la

decodifica dei messaggi inviati dal software CCV, i quali contengono l‟informazione in

formato TUIO.

In totale ci sono 4 classi diverse e queste sono state studiate per capire il loro

funzionamento e sfruttare così al meglio le loro prestazioni. Le quattro classi sono: TUIO,

TUIOCursor, TUIOEvent e TUIOObject. In questa sezione viene fatta una breve

descrizione delle funzione e delle caratteristiche più importanti di ogni classe, inoltre una

descrizione più completa di queste si può trovare nell‟allegato A.

2.2.1 Classe TUIO

Questa tra tutte e quattro è la classe più importante. La prima funzione che viene chiamata

esegue il collegamento con il „server‟, che in questo caso è il software CCV; questo invia i

messaggi ed inizializza anche alcune variabili di cui necessita per il suo funzionamento. Tra

le variabili che contiene, si trova un vettore in cui vengono inserite le istanze della classe

TUIOObject, le quali a loro volta contengono ciascuna le informazioni dei blob rilevati dal

tracker. Questi dati vengono trasmessi attraverso messaggi inviati dal software CCV, e

vengono poi ricavati attraverso una funzione interna della classe.

La classe implementa diversi metodi che sono necessari per la gestione sia degli oggetti

19

Presa dal sito di TUIO - <http://www.tuio.org/?tuio11>

http://www.tuio.org/?tuio11

Capitolo 2 – TUIO

22

TUIO che delle informazioni inviate attraverso i messaggi, inoltre sono necessari per

restituire istanze che contengono l‟informazione dell‟oggetto TUIO, e per la gestione delle

notifiche degli eventi TUIO ( può avvenire che la classe stessa faccia direttamente la

notifica, oppure se sono necessari prima dei calcoli particolari si possono interpellare altri

metodi che s‟incaricano di eseguirli e di emettere in seguito la notifica dell‟evento

rispettivo).

Segue qui un elenco dei metodi principali con una breve descrizione delle loro funzioni

principali:

- init():

Esegue il collegamento con il server ed inizializza le variabili della classe.

- processMessage():

Riceve i messaggi inviati dal tracker e vi ricava i dati. Fa uso dei messaggi tipo

ALIVE per aggiornare gli oggetti TUIO dentro l‟array. Se nel messaggio non viene

trovato più l‟id di un oggetto ciò significa che questo non è più attivo sullo schermo,

se invece nel messaggio individua un‟id che precedentemente non era presente genera

un TUIOObject e lo aggiunge nell‟array.

- getObjectById():

Questa funzione riceve come parametro l‟id di un oggetto TUIO e restituisce

l‟oggetto a cui è stato assegnato questo id.

- listenForObject():

Riceve due parametri: l‟id ed un oggetto, al quale ne aggiunge un secondo in un array

d‟istanze; e queste sono pronte a ricevere la notifica degli eventi inerenti ad ogni

oggetto TUIO.

Ci sono altri metodi che si occupano della gestione degli eventi e di controllare la corretta

comunicazione tra tutti i metodi delle altre classi.

2.2.2 Classe TUIOCursor

Soltanto questa classe crea un oggetto di tipo Sprite che viene poi inserito sul display

dell‟applicazione e va a indicare dov‟è stato rilevato il tocco. Le istanze di questa classe

vengono create nel medesimo momento in cui si creano le istanze della classe TUIOObject.

Ogni cursor è quindi collegato ad un TUIOObject.

Capitolo 2 – TUIO

23

Se l‟opzione di debug è stata configurata nella classe TUIO, viene anche inserito il numero

ID che è stato assegnato al blob.

2.2.3 Classe TUIOEvent

Questa classe estende la classe Event ed è la tipica definizione di eventi fatta per

actionScript. Gli eventi definiti nella classe sono TUIO_MOVE, TUIO_DOWN,

TUIO_CLICK, TUIO_UP, TUIO_OVER, TUIO_OUT. Ogni evento contiene come

informazione il tipo o il nome dell‟evento, le proprietà bubbles e cancelable che devono

essere definite per passare alla classe Event. Ed è la stessa classe a contenere

l‟informazione della posizione dell‟evento e l‟ID del blob.

Questi eventi vengono notificati nelle classi TUIO e TUIOObject nei momenti giusti, per

esempio, TUIO_DOWN e TUIO_UP vengono notificati rispettivamente quando il tracker

rileva un tocco e quando il tracker stabilisce che il tocco non esiste più. Questa

informazione viene estratta dai messaggi inviati dal software CCV, messaggi che si ricorda

vengono processati nella classe TUIO.

2.2.4 Classe TUIOObject

Questa classe s‟incarica di raccogliere le informazioni inerenti agli oggetti rilevati, e le

riceve dalla classe TUIO tramite i messaggi inviati dal tracker. Una volta che viene creata

un‟istanza di questa classe, i dati di posizione, velocità e rotazione, assieme alle

informazioni di id dell‟oggetto rilevato, vengono salvati in quest‟istanza. Dopo di che si

genera un cursore con la classe TUIOCursor a cui si assegnano le stesse coordinate

dell‟oggetto. Questa classe che fa anche la notifica dell‟evento TUIO_DOWN, che si fa nel

momento che si rileva un oggetto sullo schermo; in seguito bisogna utilizzare dei metodi

che permettono agli oggetti di ricevere la notifica degli eventi TUIO. Questi metodi

possono essere sia il metodo listenForObject() della classe TUIO, che il metodo

addListener() di questa classe, i quali aggiungono all‟interno dell‟array di listeners

dell‟istanza gli oggetti su cui l‟utente a „toccato‟.

Ci sono anche un altro insieme di metodi necessari per rilevare le informazioni di ciascun

TUIOObject che sia stato creato dalla classe TUIO; e questi gestiscono la notifica degli

eventi TUIO_OVER, TUIO_OUT e TUIO_MOVE. Tutti questi metodi vengono

interpellati dalla classe TUIO che è quella a cui concerne la gestione generale dei dati.

Si elencano in seguito i metodi più importanti della classe:

Capitolo 2 – TUIO

24

- TUIOObject():

Il metodo costruttore riceve i dati rilevati dal tracker di ogni blob individuato

sullo schermo, e li salva sulle proprietà della classe. Ogni istanza di TUIOObject

contiene i dati rispettivi ad un‟istanza con un identificativo specifico. Sempre

che la classe TUIO venga inizializzata in modo debug, verrà creato un cursore

con la classe TUIOCursor da collocare nella posizione dell‟oggetto TUIO.

- notifyCreated():

Fa la notifica degli eventi TUIO_DOWN e TUIO_OVER.

- notifyMoved():

Questo metodo viene chiamato periodicamente quando si aggiornano le

coordinate dell‟oggetto TUIO. Per fare ciò invia la notifica dell‟evento

TUIO_MOVE a tutti gli oggetti che si trovano all‟interno dell‟array di listeners.

- setObjOver():

Questo metodo riceve un‟argomento di tipo DisplayObject. Se prima l‟oggetto

TUIO non era rilevato sopra nessun‟altro display object, il valore ricevuto è

inserito dentro il parametro „obj‟, e si esegue la notifica dell‟evento

TUIO_OVER. Se invece il display object ricevuto è diverso da quello salvato

precedentemente nel parametro „obj‟, oppure nel caso in cui non esista l‟oggetto

(un valore „null‟), viene inviata la notifica dell‟evento TUIO_OUT (perchè il

cursore non è più sopra l‟oggetto su cui si trovava prima). Ed infine se l‟oggetto

nuovo esiste si salva nel parametro „obj‟, e si notifica TUIO_OVER per questo

display object.

- addListener():

Il metodo riceve come argomento un‟oggetto Display che viene aggiunto nel

array di listeners dell‟oggetto TUIO.

- removeListener():

Il metodo riceve come argomento un‟oggetto Display, il quale viene rimosso

Capitolo 2 – TUIO

25

dall‟array di listeners dell‟oggetto TUIO

- kill():

Il metodo si chiama quando l‟utente smette di toccare lo schermo ed il tracker

rileva che il blob non esiste più, in questo caso bisogna rimuovere il

TUIOObject ed il cursor che erano stati aggiunti nella medesima posizione. Una

volta rimosso l‟oggetto TUIO, s‟invia la notifica dell‟evento TUIO_UP per

ciascuno degli oggetti dentro dell‟array di listeners.

Fino a questo punto si sono analizzati alcuni strumenti appositi per lo sviluppo di

applicazioni e delle interfacce utente multitouch: Il tracker CCV che rileva l‟informazione,

la libreria di programmazione in flash che interpreta i messaggi inviati dal tracker, ed il

protocollo che stabilisce lo standard di comunicazione. Fatto ciò è ora possibile andare ad

applicare le nozioni fino a qui apprese per sviluppare dei componenti appositi per

applicazioni multitouch e che lavorino con gli eventi TUIO analizzati prima.

26

Capitolo 3

Componenti di FLASH

Tra gli elementi che offre il programma Flash ci sono i componenti che in generale

permettono di velocizzare la creazione delle applicazioni. Molte delle informazioni

utilizzati per capire cose sono e per il suo sviluppo sono state reperite da un articolo di

Adobe nella sezione di Flash development center scritto da Jeff Kamerer sullo sviluppo dei

componenti in Flash20

.

3.1 Cos‟è un componente?

I componenti sono oggetti di flash che possiedono delle funzionalità e proprietà con cui

l‟utente può lavorare senza preoccuparsi di produrre la logica di programmazione per il suo

funzionamento; questo implica una maggiore facilità nella costruzione di applicazioni più

complesse ed allo stesso tempo di risparmiare tempo nello sviluppo di essa. In termini

tecnici, sono progetti di flash che possono essere aperti ed utilizzati all‟interno di altri

progetti creati da uno sviluppatore.

I componenti sono elencati nella libreria dei componenti, (Figura 11.) per utilizzarli basta

trascinarli sullo stage e in seguito programmare, per mezzo di codici di programmazione

abbinati al loro funzionamento, così da renderli operativi con l‟applicazione. Ciascuno di

loro ha delle proprietà che controllano il loro comportamento ed il loro aspetto, e che si

possono modificare sia attraverso l‟interfaccia di flash, che con ActionScript.

20

“Creating ActionScript 3.0 components in Flash”,

<http://www.adobe.com/devnet/flash/articles/creating_as3_components.html>

http://www.adobe.com/devnet/flash/articles/creating_as3_components.html

Capitolo 3 – Componenti di FLASH

27

Figura 11. Elenco dei componenti. Per usarli, li si trascina sullo stage

All‟interno di flash è possibile trovare due tipi diversi di componenti: quelli che sono basati

su file SWC, oppure quelli basati su file FLA. I componenti basati su SWC hanno la

caratteristica di essere clip compilati, ovvero in termini propri di Flash un clip

prepubblicato, e questo porta con sé due conseguenze importanti: la prima è che essendo

che il clip è già stato compilato, sia a livello del codice che della parte visuale, l‟utilizzo di

questi componenti offre delle prestazioni migliori in tempo di esecuzione dato che non si

perde tempo nella traduzione del linguaggio di programmazione al linguaggio della

macchina; la seconda conseguenza però è uno svantaggio perché avendo già tutte le sue

parti compilate, il file SWC non permette di modificare nè accedere a nessuno dei suoi

elementi visuali, limitando così le opzioni di modifica della parte visuale del componente.

D‟altra parte, i componenti basati su FLA hanno la caratteristica che, una volta trascinati

sull‟area di lavoro o stage offrono la possibilità di modificare la parte visuale, sia perché ciò

permette di accedere ad ogni parte utilizzata per la sua rappresentazione visuale, che

cambiare completamente i disegni utilizzati per il componente.

All‟interno di flash, ci sono più di una decina di componenti diversi, ognuno dei quali con

delle funzioni specifiche, ma in un contesto di applicazioni multitouch, sarebbe necessario

programmare ogni componente utilizzato per ogni specifica applicazione sviluppata,

spendendo più del tempo necessario se ci fossero dei componenti appositi per questo tipo di

applicazioni. Tuttavia flash permette di creare dei componenti personalizzati, ovvero di

modificare quelli già esistenti estendendone le loro funzionalità per otterre componenti

nuovi appositi a seconda delle necessità riscontrate per ciascuna applicazione interattiva.

Per tanto è necessario capire prima come funzionano i componenti, e principalmente quelli

basati su FLA.


28

3.2 Struttura dei Componenti

Tutti i proggetti che si eseguono con Flash lavorano con dei clip, questo implica che esista

una timeline come avviene nella composizione di un film. E‟ quindi possibile costruire una

applicazione, oppure un componente come in questo caso, aggiungendo degli oggetti ad

ogni frame, ed anche allo stesso tempo si possono aggiungere altre timeline le quali

funzionano anche come dei layer (Figura 12). Quando arriva il momento di eseguire

l‟applicazione, il primo frame d‟ogni timeline inserita sarà visualizzato in contemporanea

con tutti gli altri primi frame, dopo verranno visualizzati tutti i secondi frame e così via.

Figura 12. Progetto di flash con 2 timeline diverse e con oggetti aggiunti nel primo frame

Tutti i componenti di flash hanno in comune una struttura interna che permette di

organizzare adeguatamente ogni parte che li compone: possiedono una struttura a due frame

e 4 layer (Figura 13), uno dei quali ha semplicemente ha lo scopo di inserire i nomi delle

diverse parti del componente. Un altro layer contiene tutti gli oggetti, oppure i disegni, noti

anche come Skin di cui ha bisogno il componente per la sua parte visuale; questo insieme di

elementi ha il nome di assets. Alcuni degli assets di un componenti di flash, ad esempio

„Button‟, sono il disegno di come questo si deve vedere quando si trova in uno stato

normale, il disegno riferito a quando viene premuto ed infine il disegno per quando non è

abilitato a funzionare. C‟è un terzo layer il quale contiene un simbolo noto con il nome di

avatar, il quale di solito mantiene le stesse dimensioni del componente reale, ciò perché nel

momento in cui viene creata un‟istanza di un componente, queste dimensioni vengono

assegante ai parametri „width‟ e „height‟ della classe. L‟ultimo layer contiene unicamente

un elemento il quale è molto importante ed è conosciuto come componentShim. Cos‟è

questo simbolo e per cosa serve verrà spiegato in seguito, dopo di che si effettuerà una

descrizione della struttura a due frame per i componenti e si illustreranno le ragioni per le

quale sono fatti in questo modo.


29

Figura 13. La struttura a due frame, comune per tutti i componenti di flash

3.3 Il codice interno dei componenti – L‟elemento

componentShim

Questo elemento o simbolo di flash è molto importante per i componenti perché è lui che

possiede il codice sorgente necessario per il loro funzionamento. Il componentShim è un

clip precompilato che contiene le definizioni, sia delle classi di programmazioni eseguite

dallo sviluppatore, che delle definizioni delle classi utilizzati da flash nella sua struttura

interna (come per esempio la classe UIComponent), le quali sono necessarie al

funzionamento del componente.

Il fatto che questo clip sia già compilato significa che la traduzione del codice ActionScript

3.0 nel linguaggio di macchina è stato già compiuto, permettendo così di fare due cose: la

prima è che in tal modo i componenti possono trovare il loro codice sorgente all‟interno di

uno dei loro elementi, invece di dover ricavarlo da un file esterno e dopo compilarlo. In

questo senso, avendo già tutto il codice precedentemente compilato, è possibile distribuire

dei componenti senza avere bisogno di distribuire esplicitamente il loro codice sorgente. Il

secondo vantaggio che si riscontra è al momento della compilazione del codice, poichè non

è più necessario eseguire lo stesso. Quindi questo simbolo possiede unicamente il byte code

di ActionScript compilato ed è per questa ragione che è anche noto come la definizione

ABC del componente per la sua sigla in inglese: ActionScript Byte Code definition. Invece

il componentShim non possiede nessuna rappresentazione visuale, come per esempio gli

assets oppure l‟avatar dei componenti, e dunque le sue dimensioni sono zero sia in

lunghezza che in larghezza: una volta che lo si è trascinato sullo stage, l‟elemento sembra

essere invisibile e per tanto non viene mai visualizzato al momento dell‟esecuzione

dell‟applicazione.


30

Figura 14.Le proprietà del simbolo. La voce „Export in frame 1‟

Nel momento in cui un simbolo o un clip compilato viene trascinato sullo stage, ovvero se

nella definizione delle proprietà del simbolo, si sceglie la voce di “Export in frame 1”

(Figura 14.), il simbolo diventa un output nell‟applicaizione, e questo significa che tutte le

definizioni di classi al suo interno che servono per il suo funzionamento diventano

disponibili per il compilatore. In altri termini nel momento di creare il file SWF21

, vengono

unicamente rese disponibili le definizioni di classi che hanno un riferimento ad un simoblo

che è stato usato nel progetto. Questo vuol dire che se l‟opzione d‟esportare nel primo

frame non è attivata, non basta avere un elemento nella libreria del progetto per poter

utilizzarlo nell‟applicazione, ma bisogna trascinarlo sullo stage. Quindi quando si utilizza il

componentShim, il quale non ha questa opzione attivata, anche se al suo interno ci sono

tutte le definizioni per i componenti di Flash, nel file SWF soltanto vengono caricate le

classi dei componenti che sono usati nel progetto.

21

Un file SWF è il formato del file utilizzato da flash per la esecuzioni delle applicazioni.


31

La seconda cosa che bisogna spiegare rispetto alla pubblicazione dei progetti è che flash ha

una priorità sulla sorgente del codice utilizzato per la compilazione. Flash permette di

specificare il path dove si devono cercare le definizioni delle classi utilizzate, se questo

viene fatto e ci sono delle definizioni uguali a quelle all‟interno del simbolo

componentShim, le classi trovate nel path specificato avranno priorità sulle altre. E questo è

un aspetto importante da tenere in conto al momento di sviluppare componenti, innanzitutto

perché per il loro sviluppo, si devono utilizzare definizioni di classi interne di flash che di

solito non sono disponibili per lo sviluppatore di applicazioni, poiché questo solo deve

utilizzare i componenti, ma al momento di sviluppare componenti è molto utile definire il

path delle classi interne per poi poter costruire adeguatamente i componenti e fare i debug

necessari a capire se il suo funzionamento è il corretto o meno.

Ora si passerà a studiare la struttura dei componenti.

3.4 Struttura a due frame dei componenti

Come visto prima nella Figura 13, i componenti vengono costruiti su due frame. Nel primo

frame l‟unico elemento che viene inserito è l‟avatar, mentre che nel secondo frame vengono

inseriti tutti gli asset necessari per la sua rappresentazione visuale e per il suo

funzionamento. In totale tre di quattro frame contengono elementi inseriti nel secondo

frame, uno dei quali fa da guida e contiene i nomi degli asset del componente, mentre gli

altri elementi funzionali vengono inseriti negli altri due layer. Il componentShim deve

essere inserito su un layer diverso agli asset, perchè non deve poter essere modificato

dall‟utente o da un‟altro sviluppatore di componenti. Come si può vedere sempre

dall‟immagine 4, tutti i layer tranne il layer degli asset si bloccano per impedire la sua

modifica, questa impostazione viene rappresentata attraverso l‟icona di un lucchetto, che si

trova affianco ad ogni nome di layer. Gli asset possono essere simboli creati dall‟utente

oppure altri componenti precedentemente creati, facendo in questo modo un componente

con dei sub-componenti, ma l‟importante è che tutto l‟insieme di elementi venga inserito

nel secondo frame del layer asset.

Nel momento in cui si esegue l‟applicazione, l‟unico frame che si vede è il primo frame e

quindi il secondo frame è utilizzato unicamente come contenitore degli elementi che ne

fanno parte, e mano a mano che bisogna cambiare l‟apparenza del componente sia perché si

deve reagire a una azione dell‟utente oppure perché si è modificato qualche dato e si deve

aggiornare l‟apparenza, gli asset rispettivi vengono aggiunti nel display list rimpiazzando

quelli che si vedevano precedentemente. Per spiegare meglio si illustrerà questo processo

con un breve esempio su di un tasto: quando il componente è sull‟area dello stage e non

viene fatta alcuna azione dall‟utente si vede uno skin, che contiene un disegno specifico

rappresentante un tasto in stato normale dove non c‟è nessun‟azione dell‟utente; dopo di

che se l‟utente si sposta sopra col cursore del mouse, lo skin può cambiare al fine di far

capire all‟utente che il mouse si trova sopra il componente; ed ancora quando il tasto viene


32

schiacciato, lo skin cambia ad uno che assomiglia a un bottone schiacciato, sempre per far

capire lo stato in cui il componente si trova. Tutti questi tre skin sono asset che si trovano

nel secondo frame del componente sul layer „assets‟, ed assieme a questi ci saranno tutti gli

altri skin necessari per ognuno degli stati del componente o dei suoi sub-componenti.

Per poter manipolare questi skin, gli asset devono avere delle impostazioni specifiche che

permettono a Flash di utilizzarli (Figura 15): prima di tutto, è necessario convertire i

componenti in un simbolo di flash, che sono elementi con cui il codice ActionScript può

interagire, dopo di che nella definizione delle proprietà del simbolo deve essere scelta la

voce di „Export for ActionScript‟, la quale permette di collegare ad un simbolo una

definizione di una classe fatta dall‟utente, affinché il simbolo abbia delle proprietà e

comportamenti personalizzati.

Figura 15. Impostazioni delle proprietà degli asset per i componenti

Un‟altra impostazione essenziale è l‟opzione di „Export in frame 1‟, la quale è molto

importante che non venga scelta. Quest‟opzione, che si trova sempre nella definizioni delle

proprietà dei simboli (Figura 15), quando viene selezionata assicura che il codice di

programmazione riguardante il simbolo sia compilato nel file SWF, nonostante il simbolo

non sia stato trascinato sullo stage e si trovi sulla libreria del progetto. Invece nel caso dei

componenti tutti gli asset sono stati aggiunti nel secondo frame del componente, e nessuno

di questi prevede l‟opzione di esportare nel primo frame selezionato; quindi se l‟utente non

vuole aggiungere il componente basta non trascinarlo sullo stage e deselezionare l‟opzione

per lo stesso, evitando che l‟utente debba deselezionarlo per ciascuno degli asset, e dunque

facilitando la gestione e le dimensioni del file SWF (più elementi vengono creati, più

pesante sarà il file).

Una volta che sono state selezionate tutte le opzioni desiderate per il simbolo e si da

conferma delle selezioni, se non esiste nessuna definizione di classe fatta dall‟utente, Flash

ne genera una automaticamente nel momento della compilazione, e questa classe possiederà

delle proprietà e metodi basici per il suo funzionamento. Quando questo accade, viene


33

sempre notificato da flash per mezzo di un‟avviso di allerta, (Figura 16). Se questa notifica

non viene inviata significa che flash ha trovato una classe personalizzata nel progetto e

quindi se questa non era prevista, serve per capire l‟esistenza di un conflitto tra i nomi delle

classi esistenti.

Figura 16. Notifica di flash della creazione automatica di una classe

Una terza impostazione che è importante rispetto agli asset dei componenti, si può

selezionare tra le preferenze di pubblicazione del progetto, sotto la scheda di Flash e nella

configurazione di ActionScript. Tra le voci che emergono, infatti ne esiste una con il nome

„Automatically declare stage instances‟ (Figura 17.), che come viene indicato dal suo nome,

fa sì che al momento della compilazione Flash si occupi di emettere la dichiarazione delle

istanze già trascinate sullo stage. Di solito il nome di queste istanze è assegnato dall‟utente,

ed è lo stesso nome che viene utilizzato da Flash per fare la dichiarazione, quindi si evita di

dichiarare esplicitamente le variabile nel codice.

Anche se questo può essere molto utile in certi contesti, nell‟ambito dei componenti basati

su FLA non è gradito. Infatti nel momento in cui un componente FLA viene copiato sul

progetto, è necessario che tutti i simboli all‟interno del progetto siano compilati

correttamente, questo indipendentemente dal fatto che l‟opzione di dichiarazione

automatica sia stata scelta o meno. Il modo più sicuro di farlo è quello di dichiarare

esplicitamente le istanze nel codice, e quindi a nessuno degli asset oppure delle istanze del

componente può essere stato assegnato un nome.

Ora che si è descritta la struttura dei componenti, e le impostazioni che devono avere le

parti che li compongono, si passerà a spiegare il modo in cui la struttura viene integrata nel

framework di lavoro di flash.


34

Figura 17. Opzione di „Dichiarazione automatica delle istanze sullo stage‟

3.5 Struttura interna di Flash per l‟uso dei componenti

Tutti i componenti di Flash servono per creare le interfacce delle applicazioni, e quelli che

sono basati su FLA sono raccolti all‟interno di un gruppo di componenti noto come „User

Interface‟ (Figura 11), che di solito fa uso dei metodi di alcune classi base facenti parte

della struttura dei componenti dell‟interfaccia utente. Tutte queste classi con i loro metodi

permettono di creare e sviluppare dei componenti in una maniera più facile e semplice; tutti

loro fanno parte del pachetto di classi „fl.*‟. Per usufruire delle prestazioni della struttura,

la classe del componente che si sta sviluppando deve rispondere a certi condizioni: una è la

struttura visuale, che è stata illustrata precedentemente; una seconda condizione è che deve

estendere la classe fl.core.UIComponent; la terza condizione è che, per integrarsi

adeguatamente alla struttura, il componente deve implementare dei metodi specifici che

permettono di usare i modelli di invalidazione e di styling, i quali verrano spiegati in

seguito.


35

3.5.1 La classe base dei componenti: fl.core.UIComponent

Estendere una classe in Flash comporta che la classe che lo fa erediti le proprietà ed i

metodi della classe base da cui è stata estesa (quelle che non siano state dichiarate come

tipo „static‟22

); è anche possibile che la classe base estenda a sua volta una terza classe e

così via, dunque in questo modo è possibile estendere la classe UIComponent

indirettamente, estendendo una classe che a sua volta estenda UIComponent. In questo

modo, si possono estendere classi definite precedentemente per sfruttare le loro

funzionalità, ed usarle come proprie, ma è anche certo che se una classe base per com‟è

stata definita non può fare determinate cose, tutte le classi che la estendano avrano le stesse

limitazioni. In questo senso è quindi importante sapere da che classe si estende la classe

UIComponent, e così capire quali condizioni sono imposte a tutti gli elementi che la

estendono.

Tutti gli elementi che estendono la classe Sprite condividono le seguente condizioni:

- L‟elemento non può fare uso dei script per frame specifici (frame scripts), che

sono parti di codice che si eseguono unicamente quando si arriva al frame

specifico.

- La timeline dell‟elemento non si eseguirà mai rimanendo fermo nel frame uno.

Queste due condizioni implicano innanzitutto che il codice necessario per il componente

deve essere descritto tutto nelle definizioni delle classi, e secondo che non si possono

utilizzare altri frame diversi dal primo per visualizzare il componente. I componenti, si

ricorda, hanno nel suo secondo frame tutti gli elementi necessari per la sua funzione, la

parte visuale con gli skin, e la parte operativa con il componentShim; ma il fatto che siano

stati inseriti in un frame diverso dal primo non va contro le condizioni elencate prima,

essendo che questo frame non viene mai visualizzato. Estendere la classe Sprite ha anche

altre implicazioni, le quali però in questo momento non sono particolarmente inerenti allo

sviluppo dei componenti, e pertanto non saranno di qui approfondite.

Come si era detto prima, è importante definire il path dove si possono trovare le classi

esterne del progetto, e la classe UIComponent è uno di questi casi dove bisogna indicare la

sua locazione. Quindi per poter utilizzare questa classe, si deve dire al programma dove può

trovarli. Questo si fa nelle preferenze di pubblicazioni, nelle opzioni di flash (Figura 17)

aggiungendo il path:

22

„Static‟ è una parola chiave che in ActioScript definisce che la variabile, la costante, oppure il metodo che si

sta definendo appartiene unicamente alla classe e non alle istanze della classe.

<http://www.adobe.com/livedocs/flash/9.0/ActionScriptLangRefV3/statements.html>

http://www.adobe.com/livedocs/flash/9.0/ActionScriptLangRefV3/statements.html


36

..Program Files\Adobe\Adobe Flash CSX\language\Configuration\Component Source\User

Interface

Facendo questo, nel momento di compilare il codice, verrano anche importate le definizioni

delle classe esterne che servono al componente.

3.5.2 Il metodo configUI e l‟uso degli Stili

Quando una classe viene utilizzata viene chiamata sempre una funzione nota come

costruttore della classe, la quale inizializza le variabili di cui ha bisogno, prepara gli

elementi che devono essere notificati dagli eventi registrandoli come „listeners’ degli eventi

e chiama tutti i metodi che devono essere eseguiti a tal fine. Per le classi che estendono

UIComponent, il metodo configUI è tra questi uno dei più importanti. Questo metodo è

chiamato dal metodo costruttore solo dopo aver finito l‟inizializzazione del supporto per

l‟invalidazione e per gli stili. Su questo metodo è consigliato inserire tutto il codice

necessario per la creazione, inizializzazione ed aggiunta sul display list degli elementi che

verrano visualizzati. Quindi bisogna sovrascrivere la funzione, ovvero in termini tecnici,

fare un „override‟ della funzione; ma si deve tenere in conto che, come per tutte le funzioni

che sovrascrivono un metodo della classe base, si deve chiamare la funzione originale per

mezzo del codice „super.configUI()‟. Il metodo della classe base si deve chiamare per prima

poiché questa s‟incarica d‟inizializzare le proprietà di altezza e larghezza del componente, e

inoltre si occupa di rimuovere l‟avatar del display list per inserire in seguito il primo skin

del componente.

Un‟altra variabile che è inizializzata nel metodo configUI, è la variabile „isLivePreview‟, la

quale viene utilizzata per sapere quando ci si trova nello stato di visualizzazione dell‟

anteprima del componente. Questo permette di vedere com‟è l‟aspetto del componente

nello stage quando si cambiano delle proprietà, senza aver bisogno di eseguire

l‟applicazione.

Un‟altra cosa che viene fatta dal metodo costruttore di UIComponent è quella di registrare

il compontente nel modello degli stili. Esiste un‟altra classe base, „StyleManager‟ che si

occupa di cambiare ed aggiornare l‟apparenza dell‟oggetto con alcuni metodi specifici: gli

stili di un componente possono essere per esempio il formato del testo usato, se possiede un

campo di testo, oppure i diversi skin del componente. Quindi la classe StyleManager deve

essere in grado di sapere quale sono gli stili di ogni componente, e perciò nel momento di

definire la classe si deve definire un oggetto, che per convenzione ha il nome di

„defaultStyles‟ contenente tali informazioni. Per esempio nella Figura 18, si trova un parte

di codice dove si esegue la dichiariazione dell‟oggetto „defaultStyles‟ per un componente

qualunque, ed al suo interno vengono definite un‟elenco degli skin che devono essere

utilizzati per ogni stato del componente. L‟elenco è composto da coppie nome-valore, dove


37

il nome è la variabile usata nella programmazione di ActionScript, ed invece il valore è il

nome del asset aggiunto nella struttura del componente.

Figura 18. Esempio della definizione del oggetto „defaultSyles‟ con i diversi stili per un

componente

In Flash esistono esistono gli stili definiti per default a livello di codice per il componente,

come nella Figura 18, ed esistono quelli che possono essere personalizzati e definiti da un

utente (che anche possono essere definiti via ActionScript, in classi definite dall‟utente).

Ma avendo la possibilità di creare diverse istanze per ogni componente oppure di far

condividere uno stile tra alcuni componenti, in ActionScript è possibile gestire quattro

livelli diversi di stili:

- Stili personalizzati per un‟istanza: Sono gli stili creati dall‟utente ed applicati su

una istanza di un componente. Se esiste un‟altra istanza del componente sullo

Stage, quest‟ultima non cambia i suoi stili.

- Stili personalizzati per un componente: L‟utente può scegliere dei tipi di stili

specifici per un componente, azione che avviene su tutte le istanze del

componente.

- Stili globali: L‟utente può scegliere di cambiare uno stile specifico, dopo di che

questo viene applicato su di tutte le istanze a cui può essere applicato, anche se

sono istanze di componenti diversi.

Per esempio se esiste un‟istanza del componente „List‟ ed un‟istanza del

componente „TextArea‟ entrambi lavorano con il testo ed hanno un stile in


38

comune definito con il nome „textFormat‟. Se l‟utente cambia questo stile, il

cambio avviene su ambo due le istanze.

- Stili definiti per default: Sono gli stili definiti a livello di codice.

La classe UIComponente definisce degli stili base che tutti i componenti che fanno parte

della struttura dell‟interfaccia utente condividono, anche se questi non si utilizzano tutti.

Per definizione questi stili sono globali, e si elencano in seguito:

- focusRectSkin: definisce il simbolo che deve essere usato quando il

componente ha il focus su di lui.

- focusRectPadding: la distanza del bordo alla quale deve stare il

„focusRectSkin‟.

- textFormat: definisce il formato di testo da utilizzare, se il componente

contiene del testo (per esempio un‟etichetta / TextField).

- disabledTextFormat: definisce il formato di testo da utilizzare quando il

componente non è abilitato..

- defaultTextFormat: definisce il formato di testo che si deve utilizzare per

default per il componente.

- defaultDisabledTextFormat: definisce il formato di testo per default che si

deve utilizzare quando il componente non è abilitato.

Flash possiede già una classe che si occupa di gestire gli stili dei componenti, questa classe

ha il nome di „StyleManager‟, e per permettere che questa classe gesire gli stili bisogna

registrare il componente alla classe, dopo di essere registrato la classe StyleManager ha un

riferimento al componente per sapere che ne deve gestire i suoi stili. Se un componente

estende la classe UIComponent, questa registrazione viene fatta automaticamente, ed è per

questo che dopo è possibile utilizzare i suoi metodi senza alcun problema. I diversi metodi

della classe StyleManager servono per tre funzione diverse: per applicare (set) uno stile

specifico, per ottenere (get) lo stile attuale, e per cancellare (clear) lo stile attuale. A

seconda del livello di stile che si vuole gestire ci sono diversi metodi da utilizzare che si

elencano qui di seguito:

- Metodi per stili d‟istanze:

nomeIstanza.setStyle( nome_Dello_Stile, valore_Dello_Stile );

nomeIstanza.clearStyle( nome_Dello_Stile);


39

nomeIstanza.getStyle( nome_Dello_Stile);

- Metodi per stili di componenti:

StyleManager.setComponentStyle( classe_del_Componente, nome_Dello_Stile,

valore_Dello_stile);

StyleManager.clearComponentStyle( classe_del_Componente,

nome_Dello_Stile);

StyleManager.getComponentStyle( classe_del_Componente,

nome_Dello_Stile,);

- Metodi globali:

StyleManager.setStyle( nome_Dello_Stile, valore_Dello_stile );

StyleManager.clearStyle( nome_Dello_Stile);

StyleManager.getStyle( nome_Dello_Stile);

Dove:

nomeIstanza: è il nome della istanza a cui si vuole cambiare lo stile.

nome_Dello_Stile: è il nome inserito in formato di testo, tipo String

valore_Dello_Stile: è il valore inserito in formato di testo, tipo String

classe_del_Componente: è il nome della classe a cui si vuole cambiare lo

stile

Per Flash, esiste un ordine di priorità per l‟uso degli stili: la priorità più alta ce l‟hanno gli

stili di istanza, dopo di che seguono gli stili per i componenti e alla fine gli stili globali. Se

nessuno di questi stili viene applicato ad alcuno dei metodi elencati precedentemente, lo

stile che verrà utilizzato sarà quello che è stato definito nella definizione della classe

all‟interno dell‟oggetto ‘defaultStyles’. Quando si vuole cambiare l‟apparenza di un

componente è possibile reperire i suoi stili per capire come sono stati definiti, e per fare ciò

esiste il metodo „getStyleDefinition‟ (Figura 19), il quale reperisce un elemento tipo

„Object‟ contenente tutti gli stili definiti per la classe.


40

Figura 19. Dichiarazione della funzione getStyleDefinition

Questa funzione, oltre a offrire un modo per ottenere gli stili di un componente, è utile

quando la classe sta estendendo una classe base che ha già definiti degli stili. Come si vede

nell‟immagine precedente, l‟oggetto ritornato è a sua volta un elemento ritornato dalla

funzione „mergeStyles‟ della classe UIComponent. Questa funzione riceve due argomenti,

due oggetti con la definizione degli stili: uno della classe stessa e l‟altra della classe base.

Il metodo si incarica di copiare tutti gli stili di entrambe le classi unendoli in un‟unico

elemento, e nel caso in cui si trovi uno stile uguale in entrambi gli oggetti utilizza la

definizione del primo oggetto passato al metodo; in questo modo è possibile modificare gli

stili della classe base.

Una volta che sono stati definiti gli stili ed il metodo per poter avere accesso ad essi,

bisogna implementarli. Dentro alla struttura dei componenti dell‟interfaccia utente esiste un

metodo nel quale viene inserito tutto il codice necessario per gestire il cambio dei diversi

skin e degli stili (quest‟ultimo verrà illustrato in seguito).

3.5.3 Il metodo draw() ed il modello d‟invalidazione

Tutte le volte che si vuole creare un componente, che interagisca con la struttura dei

componenti dell‟interfaccia utente, bisogna sovrascrivere un‟altro metodo che si occupa di

gestire l‟aggiornamento della parte visuale dell‟elemento, sia direttamente, sia chiamando

dei metodi appositi per farlo. Questo metodo si chiama „draw‟, e viene chiamato all‟interno

del modello d‟invalidazione di Flash.

Ogni volta che un componente deve essere aggiornato nel suo aspetto visuale, sia perchè ha

cambiato il suo stato e si rende necessario cambiare lo skin o perché si deve aggiornare a

causa della selezione di un‟opzione nell‟applicazione, il metodo draw deve essere chiamato

per gestire questo aggiornamento. Tuttavia, per ragioni di efficienza non sarebbe utile

aggiornare il componente ogni volta che si esegue un piccolo cambio al componente; per

esempio, se si cambiano le dimensioni si deve cambiare sia la proprietà di larghezza che di


41

lunghezza, e non sarebbe effieciente aggiornare il componente quando si cambia ciascuna

delle proprietà. Dunque è necessario stabilire un processo che si occupi di informare

quando si deve aggiornare la parte visuale ogni una volta che i nuovi valori di entrambe le

proprietà siano stati calcolati, e quindi chiamare una volta sola il metodo „draw‟ per

cambiare contemporaneamente tutto ciò che deva essere aggiornato. È il modello

d‟invalidazione quello che si occupa di farlo.

Il modello lavora del seguente modo: ogni volta che il componente riceve un evento,

oppure si chiama un metodo il quale cambia alcuna delle sue proprietà o semplicemente che

si deva cambiare il suo aspetto visuale, il componente si mette in uno stato di invalidazione.

Per fare questo si utilizza il metodo „invalidate()’ il quale programma una chiamata al

metodo „draw()‟ nel frame sucessivo. Quindi così come esistono diversi ragione per le quali

bisogna invalidare un componente, esistono anche diversi tipi di invalidazione e questi

vengono definiti all‟interno della classe „InvalidationType’. Questa classe insieme alla

classe „UIComponent „ compongono il pachetto di classi „fl.core‟ di Flash che alla fine

contengono tutte le funzioni base necessari per il funzionamento della struttura dei

componenti dell‟interfaccia utente.

All‟interno della classe „InvalidationType‟ sono definiti le costanti che rappresentano i

diversi tipi di invalidazioni, che si elencano adesso:

- ALL: questa costante contiene la stringa „all‟ ed indica che il componente deve

essere aggiornato completamente.

- SIZE: contiene la stringa „size‟, ed indica che si devono aggiornare le

dimensioni del componente.

- STYLES: contiene la stringa „styles‟ ed indica che gli stili del componente sono

invalidi e bisogna aggiornarli.

- RENDERER_STYLES: contiene la stringa „rendererStyles‟ e si usa per indicare

che si devono aggiornare i render styles del componente.

- STATE: contiene la stringa „state‟ ed indica che lo stato del componente non è

più valido. L‟esempio più comune di questo tipo è quando si cambia la proprietà

„enabled’ del componente.

- DATA: contiene la stringa „data‟ e si usa per indicare che un dato del

componente non è più valido e quindi si deve aggiornare il componente. Per

esempio nel componente „List‟ quando si sceglie uno dei suoi elementi.

- SCROLL: contiene la stringa „scroll‟ ed indica che la posizione della barra di

scorrimento non è più valida.


42

- SELECTED: contiene la stringa „selected‟ e si utilizza per indicare che la

proprietà „selected‟ del componente non è più valida.

È anche possibile di passare come argomento una stringa qualunque, ma è consigliato

utilizzare le costanti già definite, ed unicamente farlo nel caso in cui la descrizione

dell‟invalidazione sia tanto diversa a loro.

Chiaramente una modifica nel componente può implicare l‟invalidazione di più di un tipo.

Come per esempio la selezione di un elemento di un elenco potrebbe implicare

l‟invalidazione di tipo DATA, dopo di che bisogna aggiornare il componente in base

all‟opzione appena scelta, e questo potrebbe implicare un‟invalidazione di tipo STYLES. In

questo caso, appena si rileva la selezione del dato si invalida il tipo DATA, e si passa un

secondo argomento alla funzione „invalidate‟ per indicare che deve aspettare un‟altra

invalidazione prima di programmare la chiamata al metodo „draw()’. Questo argomento è

di tipo booleano ed deve avere il valore di „false‟. Dunque, per questo esempio, il processo

d‟invalidazione (con le chiamate ai metodi) sarebbe il seguente:

Diagramma 1. Diagramma di flusso per l‟esempio di selezione di un dato in un elenco.

Un‟invalidazione tipo DATA, una di tipo STYLES e la chiamata al metodo draw()

La chiamata al metodo draw è programata dal modello d‟invalidazione nel momento in cui

non si passa come secondo argomento il valore „false’. Una volta fattoa, è compito del

metodo „draw()’ di verificare quali invalidazioni sono state effettuate, per sapere quali

metodi bisogna chiamare, e per fare ciò fa uso di un altro metodo, „isInvalid()’, che verifica

quali stili sono stati invalidati e ritorna un valore di tipo booleano che indica se lo stile è

stato invalidato o no. È così che al verificare queste condizione, il metodo draw può sapere

che metodi chiamare, e come il modello di invalidazione si aspetta finchè si abbiano fatte

chiamata (automatica) al metodo draw() programmata dal modello d'invalidazione

Bisogno di cambiare lo skin del componente (invalidazione: STYLES)

invalidate(InvalidationType.STYLES);

Selezione del dato nell'elenco (invalidazione: DATA)

invalidate(InvalidationType.DATA,false);


43

tutte le invalidazioni necessarie, quando viene chiamato il metodo draw si chiamano tutti i

metodi che si occupano di cambiare ogni parte, aggiornando contemporaneamente tutte le

parti del componente che devono essere aggiornate. Esistono altri due metodi che bisogna

tenere in conto, i quali aiutano ad assicurarsi che il componente sia statoridisegnato

correttamente, e questi metodi sono, „drawNow()’, che fa una chiamata indiretta al metodo

draw23

; ed il metodo „validateNow()’, che fa una invalidazione di tipo ALL per dopo di che

chiama il metodo „draw()‟ e forzare l‟invalidazione di tutte le parti del componente. Queste

due metodi sono utili nel momento di sviluppare componenti, ed aiutano ad assicurarsi che

questo sia stato aggiornato correttamente.

3.5.4 Metadati dei componenti

I metadati possono essere definiti como i dati che danno informazione su un elemento

oppure che lo descrivono. Per esempio per un dipinto i metadati possono essere il suo

nome, l‟anno in cui è stato dipinto, le sue dimensioni, ecc. All‟interno di Flash, i metadati

sono le proprietà degli elementi alle quali l‟utente può avere accesso. Tutte le proprietà di

un oggetto, simbolo di flash si possono trovare nella sua definizione di classe, tuttavia

l‟utente non sempre ne ha accesso. Se si vuole quindi di permettere all‟utente di accedere a

emodificare alcune delle sue proprietà, queste possono essere definite como metadati.

Per fare ciò queste proprietà devono inanzitutto avere un modo per essere riperibili

dall‟utente. Quindi bisogna definire un metodo che permetta di raggiungere la proprietà, ed

un altro che permetta di modificarla. Questi due metodi si conoscono come i metodi „get’ e

„set’, e possono essere utilizzati per qualunque variabile/proprietà. Dunque questi metodi

sono necessari ma non sono sufficenti per definire un metadato. Per far vedere una

proprietà come metadato, bisogna aggiungere un‟altra riga di codice che fa capire al

compilatore che la variabile deve essere accessibile all‟utente, la riga di codice deve

cominciare con la parola chiave „Inspectable‟ e si devono aggiungere altri parametri e

valori che aiutano a definire il tipo di metadato ed il valor predefinito dello stesso. Un

esempio della definizione di un metadato si può vedere nella Figura 20.

Figura 20. Definizione di un metadato

Nell‟immagine si vede la definizione del metadato ‟touchMode‟ che serve per accedere alla

variabile ‟_touchMode‟ che è interna alla classe. Il tipo di metadato è booleano con un

23

Si fa una chiamata indiretta perchè il método „draw()’ è un metodo con accesso di tipo privato e quindi non

è possibile chiamarlo direttamente.


44

valore predefinito di „true‟, ed il suo nome che è „touchMode‟. Questa definizione viene

fatta una volta è deve essere inserita prima del metodo „get‟ o del metodo „set‟. Dopo

questo valore sarà possibile visualizzarlo come una proprietà del componente alla quale si

può accedere nel panello „Component Inspector’ di Flash. Esistono diversi tipi di metadati,

e le sue definizioni comprendono definire dei argomenti specifici, ma in questo studio non

si approfondirà nella sua descrizione. Invece nella sezione di sviluppo dei componenti sarà

possibile vedere la definizione di metadati per casi specifici.

Fino a questo punto si sono create e definite tutti le parti che compongono un componente.

Ma bisogna ora dare all‟elemento delle impostazioni per fare che Flash capisca che il suo

comportamento deve essere quello di un componente e non quello di qualunque altro

simbolo creato in questo programma.

3.5.5 Creazione del componentShim per i componenti personalizzati

Una volta che si ha creato tutto il codice, bisogna aggiungerlo al componente all‟interno

dell‟elemento componentShim. Questo passo è molto importante perchè è questo elemento

quello che possiede tutta l‟informazione del comportamento del componente.

Per la creazione dell‟elemento componentShim personalizzato bisogna creare un progetto

nuovo di Flash, e salvarlo nella stessa cartella in cui si è salvato il progetto dove si è

sviluppato il componente. Dopo di chè si preparano tutti gli elementi necessari per la

creazione del „shim‟ personalizzato, e per fare ciò si devono seguire i passi seguenti:

* La parola „myComponent‟ fa riferimento al nome del compoente sviluppato. Dunque nel

caso di creare un shim, questa parola deve essere rimpiazzata dal nome del componente

personalizzato per il quale si sta creando l‟elemento componentShim,

1. Creare un simbolo nuovo di tipo MovieClip con il nome „myComponentShim

source‟

Selezionare selezionare l‟opzione „esportare per ActionScript‟

Nel nome della classe inserire lo stesso nome del pachetto della classe del

componente svilupatto. Per esempio: com.myComponentShim

Cliccare su OK, dopo di che verrà visualizzata l‟alerta di creazione di una

classe automatica.


45

2. Creare un‟altro simbolo di tipo MovieClip con il nome „myComponent‟

Selezionare l‟opzione „esportare per ActionScript‟

Nel nome della classe inserire lo stesso nome del pachetto della classe del

componente svilupatto. Per esempio: com.myComponent

Verificare di lasciare selezionata la voce: „Esportare nel primo frame‟

Cliccare OK

3. Aprire il progetto del componente sviluppato e trascinare l‟elemento

„componentShim‟ dalla libreria del componente personalizzato all‟interno della

libreria del progetto del componentShim personalizzato.

Fare click destro nel componentShim per vedere le sue opzioni e selezionare

la voce „Linkage‟

Nella finestra emergente attivare la voce: „Esportare nel primo frame‟.

Cliccare OK

4. Salvare il progetto.

Nel caso in cui nel progetto del componente sviluppato non esista ancora l‟elemento

componentShim è possibile crearne uno seguendo i passi seguenti, utilizzando un file

interno di Flash che contiene tutte le preparazioni necessarie per la sua creazione. Questo

file si chiama „ComponentShim.fla‟ e lo si può trovare nella cartella:

…\Adobe\Adobe Flash CSX\language\Configuration\Component Source\ActionScript

3.0\User Interface\

Oppure in MAC:

…/Applications/Adobe Flash CSX/Configuration/Component Source/ActionScript

3.0/User Interface/

A questo punto sono state fatte tutte le preparazioni necessarie per la creazione di un shim

personalizzato, e lo stesso file può essere usato ogni volta che sia necessario. Per la

creazione del clip compilato si devono fare i passi seguenti:

5. Fare click destro sul simbolo „myComponentShim source‟ e selezionare la voce

„Convertire in un clip compilato.

6. Rinominare il clip appena creato nella libreria come „myComponentShim‟.


46

7. Fare click destro e selezionare la voce l‟opzione „Linkage‟ e nella finestra

emergente disattivare l‟opzione „esportare nel primo frame‟.

8. Trascinare dal progetto attuale il shim appena creato all‟interno della libreria del

progetto del componente sviluppato (Di solito l‟allocazione nella libreria è una

cartella „_private‟, Figura 21). Se prima c‟era l‟elemento „componentShim‟,

cancellarlo

Figura 21. Allocazione del componentShim, oppure del shim personalizzato, nella cartella

„_private‟ della libreria del progetto.

9. Editare il simbolo del componente in fase di sviluppo ed inserire il nuovo elemento Shim

nel frame 2 del layer „componentShim‟, preferibilmente con le coordinate x:10 e y:10.

10. Bloccare tutti i layer tranne il layer degli assets.

11. Chiudere tutte le cartelle della libreria del progetto e salvare.


47

Nel momento in cui venga fatto un cambio nel codice per aggiornarlo, si devono ripetere

dal passo 5 fino all‟8, nel quale nel momento di trascinare il shim nella libreria, verrà fatta

un‟alerta di un conflitto, indicando che Flash ha trovato un‟elemento con lo stesso nome.

(Figura 22). Basta selezionare la voce di „Replace existing items‟ e l‟elemento

componentShim personalizzato verrà aggiornato automaticamente.

Figura 22. Alerta di conflitto nel momento di trascinare un elemeneto nuovo nella libreria di un

progetto.

Dopo di fare questi passi, il componente contiene tutti gli elementi necessari per il suo

funzionamento ed unicamente bisogna selezionare le ultime impostazione per il

componente.

3.5.6 Definizione di un componente e creazione dell‟anteprima

L‟ultima cosa che bisogna fare è selezionare le impostazioni per fare che il simbolo si

comporte come un componente e dopo creare l‟anteprima (livePreview) del componente.

Ora si illustrerano le impostazioni necessarie per fare un componente e la creazione del

livePreview

Nella libreria del progetto deve essere stato creato un simbolo nel quale sono stati inseriti

tutti gli asset del componente ed a cui è stata assegnata la classe personalizzata che contiene

tutto il codice ActionScript per il suo funzionamento. Tra le opzioni di questo simbolo si

deve scegliere la voce „Component Definition...‟, dopo di che verrà visualizzata una

finestra con dei campi da compilare (Figura 23).


48

Figura 23. Finestra per fare la definizione di un componente

Nel primo campo si deve inserire il nome della classe che contiene tutto il codice di

programazione, ma si deve anche aggiungere il pachetto al quale appartiene la classe. Un

breve esempio illustrera questo concetto di pacchetti. Se il progetto Flash è stato salvato

sulla cartella „Documenti‟, il proggetto può avere accesso a tutte le definizioni di classe che

si trovino sullo stesso path. Ma se si vuole raggruppare le definizioni di classe

classificandoli per le sue funzioni, è anche possibile creare delle sotto-cartelle. Quindi Il

nome della sotto cartella definisce il nome del pacchetto al quale appartiene la classe: se la

sotto-cartella si chiama „com‟ ed al suo interno si inserisce la classe di nome ‟myClass‟, il

nome completo sarebbe „com.myClass‟. Il nome del pacchetto permette al programma di

sapere dove andare a cercare le classi che si importano nelle definizioni delle classi

personalizzati. Dopo di inserire il nome della classe, si devono attivare le opzioni seguenti:

„Require minimum player version, „Require minimum ActionScript version, „Display in

Components panel‟ e si deve cambiare il numero del frame di edizione del componente al

frame 2.

A questo punto, il componente personalizzato ha tutte le caratteristiche ed impostazioni

necessarie per funzionare al interno di Flash come un vero componente. L‟unica cosa che


49

manca è la possibilità di vedere l‟anteprima del componente. Per la sua creazione, si

seguono i passi consigliati dal sito di Adobe, i quali vengono elencati in seguito:

1. Cliccare sul componente per vedere il menu di opzioni e scegliere la voce „Export

SWC File‟. Salvando il fale sulla stessa cartella del progetto.

2. Prendere il file SWC e cambiare l‟estensione ad una di tipo .zip.

3. Aprire il file ed estrarre il file interno con il nome di „library.swf‟ e metterlo sulla

stessa cartella del progetto.

4. Si consiglia di cambiare il nome del file „library‟ ad uno con la forma

„myComponentPreview‟, per capire la funzione del file.

5. Nella definizione del componente (Figura 23) nel campo di anteprima, attivare

l‟opzione di „Live Preview‟, nella finestra che esce selezionare la voce „Live

Preview with .swf file embedded in .fla file‟ ed sfogliare le cartelle per selezionare

il file appena cambiato nel passo precendente.

Dopo di realizzare questi passi, i componente deve essere visualizzato con l‟anteprima, allo

stesso modo come è possibile vedere gli altri componenti. Questo permette di cambiare le

proprietà del componente ed visualizzarli senza che ci sia bisogno di eseguire

l‟aaplicazione.

Ora che si ha fatto uno studio di tutta la struttura dei componenti dell‟interfaccia utente

insieme al modello d‟invalidazione e si sono individuati tutti i requisiti ed impostazioni che

devono contenere questi simboli per essere componenti e non altro, il passo seguente sarà

quello di sviluppare dei componenti che soddisfino tutti questi requisiti per poter integrarli

sia alla struttura dei componenti che al modello d‟invalidazione.

50

Capitolo 4

Gesti

Praticamente tutti i dispositivi di ultima generazione in ambito tecnologico offrono la

possibilità di utilizzare dei gesti per controllare il loro funzionamento: scegliere un‟opzione

da uno schermo, scorrere la finestra oppure trascinare un‟elemento, tutte funzioni che si

possono fare appoggiando il dito sul display, e questi sono solo esempi di alcuni gesti

semplici fatti su schermi. Per dare una definizione più formale di cos‟è un gesto si utilizzerà

quella trovata nel libro di Saffer: “un gesto è qualsiasi movimento fisico che un sistema

digitale sia in grado di rilevare e di rispondere a, senza il bisogno di un‟altro dispositivo

appuntatore tradizionale, come il mouse”24

. Quindi un gesto può essere un qualsiasi

movimento nell‟aria oppure un tocco su uno schermo per fare una selezione.

In questo capitolo si descriveranno alcune delle caratteristiche e gli attributi più importanti

dei gesti tattili. Inoltre verrà presentato un algoritmo in grado di confrontare e rivelavare il

gesto fatto dall‟utente e confrontarlo con dei template normalizzati, contenuti in una libreria

creata anteriormente.

Molta dell‟informazione sui gesti è stata presa dal libro di Saffer “Designing Gestural

Interfaces”, nel quale tra tutte l‟informazione sulla creazione di interfaccie gestuali ed l‟uso

in generale dei gesti, ci si è concentrati sui concetti base dei gesti tattili e su i loro attributti.

4.1 Caratteristiche delle interfacce gestuali

In generale i gesti si possono classificare in due gruppi diversi: i gesti che non richiedono

l‟interazione fisica con il dispositivo, noti come gesti di forma-libera, che possono

utilizzare dispositivi di input, come guanti, oppure funzionare senza l‟utilizzo di nessun

24

Saffer, D. - “Designing Gestural Interfaces”, pagina 2.

Capitolo 4 – Gesti

51

apporto addizionale. Mentre che gli altri gesti (tipo touchscreen) sono quelli che richiedono

un interazione dell‟utente con il dispositivo. Le interfacce che usano quest‟ultimi si

chiamano Interfacce di Utente di tipo Touchscreen, TUI dal suo acronimo in inglese

(Touchscreen User Interface).

Al giorno d‟oggi l‟utilizzo dei gesti nelle applicazione è talmente diffuso che è impossibile

non percepire i cambiamenti e i vantaggi apportati nella vita quotidiana. Per questo motivo

può essere interessante sviluppare una classe base di Actionscript che permetta di creare e

gestire i gesti. E‟ importante tener conto che l‟uso di questi tipi di interfaccie porta con sé

alcuni svantaggi come:

· Una difficoltà inerente all‟uso di nuovi gesti (usabilità).

Anche se molti dispostivi utilizzano già alcuni gesti, l‟uso di nuovi gesti porta

sempre con sé il rischio di non permettere agli utenti apprezzare il nuovo sistema.

Se i gesti sono troppo complessi oppure scomodi può darsi che l‟utente perda

l‟interesse in utilizzare il sistema.

· Dipendenza nella parte visuale

Questo è un problema per le interfacce tattili, che necessitano di un display dove

proiettare l‟immagine con la quale l‟utente interagisce.

Per i gesti di forma libera non c‟è questo impedimento, ma possono esistere

problematiche legate alle capacità fisiche dell‟utente.

L‟uso di interfacce interattive non porta soltanto degli svantaggi ma anche porta alcuni

vantaggi, come:

· La possibilità di avere un‟interazione più naturale

In generale agli essere umani piace poter interagire direttamente con gli oggetti,

quindi i gesti interattivi permettono di interagire naturalmente e fisicamente con gli

oggetti digitali così come con quelli reali.

· Minor dipendenza dall‟hardware

Nelle interfacce tattili, il solito sistema hardware per gli input, come la tastiera e il

mouse, non sono più necesari, poichè i touchscreen o altri sensori permettono agli

utenti di agire senza il bisogno di tale hardware. Questo permette di collocare tali

sistemi interattivi in spazi in cui un computer classico sarebbe impraticabile o fuori

luogo come ad esempio in punti vendita o altri luoghi pubblici.


52

4.1.1 Attributi dei gesti

La maggior parte dei gesti hanno caratteristiche simili tra di loro. Deve essere chiaro,

comunque, che più sofisticata sia l‟interfaccia, con un numero maggiore di sensori, più

grande sarà il numero di attributi impiegati.

Per i gesti touchscreen si sono identificati i seguenti attributi:

· Presenza

Questo è il più semplice degli attributi. Qualcosa deve essere presente per fare un

gesto in modo da causare un interazione. Per il più semplice dei touchscreen, la

presenza di un dito crea un evento tattile

· Durata

Tutti i gesti avvengono nel tempo e possono essere effettuati più o meno

velocemente. Quando l‟utente interagisce con un pulsante può darsi che lo stia solo

toccando o che lo stia tenendo premuto a lungo.

L‟attributo è misurato calcolando il tempo dal contatto iniziale alla fine del gesto.

· Posizione

Questo attributo indica la posizione dove si stabilisce il contatto, delle cordinate x/y

se si è dell‟intero di uno schermo oppure di un‟elemento proiettato nello schermo.

Successivamente calcolando lo spostamento del dito sullo schermo.

· Movimento

Può essere lo spostamento del gesto, il suo orientamento o la sua direzione. Per

alcuni sistemi qualsiasi movimento è sufficiente per ottenere una risposta.

La posizione non influisce sulla determinazione del movimento.

· Numero di punti tattili/ combinazioni

Sempre più interfacce gestuali hanno compatibilità multitouch, permettendo agli

utenti di usare più di un dito o mani contemporaneamente per controllarle e di

svolgere combinazioni di gesti allo stesso tempo. Questo ovviamente implica una

maggiore complessità nella programmazione dell‟interfaccia.

Uno degli esempi più comuni è quello di usare entrambe le mani per allargare

un‟immagine, trascinando in due angoli opposti apparentemente stirando

l‟immagine.


53

· Numero dei partecipanti

Potrebbe essere utile che con alcuni dispositivi utilizzino utenti multipli, come ad

esempio per il dispositivo Surface elaborato da Microsoft, il quale è stato pensato

per essere utilizzato in attività sociali, come giochi oppure in collaborazioni

lavorative.

Questi concetti appena descritti sono solo alcune delle caratteristiche che si possono trovare

nei gesti e nelle interfacce tattili. Ora si passerà a descrivere i diversi gesti che possono

essere utilizzati sui sistemi ad interfaccia tattile.

4.1.2 Gesti basici/Pattern per i touchscreen

Questo tipo d‟interfaccia esiste già su molti dispositivi, come ad esempio i cellulari. Con il

tempo, tanti dei gesti che utilizzano sono diventati di uso comune e ormai si utilizzano

come modelli o „pattern‟ già riconosciuti per fare delle azioni determinate. I patterns sono

“combinazioni di un gesto e di un sistema di risposta che possono essere ripetuti in una

varietà di situazioni attraverso diversi dispositivi”25

TAP

Questo gesto può essere un tocco oppure un breve colpo, in un‟area specifica oppure

su un oggetto, che inizia un‟azione. Di solito viene utilizzato ogni qualvolta si ha il

bisogno di attivare, aprire un oggetto o premere un tasto. Inoltre il colpo si potrebbe

usare per selezionare degli oggetti sullo schermo. Ha le stesse funzioni del click del

mouse.

E‟ anche possibile dividere il gesto nelle sue azioni base: appena entra in contatto

con la superficie, ed appena il dito si alza dallo schermo. Se queste due azioni

vengono effettuate velocemente si può interpretare come un click del mouse. Un

colpo quando viene trattenuto potrebbe eseguire un azione multipla su una riga.

Per la funzione di selezione deve esistere una coincidenza tra la posizione del evento

tattile e la posizione dell‟oggetto sullo schermo.

DRAG

E‟ l‟azione di appoggiare il dito su un elemento presente sullo schermo per spostarlo

o trascinarlo in un‟altra posizione. E‟ il gesto più semplice per la manipolazione

degli oggetti. Gli utenti, dato che non hanno la possibilità di afferrare e prendere un

25

Idem. Pagina 45.


54

oggetto fisico, necessitano di un modo per poter muoverli, è cosi che trascinarli o

spingerli con le dita diventa un azione naturale da compiere.

Per realizzare questo gesto, l‟oggetto deve essere stato selezionato prima, questo si

può fare con il pattern descritto prima: l‟utente preme l‟oggetto, così da farlo reagire

allo spostamento del dito attraverso lo schermo. Gli oggetti possono avere delle

limitazioni sugli spostamenti, ad esempio a destra o sinistra.

PINCH

Quest gesto avviene quando le due dita si avvicinano (Stringere per rimpicciolire)

oppure si allontanano (Estendere per ingrandire) su un oggetto causando un

cambiamento delle dimensioni. Lo scalamento è quindi minore di 1 se le dita si

avvicinano, rimpicciolendo l‟oggetto, e maggiore di 1 se le dita si allontanano,

ingrandendo l‟oggetto. Questi due patterns solitamente si trovano insieme.

Dunque questi pattern si possono utilizzare per cambiare le dimensioni di un

oggetto, o di un‟immagine, facendo un effetto di zoom, come per esempio su una

mappa, una pagine web, dei documenti oppure dello schermo intero. È utilizzato

sopratutto per alcuni dispositivi di piccole dimensioni, dove gli utenti hanno bisogno

di ingrandire per osservare correttamente gli oggetti nel dettaglio.

Questo tipo di pattern richiede un sistema in grado di riconoscere due eventi tattili

(multitouch). Solitamente essi scalano un oggetto in modo proporzionale anche se in

genere non ci sarebbe bisogno. Il punto iniziale della posizione delle due dita

corrispondono solitamente al 100% delle dimensioni di partenza dell‟oggetto.

Quando le dita si avvicinano o si allontanano, l‟oggetto scala in tempo reale per

adattarsi alla nuova distanza tra di esse in un rapporto che i progettisti devono

stabilire in base alle dimensioni dell‟oggetto originale e dello schermo. Potrebbe

esserci un punto limite oltre il quale l‟utente non può agire più per non permettere di

diminuire l‟oggetto a delle dimensione che poi forse non li permettono più di

manipolare l‟oggetto, impedendo anche di vedere o interagire.

Questi pattern per i touchscreen descritti prima sono quelli trovati sul libro di Saffer, che

sono d‟interesse per lo scopo della tesi. Però è possibile realizzare un‟altra azione sempre

con l‟utilizzo di due dita sullo oggetto:

ROTATION

Questo gesto avviene quando due dita vengono messe sopra dello stesso oggetto.

Dopo di che si prende come riferimento l‟asse formato dalle posizione iniziali delle

dita ed ogni spostamento delle dita crea un'altro asse che forma un‟angolo con l‟asse


55

di riferimento. L‟oggetto selezionato si può far ruotare lo stesso valore di

quest‟angolo.

Questo gesto può avvenire contemporaneamente al pattern di Pinch oppure al

pattern di Drag, o a tutti e due insieme. Poiché allo stesso tempo che le dite girano

sull‟asse di riferimento, possono avvicinarsi rimpicciolendo l‟oggetto, ovvero

allontanarsi, ingrandendolo. E‟ anche possibile calcolare lo spostamento relativo tra

un dito e l‟altro mentre stanno generando una rotazione oppure uno scalamento.

4.2 Gesti tattili non convenzionali

Gli schermi touchscreen comunque offrono la possibilità di appoggiare le dita su qualsiasi

parte dello schermo e spostarsi attraverso esso. In questo modo è possibile realizzare dei

movimenti non standard con le dita, per esempio, un cerchio oppure un‟onda. Questi gesti

sono caratterizzati da una forma libera, che però il sistema touchscreen, ovvero

l‟applicazione interattiva, deve essere in grado di rilevare ed interpretare come un gesto.

Per fare questo l‟interfaccia deve avere accesso ad una libreria di template con la quale

confrontare i gesti fatti dall‟utente, in modo di capire e rilevare se quelli appena fatti sono

validi e se si deve reagire ad essi. Bisogna allora riconoscere il gesto appena fatto

dall‟utente al fine di memorizzare ogni movimento che fa ed in questo modo i gesti non

convenzionali sono descritti da una sequenza di punti. Dopo la memorizzazione del gesto,

si deve confrontare con ogni template della base di dati, cercando di trovare una

coincidenza tra di loro. Il problema è riuscire a riconoscere lo stesso gesto fatto da diverse

persone. Lavorare con questi tipi di gesti è quasi come interpretare lo stile di scrittura di

ogni persona. Quindi per confrontare adeguatamente i gesti con i template bisogna tenere in

conto e fare molta attenzione a questi aspetti. Per risolvere questo problema in una maniera

relativamente semplice si è studiato un algoritmo che verrà esaminato più nello specifico

nella sezione seguente.

4.2.1 Tecnica “$1 Recognizer” per il riconoscimento dei gesti touchscreen

Questo algoritmo (Wobbork et al., 2007) si utilizza per confrontare un gesto rilevato con un

insieme gesti standard che si utilizzano come riferimento. Ogni gesto in questa tecnica è

descritto come un insieme di punti allocati su un sistema di coordinate, che di solito è lo

schermo, oppure l‟applicazione dove si è effettuato il gesto. In questo senso è possibile

avere un‟enorme quantità di gesti diversi, anche se il gesto descrive la stessa figura.


56

Si possono incontrare due problemi legati al riconoscimento: uno dipende dalle dimensioni

del gesto, l‟altro dalla velocità con cui questo è fatto. Infatti il numero di punti rilevati da un

sistema dipende dal rango di velocità dei suoi componenti, dal frame rate della videocamera

e dalla velocità di elaborazione del software.

Figura 24. Due gesti fatti da due persone diverse26

Per esempio nella Figura 24, si illustrano due gesti svolti da due persone differenti, si

possono evidenziare due cose: la prima è che hanno un numero diverso di punti, quindi

dimensioni diversi di gesti possiedono un numero diverso di punti; e la seconda cosa è che

se si ruota il primo gesto in un angolo di 90 gradi in senso orario, i gesti si assomigliano. In

base a queste considerazioni, l‟algoritmo elaborato cerca di:

· Non dipendere del numero di campioni prelevati in base alla velocità ne dalle

misure del dispositivo di rilevamento

· Non essere influenzato dalla rotazione, scalamento e posizione.

· Non richiedere dei requisiti di tecniche matematiche avanzate.

· Essere facilmente scrivibile in poche righe di codice

· Essere sufficientemente veloce per scopi interattivi.

· Permettere agli sviluppatori ed agli utenti d‟insegnare al sistema un gesto nuovo

tramite un solo esempio.

· Restituire un‟elenco con gli N-migliori possibili gesti ed il punteggio [0..1]

indipendentemente dal numero di punti del input.

· Prevedere un rango di velocità competitivo con algoritmi più complessi.

Per riuscire a fare questo l‟algoritmo si basa su quattro passi:

26

Wobbrok, J et al. “Gestures without libraries, toolkits or training: a $1 Recognizer for user Interface

prototypes”


57

1. Fase di ricampionamento dei dati.

Sia i gesti già conosciuti che quelli che si vogliono confrontare devono essere

ricampionati al fine di essere paragonati tra loro. Se il numero di punti è diverso,

non è possibile confrontare i due gesti per sapere se sono uguali o meno. Quindi

avere tutti i gesti ricampionati con lo stesso numero di punti è il primo passo

dell‟algoritmo. Per elaborazione di questa tecnica si sono svolte delle prove per

cercare un numero ottimale di campioni, al fine di non far diventare i gesti troppo

piccoli, perdendo in precisione, o farli diventare troppo grandi, per non aumentare il

tempo di elaborazione dei punti. Il numero consigliato è N = 64.

Figura 25. Esempio di ricampionamento con diversi valori di N27

Per svolgere questa fase si calcola la lunghezza totale del gesto, utilizzando i punti

originali, e successivamente questo valore viene diviso per (N-1) al fine di ottenere

la nuova distanza, I, che deve intercorrere tra un punto e l‟altro. Conosciuto il valore

I, si scorrono i punti originali e si sommano le distanze tra loro, se questi hanno un

valore maggiore di I si aggiunge un nuovo punto utilizzando l‟interpolazione

lineare. Cos`si può continuare finchè tutti i punti siano stati calcolati.

1. Rotazione basata sull‟angolo indicativo

L‟angolo indicativo viene definito nello studio di (Wobbrock et al.) come l‟angolo

formato tra il centro del gesto ed il suo primo punto. Una volta calcolato questo

punto, utilizzando le regole trigonometriche, si fa ruotare il gesto finchè questo

angolo sia zero.

27

Idem.


58

Figura 26. Rotazione del gesto finche il suo angolo indicativo è zero28

2. Scalamento e traslamento

Dopo la rotazione i gesti si scalano, in maniera non uniforme, ad uno quadrato con

dimensioni fisse, detto quadrato di riferimento.

Questa fase permette di ottenere i gesti tutti con le stesse dimensioni; in altre parole

si fa una normalizzazione delle dimensioni del gesto e poi questo viene spostato

nell‟origine, portando il centro nelle coordinate (0,0).

3. Riconoscimento

Nell‟ultimo passo dell‟algoritmo si fa il riconoscimento, cioè si confronta il gesto

con ogni modello della libreria di gesti. Per fare questo, si calcola la distanza media

esistente tra i punti del gesto ed i punti del modello, ossia si calcola la distanza tra il

primo punto del gesto e il primo punto del modello, poi si ripete il calcolo per tutti i

restanti punti (Figura 27). Alla fine si sommano tutte le distanze, e il risultato viene

diviso per N, numero di punti.

Questo calcolo viene fatto per ogni template della libreria, alla fine, il confronto che

dia la distanza media più piccola sarà quello che coincide con il gesto.

28

Idem.


59

Figura 27. Le distanze tra punto e punto di due gesti.29

Le caratteristiche di questa tecnica appena descritta sono ottime per le applicazioni

multitouch; poiché non tiene conto delle diversità di “scrittura” dei diversi utenti, né dalla

posizione, scala e rotazione del gesto. Per questi ragioni questa tecnica è stata scelta per

essere utilizzata nelle classi per il rilevamento dei gesti.

4.2.1.1 Classe di ActionScript che implementa la tecnica „1$'.

Questo algoritmo è già implementato da alcuni classi di ActionScript30, in particolare sono

due le classi che si utilizzano come oggetti, mentre una terza contiene tutto il codice per

implementare l‟algoritmo „1$‟.

In seguito si descrivono le classi:

La classe „DollarTemplate.as‟:

E‟ una classe ausiliaria che si utilizza come un oggetto, contiene il nome

identificativo ed i punti di un gesto.

29

Icard, A. “Simple gesture recognition in AS3” <http://blog.sqrtof5.com/?p=173> 30

Betriebsraum weblog “Efficient Gesture recognition and Corner Finding in AS3”

<http://www.betriebsraum.de/blog/2009/07/21/efficient-gesture-recognition-and-corner-finding-in-as3/>

http://blog.sqrtof5.com/?p=173

http://www.betriebsraum.de/blog/2009/07/21/efficient-gesture-recognition-and-corner-finding-in-as3/


60

Il costruttore riceve come primo argomento il nome identificativo del gesto, tipo

String, e come secondo argomento una variabile di tipo Array che contiene i punti

del gesto appena memorizzato tramite la tecnica „1$‟ appena descritta.

La seconda classe „DollarResult.as‟:

E‟ una classe in cui si salva il risultato del confronto tra il geto appena fatto

dall‟utente e quello di riferimento, inoltre salva il punteggio che indica quanto si

assomigliano il gesto fatto dall‟utente al modello.

Il metodo costruttore riceve come primo argomento una variabile di tipo

DollarTemplate, che contiene il modello di riferimento per il gesto, e come secondo

argomento una variabile di tipo Number che rappresenta il punteggio ottenuto dal

confronto tra il gesto ed il modello di riferimento.

La terza classe, di nome „DollarRecognizer.as‟,

E‟ quella che possiede tutti i metodi per implementare l‟algoritmo. I metodi che

utilizza sono:

o DollarRecognizer(templates:Array = null)

Il metodo costruttore riceve un array con i modelli dei gesti. Se non riceve

nessun argomento, si assegna un valore di „null‟ all‟array dei modello.

o resample(points:Array, numPoints:uint):Array

Metodo statico che si occupa del ricampionamento del gesto. Riceve il gesto

originale ed il numero di punti che deve ricampionare.

o rotateToZero(points:Array):Array

Metodo statico che si occupa di ruotare tutti i punti di un valore uguale

all‟angolo indicativo, descritto nell‟algoritmo.

o scaleToSquare(points:Array, size:Number):Array

Metodo che si occupa di scalare i punti del gesto che riceve come primo

argomento. Lo si scala addatandolo al quadratto di riferimento descritto nel terzo

passo dell‟algoritmo determinato dal secondo argomento, „size‟. Questa

dimensione è definita nella costante della classe SQUARE_SIZE.


61

o translateToOrigin(points:Array):Array

Metodo che si occupa di spostare tutti punti del gesto alle coordinate (0,0).

Calcola il centroide del gesto che riceve come argomento e lo sottrae a tutti i

suoi punti.

o recognize(points:Array):DollarResult

Metodo che si occupa di confrontare il gesto che riceve come argomento e

restituisce il risultato del confronto. Questo metodo si occupa di fare tutti i passi

dell‟algoritmo e fa il confronto con ognuno dei modelli trovati nella libreria di

gesti.

La classe possiede altri metodi interni che utilizza per il calcolo dei valori utili per

completare i passi dell‟algoritmo, ma per poter utilizzare questa classe bastano i

metodi appena elencati.

Fino a questo punto ci si è concentrati sullo studio dei diversi elementi che servono per la

creazione degli strumenti base di ActionScript per lo sviluppo di applicazioni multitouch.

Nel capitolo seguente verrà descritto il processo di sviluppo ed elaborazione di questi

strumenti.

62

Capitolo 5

Sviluppo di strumenti basi di

ActionScript per applicazioni

Multitouch

In questa sezione si illustrerà il processo di sviluppo di due strumenti fatti per la creazione

di applicazioni multitouch: dei componenti tattili che si possono utilizzare in Flash, e delle

classi per la creazione ed il rilevamento dei gesti sullo schermo.

5.1 Sviluppo di componenti tattili

Si è deciso di sviluppare alcuni componenti che si pensa siano utili nel contesto di

applicazioni interattive. In seguito si vedrà il processo e le caratteristiche di ogni

componente sviluppato ed allo stesso tempo si daranno alcune raccomandazioni per evitare

certi errori trovati nel processo di sviluppo.

5.1.1 Componente: TouchButton

Figura 28. Il componente TouchButton

Capitolo 5 –Sviluppo di strumenti basi di ActionScript per applicazioni multitouch

63

Il tasto (Figura 28) è stato scelto come il primo componte da sviluppare per diversi ragioni.

Prima di tutto, il fatto di premere un tasto per realizzare azioni semplici è un gesto molto

diffuso tra la gente comune e non solo tra utenti di nuove tecnologie. Quindi un

componente con le funzionalità di un tasto è di sicuro un elemento che verrá utilizzato ed

integrato facilmente in tante applicazioni multitouch.

5.1.1.1 Apparenza

Il componente ha degli skin di forma circolare, che assomigliano alla punta delle dita, per

addatarsi meglio alla parte del dito che entra in contatto con lo schermo. Per questo

componente sono stati utilizzati nove skin diversi, per rappresentare gli stati di „non

premuto‟, „premuto‟, „sopra‟, „non abilitato‟, „selezionato e non premuto‟, „selezionato e

premuto‟, „selezionato e spora‟, „selezionato e non abilitato‟ ed in fine lo skin per il focus

„focus Skin‟. Tutti gli skin disegnati si possono vedere nella Figura 29, che mostra il frame

di edizione del componente.

Figura 29. Gli asset per il componente „TouchButton‟

5.1.1.2 Proprietà

Il componente estende la classe „LabelButton‟ in quanto questa classe possiede già delle

proprietà utili alle funzionalità del componente in questione, proprietà come il „Label‟ del


64

componente, oppure „mouseState‟ che indica lo stato del componente a seconda delle azioni

del mouse: se il puntatore è sopra il tasto, se il tasto è stato cliccato, o „enabled‟ che indica

se il componente è abilitato. In questo modo basta aggiungere le funzioni ed il codice

necessario per fare sì che il componente reagisca agli eventi di tocco ed integrare questa

parte con la struttura dei componenti ed il modello d‟invalidazione. Quindi il componente

„TouchButton‟ possiede tutte le proprietà del componente „LabelButton‟ ed altre due che

sono state aggiunte per integrare le nuove funzionalità.

o buttonState:String;

Questa proprietà si utilizza per sapere lo stato attuale del tasto. Può avere due valori

diversi: „up‟, „down‟ che rappresentano i due stati principali del tasto. Nel codice ci

sono le due funzioni „get‟/‟set‟ che permettono di avere accesso alla proprietà, come

mostrato in Figura 30. Dunque per accedere alla proprietà si esegue l‟istruzione:

„nomeIstanza.buttonState‟ dove „nomeIstanza‟ sarà il nome dell‟istanza dichiarato

nello stage.

Figura 30. Funzione get e set per il componente „TouchButton‟

Nella funzione „set‟ si fa notare il cambio del valore della variabile „mouseState‟.

Questa variabile è una proprietà della classe base „LabelButton‟ che controlla lo

stato del bottone ed anche lei possiede le sue funzioni „get‟ e „set per accedere e

modificare il suo valore. Nel momento in cui si cambia questa proprietà, la funzione

„set‟ fa un‟invalidazione di STATO, selezionando il rispettivo per rappresentare lo

stato attuale del componente. Per sapere quale skin selezionare, si verificano la

variabile „mouseSate‟, ed un‟altra proprietà ereditata, „selected‟, che come indica il

nome, indica se il componente è selezionato o meno.

La classe base ha già dei metodi che gestiscono lo stato del componente rispetto alle

azione dell‟utente con il mouse, questo stato è controllato con la proprietà

„mouseState‟. Però dato che il componente TouchButton non interagisce con questo

dispositivo, si è utilizzato la proprietà „buttonState‟ per cambiare


65

contemporaneamente entrambi i valori della proprietà „mouseState‟ in questo modo

si utilizzano i metodi della classe base che lavorano già con il modello

d‟invalidazione, risparmiando così tempo e logica di programmazione.

o touchMode:Boolean = true;

La proprietà touchMode è una variabile booleana che indica se il componente è

abilitato per ricevere eventi di tipo touch o meno e per accedervi ci sono i metodi

„get‟ e „set‟. Nel momento in cui la proprietà viene cambiata, si fa un‟invalidazione

di STATO, come si vede nella Figura 31. L‟istruzione: „nomeIstanza.touchMode‟

permette di accedere alla proprietà dell‟istanza nello stage.

Figura 31. Metodo „set‟ della prorpietà touchMode e l‟invalidazione di STATO.

Dunque nel momento in cui il componente non si trova più in modalità Touch,

bisogna togliere i „listeners‟ agli eventi touch. Quindi nel momento in cui si verifica

l‟invalidazione di tipo STATO, si chiama il metodo „setupListeners‟ che si occupa

di registrare il componente per essere notificato o meno per gli eventi touch. Questa

invalidazione viene fatta nello stesso modo in tutti i componenti sviluppati.

Figura 32. Collegamento dei componenti per fare il debug. Controllato dalla proprietà

„_touchMode‟

Questa proprietà è anche utilizzata in tutti i componenti per per gestire il debug. Il

suo valore deve essere assegnato prima di eseguire l‟applicazione per fare il

collegamento o meno con il tracker per ricevere i dati. In una applicazione normale,

è l‟applicazione stessa che deve occuparsi del collegamento con il tracker, ma per lo


66

sviluppo dei componenti serve provare le funzionalità quindi si deve accedere

all‟informazione inviata dal tracker. Il collegamento viene fatto nella funzione

costruttrice di ogni componente, come si può vedere nel caso particolare del

componente TouchButton nella Figura 32.

Le altre proprietà sono quelle ereditate dalla classe „LabelButton‟ e quindi la sua

descrizione può essere trovata nella documentazione di questa classe.

5.1.1.3 Metodi

o configUI()

Questo metodo unicamente chiama la funzione della classe base, poiché

inizialmente non bisogna aggiungere nessun‟elemento nel display.

o setupListeners()

Questo metodo gestisce il registro del componente per essere notificato degli eventi

di tipo touch. Questo dipende dalla proprietà touchMode, ma deve essere gestito se

il componente cambia da uno stato abilitato ad uno non abilitato. Questo stato viene

controllato dalla proprietà „enabled‟ che tutti i componenti condividono ed è definita

nella classe UIComponent. Quindi il metodo verifica le due proprietà per sapere

quando registrare o meno il componente. (Figura 33).

Figura 33. Metodo setupListener per il componente TouchButton

Lo stesso tipo di verifica per aggiugnere o togliere il registro agli eventi è stato fatto

per tutti i componenti, dato che per tutti bisogna gestire la stessa situazione. In

alcuni casi bisogna fare attenzione con gli eventi dei subcomponenti. Queso caso

verrà descritto con il componente TouchKeyboard.


67

o draw()

Il codice utilizzato per il componente è stato il seguente:

Figura 34. Gestione dell‟invalidazione di stato per il componente TouchButton nel metodo

draw()

Questo metodo è la ridefinizione del metodo „draw()‟ della classe base, che deve

gestire l‟invalidazione di tipo STATO nel momento in cui si modifica la proprietà

touchMode (Figura 34).

o downHandler()

Figura 35. Metodo „downHandler()‟ del componente TouchButton

Questo metodo gestisce l‟evento di tipo TUIO_DOWN, aggiunge il componente per

poter ricevere le notifiche degli eventi TUIO e notifica l‟evento BUTTON_DOWN,

della classe „ComponentEvent‟, l‟ evento TOUCH_BUTTON_DOWN, della classe

„TouchButtonEvent‟. Dopo di che modifica la proprietà „buttonState‟ assegnadole il

valore „down‟, che come è stato spiegato prima, fa partire il modello d‟invalidazione

per gestire il cambio di skin del componente.


68

o upHandler()

Questo metodo si occupa della notifica dell‟evento TOUCH_BUTTON_UP, della

classe „TouchButtonEvent‟, e modifica la proprietà „buttonState‟ assegnadole il

valore „up‟, che così come fa il metodo „downHandler‟ fa partire il modello

d‟invalidazione che gestisce il cambio dell‟aspetto del componente.

5.1.1.4 Stili

Gli stili utilizzati da questo componente sono gli stessi del componente „LabelButton‟,

quindi in seguito si fa soltanto un elenco di loro:

upSkin: utilizzato per l‟apparenza del tasto quando non è premuto.

downSkin: utilizzato quando il tasto è premuto.

overSkin: utilizzato quando, per esempio il puntatore del mouse si trova sopra del

componente

disabledSkin: utilizzato quando il component non è abilitato.

selectedDisabledSkin: utilizzato quando il component è selezionato e non abilitato.

selectedUpSkin: utilizzato quando il tasto è selezionato però non è premuto.

selectedDownSkin: utilizzato quando il tasto è selezionato e premuto.

selectedOverSkin: utilizzato quando il component è selezionato ed un puntatore, per

esempio, si trova sopra di lui.

focusSkin: utilizzato per indicare che il componente ha il „focus‟ su di lui.

focusRectSkin: lo skin utilizzato per racchiudere il componente in un rettangolo, per

indicare lo stato di „focus‟.

Questi stili vengono di solito utilizzati quando si usa il componente button, però per

esempio nel caso delle applicazioni touch, con schermi tattili, gli skin che rappresentano gli

stati di „over‟ non vengono mai utilizzati. In quanto non è possibile rilevare la mano o il

dito che entri in contatto con lo schermo, lo stato „over‟ non è mai raggiunto. Tuttavia

questi stili sono stati inseriti per poter fare le prove usando il mouse come dispositivo di

input.


69

5.1.1.5 Eventi

Per il componente TouchButton fa la notifica di 3 eventi. Uno dalla classe

„ComponentEvent‟: l‟evento „BUTTON_DOWN‟. Tuttavia per estendere le funzioni, e per

avere un insieme di eventi per il componente, si ha creato una classe personalizzata di

eventi. Questa classe contiene le definizioni per due eventi:

- TOUCH_BUTTON_DOWN: Indicare il momento quando il tasto è stato premuto

- TOUCH_BUTTON_UP: Indica quando il tasto è stato rilasciato.

La classe non possiede nessuna proprietà. Al massimo una proprietà che potrebbe essere

aggiunta sarebbe lo stato attuale del tasto, però questo variabile è stata già definita come

proprietà del componente e quindi si può reperire direttamente dall‟istanza dalla quale si

vuole sapere l‟informazione.

5.1.2 Componente: TouchNumericStepper

Il componente TouchNumericStepper (Figura 36) è stato sviluppato come un‟estensione del

componente di flash: NumericStepper. La funzionalità è la stessa del componente di

partenza e quindi la programmazione si è basata nell‟aggiungere la parte della risposta

tattile del componente alle azioni dell‟utente.

Figura 36. Il componente TouchNumericStepper

5.1.2.1 Apparenza

Gli skin utilizzati per questo componente sono stati gli stessi che per il componente

NumericStepper di Flash. Semplicemente si hanno modificato le forme dei tasti ed le sue

dimensioni per renderli adeguati per il suo uso in un‟applicazione tattile (Figura 37). Come


70

con il componte precedente si sono utilizzati skin per i quattro diversi stati, dei quali lo

stato di over di nuovo è stato usato per le prove fatte con il dispositivo mouse. Questo

componente contiene un subComponente: TextInput, al quale non è stato fatto

cambiamento alcuno.

Figura 37. Gli asset per il componente TouchNumericStepper

5.1.2.2 Proprietà

Questo componente contiene unicamente una proprietà nuova, touchMode, invece tutte le

altre prorpietà sono ereditate dalla classe base „NumericStepper‟.


La proprietà touchMode è una variabile Booleana che indica se il component è

abilitato per ricevere eventi di tipo touch o meno, e per accedere e modificarne

anche ci sono i metodi „get‟ e „set‟. Nel momento che la proprietà viene cambiata, si

fa un‟invalidazione di STATO. Il valore di default è true, quindi il componente

riceve gli eventi di tipo touch, per default.


71

5.1.2.3 Metodi

o configUI()

Questo metodo fa la chiamata al metodo configUI() della classe base e poi assegna

le dimensioni dei tasti di aumento e diminusione del del valore componente

o setupListeners()

Questo metodo gestisce il registro del componente per essere notificato degli eventi

di tipo touch. Questo dipende dalla proprietà touchMode, ma anche deve essere

gestito se il componente cambia di uno stato abilitato ad uno non abilitato (proprietà

„enabled‟). La sua codifica è simile a quella di tutti gli altri componenti, cambiando

unicamente l‟istanze che sono state registrate. (Figura 38).

Figura 38. Metodo setupListeners() per il componente TouchNumericStepper

o draw()

Override del metodo della classe base, nella quale si aggiunge soltanto la gestione

dell‟invalidazione di tipo STATO quando si modificano sia la proprietà „enabled‟

che la proprietà „touchMode‟. Il metodo è stato definito uguale che per il

componente TouchButton (Figura 34).

o downTouchHandler()

Questo metodo viene chiamato nel momento che si schiaccia uno dei due tasti del

componente (Figura 39). Prima si registra il tasto che sia stato schiacciato per


72

ricevere gli eventi TUIO – lo si fa con il metodo TUIO.listenForObject() -, dopo di

che si controlla quale dei due tasti è stato premuto per poter aumentare o diminuire

il valore del stepper a seconda del caso.

Questo metodo è stato una modifica del metodo della classe base che si occupa di

gestire la stessa situazione per un evento del dispositivo mouse. In questo modo,

modificando soltanto le parti pertinenti, è possibile utilizzare le funzioni già

elaborate per la classe base che già gestiscono tutta la funzionalità principale del

componente NumericStepper.

Figura 39. Metodo downTouchHandler del componente TouchNumericStepper

o upTouchHandler()

Questo metodo si occupa di cambiare lo stato del tasto assegnando il valore di „up‟.

Per questo componente è stato necessario agigugnere una condizione per gestire il

tipo di elemento che veniva rilevato come „target‟ dell‟evento, il quale non sempre

risultava di essere di tipo „Button‟. Siccome il metodo „setMouseState()‟ è solo

definito per questa classe, nel momento che il target non era di tipo „Button‟

accadeva un errore. L„istruzione „if‟ permette di gestire questa situazione (Figura

40).


73

Figura 40. Metodo upTouchHandler e l‟istruzione „if‟ per gestire l‟errore del tipo di elemento del

target dell‟evento.

o drawLayout()

Figura 41. Metodo „drawLayout()‟ del componente TouchNumericStepper. Si gestisce

l‟allocazione dei pulsanti

Questo metodo è un override della funzione della classe base la quale bisognava

modificare per gestire le nuove dimensioni degli elementi, i tasti ed il campo del

testo. Il metodo si occupa di allocare adeguatamente ogni elemento, e di cambiare la

dimensione del testo, nel momento in cui le dimensioni del componente vengono

modificate. Alla fine del metodo si chiamano i metodi „drawNow()‟ dei pulsanti e

del campo di testo per ridisegnarli ed assicurarsi di vedere i cambiamenti (Figura

41).


74

5.1.2.4 Stili

Essendo che il componente estende la classe NumericStepper, gli stili utilizzati sono gli

stessi della classe base. Ma soltanto si fa la definizione degli stili dei tasti poiché gli skin

del campo di visualizzazione del valore non sono stati modificati. In seguito vengono

elencati:

downArrowDisabledSkin: skin utilizzato per il tasto che diminuisce il contatore

quando il componente non è abilitato.

downArrowDownSkin: utilizzato per il tasto che diminuisce il contatore quando

viene premuto.

downArrowOverSkin: utilizzato poer il tasto che diminuisce il contatore quando il

mouse è sopra del tasto.

downArrowUpSkin: utilizzato per il tasto che diminuisce il contatore quando è

abilitato e non c‟è nessun‟azione su di lui.

upArrowDisabledSkin: utilizzato per il tasto che aumenta il contatore quando il

componente non è abilitato.

upArrowDownSkin: utilizzato per il tasto che aumenta il contatore quando viene

premuto.

upArrowOverSkin: utilizzato poer il tasto che aumenta il contatore quando il mouse

è sopra del tasto.

upArrowUpSkin: utilizzato per il tasto che aumenta il contatore quando è abilitato e

non c‟è nessun‟azione su di lui

Ci sono altri stili, che vengono dalla classe base, che però non è stato necessario modificarli

poiché non sono necessari per la funzionalità tattile del componente.

5.1.2.5 Eventi

Gli eventi sono gli stessi che per il componente NumericStepper, in vista che il componente

non fa nessun‟azione diversa dal componente base. Nel momento in cui il valore del

contatore viene cambiato viene notificato un evento di tipo „Event.CHANGE‟. Tutta

l‟informazione rispettiva si può trovare nella documentazione della classe base.


75

5.1.3 Componente:TouchSlider

Il componente TouchSlider (Figura 42) è stato sviluppato anche estendendo la classe base

del componente di Flash: „Slider‟. Questa componente, insieme al componente

TouchNumericStepper, perchè ls sue funzioni sono molto utile nel contesto di

un‟applicazione tattile. Il gesto di „trascinare‟ („drag‟ dalla sua traduzione in inglese) è in

generale molto naturale da fare da parte degli utenti. Ormai ci sono tanti dispositivi che

usano questo gesto

Figura 42. Il componente TouchSlider

5.1.3.1 Apparenza

Figura 43. Gli asset per il componente TouchSlider

Per questo componente è stato necessario creare degli skin per rimpiazzare gli skin

utilizzati dal componente base. Per la barra, o track, sono stati creati duw skin diversi, uno

per lo stato „abilitato‟ e l‟altro quando il componente è nello stato „non abilitato‟. Invece

per l‟indicatore, o thumb, servono tutti i quattro skin diversi per gli stati di „premuto‟, „non

premuto‟, „over‟ e „non abilitato‟ (Figura 43). Di nuovo, lo skin di „over‟ è usato per

quando il componente sia usato con il dispositivo mouse. Le dimensioni sono state pensate


76

per dare uno spazio sufficente per toccare il componente, ma allo stesso tempo non troppo

grande per non occupare più spazio del necessario – sopratutto per il track-.

5.1.3.2 Proprietà

Il componente possiede solo una proprietà diversa alla sua classe base, per la funzionalità

interattiva non c‟era bisogno di utilizzarne altre.


Questa proprietà, allo stesso modo che negli altri componenti, è una variabile

Booleana che indica se il component è abilitato per ricevere eventi di tipo touch o

meno, e per accedere e modificarne anche ci sono i metodi „get‟ e „set‟. Nel

momento che la proprietà viene cambiata, si fa un‟invalidazione di STATO.

5.1.3.3 Metodi

I metodi del componente TouchSlider che si occupano della parte di funizonalità sono

pratticamente gli stessi della sua classe base. I metodi nuovi sono quelli che gestiscono la

parte d‟interattivita e di risposta agli eventi touch e sono versioni modificati da quelle

trovati nella classe „Slider‟

o configUI()

Figura 44. Metodo confiGUI() del componente TouchSlider

In questo metodo si chiama la funzione configUI() della classe base che si occupa

d‟inserire gli elementi iniziali. Invece su questo metodo si danno le dimensioni

iniziali per l‟indicatore e la barra (Figura 44).


77

o setupListeners()

In questo metodo vengono registrati a seconda del caso, i listeners per il track e per

il thumb del componente. La gestione viene fatta uguale che con i due componenti

precedenti: dipende dalle proprietà „enabled‟ e „touchMode‟.

o draw()

Questo metodo è un override della funzione della classe base. Alla quale è stata

aggiunta la gestione dell‟invalidazione di tipo STATO, che avviene quando la

proprietà „touchMode‟ viene cambiata, chiamando il metodo „setupListeners‟.

o downTouchHandler()

Figura 45. Metodo downTouchHandler del componente TouchSlider

Nel componente, sia la barra che l‟indicatore, entrambi sono subcomponenti di tipo

Button. Quindi in questa funzione viene innanzitutto controllato che il target

dell‟evento sia uno di questi due elementi. Dopo di che si registra l‟elemento per

ricevere gli eventi TUIO e lo si cambia la proprietà „mouseState‟ utilizzando il

metodo publico della classe „setMouseState()‟. Se è stato l‟indicatore ad essere

premuto, lo si registra per rispondere agli eventi TUIO_MOVE e TUIO_UP,

necessari per il trascinamento e poi per il rilascio dell‟indicatore. Invece se è la

barra ad essere premuta, si calcola la posizione dov‟è stata toccata e si sposta il

valore dello slider su quella posizione (Figura 45).


78

Questo metodo prima verifica che il target dell‟evento sia stato l‟indicatore o la

barra e dopo determina quale dei due è stato premuto e lo salva su una variabile

interna, „pressedButton‟. Dopo di che, se è stato l‟indicatore ad essere premuto, si fa

la notifica dell‟evento „SliderEvent.THUMB_PRESS‟, se invece è stata la barra ad

essere premuta, si calcola il punto di contatto per assegnare il nuovo valore al

componente e dopo si fa la notifica dell‟evento „SliderEvent.CHANGE‟

o upTouchHandler()

Questo metodo si occupa di cambiare lo stato dell‟elemento per cambiare lo stile.

Anche per questo componente è stato necessario controllare l‟oggetto a cui fa

riferimento il target dell‟evento poiché a volte veniva riferenziato un elemento

diverso ed al provare cambiare lo stato dell‟elemento, si produceva un errore. Per

evitarlo si ha utilizzato un‟istruzione „if‟ che controlla il target, verificando che sia

la barra oppure l‟indicatore.

o doDragTouchVersion()

Questo metodo è una versione modificata del metodo „doDrag‟ della classe base

viene chiamata con lo spostamento del dito per trascinare l‟indicatore dello slider

(con l‟evento TUIO_MOVE).

o thumbReleaseTouchHandler()

Questo metodo è la versione modificata del metodo „thumbreleaseHandler‟ della

classe base, il quale viene chiamato nel momento che l‟indicatore viene rilasciato

dall‟utenteIl metodo si occupa di togliere il registro dei listeners per gli eventi

TUIO_MOVE e TUIO_UP.

5.1.3.4 Stili

Gli stili sono gli stessi della sua classe base, e vengono elencati in seguito:

thumbUpSkin: lo skin che viene utilizzato nello stato normale dell‟indicatore, senza

che nessun evento sia stato notificato.

thumbOverSkin: viene utilizzato quando il mouse, per esempio, si trova sopra

dell‟indicatore.

thumbDownSkin: viene utilizzato quando l‟indicatore è premuto.


79

thumbDisabledSkin: viene utilizzato per l‟indicatore quando il componente non è

abilitato.

sliderTrackSkin: lo skin utilizzato per la barra quando il componente è abilitato.

sliderTrackDisabledSkin: lo skin utilizzato per la barra quando il componente non è

abilitato

tickSkin: skin utilizzato per il marchio dei tick (questo viene abilitato con una delle

proprietà della classe base del componente)

Gli altri stili non sono stati modificati è quindi hanno lo stesso valore definito nella classe

base, perciò non vengono elencati qua.

5.1.3.5 Eventi

Gli eventi notificati da questo componente sono gli stessi della componente slider:

„SliderEvent.THUMB_PRESS‟, che viene notificato appena si preme l‟indicatore;

„SliderEvent.CHANGE‟, che viene notificato quando il valore dello slider cambia sia per

un tocco nella barra che per un cambio diretto alla proprietà „value‟; l‟evento

„SliderEvent.THUMB_DRAG‟ che viene notificato mentre l‟indicatore è trascinato; e

„SliderEvent.THUMB_RELEASE‟, notificato quando l‟indicatore è rilasciato.

5.1.4 Componente:TouchKeyboard

Quest‟ultimo componente estende direttamente la classe „UIComponent‟, ma utilizza un

sub-componente: TouchButton. Il modo in cui questo componente funziona è un po‟

diverso dagli altri, nel senso che inizialmente il componente è un unico tasto, noto come

„openButton‟, che rappresenta la tastiera nel suo stato non attivo. Poi, nel momento in cui

questo tasto è premuto, la tastiera si attiva e viene visualizzata. Il componente cambia

completamente lo skin utilizzato a seconda del suo stato „attivo‟ (Figura 46).Una volta che

il componente si trova nel suo stato attivo, si può disattivare premendo il tasto di chiusura,

che si trova nella parte bassa a destra della tastiera, col simbolo di spegnimento.


80

Figura 46. Il componente TouchKeyboard

Questo componente implementa anche una piccola funzione multitouch: come in una

tastiera reale, quando si tiene premuto il tasto „shift‟, le lettere vengono scritte come lettere

maiuscole, oppure viene scritto il carattere secondario, se esiste. Nel momento in cui viene

premuto il tasto „shift‟ le lettere nella tastiera diventano maiuscole, e nei tasti con caratteri

secondari viene evidenziato il secondo carattere, cambiando il formato del carattere (colore

e dimensioni). Dopo di che nel momento di rilasciarlo, i tasti ritornano al suo formato

originale.

Un‟altra funzione simile alle tastiere reali è il tasto „Caps Lock‟, il quale nel momento di

essere premuto, fa diventare tutte le lettere maiuscule (anche visualmente) tranne quelle dei

tasti che contengono caratteri secondari.

Lo scopo di questo componente è quello di implementare una funzione multitouch, che

anche se solo viene utilizzata per una funzione molto semplice (il „shift‟), fa vedere il

funzionamento di questi tipi di sistemi ed i suoi vantaggi: la possibilità di realizzare azioni

contemporaneamente.

5.1.4.1 Apparenza

Questo componente possiede un gran numero di asset. Sono stati creati gli skin per i quattro

diversi stati, tutti e quattro per ogni tipo di tasto utilizzato. Più il fondo della tastiera. In

seguito si illustreranno gli asset per ogni gruppo di tasti:


81

o „OPEN BUTTON‟

Figura 47. Il tasto openButton della tastiera

Il tasto open button appartiene alla classe TouchButton e quindi utilizza quattro

simboli diversi. Gli stessi quattro simboli si sono utilizzati per rimpiazzare gli otto

asset del componente TouchButton, usando per esempio l‟asset „upSkin‟ sia per lo

stato „selezionato‟ che „non selezionato‟ (gli asset del componente touchButton sono

nella Figura 29). Lo stesso è stato fatto per gli altri tasti della tastiera che fanno

parte della stessa classe TouchButton.

Figura 48. Gli asset per il tasto „openButton‟

Questo tasto ha un‟immagine di una tastiera. È visualizzato quando la tastiera non è

attiva e in questo modo il componente non occupa spazio inutilmente.


82

o KEYBOARD BACKGROUND

Figura 49. L‟asset per lo sfondo della tastiera

Questo asset è utilizzato come sfondo della tastiera. Nel contesto della display list,

questo simbolo è il contenitore di tutti i tasti della tastiera, tranne il tasto „open

button‟.

Nella Figura 49, è possibile vedere la dimensione della tastiera rispetto alla

dimensione del tasto d‟attivazione. Questo simbolo è stato inserito con questi

dimensioni per una ragione importante: essendo il contenitore di tutti gli altri tasti

della tastiera, le variazioni nelle dimensioni di questo simbolo vengono anche

applicate su tutti gli elementi che contiene. Siccome tutti gli altri asset sono stati

creati con le sue dimensioni reali, se questo componente avesse inizialmente delle

dimensioni più piccole, nel momento di cambiare le sue misure per rendere la

tastiera di una dimensione reale, l‟aumento nelle dimensione verrebbe anche

applicato a tutti i suoi elementi, rendendoli più grandi della loro misure originale.

Dunque, le dimensioni di questi tipi di asset deve essere relativo al suo contenitore:

se dall‟inizio si sa che al contenitore verrà applicato un cambio nelle sue

dimensioni, tutti i suoi elementi devono essere createicon delle misure apposite, in

modo che nel momento del cambiamento tutti gli elementi abbiano le misure

desiderate.

Nel caso di questo componente, tutti gli asset sono stati inseriti con le loro

dimensioni originali, e non viene fatto nessun cambio nelle dimensioni del

componente.


83

o „BASE BUTTON‟

Figura 50. Gli asset per i tasti dei caratteri e due esempi di tasti

Questi tasti, sempre della classe TouchButton, contengono tutti i caratteri della

tastiera. Oltre ai caratteri principali, per i tasti che contengono un carattere

secondario è stato aggiunto un altro campo di testo per la loro visualizzazione.

o „FUNCTION BUTTON‟

Figura 51. Gli asset per i tasti di funzione


84

Questi tasti sono tutti quelli che servono per realizzare delle funzioni nella tastiera,

per esempio il tasto „shift‟ ovvero il tasto „intro‟. Anche questi fanno parte della

classe TouchButton

L‟uso di questi asset esiste per tutti i tasti di funzioni che possiedono dimensioni

diverse tra di loro, anche per assomigliare l‟apparenza di una tastiera reale.

Dipendendo del tasto, si è anche aggiunto un campo di testo per mettere il nome

della funzione.

o „CLOSE BUTTON‟

Il tasto di chiusura e disattivazione della tastiera fa parte della classe TouchButton, e

la si trova nella parte bassa a destra della tastiera.

Figura 52. Gli asset per il tasto „close button‟ della tastiera


85

5.1.4.2 Proprietà

Le proprietà per questo componente sono in generale tutte quelle per controllare il suo

funzionamento. Soltanto alcune proprietà sono accessibile per sapere lo stato attuale del

componente (per esempio „Attivo‟/‟Disattivo‟). Molte delle informazioni utili della tastiera,

come per esempio il tasto che è stato premuto, sono reperibile dagli eventi, che verranno

illustrate più avanti.

o const OPEN_CLOSE:String = "openCloseKeyboard";

Questa costante serve per invalidare lo stato „attivo‟/‟disattivo‟ del componente e

viene utilizzata nel momento in cui sia il tasto d‟attivazione del componente che il

tasto di chiusura siano schiacciati (proprietà isActive). Nel metodo set di questa

proprietà viene fatta l‟invalidazione di tipo OPEN_CLOSE.


La proprietà touchMode è una variabile Booleana che indica se il componente è

abilitato per ricevere eventi di tipo touch o meno, e per accederevi e modificarla ci

sono i metodi „get‟ e „set‟. Nel momento che la proprietà viene cambiata, si fa

un‟invalidazione di STATO. Il valore di default è true.

o isActive:Boolean = false;

Questa proprietà è utilizzata per gestire lo stato „attivo‟/‟disattivo‟ del componente.

Possiede un valore „false‟ per default poiché la tastiera è disattiva. Viene modificata

nel momento in cui il tasto d‟attivazione, open_button, oppure quello di chiusura

vengono premuti. Quando questo accade, si fa un‟invalidazione di tipo

OPEN_CLOSE, come si può evidenziare nella Figura 53.

Figura 53. Definizione per la proprietà „isActive‟ del componente TouchKeyboard


86

o capsLockOn:Boolean = false;

Proprietà utilizzata per indicare lo stato del tasto „Caps Lock‟. Il suo valore viene

inviato come parametro dell‟evento ogni volta che un tasto viene premuto.

Figura 54. Metodo set della proprietà capsLockOn

Nella Figura 54 si può vedere che nel momento di cambiare il valore della proprietà

si fa un‟invalidazione di tip STYLES, questa si fa perchè questa proprietà controlla

il modo di vedere i caratteri dei tasti. Un cambio del suo valore quindi significa un

ridisegno della parte visuale di questi tasti.

o ctrlOn:Boolean = false;

Proprietà utilizzata per indicare lo stato del tasto „Ctrl‟. Il suo valore viene inviato

come parametro dell‟evento ogni volta che un tasto viene premuto.

o shiftOn:Boolean = false;

Proprietà utilizzata per indicare lo stato del tasto „Shift‟. Il suo valore viene inviato


o altOn:Boolean = false;

Proprietà utilizzata per indicare lo stato del tasto „Atl‟. Il suo valore viene inviato


5.1.4.3 Metodi

o configUI()

Questo metodo chiama la funzione configUI() della classe base. Dopo

l‟inizializzazione il tasto „open_button‟ gli assegna gli stili e poi l‟aggiunge nella

display list.


87

Figura 55. Metodo configUI() del componenteTouchKeyboard

Il metodo „copyStylesToChild‟ è quello che si occupa di assegnare al tasto gli stili

definiti all‟interno della costante OPEN_BUTTON_STYLES. Per tutti i tasti è stato

definito una costante come questa nella quale si definiscono gli stili che si devono

assegnare al tasto, i valori si prendono dall‟oggetto „defaultStyles‟ del componente.

o TouchKeyboard()

Metodo costruttore che si occupa di inizializzare tutti i bottoni delle funzioni della

tastiera, insieme a tutte le altre variabili che servono per creare la tastierat. Inoltre

crea i formati di testo che devono avere i tasti quando cambia la funzionalità al

premere il tasto „shift‟

o setupKeyboardLayout()

Questo metodo si occupa di inizializzare tutti i tasti della tastiera assegnando le

dimensioni giuste e li alloca nelle posizioni giuste. Si occupa anche di aggiungere i

caratteri nel label di ogni tasto, ed i caratteri secondari su quelli che l‟hanno, e di

applicare gli stili rispettivi ai tasti di funzione, dei caratteri, d‟attivazione e di

chiusura.

o setupMouseListeners()

Questo metodo che si occupa di registrare i tasti (d‟attivazione, chiusura, dei

caratteri e quelli di funzione) all‟evento MOUSE_DOWN del dispositivo Mouse,

per gestire la risposta del componente quando i tasti vengono premuti con il mouse.


88

o isEnabled()

Questo metodo è stato necessario implementarlo per gestire il cambio dagli stati

„abilitato‟ e „non abilitato‟. Siccome ogni tasto è un componente a sé, bisogna

cambiare non solo lo stato del componente generale ma anche di ogni

subcomponente. Quando la proprietà „enabled‟ del componente viene attivata, si

abilitano tutti i tasti, ed invece quando il componente viene disabilitato, tutti i

subomponenti divengono „non abilitati‟. In questo modo si assicura la gestione

degli eventi di tocco definiti nella classe dei tasti: TouchButton.

o setupTouchListeners()

Questo metodo viene chiamato dopo del metodo isEnabled(), e si occupa di gestire

la registrazione dei tasti agli eventi, fatto che dipende delle proprietà „enabled‟ e

„touchMode‟, così come i componenti precedenti. La registrazione deve essere fatta

su ogni tasto della tastiera. Anche su questo metodo viene cambiata la proprietà

„touchMode‟ di ogni tasto, per assicurare la gestione degli eventi, così com‟è stato

fatta con la proprietà „enabled‟.

o draw()

Questo metodo gestisce le invalidazioni di tipo STATE, nella quale si chiama il

metodo isEnabled(), l‟invalidazione di tipo STYLES, che se sono stati schiacciati i

tasti „shift‟ o „CapsLock‟ chiama il metodo „capsLockFunction()‟, Figura 56;

l‟invalidazione di tipo OPEN_CLOSE, che dipendendo della proprietà „isActive‟

chiama il metodo addRemoveKeyboard(). Nella parte finale di questo metodo, si fa

la chiamata al metodo drawNow() di ogni subcomponente.

Figura 56. Verifica dell‟invalidazione di tipo STYLES e chiamata al metodo „capsLockFunction()‟

dopo verificare si è stato schicciato il tasto „CapsLock‟ o „shift‟


89

Questo metodo è molto importante innanzitutto per i componenti che contengono

come asset altri componenti. La sua chiamata assicura che il subcomponente sia

aggiornato adeguatamente, assicurando la sua corretta visualizzazione.

o touchDownHandler()

Questo metodo si occupa di gestire la funzione della tastiera a seconda del tasto che

è stato premuto per mezzo di un‟azione interattiva (Evento di tocco). Così nel

momento che si preme un tasto si fa la notifica di un evento di tipo

TouchKeyboardEvent. KEY_DOWN , passando gli argomenti rispettivi a seconda

del tasto in funzione. Un esempio della verifica che fa il metodo s‟illustra nella

Figura 57.

Figura 57. Esempio della verifica per il tasto „shift‟.

Come si può vedere nella figura precedente, prima si controlla che tasto sia stato

premuto, questo valore viene visualizzato nella variabile „myButton‟ e dopo a

seconda del tipo di tasto si calcolano i valori che devono essere passati come

argomenti per creare l‟evento di tipo KeyboardEvent.TOUCH_KEY_DOWN.

o touchUpHandler()

Questo metodo, in un modo simile al precedente, si occupa di gestire la funzionalità

della tastiera nel momento che un tasto è rilasciato. Facendo la notifica di un evento

di tipo TouchKeyboardEvent. KEY_UP.

o mouseDownHandler()

Questo metodo si occupa di gestire gli eventi notificati sulla tastiera quando un

tasto qualsiasi è schiacciata con il dispositivo Mouse. La funzionalità dipende del

tasto che è stato premuto e le informazioni rispettive sono tutte reperibili

dall‟evento TouchKeyboardEvent.


90

o mouseUpHandler()

Questo metodo si occupa di gestire gli eventi di tipo MOUSE_UP, e fa lo stesso che

il metodo touchUpHandler solo che per il dispositivo mouse.

o capsLockFunction()

Questo metodo verifica il cambiamento dei caratteri in maiuscole oppure in

minuscole, cioè se i tasti „CpasLock‟ o ‟Shift‟ sono stati schiacciati.

o addRemoveKeyboard()

Questo metodo si occupa di togliere oppure di aggiungere la tastiera nel display

List, e dipende dal fatto se la tastiera si trova in uno stato attivo o no (stato che viene

cambiato quando si premono i tasti d‟attivazione e di chiusura del componente).

5.1.4.4 Stili

Gli stili defniti sono quelli che vengono utilizzati per ogni tipo di tasto trovato nella tastiera:

Open Button, Function Button, Base Button, Close Button. In totale sono quattro skin per

ciauscuno di loro, i quali si elencano in seguito.

OpenButtonDownSkin: Stile utilizzato per il tasto d‟attivazione della tastiera

quando questo è stato premuto.

OpenButtonUpSkin: Stile utilizzato per il tasto d‟attivazione della tastiera quando

questo si trova in uno stato normale abilitato.

OpenButtonOverSkin: Stile utilizzato per il tasto d‟attivazione della tastiera quando

l‟indicatore del mouse si trova sopra di questo.

OpenButtonDisabledSkin: Stile utilizzato per il tasto d‟attivazione della tastiera


CloseButtonUpSkin: Stile utilizzato per il tasto di chiusura della tastiera quando


CloseButtonDownSkin: Stile utilizzato per il tasto di chiusura della tastiera quando

questo è stato premuto.


91

CloseButtonOverSkin: Stile utilizzato per il tasto di chiusura della tastiera quando


CloseButtonDisabledSkin: Stile utilizzato per il tasto di chiusura della tastiera


keyboardSkin: Stile utilizzato per il fondo della tastiera.

KeyboardButtonUpSkin: Stile utilizzato per i tasti dei caratteri della tastiera quando


KeyboardButtonDownSkin: Stile utilizzato per i tasti dei caratteri della tastiera


KeyboardButtonOverSkin: Stile utilizzato per i tasti dei caratteri della tastiera

quando l‟indicatore del mouse si trova sopra di questo.

KeyboardButtonDisabledSkin: Stile utilizzato per i tasti dei caratteri della tastiera


FunctionButtonUpSkin: Stile utilizzato per i tasti di funzione della tastiera quando


FunctionButtonDownSkin: Stile utilizzato per i tasti di funzione della tastiera


FunctionButtonOverSkin: Stile utilizzato per i tasti di funzione della tastiera quando


FunctionButtonDisabledSkin: Stile utilizzato per i tasti di funzione della tastiera


Tutti i tasti della classe TouchButton usano in totale 8 skin diversi, definiti per la sua classe

(Figura 29) però sono stati utilizzati gli stessi 4 skin sia per gli stili „selected‟ che per quelli

normali. Per questo componente sono stati utilizzati tanti skin diversi, che si ricorda sono

simboli che devono avere l‟opzione di „esportar per actionscript‟ selezionata, quindi è

molto importante che nessuno dei simboli abbia un nome di classe uguale ad un‟altro asset

del componente oppure agli asset di un altro componente di flash. Nel caso abbiano gli

stessi nomi l‟applicazione comunque potrebbe funzionare, però la classe StyleManager avrá

dei problemi nel momento di selezionare lo stile da utilizzare, ed utilizzerà unicamente il


92

primo skin che troverà tra gli asset di tutti i componenti che si stiano utilizzando per

l‟applicazione.

All‟interno del codice si è creato una variabile di tipo „Object‟ per ogni tipo di tasto che

appartiene alla tastiera. Questi oggetti contengono gli stili che ognuno di loro deve

utilizzare come asset. L‟oggetto „defaultStyles‟ del componente TouchKeyboard, possiede

nel suo interno le definizioni di tutti gli stili utilizzati, quindi nel momento della creazione

della tastiera si assegnano gli stili rispettivi per i tasti del componente

5.1.4.5 Eventi

Per la tastiera tattile è stata definita una classe per i suoi eventi la quale estende la classe

base „KeyboardEvent‟. Questa classe define due eventi: TOUCH_KEY_UP e

TOUCH_KEY_DOWN che rappresentano i due stati di qualunque elemento della tastiera.

Come questa classe estende la classe degli eventi di Flash utilizzata per la tastiera reale,

ereda le sue proprietà, quindi è possible sapere gli stati dei tasti di funzione attraverso di

loro.

In questa classe è stata definita unicamente una proprietà adizionale:

o charValue: contiene la lettera oppure il simbolo del tasto che è stato premuto. Nel

momento che il tasto premuto è stato uno dei tasti di funzione, lo si assegna il valore

vuoto (charValue = ‟‟ ).

Un esempio dell‟informazione dell‟evento TOUCH_KEY_DOWN sii può vedere nella

Figura 58,

Figura 58. Informazione dell‟evento TouchKeyboardEvent.TOUCH_KEY_DOWN

Quest informazione si può vedere all‟utilizzare l‟istruzione trace(event), dove la variabile

„event‟ è l‟evento notificato al toccare il tasto „t‟. Ogni volta che viene premuto un tasto

della tastiera, diverso al tasto d‟attivazione, si fa la notifica di un evento con l‟informazione

rispettiva al tasto schiacciato.


93

5.1.5 Errori nei componenti rilevati nel processo di sviluppo

Durante il processo di sviluppo dei componenti si sono verificati alcuni problemi che non si

sono riusciti ad correggere o a capirne la ragione per cui avvenivano. Questi problemi si

illustrano in seguito, insieme ad alcune supposizioni sulle cause.

Si sono rilevati degli errori su due dei componenti sviluppati: per quanto riguarda il

TouchSlider la proprietà di orientamento del componente non funziona correttamente. Nel

momento di cambiare da un orientamento orizzontale ad uno verticale, il componente non

viene ruotato un angolo di 90 gradi come dovrebbe succedere ma invece viene invertito sul

asse orizzontale (Figura 59). Questa funzione viene controllata dal metodo „set‟ della

proprietà „direction‟ della classe base. Durante il processo di sviluppo, la proprietà è stata

messa alla prova e funzionava correttamente, anzi la funzione „set‟ non è stata modificata in

nessun momento. L‟errore si è presentato al momento di creare l‟anteprima. È verosimile

che l‟errore si sia verificato dopo la definizione delle impostazioni del componente.

Figura 59. Errore nel componente TouchSlider al cambiare la proprietà „direction‟

Tuttavia, questo problema accade unicamente quando si cambia la proprietà dal panello

„Component Inspector‟, da dov‟è possibile modificare tutte le proprietà dei componenti che

sono state definite come metadati. Se invece la direzione viene cambiata in fase di

esecuzione del programma, il componente cambia di orientamento correttamente.

L‟altro errore si è rilevato sul componente TouchKeyboard, nel quale la sua anteprima non

funziona adeguatamente e si visualizza uno degli asset del componente che non dovrebbe

essere visibile (Figura 60).

Figura 60. Errore nell‟anteprima del componente TouchKeyboard


94

Questo errore si crede sia dovuto a problemi di compatibilità tra Flash CS3 e CS4. Tutti i

componenti sono stati sviluppati su Flash CS3, ed alla fine sono stati importati su Flash

CS4 per fare le prove nello schermo tattile, ma sul programma Flash CS3 l‟anteprima del

componente non è visualizzata in questo modo, mentre sulla versione più recente aveva

quest‟apparenza. Nella fase di esecuzione, il componente è visualizzato normalmente senza

nessun errore.

5.1.6 Importando i componenti in FLASH

Per poter utilizzare i componenti appena sviluppati è necessario metterli su una cartella da

dove Flash possa trovarli per poi importarli all‟interno del programma e poter utilizzarli

come dei componenti, trascinabili sullo stage ogni volta che se ne vuole utilizzare uno. Per

fare ciò bisogna andare alla cartella d‟istalazzione di Flash, che si trova nel path seguente:

..Program Files\Adobe\Adobe Flash CSX\language\Configuration\Components\

Oppure può essere il path seguente:

..Program Files\Adobe\Adobe Flash CSX\Common\Configuration\Components\

In questa cartella vengono inseriti tutti I componenti di flash. Qua è possibile creare una

cartella nuova ed al suo interno verrà inserito il file .fla del progetto dove si è sviluppato il

componente. Dopo di che si esegue il programma ed nel panello dei componenti, verrà

visualizzata una voce nuova con il nome della cartella appena creata, ed una volta si

estende l‟opzione, sarà possibile vedere tutti i componenti che siano stati inseriti all‟interno

della cartella (Figura 61).

Figura 61. I componenti personalizzati all‟interno del panello dei componenti di Flash


95

5.2 Creazione di classi di AS3 per l‟interazione con i Gesti

Nella parte descritta in seguito si è cercato di creare delle classi che permettessero

l‟interazione con i gesti fatti dall‟utente. Per poter sviluppare una classe che se ne occupi,

bisogna sapere prima a quali gesti si deve reagire e perciò è necessario fare una

classificazione dei tipi di gesti con cui si vuole interagire.

5.2.1 Classificazione dei gesti

Prima di tutto bisogna sapere quali gesti si possono utilizzare per una applicazione

touchscreen, e rispetto a quanto esposto nel capitolo 4, si è fatta una selezione dei gesti ed

una classificazione di essi: „Gesti Semplici‟, quei gesti che con il tempo sono diventati dei

pattern/modelli per il loro ampio uso, e „Gesti Complessi‟, che sono quei gesti fatti

dall‟utente che si devono confrontare con i modelli contenuti in una libreria template.

Questo si è riassunto nella tabella 3.

GESTI SEMPLICI GESTI COMPLESSI

1 BLOB 2 BLOB

DRAG ROTATE Tutti i gesti fatti in modo

libero dall‟utente

SELECTED SCALE

TAP

Tabella 3. Classifica dei gesti a con cui si vuole interaggire.

Questi gesti sono stati scelti per le seguenti ragioni: i gesti semplici sono i modi di fare già

conosciuti da gran parte degli utenti; mentre per i gesti complessi, bisogna scegliere i gesti

da utilizzare come la libreria dei template, per dopo fare il confronto con i gesti fatti

dall‟utente. Quest‟ultimi permettono di arricchire le funzionalità delle interfacce

touchscreen, poiché fanno possibile l‟utilizzo di un maggiore numero d‟input per il sistema.

5.2.2 Classi di ActionScript 3.0 sviluppate

Dopo la classifica dei gesti ci si è incentrati sul processo di sviluppo delle classi. La prima

classe sviluppata permette di creare una base di dati con i template dei gesti, che stampa le

informazioni in formato XML. La seconda classe permette di creare un‟istanza capace di

reagire ai gesti semplici. L‟ultima classe importante che si è creata è una classe che riesce


96

ad individuare il momento in cui l‟utente fa un gesto complesso, per fare ciò utilizza le altre

due classi.

Oltre alle tre classi principali, si sono creati altre classi aussiliari come per esempio quella

che definisce gli eventi. Queste classi aussiliari non sono fondamentali per il funzionamento

generale del pacchetto di classi e perciò non verranno descritte.

5.2.2.1 Classe per la creazione di una libreria di gesti: GestureCreator.as

Questa classe fa uso di una delle classi che implementano la tecnica „1$‟ che si sono

descritte nella sezione 4.2.1.1. La classe utilizzata è la „DollarTemplate‟, che si usa per

normalizzare tutti gesti che si vogliamo salvare nella libreria. Quest‟utima è stata realizzata

in modo tale da permettere di creare i gesti sia con il mouse che con le dita.

Per la creazioni di gesti, bisogna implementare un‟istanza della classe „GestureCreator‟, il

costruttore deve ricevere come argomento l‟elemento sul quale verranno rilevati i gesti.

Questo elemento può essere sia lo stage, oppure ad esempio una Sprite o MovieClip.

Questa scelta permette una maggiore libertà nell‟uso di questa classe, nel senso che se si

vuole passare a un elemento disegnato all‟interno di un‟applicazione più complessa lo si

può fare senza alcun problema.

Figura 62. Rilevamento del tipo d‟argomento passato al costruttore della classe „GestureCreator‟.

Quindi nel costruttore viene identificato se l‟elemento passato è di tipo Stage o no. Se

l‟oggetto non è di tipo Stage, ci troviamo di fronte ad un elemento utilizzabile dall‟utente,

come uno spazio di disegno dei gesti. Se invece è stato lo stage ad essere passato come

argomento, lo si salva su una variabile interna, e si crea uno elemento tipo Sprite per usarlo

come lo spazio di disegno, nella Figura 62, si può vedere questa parte del codice. Oltre alla

creazione dello spazio di disegno, vengono anche aggiunti: uno spazio per il testo, dove


97

l‟utente può inserire il nome che vuole usare per il gesto; due tasti semplici, uno dei quali

viene utilizzato per salvare il gesto appena fatto dall‟utente e l‟altro per stampare le

informazioni di tutti i gesti salvati; un terzo tasto che serve per attivare l‟opzione di

realizzare gesti con forma poligonale; ed un‟altro elemento sprite che serve a dipingere la

traiettoria del gesto fatto dall‟utente. Tutto questo è fatto a livello di codice. La interfaccia

si può vedere nella Figura 63.

Figura 63. Interfaccia per la creazione dei gesti.

Lo spazio di disegno viene registrato per essere notificato sia dall‟evento MOUSE_DOWN

che dall‟evento TUIO_DOWN. Nel momento in cui si fa la notifica di questi eventi si

chiama un metodo che prima cancella tutti i punti del gesto precedente dall‟array, e dopo

elimina tutto quello che è stato disegnato in prima, successivamente registra lo spazio di

disegno per essere notificato dagli eventi MOUSE_MOVE, MOUSE_UP , TUIO_MOVE e

TUIO_UP. Nella Figura 64 mostra il metodo fatto per l‟evento del mouse, l‟altro metodo fa

praticamente lo stesso, con la differenza che invece di registrare eventi della classe

MouseEvent, ne registra quelli della classe TUIOEvent.


98

Figura 64. Metodo per gestire l‟evento MOUSE_DOWN

L‟elemento di nome „painting‟ nella funzione della figura precedente è quello che fa il

disegno del gesto sullo spazio di disegno, e viene allocato nel punto dove si trova il mouse,

tramite l‟istruzione:

painting.graphics.moveTo(recordArea.mouseX, recordArea.mouseY);

Nel caso il gesto sia stato fatto con un dito si utilizzano le proprietà „LocalX‟ e „LocalY‟

per definire la posizione del dito rispetto allo spazio di disegno. A questo punto, si comincia

a seguire il movimento del dito/mouse chiamando i metodi che sono stati registrati per

essere notificati ogni volta che si rileva uno spostamento di loro. Questi metodi, ogni volta

che vengono chiamati, inseriscono il punto dov‟è stato rilevato l‟evento all‟interno di un

array di punti. In questo modo è possibile salvare tutti i punti del gesto e allo stesso tempo

completare il disegno aggiungendo il nuovo punto in cui si è spostato il dito/mouse.

Il codice che sviluppa questa parte è il seguente:

Figura 65. Codice utilizzato per „dipingere‟ il gesto nello spazio di disegno


99

Dove la variabile „gesturePoints‟ è un array utilizzato per salvare i punti del gesto che sta

registrando. Una volta terminato il gesto, si chiamano due metodi: il primo si occupa di

normalizzare i punti appena rilevati, utilizzando un‟istanza della classe „DollarTemplate‟ ed

assegnarli il nome appena inserito (sezione 4.2.1.1). Il secondo metodo gestisce la selezione

dell‟opzione di „Polygonal Gesture‟. Se questa opzione è selezionata, la classe fa

un‟elaborazione in più dei punti per fare un‟approssimazione del gesto ad una figura

poligonale31

. La parte del codice che se ne occupa è illustrata nella Figura 66,

Figura 66. Codice per gestire la normalizzazione del gesto e l‟opzione dei gesti poligonali

Nella prima riga di codice si fa la normalizzazione del gesto, dopo di che se l‟opzione di

Gesti poligonali è attiva, la variabile booleana „polyGesture‟ richiama il metodo

„getCornerPoints()‟ della classe ShortStraw32

per ottenere un vettore con gli angoli del

poligono, e svolge una normalizzazione del vettore: tutti i gesti nella libreria devono avere

la stessa lunghezza per poterli paragonare con i gesti fatti dall‟utente. Lasciare un gesto solo

con quattro o cinque punti della figura poligonale non permetterebbe di fare un confronto

corretto tra i gesti. Successivamente alla normalizzazione del gesto si chiama un‟altro

metodo ausiliare che si utilizza per dipingere il gesto appena normalizzato e visualizzarlo

nello stage. Un esempio si può vedere nella Figura 67.

La figura viene disegnata nell‟angolo dello stage perché si utilizzano le coordinate

normalizzate, per aiutare il matching dei gesti le figure vengono disegnate intorno alle

coordinate (0,0). Se si vuole cambiare questo, basta sommare le coordinate del nuovo

centro a tutte le coordinate dell‟array.

31

Algoritmo elaborato nello studio di Wollin, A. et al. – “Short Straw: a simple and effective corner finder for

polylines” <http://srlweb.cs.tamu.edu/srlng_media/content/objects/object-1246294647-

350817e4b0870da27e16472ed36475db/Wolin_SBIM08.pdf> 32

Betriebsraum weblog “Efficient Gesture recognition and Corner Finding in AS3”

<http://www.betriebsraum.de/blog/2009/07/21/efficient-gesture-recognition-and-corner-finding-in-as3/>

http://srlweb.cs.tamu.edu/srlng_media/content/objects/object-1246294647-350817e4b0870da27e16472ed36475db/Wolin_SBIM08.pdf




100

Figura 67. Esempio del gesto, in blu, e la sua versione normalizzata, in rosa

Dopo aver inserito i punte del gesto e averli normalizzati si può scegliere di salvare il gesto

oppure stampare i gesti registrati fino a quel momento. Al premere del tasto REC si chiama

un metodo che verifica che la lunghezza del gesto sia maggiore ad un unico punto e che sia

stato inserito un nome per il gesto. In caso contrario il gesto non viene inserito nell‟array di

gesti, questa verifica viene fatta nel momento in cui viene premuto. Figura 68 mostra

questo metodo; la variabile booleana „proceed‟ è utilizzata come variabile di controllo:

finchè non vengono verificate il nome e la lunghezza non viene chiamato il metodo per la

normalizzazione del gesto e non si aggiunge il gesto nell‟array.

Figura 68. Codice del metodo del tasto REC


101

Per stampare le informazioni dei gesti registrati basta premere il pulsante Print e nella

finestra di output ne vengono visualizzate le informazioni in formato XML, per poi copiarli

su un file .xml che si può utilizzare come base per paragonarli ai gesti fatti in qualsiasi altra

applicazione. Il formato è il seguente:

<Gestures>

<gesture name= _gestrureName>

<point x = x_value y =y_value></point>

…

<point x = x_value y =y_value></point>

</gesture>

<Gestures>

Il metodo che si occupa di generare il file XML viene illustrato nella Figura 69. Tutti i gesti

normalizzati hanno una lunghezza di 64 punti, questa impostazione si può cambiare

all‟interno della classe „DollarRecognizer‟ nella proprietà NUM_POINTS.

Si possono inoltre inserire dei nomi personalizzati per ogni gesto, questo può servire per

ottenere due gesti con ugual nome che possono essere utili nel caso in cui potrebbe esserci

un fraintendimento dovuto alla direzione in cui l‟oggetto è stato tracciato. Un esempio è il

cerchio che può essere disegnato in senso orario e antiorario; a livello grafico non c‟è

differenza, ma i punti nei due casi sono molto diversi. In questo modo è possibile creare

tutti le versioni di uno stesso gesto.

Figura 69. Metodo per la creazione della libreria di gesti in formato XML

Questa classe serve per creare, in modo semplice, un database di gesti; l‟interfaccia è creata

per mezzo di ActionScript,al fine di alleggerire il lavoro all‟utente: per fare funzionare la

classe bastano soltanto due righe di codice che possono essere scritte sul primo frame

script:

import gestures.GestureCreator;

var myCreator:GestureCreator = new GestureCreator(this.stage);


102

5.2.2.2 Classe simpleGestObject.as

Con questa classe si è pensato di gestire i gesti semplici per un oggetto qualsiasi nello

schermo con il quale si possa interagire. Inizialmente si era pensato di gestire tutto da una

classe generale che determinasse ogni volta se un gesto semplice era fatto su un oggetto.

Trattandosi di gesti semplici, e non avendo bisogno di paragonarli con nessun‟altro

elemento, si è deciso di fare che ogni elemento determinasse da sé se un gesto semplice

stava avvenendo su di lui. Questo significa che ogni elemento deve essere in grado di

sapere se una azione è stata svolta su di esso. A questo punto si è affrontato il primo

problema: se un‟elemento è stato già inserito nello stage, bisogna prima farlo reagire agli

eventi semplici, in altre parole registrarlo come listener di questi tipi di eventi. Per fare ciò

si possono fare due cose: la prima opzione è quella di aggiungere sullo stesso elemento tutti

i listener e programmare la sua risposta agli eventi; la seconda opzione è inserire l‟elemento

come figlio di un contenitore che abbia già il comportamento desiderato. Alla fine si è

optato per la seconda opzione, poiché esiste già una classe che si comporta di questo modo.

La classe si è trovata tra uno degli esempi realizzati dalla NUI-group, ed è stata definita

come una classe astratta che quindi si può estendere per aggiungere le sue funzionalità in

una classe nuova. La nuova classe deve allora prendere l‟elemento che si vuole far

diventare interattivo ed aggiungerlo come „figlio‟, questo vuol dire che tutte le modifiche

che siano applicate sulla classe nuova saranno anche applicate a tutti gli elementi che

contiene. Questo si può vedere nella Figura 70, dove si mostra la definizione della classe

nella quale si estende la classe „RotatableScalable‟ elaborata dalla NUI-group, e si vede

anche il costruttore della classe nuova, chiamata „simpleGestObject‟.

Figura 70. Definizione della classe simpleGestObject ed il metodo costruttore


103

Nella classe si definisce una variabile „wrappedObject‟ alla quale viene assegnato

l‟elemento passato come argomento al costruttore. Dato che non si conosce a priori il tipo

di elemento passato (potrebbe essere di tipo „Sprite‟ o „MovieClip‟, per esempio), si

preferisce non definire nessun tipo: „dispObj*‟: si cambiano le coordinate dell‟elemento per

aggiungerlo come un figlio dell‟istanza della classe „simpleGestObj‟ appena creata, e al

nuovo elemento si assegnano le coordinate del figlio precedente. In questo modo nel

momento d‟inserire la nuova istanza, si troverà nella stessa posizione dove si trovava prima

l‟elemento che si vuole far diventare interattivo.

A questo punto la classe base si occupa di gestire il comportamento interattivo

dell‟elemento: registrare l‟istanza per essere notificata dagli eventi TUIO e risponde agli

spostamenti per fare vedere un trascinamento dell‟elemento. Se l‟elemento è toccato con

due dita, è possibile ruotarlo oppure cambiare le sue dimensioni. E´anche possibile passare

dei parametri booleani che permettono di controllare il modo come l‟elemento reagisce: se

si vuole che l‟elemento non possa essere rotato o scalato o spostato oppure che l‟elemento

nemmeno reagisca alle azioni dell‟utente.

Tuttavia mancano implementare i gesti semplici di „Selected‟ ed individuare bene il gesto

„TAP‟. Per gestire il gesto „Selected‟ si è utilizzato una variabile di tipo Timer, la quale si

fa partire nel momento in cui l‟utente appoggia il dito sull‟oggetto. Poi, se l‟utente alza il

dito prima che il Timer finisca il conteggio, si fa partire l‟evento del gesto TAP, se invece

l‟utente preme a lungo l‟elemento il tempo sufficente di permettere alla variabile Timer di

finire il conteggio, si fa partire l‟evento „selected‟. A questo punto, la classe fa la notifica di

tutti i gesti, però bisogna gestire i momenti quando alcuni di essi non possono essere

notificati: per esempio, se l‟elemento è stato già premuto, e lo si tocca con un secondo dito,

non si può notificare il gesto TAP per quest‟ultimo, oppure se il timer ha già finito il

conteggio, non si può di nuovo fare la notifica del TAP. Questa logica si è gestita con degli

variabile booleane che utilizzate per controllare le situazioni prima considerate.

5.2.2.3 Classe generale per rilevare i gesti: TouchGesture.as

Questa classe si occupa di rilevare tutti i gesti fatti dall‟utente determinando i momenti in

cui accade ogni gesto, se il gesto è di tipo complesso, si confronta con i template della

libreria di gesti creata precedentemente. Il costruttore si occupa di caricare la libreria di

gesti per poterla utilizzare in caso di bisogno. Così com‟è stato fatto per la classe

„GestureCreator.as‟, la classe riceve come argomento un elemento e questo viene usato

come area d‟interazione (Figura 71). Questo elemento può essere sia di tipo Sprite,

MovieClip, oppure tipo Stage.

Quindi all‟inizio del metodo si verifica se l‟elemento ricevuto è uno stage, se è così si

aggiunge un elemento tipo Sprite nella display list dello stage, la quale verrà utilizzata

come area d‟interazione; invece se l‟elemento ricevuto è diverso dello stage, sará questo


104

elemento ad essere utilizzato come area di interazione e quindi viene assegnata alla

variabile della classe che fa riferimento a questo spazio (la variabile „touchArea‟).

L‟elemento viene inserito nella posizione 3 della display List. Le posizioni precedenti

vengono occupate dal: MainTimeline, e da due elementi per il riconoscimento dei tocchi,

che vengono inserite dal metodo „TUIO.init( )‟ nel momento dell‟inizio di una

comunicazione col tracker.

Figura 71. Costruttore della classe „TouchGesture‟

Fino a questo punto c‟è un‟area dove si possono ricevere dei gesti con cui l‟applicazione

può interagire. Ora si deve gestire il rilevamento delle azioni dell‟utente per determinare se

il movimento fatto da lui è un gesto semplice, o un gesto complesso che si deve confrontare

con gli elementi del database.

Prima si è programmata la parte che si occupa dei gesti semplici. Questi tipi di gesti sono

gestiti da una delle classi create precedentemente quindi, si è creato un metodo che

implementa la classe „simpleGestObject.as‟ per creare gli elementi interattivi:


105

o makeObjInteractive(dispObj:*, rot:Boolean = true, sca:Boolean = true,

mov:Boolean = true, noSel:Boolean = true):void

Questo metodo riceve come argomenti l‟oggetto d‟interesse e delle variabili

booleane che controllano se l‟elemento può essere rotato, scalato, spostato oppure se

può essere selezionato. Nel metodo si usa una variabile interna per fare riferimento

al contenitore dell‟elemento per poter dopo aggiungerlo di nuovo sullo stesso

contenitore. Per ultimo, crea un‟istanza della classe „simpleGestObj‟ passandogli

come argomento l‟elemento che si vuole reagisca ai gesti semplici. Questa parte del

codice s‟illustra nella Figura 72.

Figura 72. Metodo della classe TouchGesture per fare che un elemento reagisca ai gesti semplici

usando la classe simpleGestObject.

Inoltre, si crea una variabile per controllare il gesto semplice „Selected‟, il quale

avviene quando l‟utente preme a lungo l‟elemento. La durata del tempo che deve

essere premuto viene controllata da una variabile di tipo Timer che si passa anche

come argomento del costruttore dell‟istanza simpleGestObject.

Con questo metodo viene gestita tutta la parte dei gesti semplici, poiché tutta la logica di

individuazione dei momenti in cui avvengono ciascuno dei gesti semplici sull‟elemento è

gestita dalla classe simpleGestObject.

Dopo di questo, bisogna individuare i gesti complessi che vengono realizzati dall‟utente.

Prima di tutto, un fattore che differenza un gesto dall‟altro è che i gesti semplici accadono

sugli elementi, mentre che i gesti complessi lo fanno sull‟area interattiva. Il momento in cui

il target dell‟evento TUIO è l‟area interattiva, è lo stesso momento in cui si deve

cominciare a memorizzare i movimenti dell‟utente. Però se si vuole che l‟applicazione sia

multitouch, si deve chiamare contemporaneamente questo metodo. Ci si può pensare ancora

di un altro modo, ogni volta l‟utente tocca l‟area interattiva, si aggiugne un elemento che si

registra come listener del movimento di quel dito e ne memorizza la sua posizione ogni

volta che il dito si sposta. Questa classe aussiliare, gestureObject.as, possiede gli stessi

metodi per la memorizzazione del gesto che si sono utilizzati per la classe GestureCreator.


106

Figura 73. Creazione delle istanze gestureObject quando l‟utente tocca l‟area interattiva

Nella Figura 73 si può vedere la parte del codice che è chiamata quando l‟utente tocca la

touchArea, si crea un‟istanza della classe aussiliare che si salva su un array locale, e si

registra per essere notificata dagli Evento TUIO per far si che l‟istanza memorizzi i

movimenti dell‟evento TUIO che l‟ha generato. Una volta che l‟utente alza il dito, si

chiama il metodo stopRecording dell‟istanza:

Figura 74. Metodo stopRecording della classe gestureObject.

Nel metodo stopRecording dell‟istanza gestureObject, si fa la notifica dell‟evento

GESTURE_END e si passa come parametro l‟identificativo del evento che ha appena

finito. In questo modo la classe TouchGesture riceve l‟evento e con l‟identificativo può

cercare l‟elemento per riperire il gesto memorizzato da essi e fare il confronto con i

template del database:

Figura 75. Metodo della clase TouchGestures che si chiama quando l‟utente a finito di fare un

gesto

Il metodo chiamato riceve un evento di tipo GestureEvent che contiene l‟identificativo del

gesto che si usa per ricuperare l‟array di punti del gesto appena memorizzato. Dopo di che


107

l‟evento fa il matching con il database ed fa la notifica di un evento di tipo COMPLEX, che

possiede il nome ed il punteggio risultati dal confronto con i template della libreria. Il

confronto è fatto da una variabile, „recognizer‟, della classe DollarRecognizer, della quale

si chiama il metodo pubblico „recognizer‟ e si passa come parametro una copia dell‟array di

punti del gesto fatto dall‟utente. Il metodo confronta il gesto con tutti gli elementi del

databse e determina il template si assomiglia di più.

5.2.2.4 Classe GestureEvent.as

Questa classe definisce le costanti che rappresentano i gesti individuati con le classi create

prima, ed possiede delle proprietà che possiedono le informazioni sugli eventi.

Le costanti sono le seguenti con le proprietà della classe che possiedono le informazioni

rispettive si elencano in seguito:

GESTO PROPRIETÀ

TAP -

SELECTED -

DRAG -

ROTATE rotValue:Number

SCALE scaleValX:Number, scaleValY:Number

COMPLEX complexGest:String

GESTURE_END gestureID

Tabella 4. Costanti e proprietà della classe GestureEvent

5.2.3 Applicazione di test per le classi dei gesti

Una volta creati le classi si sono implementati in una piccola applicazione per vedere il loro

funzionamento. Prima di tutto si è creata la libreria di template utilizzando la classe

GestureCreator. I gesti utilizzati come basi di dati sono stati i seguenti

CIRCLE SQUARE TRIANGLE SPIRAL WAVE

Dopo di che si è fatta una piccola applicazione per realizzare gesti ed interaggire con delgi

oggeti interattivi. Per i gesti si sono fatte 10 prove per ogni gesto, ogni volta che si fa un

gesto, si stampa l‟identificativo del template ed il punteggio.I risultati si riassumono nella

tabella seguente:


108

CIRCLE SQUARE TRIANGLE SPIRAL WAVE

Circle x8 Square x10 Triangle x9 Spiral x10 Wave x7

Square x2 Square x1 Square x3

Anche se i numeri di casi provati non è sufficente per fare uno giudizio giusto, si illustra

che il gesto con il quale si può più confondere è il quadratto Sicuramente facendo tante altre

prove sarà possobile assicurare qualcosa. Ma questo è solo per chiarire che ci sono ancora

cose da fare, come lavorare nella precisione del metodo di confronto.

Per provare le notifiche degli eventi semplici, si è inserito un quadratto il quale si è fatto

diventare interativo. Ed è stato possibile provare le azioni di rotazione, scalamento,

dragging e selezione e la notifica di tutti i gesti. Tutti gli eventi individuati dalla classe

TouchGesture.as. È stato possibile verificare la notifica sia dei gesti semplici sia dei gesti

complessi.

Con questo è finito lo sviluppo delle classi per individuare e riconoscere i gesti e si è

verificato la sua funzionalità per una applicazione Multitouch. Ancora si possono

migliorare molte cose, per esempio per le classi er i gesti si può migliorare la precisione

oppure la logica di programmazione per farle più efficienti; con i componenti, si possono

correggere gli errori nell‟anteprima oppure meglio, creare altri componenti. Ma con questo

lavoro

109

CONCLUSIONI

Attraverso questo lavoro sono stati sviluppati alcuni strumenti utili per la creazione di

interfacce interattive di tipo touchscreen, mirati ad essere utilizzati sia con gli schermi

touchscreen semplici che possono rilevare unicamente un oggetto sullo schermo alla volta,

sia con schermi più avanzati che riescono a rilevare più di un oggetto contemporaneamente,

noti come schermi multitouch. Anche se esistono già strumenti che permettono di lavorare

con questa tecnologia, è ancora possibile creare modi nuovi e diversi tramite cui l‟utente

può interagire con queste tipi di interfacce. Quindi lo sviluppo di strumenti che permettano

di fare questo è stato lo scopo di questo studio.

Per raggiungere l‟obiettivo di questa tesi, è stato necessario studiare la composizione di

questi sistemi. Tutti i sistemi di interfacce touchscreen devono essere composti minimo di

tre parti: un sensore, che misura i cambiamenti sullo schermo; un comparatore, che

stabilisce se i cambiamenti rilevati dal sensore sono validi o meno; ed un attuatore che in

base a cosa ha determinato il comparatore, decide come reagire al cambiamento rilevato dal

sensore. Il tipo di risposta di un‟applicazione dipende del tipo d'applicazione interattiva che

si vuole sviluppare, però le prestazioni dell'applicazione ed il grado di risposta alle azioni

dell‟utente dipendono delle capacità delle parti che lo compongono: il sensore determina le

azioni alle quali il sistema può reagire, poiché se una azione non è misurabile dal sensore,

non esiste per il sistema digitale; il grado do risposta dipende anche delle capacità del

comparatore per elaborare i dati misurati. Più informazione il comparatore è capace di

recuperare per comunicarla all'attuatore, più interattiva potrà essere l'applicazione che si

vuole sviluppare.

Quindi è stato necessario studiare le diverse parti del sistema per determinare com‟era

possibile migliorare le sue prestazioni. Il sistema con il quale si è lavorato è composto da

una parte hardware ed una parte software. L‟hardware è uno schermo tattile fatto per

misurare i cambiamenti con tecniche ottiche. Queste tecniche sono state descritte nella

sezione 1.3. Invece nella parte software si trovano sia il comparatore sia l‟attuatore del

sistema. Il comparatore è un software di tipo tracker, descritto nella sezione 1.4.1., che

individua i blob sullo schermo, e calcola ed invia le informazioni basiche dei blob rilevati

all‟attuatore. Tuttavia il sistema utilizza un insieme di classi di ActionScript 3.0, la libreria

touchlib, che elaborano i messaggi inviati dal tracker per trovare ancora più informazioni

CONCLUSIONI

110

sulle azioni dell‟utente. Per comprendere com‟è stato fatto questo bisognava studiare il

protocollo TUIO, che standardizza il tipo d‟informazione che deve essere ricavata per ogni

blob e la costruzione dei messaggi che contengono questi dati. Questo protocollo assieme

alla libreria touclib, sono stati descritti nel capitolo 2.

Quindi le classi di ActionScript sono state utilizzate per processare ancora di più le

informazioni in formato TUIO, migliorando le prestazioni del comparatore. Per usufruire

di questi dati, si utilizza un programma, Flash, che possa utilizzare AS3 per sviluppare delle

applicazioni che ne facciano utilizzo per reagire alle azioni dell‟utente. Flash è un

programma utile per creare applicazioni interattive che reagiscono agli eventi del mouse e

della tastiera. Ciononostante, non possiede strumenti giusti per la creazione di interfacce

touchscreen. Perciò uno degli scopi di questa tesi è stato sviluppare alcuni componenti di

Flash che sono in grado di reagire alle azioni fatte dall‟utente sullo schermo touchscreen.

Questi componenti sono un bottone, una barra di scorrimento, un stepper numerico e una

tastiera. Per la creazioni di essi è stato necessario studiare cosa sono i componenti, come

funzionano all‟interno del programma Flash e quale sono le loro caratteristiche.

Alcuni dei componenti sviluppati sono estensioni di componenti che si trovano in Flash,

dunque è stato necessario studiare il funzionamento dei componenti che si volevano

estendere per integrare adeguatamente le nuove funzionalità dei componenti sviluppati. A

questo scopo sono state studiate le proprietà ed i metodi di ogni componente base per

sapere quali potevano essere utilizzate nei componenti nuovi. Inoltre, per tutti i componenti

si deve conoscere il funzionamento di due elementi fondamentali: il primo è la classe

„UIComponent‟, che è una classe che possiede le proprietà ed i metodi di base per tutti i

componenti di Flash, come per esempio la proprietà „enabled‟. Tutti i componenti che si

vogliano sviluppare, quindi, devono estendere questa classe, direttamente oppure

indirettamente, estendendo altri componenti; il secondo elemento è il modello

d‟invalidazione, il quale si utilizza per gestire il modo in cui il componente reagisce a

livello visuale alle azioni dell‟utente. Per fare uso di questi elementi, sono stati

implementati dei metodi specifici, per esempio il metodo configUI oppure il metodo draw, i

quali vengono chiamati automaticamente dalla struttura dei componenti dell‟interfaccia

utente. Ciò si è fatto mentre si è fatta la logica di funzionamento del componente nella

quale si definisce la parte che interessa di più: il modo un cui il componente deve reagire

alle azioni dell‟utente sullo schermo. Poi è stato necessario creare tutti gli asset di ogni

componente ed assegnare ad ognuno di loro le impostazioni necessarie per funzionare con

la struttura a due frame con cui si devono costruire i componenti. Inoltre, se il componente

sviluppato deve notificare qualche evento particolare che contenga l‟informazione della

risposta all‟utente si deve creare una classe adatta per farlo. Finalmente si è creato

l‟elemento componentShim, che è fondamentale poiché contiene già compilate tutte le

informazioni del comportamento del componente. A questo punto, c‟era già un componente

funzionale, ma ancora è stato necessario creare un ultimo elemento, l‟anteprima, che

permette allo sviluppatore dell‟applicazione di visualizzare le modifiche fatte al

CONCLUSIONI

111

componente senza aver bisogno di eseguire il programma. Tutti questi passi sono state fatti

per ciascuno dei componenti sviluppati.

Con questo si è raggiunto il primo scopo della tesi: la creazione di componenti che si

possano utilizzare per applicazioni interattive di tipo touchscreen. Per svilupparli, quindi, è

stato necessario non solo capire il loro funzionamento, ma anche utilizzare adeguatamente

gli eventi TUIO rilevati dalla libreria touchlib, la descrizione del processo di sviluppo si è

fatta nella sezione 5.1.

A questo punto è possibile creare applicazioni interattive dove l‟utente può toccare degli

elementi sullo schermo e ricevere una risposta, ma questo non è l‟unico modo in cui

l‟utente può interagire con le interfacce touchscreen, perciò si sono studiati i gesti (capitolo

4), insieme ad un algoritmo adatto per il loro riconoscimento. Per permettere all‟utente di

interagire con il sistema per mezzo dei gesti, semplici o complessi, si sono creati delle

classi apposite che estendono ancora di più le funzioni del comparatore. Nel sistema con il

quale si è lavorato in questa tesi, il comparatore riusciva a rilevare unicamente gli eventi

TUIO ma, utilizzando le classi create, è ora possibile rilevare quando l‟utente fa gesti

semplici o complessi. Per i gesti semplici o standard, tipo „drag‟ o „rotate‟, si è creata una

classe che riceve un elemento che si può visualizzare nello schermo, tipo Sprite o

MovieClip, e lo fa diventare interattivo. Le classi create anche permettono al sistema di

essere in grado di rilevare quando l‟utente fa altri gesti che non hanno una definizione

univoca, ma per riconoscerli bisogna far uso di una libreria di template, caricata da un file

esterno, con la quale si possono confrontare per sapere se i gesti sono validi o no. Anche se

gli elementi di questo database saranno diversi per ogni applicazione, comunque il sistema

deve essere in grado di rilevare il gesto, perciò si una delle classi create implementa dei

metodi che permettono di memorizzare il movimento di ogni dito che l‟utente appoggia

sullo schermo e ne registra il suo movimento. Questa caratteristica fa di questa classe uno

strumento adatto per il suo uso in applicazioni multitouch. Alla fine si è creata una classe

generale che utilizza tutte le due classi create prima, per poter gestire con un‟unica classe

l‟interazione con l‟utente. In questa classe si sono state definite dei metodi che si occupano

di gestire la creazioni di elementi interattivi così come di confrontare i gesti rilevati con gli

elementi del database. Per provare le prestazioni di queste classi, si è sviluppata una piccola

applicazione che permette di registrare un insieme di gesti e generare in formato XML le

informazioni dei gesti che si vogliono utilizzare come template, per poi creare facilmente

un file che si possa utilizzare come il database di template.

Nel processo di sviluppo è stato necessario utilizzare altre classi creati da altri

programmatori, come per esempio le classi che implementano l‟algoritmo di

riconoscimento, e quindi è stato necessario studiare le loro funzioni per riuscire ad

utilizzare adeguatamente i loro metodi. Con questo è stato possibile raggiungere l‟altro

obiettivo di questo studio: creare uno strumento che permetta di arricchire il modo in cui le

interfacce touchscreen, e in questo caso anche le interfacce multitouch, possono reagire alle

azioni degli utenti.

CONCLUSIONI

112

Da questo punto è possibile migliorare ancora molte delle funzioni degli strumenti

sviluppati nel presente lavoro. Per esempio, si sono rilevati alcuni errori negli elementi di

anteprima di alcuni componenti, e ciò possibilmente è dovuto ad alcune incompatibilità tra

le versioni dei programmi utilizzati: i componenti sono stati sviluppati in una versione

precedente a quella utilizzata nel sistema touchscreen. Chiaramente è possibile creare

ancora molti altri componenti che possano essere utilizzati in questo tipo di interfacce.

Invece dalla parte delle classi per il rilevamento dei gesti, è possibile migliorare la

precisione di rilevamento del gesto. Questo è molto importante poiché esistono alcuni gesti

che nel processo di normalizzazione per poter confrontarlo con i template, cambiano un

po‟. Per esempio, si è rilevato che con un gesto come fare una riga c‟erano dei problemi per

rilevarla come tale. Questo problema è legato all‟algoritmo utilizzato e quindi è possibile

migliorare questi aspetti utilizzando altri algoritmi più robusti.

Gli elementi sviluppati in questa tesi sono stati creati in modo tale da reagire

individualmente ad un gesto fatto dall‟utente sullo schermo. In questo modo è possibile

utilizzare questi strumenti sia per interfacce touchscreen normali sia per interfacce

multitouch. Deve essere chiaro che questi elementi sono basati su tecniche di rilevamento

ottiche e perciò non vuol dire che non ci siano altre metodi basate su altre tecniche e

tecnologie che riescano a fare le stesse funzioni in un modo migliore o peggiore, ma

l‟utilizzo di questa tecnologia permette di fare un‟implementazione non costosa di

un‟interfaccia touchscreen, e ciò permetterebbe di utilizzare questo tipo di sistemi in molte

situazioni quando non si ha accesso a tecnologie più costose. Una cosa è certa, comunque:

l‟uso delle interfacce gestuali ogni volta sarà più diffuso, così come si può evidenziare in

tanti dispositivi che ne fanno uso ora, e la loro implementazione in tanti ambienti diversi

implicherà la creazione di nuovi modi d‟interazione con l‟utente, e perciò lo sviluppo di

strumenti adatti sarà sempre necessario.

113

BIBLIOGRAFIA - Adobe Documentation – “Programming ActionScript 3.0” – Adobe Systems

Incorporated , 2007, United States of America.

- Baxter, L. K. - “Capacitive Sensors: Design and applications” - John Wiley &

Sons, 1997, Piscataway, NJ,United States of America

- De Donatis, A. - “Advanced ActionScript Components: Mastering the Flash

component Architecture” – Friends of Ed, 2006, United States of America.

- Henderson, H. – “Encyclopedia of Computer Science and Technology” – Seconda

Edizione, Infobase Publishing, 2009, New York, United States of America.

- Kaltenbrunner, M. & Bovermann, T. & Bencina, R. & Costanza, E. - "TUIO - A

Protocol for Table-Top Tangible User Interfaces" - Proceedings of the 6th

International Workshop on Gesture in Human-Computer Interaction and Simulation

(GW 2005), Vannes, France.

- NUI Group Authors - “Multitouch Technologies” - NUI Group, Prima edizione,

Community Release: Maggio 2009.

- Richardson, D. & Milbourne, P. – “Foundation ActionScript 3.0 for Flash and

Flex” – Friends of Ed, 2009, United States of America.

- Saffer, S. - “Designing Gestural Interfaces”- O‟Reilly, November, 2008, Canada.

- Stumpe, B. - “A new principle for an X-Y Touch Screen” - CERN, Marzo 16, 1977.

Reperibile nel sito <http://cdsweb.cern.ch/record/1266588/files/StumpeMar77.pdf>

- Webster, S. & Yard, T. & McSharry, S. – “Foundation ActionScript 3.0 with Flash

CS3 and Flex” – Friends of Ed, 2008, United States of America.

http://www.google.com/search?tbs=bks:1&tbo=p&q=+inauthor:%22Larry+K.+Baxter%22

http://cdsweb.cern.ch/record/1266588/files/StumpeMar77.pdf

Bibliografia

114

- Wobbrok, J. & Wilson, A. & Li, Y. –“Gestures without libraries, toolkits or

training: a $1 Recognizer for user Interface prototypes”, 2007, Newport, Rhode

Island, United States of America.

Reperibile nel sito <http://faculty.washington.edu/wobbrock/pubs/uist-07.1.pdf>

- Wollin, A. & Eoff, B. &Hammond, T. – “Short straw: A simple and effective corner

finder for polylines” – Dipartamento di Computer Science dell‟universtià di Texas

A&M, 2008.

Reperibile nel sito <http://srlweb.cs.tamu.edu/srlng_media/content/objects/object-

1246294647-350817e4b0870da27e16472ed36475db/Wolin_SBIM08.pdf>

WEB-SITES

- Adobe - “ActionScript 3.0 Language and Components reference: Statements,

keywords and directives”.

<http://www.adobe.com/livedocs/flash/9.0/ActionScriptLangRefV3/statements.html

> [citato: 09 Ottobre, 2010]

- Apple – “Press Release Library” <http://www.apple.com/pr/library/> [citato: 21

ottobre, 2010]

- Betriebsraum weblog. Rich internet applications, SW Development, Human-

Computer Interaction – “Efficient Gesture recognition and corner finding in AS3”,

Giulio 19, 2009. <http://www.betriebsraum.de/blog/2009/07/21/efficient-gesture-

recognition-and-corner-finding-in-as3/> [citato: 10 ottobre,2010]

- Hugh Le Cain “ELECTRONIC SACKBUT”, Gayle, Y. , 1999

<http://www.hughlecaine.com/en/sackbut.html> [citato: 21 Ottobre,2010]

- Kamerer, J. “Creating ActionScript 3.0 components in Flash”, Adobe Developer

Connection, Flash Developer Center.

<http://www.adobe.com/devnet/flash/articles/creating_as3_components.html>

[Citato: 9 Ottobre, 2010]

- Physics Department, Boston University , “Total Internal reflection and lenses”

<http://physics.bu.edu/~duffy/py106/Lenses.html> [citato: 14 Settembre, 2010]

http://faculty.washington.edu/wobbrock/pubs/uist-07.1.pdf





http://www.apple.com/pr/library/



http://www.hughlecaine.com/en/sackbut.html

http://www.adobe.com/devnet/flash/articles/creating_as3_components.html

http://physics.bu.edu/~duffy/py106/Lenses.html

Bibliografia

115

- R-Blank, “ActionScript 3 Display List Event Flow” -

<http://www.rblank.com/2009/11/02/actionscript-3-display-list-event-flow/>

[citato:23 Settembre, 2010]

- ResistiveTouchScreens.org <http://resistivetouchscreen.org/> [citato: 20 Ottobre,

2010]

- Stumpe, B. & Sutton, C. “The first capacitative touch screens at CERN”, CERN,

Marzo 31, 2010, <<http://cerncourier.com/cws/article/cern/42092>> [citato: 15

Ottobre, 2010]

- Synaptics, “Synaptics and Pilotfish collaborate to develop next generation mobile

phone concept” Press Release, August 21st of 2006

<http://www.synaptics.com/about/press/press-releases/synaptics-and-pilotfish-

collaborate-develop-next-generation-mobile-phone-> [citato: 12 Settembre, 2010]

- Touchlib , NUIGroup, <http://nuigroup.com/touchlib/>

http://www.rblank.com/2009/11/02/actionscript-3-display-list-event-flow/

http://resistivetouchscreen.org/

http://cerncourier.com/cws/article/cern/42092



http://nuigroup.com/touchlib/

116

ALLEGATO A

DOCUMENTAZIONE DELLE CLASSI TUIO DELLA LIBRERIA TOUCHLIB DELLA

NUI GROUP

//------------------------------------------------------------------------------------------------------------

TUIO.as

La classe principale che fa il collegamento con il tracker e processa i messaggi ricevuti con

le informazioni sui blob rilevati dal tracker.

Proprietà

static var FLOSCSocket:XMLSocket;

static var FLOSCSocketHost:String;

static var FLOSCSocketPort:Number;

: Insieme di variabili utilizzate per fare la connessione

con il server. Nella NUI Group, questo collegamento si fa con

il tracker CCV che invia i messaggi con le informazioni dei

blob individuati.

static var thestage:Stage;

: Variabile che si utilizza per avere una riferenza interna

allo stage del progetto con cui si sta lavorando.

static var objectArray:Array;

: Vettore che contiene gli oggetti che contengono le

informazioni dei blob individuati dal sensore. Questi oggetti

sono della classe TUIOObject.

public static var debugMode:Boolean;

: variabile Booleana utilizzata per attivare la funzione di

debug delle classi. In questo modo vengono visualizzati la

Allegato A

117

posizione dei blob rilevati e l‟identificativo assegnato a

ciascuno di loro.

static var debugText:TextField;

static var debugToggle:TextField;

: Queste due variabili vengono usate nel modo debug,

per mostrare le informazioni pertinenti.

static var recordedXML:XML;

: Questa variabile è utilizzata per salvare l‟informazione

inviata nel messaggio dal tracker

static var bRecording:Boolean = false;

: Questa variabile si usa internamente per sapere se si

sta facendo il debug, valore = false, oppure se si stanno

ricevendo i messaggi dal tracker, valore = true.

static var xmlPlaybackURL:String = "";

static var xmlPlaybackLoader:URLLoader;

static var playbackXML:XML;

: variabili utilizzate per caricare un file XML con dei

dati precedentemente registrati. Si usano per fare il debug

della libreria.

static var bInitialized = false;

: Variabile Boolean ache si utilizza per sapere se il

collegamento con il tracker è stata fatta precedentemente, Il

suo valore cambia a „true‟ una volta si fa il collegamento.

Metodi

- init() public static function init (s:DisplayObjectContainer, host:String, port:Number,

debugXMLFile:String, dbug:Boolean = true):void

- Inizializza le variabili e fa la connessione con il server.

- Se il parametro 'dbug' è 'true', aggiunge il campo di testo dove è possibile vedere le

posizione e l'ID di ogni cursore. Crea un bottone nell'angolo superiore sinistro che

serve per cambiare il modo debug

- Inizializza una variabile XML, 'recordedXML', con i tag

<OSCPackets></OSCPackets>.

Allegato A

118

- xmlPlaybackloaded() private static function xmlPlaybackLoaded(evt:event):void

- crea una variabile xml, playbackXML con l'informazione dentro

xmlPlaybackLoaded.Questo metodo si utilizza per fare il DEBUG della libreria

- frameUpdate() private static function frameUpdate(evt:Event):void

- Se la variabile playbackXML non è vuota, invia l'informazione su

playbackXML.OSCPACKET[0] sulla funzione "processMessage()" utilizzato per il

debug della libreria

- getObjectById() public static function getObjectById(id:Number):TUIOObject

- Scorre l'array dei blob rilevati e ritorna l'ogetto con l‟identificativo richiesto.

- listenForObject() public static function listenForObject(id:Number, receiver:Object):void

- Registra l'oggetto, receiver, come un listener degli eventi del blob identificato con

l‟identificativo, id.

- processMessage() public static function processMessage(msg:XML):void

- Questo metodo si occupa di prendere l‟informazione ricevuta dal tracker e salvare

i dati nelle variabile locali.

- Determina quali oggetti sono stati appena rilevati, quali c‟erano già prima e quali

blob non ci sono più sullo schermo

- Per gli oggetti nuovi, crea una nuova istanza di TUIOObject, prende i dati e li

salva nelle variabili locali, aggiunge l‟oggetto sullo stage e lo inserisci nell'array di

blobs. Invece se l'oggetto c'era prima, si aggiornano i suoi dati e si fa la notifica

dell'evento TUIO_MOVE.

- toggleDebug() private static function toggleDebug(e:Event):void

- Il metodo che viene chiamato ogni volta che si clicca il tasto inserito nellángolo

superiore. Fa toggle del valore de la variabile 'debugMode' a 'true o 'false'.

Allegato A

119

- dataHandler() private static function dataHandler(event:Event):void

- Questo metodo si chiama ogni voltache si riceve un messaggio dal tracker

- se la variabile 'bRecording' è 'true', copia l'informazione dell'evento sulla variabile

recordedXML

- chiama il metodo processMessage() passando come argomento il messaggio

appena ricevuto

//------------------------------------------------------------------------------------------------------------

TUIOCursor.as

extends Sprite

Questa classe crea il marcatore sullo schermo che indica la posizione rilevata.

- TUIOCursor() Constructor

public function TUIOCursor(debugText:String):void

- crea un cerchio (pallina rosa) che è posizionato nelle coordinate dell'input rilevato.

- se la stringa ricevuta è diversa di null e non è vuota, aggiunge il testo, debugText,

in una posizione vicina al cursore. debugText contiene l‟identificatore del cursore.

//------------------------------------------------------------------------------------------------------------

TUIOEvent.as

extends Event

Questa classe definisce i nomi degli eventi come TUIO ed i parametri di posizione, di ID e

l'oggetto relativo all'evento.

Eventi

TUIO_MOVE

TUIO_DOWN

TUIO_CLICK

TUIO_UP

TUIO_OVER

TUIO_OUT

Allegato A

120

Proprietà

public var TUIOClass:String;

: Contiene la classe dell‟oggetto TUIO

public var sID:int;

: Contiene l‟identificativo della sessione di

rilevamentodel tracker.

public var ID:int;

: Contiene l‟identificativo dell‟oggetto che fa la

notifica dell‟evento.

public var angle:Number;

: Il valore dell‟angolo dell‟oggetto.

public var stageX:Number;

public var stageY:Number;

: Le coordinate globali dell‟evento.

public var localX:Number;

public var localY:Number;

: Le coordinate locali dell‟evento.

public var oldX:Number;

public var oldY:Number;

: le coordinate iniziali dell‟oggetto chef a la

notifica dell‟evento

public var buttonDown:Boolean;

public var relatedObject:DisplayObject;

: Contiene il marcatore, TUIOCursor, usato per

indicare la posizione dove si è rilevato il contatto del

oggetto con lo schermo.

Metodo

- TUIOEvent() Constructor

public function TUIOEvent(type:String, bubbles:Boolean = false, cancelable:Boolean =

false, stageX:Number = 0, stageY:Number = 0, localX:Number = 0, localY:Number = 0,

oldX:Number = 0, oldY:Number = 0, relatedObject:DisplayObject = null, ctrlKey:Boolean

= false, altKey:Boolean = false, shiftKey:Boolean = false, buttonDown:Boolean = false,

delta:int = 0, TUIOClass:String = "2Dcur", ID:int = -1, sID:int = -1, angle:Number = 0.0)

Allegato A

121

Questo metodo riceve i parametri e li salva nelle variabili locali. Dopo di che chiama il

metodo super();

//------------------------------------------------------------------------------------------------------------

TUIOObject.as

Contiene l'informazione dell'oggetto rilevato (cursore, blob). Informazione come posizione,

velocitá, accelerazione, ID della sessione, ecc..

Proprietà

x:Number;

y:Number; : Coordinate globali dell‟oggetto

oldX:Number;

oldY:Number; : Coordinate del primo punto dove si è rilevato l‟oggetto

dX:Number;

dY:Number; : Valori calcolati della velocità nella direzione X e Y

area:Number; : Valore dell‟area dell‟oggetto rilevato.

TUIOClass:String; : Variabile che contiene la classe dell‟oggetto

sID:int; : Variabile con l‟identificatico della session.

ID:int : Variabile con l‟identificativo dell‟oggetto rilevato

angle:Number; : Variabile con il valore dell‟angolo.

pressure:Number; : Variabile utilizzata per salvare un valore di pressione

dell‟oggetto.

isNew:Boolean; (private) : Variabile per indicare se l‟oggetto è stato appena creao

isAlive:Boolean; : Variabile utilizzata per indicare la presenza

dell‟oggetto sullo schermo. È´true, finche l‟oggetto ci sia sullo

schermo.

Allegato A

122

obj; : Variabile con cui fa riferimento all‟oggetto su cui è

stato rilevato il blob.

spr:Sprite; : Variabile utilizzata per fare riferimneto all‟oggetto

utilizzato come marcatore

trlx:Sprite;

color:int;

aListeners:Array; : Array con tutti gli oggetti che son ostati registrati

come listeners dell‟oggetto TUIO

Metodi

- TUIOObject() Constructor

public function TUIOObject(cls:String, id:int, px:Number, py:Number, dx:Number,

dy:Number, sid:int = -1, ang:Number = 0, o = null):void

- Riceve i valori trovati nel messaggio inviato dal tracker e li salva nelle variabile

locali.

- si crea un cursore della classe TUIOCursor e si alloca nella posizione ('px', 'py').

- notifyCreated() public function notifyCreated():void

- Fa la notifica degli eventi TUIO_DOWN e TUIO_OVER.

- setObjOver() public function setObjOver(o:DisplayObject):void

- Il metodo si occupa di determinare quando il cursore si trova sopra di un altro

oggetto, nel caso si fa il dispatch dell‟evento: TUIO_OVER.

- Se l‟oggetto che aveva como riferimento è diverso all‟oggetto appena ricevuto, si

fa la notifica dell‟evento: TUIO_OUT dal oggetto che aveva il riferimento. Dopo di

che, se l‟ggetto ricevuto è diverso di null, si fa la notifica dell‟evento:

TUIO_OVER, e si assegna come il nuovo oggetto di riferimento.

- addListener() public function addListener(receiver:Object):void

- aggiunge l‟elemento che riceve come argomento e lo aggiunge nell‟array di

elementi che devono essere notificati dagli eventi dell‟oggetto.

Allegato A

123

- removeListener()

public function removeListener(receiver:Object):void

- rimuove l'oggetto appena ricevuto dall'array di listeners.

- kill() public function kill():void

- La funzione viene chiamata per rimuovere un TUIOObject dallo schermo.

- Se l‟oggetto si trovava sopra di un‟elemento del display, si fa la notifica degli

eventi: TUIO_OUT e TUIO_UP. Dopo di che fa la notifica dell‟evento TUIO_UP a

tutti gli elementi che si erano registrati per essere notificati dagli eventi di quest

ooggetto.

- poi, per tutti gli oggetti nell array 'aListeners' fa il dispatch dell'evento: TUIO_UP.

- notifyMoved()

publc function notifyMoved():void

- Fa la notifica dell‟evento TUIO_MOVE, per tutti gli elementi che si sono registrati

per essere notificati degli eventi di questa classe

Documents

Tesi di Laurea Magistrale - Javeriana