Eötvös Loránd Tudományegyetem Informatikai Kar Média- és Oktatásinformatika Tanszék Meseszerkesztő Flash technológióval, multitouch használatával Szakdolgozat Készítette: Szabadszállási József Programtervező informatikus BSc szak Témavezető: Dr. Turcsányiné Szabó Márta, egyetemi docens Budapest, 2011. A projekt az Európai Unió támogatásával és az Európai Szociális Alap társfinanszírozásával valósul meg, a támogatási szerződés száma TÁMOP 4.2.1./B- 09/1/KMR-2010-0003. 1
Tartalomjegyzék 1 Bevezető... 4 1.1 A tabletek megjelenése... 4 1.2 Az érintésérzékeny mobileszközök elterjedése... 4 1.3 A szakdolgozat témája, célcsoport... 6 2 Felhasználói dokumentáció... 7 2.1 Általánosan az Adobe Air-ről.... 7 2.2 A program telepítése, rendszerkövetelmények, frissítés... 8 2.3 A program felépítése, használata... 9 2.4 Hol találhatóak az elmentett projektek?... 11 2.5 Óvodai látogatások tapasztalatai, menetközbeni módosítások... 12 3 Fejlesztési dokumentáció... 14 3.1 A fejlesztőkörnyezet telepítése, beállítása, a projekt megnyitása... 14 3.2 Android, ios, asztali környezetben tesztelés, futtatás előfeltételei... 15 3.3 MVC(S) Model View Controller (Service)... 17 3.4 Az projekt részei, az MVC adaptálása... 17 3.5 A program és a projektek adatainak logikai és fizikai felépítése... 18 3.6 Nézetek... 20 3.7 Controller... Hiba! A könyvjelző nem létezik. 3.8 Model... 22 3.9 A program indulása, inicializálás... 22 3.10 Multitouch lehetőségek a Flash platformon... 23 3.11 Konkrét touch megvalósítás, a TouchManager osztály... 25 3.12 Külső komponensek, képek kezelése... 27 3.13 Tesztelési esetek... 28 3.13.1 A fehér doboz tesztelés... 28 3.13.2 Fekete doboz tesztelés... 31 3.14 Optimalizáció... 31 3.14.1 Array, Vector típusok... 32 3.14.2 MovieClip, Sprite, Bitmap... 32 2
3.14.3 Átméretezés, forgatás... 32 3.14.4 MouseEvent, TouchEvent... 33 3.14.5 Memóriakezelés, nem használt objektumok törlése... 33 3.15 Továbbfejlesztési lehetőségek... 33 4 Felhasznált irodalom... 35 Mellékletek... 36 3
1 Bevezető A szakdolgozatom témája egy meseszerkesztő alkalmazás óvódás korú gyerekeknek, érintés érzékeny számítógépeken. Azért választottam ezt a technológiát, mert érdekelt az új beviteli lehetőség, ami segítségével egér és billentyűzet nélkül tudunk rajzolni, műveleteket végezni a kijelzőn közvetlenül. A célcsoport, és a téma kiválasztásánál az motivált, hogy minél könnyebb, egyértelműbb felületet tervezzek, ami könnyen megvalósítható, és a gyerekekkel közvetlenül tesztelhető. A következőkben bemutatom az érintés érzékeny eszközök fejlődését, és azokat az eszközöket, amiket a program írása közben használtam. 1.1 A tabletek megjelenése 2002-ben jelentette be a Microsoft az első tablet-et 1, melynek fő beviteli eszköze maga az érintésérzékeny monitor volt, azonban kezelése nehézkes volt. Főleg tollal való használatra tervezték, és bár írásfelismerést tartalmazott (kizárólag a tollal működött), ez nem működött tökéletesen, ugyanis nem ért fel a gépelés sebességével. A másik komoly probléma az volt, hogy a hírekkel ellentétben egyáltalán nem volt könnyen hordozható. 2006-ban egy új kategória, az UMPC 2 jelent meg, mely a hordozhatóságot tartotta szem előtt. Kisebb méretű, könnyebb készülékek voltak, de nem igazán terjedtek el széles körben. Operációs rendszernek legtöbbször Windows XP 3, illetve valamilyen lebutított speciális formáját alkalmazták, melyek sebessége nem volt felhasználóbarát, azon túl, hogy az akkumulátort sem igazán kímélte. 1.2 Az érintés érzékeny mobileszközök elterjedése Az Apple 2007 januárjában jelentette be az iphone-t 4, mely forradalmasította a mobiltelefonról alkotott képünket. Előtte különálló gombokkal vezéreltük a telefont, majd speciálisan kialakított ceruzával tudtunk interakcióba lépni vele. Az iphone kifejezetten az ujjal való használatra lett tervezve, ezért nagyon jó tulajdonságokkal 1 http://www.microsoft.com/presspass/press/2002/jun02/06-25techxumbrellapr.mspx, letöltés ideje: 2011.04.28. 10:30 2 Ultra Mobile PC - http://www.umpc.com/history-definitions.html, letöltés ideje: 2011.04.28. 10:30 3 http://www.microsoft.com/hun/windows/products/windowsxp/default.mspx 4 http://www.apple.com/iphone/ 4
rendelkező kapacitív beviteli felületet kapott, ami lehetővé teszi a többujjas érintés érzékelését is. A készülék hardveres adottságai mellett az Apple olyan bevitel módszereket fejlesztett ki (pl: két ujjal nagyítás, kicsinyítés, görgetés, lapozás), melyek ipari szabvánnyá nőtték ki magukat, elsajátításuk annyira természetes, hogy ma már el sem tudunk képzelni nélkülük okostelefont. Az Apple 2010 tavaszán jelentette be az ipad-et 5, mely rövid idő alatt teljesen megváltoztatta a tabletekről alkotott képünket. Az addigi nehézkes, tollal való irányítást az iphone-ból ismert, jól működő, könnyen elsajátítható érintésérzékelés váltotta fel, mely szükségtelenné tette a kiegészítő tollat. Továbbá az Apple operációs rendszer terén is szakított azzal a hagyománnyal, hogy teljes értékű, vagy az ismert asztali gépeken használt Mac OS X 6 egy speciális lebutított verzióját adta az eszközhöz, hanem az iphone-ból jól ismert iphone OS-t 7 használta, mely a sebesség és az akkumulátor idejét tekintve is a legjobb döntésnek bizonyult. Az iphone OS-nek egy komoly ellenfele akadt, a 2008 őszén megjelent Android 8, mely teljesen nyílt forráskódú, Linuxra 9 épül. Kifejezetten mobil eszközökre fejlesztették, mely jelenleg a 2.3 (GingerBread), és a 3.0 (HoneyComb) verziónál tart, melyek között a legnagyobb különbség, hogy a 3-as sorszámú verziókat már tabletekre optimalizálták. Az első Androidos tablet-et a Samsung jelentette meg Galaxy Tab 10 néven az ipad sikerét látván 2010 őszén. Attól eltérően csak 7-inch-es kijelzővel rendelkezett, de ugyanúgy ujjal való vezérlést tett lehetővé. Bár lassabb, mint az ipad, de két beépített kamerával rendelkezik. Emellett az is mellette szól, hogy könnyebb rá fejleszteni, hisz egy kattintással ki tudjuk próbálni az eszközön a programunkat, míg az ipad-en sokkal több lépcsőből áll, míg a tesztelni kívánt programot ki tudjuk próbálni az eszközön. A tabletek igazi elterjedése az ipad és a Galaxy Tab megjelenésével kezdődött. Sok más gyártó, látván a tabletek sikerét, saját készüléket jelentett be, az Apple elkészítette az ipad 2-t, a Samsung pedig a nyár folyamán jelenteti meg az új Galaxy Tabot, melyekben közös, hogy most már duplamagos processzort tartalmaznak, ezért sokkal gyorsabbak elődeiknél, emelett az ipad 2 is 2 kamerával rendelkezik. 5 http://www.engadget.com/2010/01/27/the-apple-ipad/, letöltés ideje: 2011.04.28. 10:30 6 http://www.apple.com/hu/macosx/ 7 http://www.apple.com/ios/ 8 http://www.android.com/ 9 http://www.linux.com/ 10 http://www.samsung.com/global/microsite/galaxytab/ 5
1.3 A szakdolgozat témája, célcsoport Szakdolgozatomban a kézzel vezérelhető eszközökre készítettem egy programot, mellyel meséket szerkeszthetnek az óvodáskorú gyermekek. A téma választásában Turcsányi-Szabó Márta tanárnő a Team labor 11 vezetője segített, aki már sok éves tapasztalattal rendelkezik a jelenleg TeaMeseszerkeszto 12 program használatával kapcsolatban, amely látványos, játékos formában segíti a gyermekek fejlődését. Célom egy olyan program létrehozása, melyen keresztül a gyermekek az egér mellőzésével, az új érintésalapú technológia használatával tudnak rajzolni, meséket szerkeszteni. Ezáltal megvizsgálhatjuk a fiatal generáció és az érintés érzékeny technológia kapcsolatát, előnyeit, korlátait, hisz náluk még nem teljesen alakult ki a számítógépek kezelése, és az ujjal való vezérlés segítségével sokkal könnyebben ismerkednek meg a számítástechnikával. A projekt az Interaktív media óra keretein belül, a T@T labor részeként készült el. Az órán előadtam a program előzetes tervét, majd a projektben résztvevőkkel folyamatosan konzultáltunk a funkciókról, a lehetséges fejlesztésekről és hibákról. Ez nagyon fontos volt a program fejlesztésében, hisz a célkorosztály nagyon fiatal, őket nagyon nehéz lenne bevonni a fejlesztésbe. A konzultációban részt vevők ezen a területen dolgozó szakemberek: Polgár Péter, ergonómia; Pásztor Andrea, interaktív felhasználói felületek gyermekeknek és Pasaréti Otília a digitális narratívák területén doktorál. Ezen személyek nagyon sok tapasztalattal rendelkeznek az óvodás gyermekek szokásainak, viselkedésének ismeretében, viszont rajtuk kívül nagyon fontos visszajelzést adott az óvónők és a gyermekek véleménye is. Többször is kísérleteztünk az óvodában a gyermekekkel, és tapasztalataink átbeszélése után folyamatosan változott a program működése, és (ami a gyermekeknek legjobban tetszett), maga a felület is. 11 http://teamlabor.inf.elte.hu/ 12 http://teamese.inf.elte.hu/index.htm 6
2 Felhasználói dokumentáció Ebben a fejezetben található, hogyan kell a programot, illetve a program futtatókörnyezetét telepíteni. A program használatát részletesen, ábrákkal illusztráltam, a könnyeb érthetőség kedvéért. 2.1 Általánosan az Adobe Air-ről Az Adobe 2007 tavaszán jelentette be az AIR 13 1.0 béta változatát, mellyel a már meglévő Flash, Html, Javascript-ben kódolt internet alapú programokat lehetett futtatni böngészőn kívül, a felhasználó számítógépén, a program jelenleg a 2.7-es verziónál tart. Mivel az AIR az asztali környezetre pozícionált szoftver, ez előnyökkel és hátrányokkal is jár. Egy böngésző alapú programot nem kell telepíteni, bárhonnan elérhető, ezzel szemben az AIR szoftvereket a felhasználónak a gépre kell telepítenie (ez főleg akkor jelent problémát, ha nincs adminisztrátor joga). Másrészről a böngészőben megjelenített alkalmazással szemben itt az alkalmazást be kell csomagolni (apk - air package), digitálisan alá kell írni. Az előnyei között az egyik legfontosabb, hogy hozzáfér a háttértárhoz, file rendszerhez, miközben a böngészőben nagyon limitált, hogy hogyan tudunk adatokat tárolni, megnyitni. Ez az esetek többségében távoli szerveren történik, míg az AIR-ben sokkal rugalmasabb az adatelérés, nem kell hozzá folyamatos internet kapcsolat, mely nagy előnyt jelent a mai mobil korszakban, ahol az internet nem mindenhol elérhető, de szeretnénk a programjainkat mindenhol használni. Fejlesztői szempontból az AIR az első igazi multiplatform rendszer, mivel az asztali rendszereken túl ma már több mobilra, táblagépre és most már TV-kre is írhatunk alkalmazásokat. Minden esetben ugyanazt a nyelvet, az Actionscript 3-at 14 használjuk, ahogy Flash-ben is, kiegészítve bizonyos AIR specifikus könyvtárakkal, mely nagyban megkönnyíti a fejlesztést, és lehetővé teszi, hogy gyakorlatilag a logikai réteg minden esetben ugyanaz maradjon, csak a nézetek változzanak, ezáltal a fejlesztési idő is a töredékére csökken. Az asztali környezetben Windows, Linux, OSX, a mobil platformon Android, OSX, Blackbery, a TV-n pedig a Samsung teszi lehetővé a futtatást. A fejlesztőkörnyezethez 13 http://www.adobe.com/hu/products/air/ 14 http://www.adobe.com/devnet/actionscript/articles/actionscript3_overview.html 7
az AIR SDK-ra 15 van szükség, melyet az Adobe honlapjáról le lehet tölteni. Többféle program közül választhatunk, ha fejleszteni szeretnék, Adobe DreamWeaver 16, Adobe Flash Builder 17, Adobe Flash CS5 18, vagy az Adobe Flex SDK 19, útobbi teljesen ingyenes. További információt az Adobe honlapján lehet elérni: (http://www.adobe.com/devnet/air.html). 2.2 A program telepítése, rendszerkövetelmények, frissítés Az Air futtatókörnyezet asztali környezetben Windows Xp, Windows 7 20, Mac OS X és Linux operációs rendszer alatt fut, a pontosabb specifikációt a http://www.adobe.com/products/air/systemreqs/ címen lehet elolvasni. A futtatókörnyezetet a http://get.adobe.com/air/ címről kell letölteni, majd telepíteni a gépre. AZ ADOBE AIR TELEPÍTŐ ABLAKA Android alapú telefonokon/tableteken legalább 2.2-es verzió kell, és kellően erős hardver (pontosabb specifikáció a fenti címen érhető el). A letöltéshez az Android Market-et használjuk, ahol az Adobe Air kulcsszóra keresve telepíthetjük a szoftvert. 15 http://www.adobe.com/products/air/sdk/ 16 http://www.adobe.com/products/dreamweaver.html 17 http://www.adobe.com/products/flash-builder.html 18 http://www.adobe.com/products/flash.html 19 http://www.adobe.com/products/flex/ 20 http://windows.microsoft.com/hu-hu/windows7/products/home 8
ios-en, az Air-t nem kell telepíteni, hisz a program magában tartalmazza a futtatókörnyezetet, viszont a program egyelőre csak a fejlesztésben résztvevő készülékre telepíthető, hisz az Apple nem engedélyezi, hogy az itunes-on 21 kívülről telepítsünk programot. Miután az Air Runtime-ot sikerült telepíteni, az internetről letöltve a meseszerkeszto.air telepíthető, Androidon ez a file apk -ra végződik, mivel egy szabványos Androidos csomag. Asztali környezetben a program rendelkezik egy automatikus frissítéssel, ami ha van internetelérés, ellenőrzi van-e újabb verzió, és ha igen, akkor megkérdezi, hogy telepítse-e. 2.3 A program felépítése, használata A program két fő részből épül fel, az eszköztárból és a fő nézetből. Az eszköztáron lévő ikonok, és funkciójuk attól függően változnak, hogy melyik nézetet látjuk. A program a kezdőképernyővel indul (1. számú melléklet), ahol két ikon található, az elsővel új projektet tudunk létrehozni, a második pedig már létező projektek megnyitására szolgál. Itt nincs jelen az eszköztár, hisz nincs más funkció, amely itt elérhető a két ikonon kívül. Az új ikon kiválasztásával egyből a meseszerkesztő nézethez jutunk, ahol egy rajzlapot látunk. Itt több lapot is hozzá tudunk adni, navigálhatunk a lapok között, illetve a megrajzolt figurákat tudjuk mozgatni, forgatni és a méretüket változtatni. A bal és a jobb oldalon található nyilakkal balra illetve jobbra léphetünk a lapok között. Amennyiben nincs jobbra több lap, automatikusan létrejön egy új. Az eszköztár itt már elérhető, és tartalmaz egy vissza gombot (mely minden más nézeten is megtalálható), ebben az esetben a kezdő képernyőre visz vissza. Ezután található a rajz ikon, mellyel új rajzokat tudunk létrehozni a rajzlap nézeten. 21 http://www.apple.com/itunes/ 9
AZ ESZKÖZTÁR MŰVELETEI A RAJZLAPOK NÉZETBEN A megnyitás gombra kattintva a mesék nézethez jutunk, ahol a már létrehozott mesék közül ki tudunk választani egyet és megnyitni. Itt az eszköztáron csak a vissza gomb található, mely a kezdő oldalra visz vissza. Ha kiválasztunk egy projektet, az betöltődik, és a mese nézethez jutunk (1. számú melléklet), ahol látjuk a létrehozott rajzlapokat és rajta a rajzokat. Lehetőségünk van módosítani, törölni, új rajzokat készíteni, majd menteni a mesét, mely felülírja a korábbi verziót. A rajzolás megkezdéséhez a rajz ikonra kell kattintanunk az eszköztáron. A rajzlapon (1. számú melléklet) tudunk új rajzokat létrehozni, illetve a már létezőket módosítani. Az eszköztár a rajzolásnak megfelelően alakul, a vissza gomb után található a ceruza, mellyel az ecsetet választjuk ki, a következő a radír, amivel törölni tudunk, és az utolsó a festékes vödör, mellyel adott alakzat belsejét tudjuk kitölteni a választott színnel. AZ ESZKÖZTÁR MŰVELETEI RAJZ KÖZBEN Attól függően mi az aktív művelet, az ikonok háttere megváltozik, és a rajzlap körül is kicserélődnek az elemek. Ez azt jelenti, hogy a ceruzánál láthatóak színes ceruzák és a méretválasztó, a radírnál csak a méretet tudjuk megadni, a festékes vödörnél pedig csak a színeket (ezt nem ceruzák, hanem ugyanúgy vödrök jelzik, ezáltal még könnyebben felismerhető hogy itt a kitöltés a kiválasztott funkció). Ezután ha a vissza gombra kattintunk, a program automatikusan elmenti a képet a 10
háttértárolóra, és hozzáadja a rajzlaphoz, ahol később mozgatni, átméretezni illetve forgatni tudjuk. Az érintés érzékeny eszközökön egy plusz funkció is elérhető. Ha hosszabb ideig lenyomva tartjuk ujjunkat a rajzon, akkor 4 kis ikon jelenik meg. Ezekkel tudjuk vízszintesen, függőlegesen a tengelye körül elforgatni a rajzot, vagy lezárni (ekkor nem tudjuk véletlen elmozdítani), a negyedik funkció pedig törlés, amellyel az egész rajzot törölni tudjuk. A HOSSZÚ ÉRINTÉS MŰVELETEI 2.4 Hol találhatóak az elmentett projektek? A program a Documents könyvtárba, a MeseSzerkeszto alkönyvtárba menti a file-okat, ami asztali környezetben a felhasználói dokumentumok mappája, Androidon pedig a meghajtó gyökere. Ebbe a mappába másolja a projects.xml-t, ami számon tartja milyen projektek lettek létrehozva, amiket saját könyvtárba ment. Ezekben a könyvtárakban találhatóak a mesékhez tartozó képek illetve a meséket leíró xml-k. A program minden indulásnál ellenőrzi, hogy létre van-e már hozva a MeseSzerkeszto könyvtár, ha nem létezik, létrehozza azt. 11
2.5 Óvodai látogatások tapasztalatai, menet közbeni módosítások A projektben részt vevőkkel óvodában 2 alkalommal teszteltük a programot, melynek segítségével nagyon sok hasznos információt szereztünk menet közben, így folyamatosan alakítottuk ki a program működését, kezelőfelületét. A teszt általában 1- másfél óráig tartott, 2 Samsung Galaxy Tab-on, és több korosztály is kipróbálhatta. Emellett voltak olyan gyerekek, akiknek már voltak tapasztalatai az érintés érzékeny beviteli eszközökkel, de fontosnak tartottuk hogy ne csak velük teszteljük a programot, ezért nem csak ők tesztelhették a programot. A tesztelés alatt próbáltam minél kevésbé beavatkozni, kiváncsi voltam hogy a felület egyértelmű e számukra, és tudják e kezelni a funkciókat anélkül hogy én elmondtam volna hogy minek mi a hatása a programban. Meglepően jó eredményeket értünk el már a legelső teszten, hisz segítség nélkül tudták az összes funkciót használni, szinte sosem kellett semmit elmagyarázni, annyira jól sikerült a felület elsőre. Már a tesztek előtt is elhatároztam, hogy sehol nem használok szövegeket, mindent ikonokkal, piktogramokkal váltottam ki, hogy a gyermekek könnyen és gyorsan tudják használni a programot. A szövegeken kívül a hibajelzéseket, felugró ablakokat is nélkülöznöm kell, hisz ezekkel a gyermekek nem tudnak mit kezdeni. Az első legfontosabb változás, a program korai szakaszához képest, az új projekt létrehozása. Ez az első verziókban a nyitóoldal új projekt létrehozása ikon kiválasztása után egy olyan ablakot hozott elő, ahol be lehetett írni a mese címét, szerzőjét, leírását. Könnyen látható hogy egy gyermek még egy ilyen képernyőt nem tud használni, ezért át kellett alakítanom ezt a folyamatot. Most már egyből a rajzlap nézet jön elő az új ikon választása után, és a mentés gombra sem jön fel az ablak, a mese neve az aktuális időből generálódik. Ezen kívül a betöltésnél is módosítottam az ikonokat, amik a projekteket szimbolizálták, a nevüket letöröltem, hisz semmi szükség rá, és a meséből véletlenszerűen kivágott képek váltakoznak, így rá lehet ismerni a projektre. A rajzolás részt teszteltük legtöbbet az óvodában, ahol annyi tapasztalatunk összegyűlt, hogy egy részét csak a továbbfejlesztések közé tudtam felvenni, a fontosabbakat folyamatosan módosítottam. Az első fontosabb módosítás abból adódott, hogy az eredeti verzióban rajz közben nem tudták a gyermekek, milyen eszköz van éppen kiválasztva, a ceruza, radír vagy a festékes vödör. Ezt kétféleképpen tudtuk vizuálisan 12
erősíteni, az először is a kiválasztott ikon mögé egy hátteret raktunk, másodszor pedig (mely vizuálisan sokkal erősebb), maga a felület is megváltozik. A ceruzarajznál a színek és a méret, a radírnál csak a méret, a festékes vödörnél pedig színes vödrök jelennek meg. Ezáltal sokkal könnyebben felismerhető mi a kiválasztott eszköz. 13
3 Fejlesztési dokumentáció Ebben a fejezetben azt írom le, hogy tudjuk elkezdeni a fejlesztést AIR-ben, hogy lehet feltelepíteni a környezetet, és a már meglévő forráskódokat hogy tudjuk importálni, használni, tesztelni. Az tesztelésnél ajánlott a Samsung Galaxy Tab használata. 3.1 A fejlesztőkörnyezet telepítése, beállítása, a projekt megnyitása A program Air-ben lett megírva, mely tulajdonképpen Flash alapú, Actionscript 3 22 nyelvet használ. Ez a nyelv ECMAScript 23 alapú programozási nyelv, amely nagyban hasonlít a JavaScriptre, azonban annál típusosabb nyelv, és jobban támogatja az objektumorientált fejlesztést. Az Air a Flash-től eltérően, mely főleg böngészőre optimalizált, már asztali környezetre íródott, tehát teljesen független a böngészőktől. Az AIR-hez ingyenesen letölthető az SDK az Adobe honlapjáról, de sokkal könnyebb fejleszteni, ha letöltjük az Adobe még fejlesztés alatt álló Flash Builder 4.5-ös fejlesztőkörnyezetét, mely alapból tartalmazza az AIR SDK-t is. A program időkorlátos verzióját a http://www.adobe.com/products/flash-builder.html címről tudjuk letölteni. A Flash Builder (régi nevén Flex Builder) az Eclipse-re 24 épül, ami egy ingyenes, elterjedt fejlesztőeszköz Java alapokon. A 4.5-ös verzió az előzőtől főleg abban tér el, hogy mobilra optimalizált, tehát egyszerűen tudunk vele fejleszteni Android, BlackBerry 25 és ios eszközökre is. Miután feltelepítettük a Flash Builder-t, importálnunk kell a projekt részeit, ezt a File-> Import menőpont alatt tudunk megtenni. Az Import ablakban az Existing Projects into Workspace -t válasszuk, majd a Next-re kattintva a gyökér könyvtárban kiválasztjuk azt, ahová a projektet lementettük. Ezután vagy erről a helyről használjuk, vagy átmásolhatjuk a mi munkakörnyezetünkbe, amit érdemes megtenni, főleg ha valami verziókövető rendszert is használunk. Miután sikeresen importáltuk a projektet a Package Explorer-ben megjelenik 3 projekt, a Common, Desktop és a Mobile. Minden mappában megtalálható az src, a Flex 4.5 és a bin, ezen kívül a Desktop és a Mobile tartalmaz még bin-debug, Referenced Libraries, és release-build könyvárakat is. Az src-ben találhatóak a forráskódok, amik 22 http://www.adobe.com/devnet/actionscript/articles/actionscript3_overview.html 23 http://www.ecma-international.org/publications/standards/ecma-262.htm 24 http://www.eclipse.org/ 25 http://us.blackberry.com/ 14
az Actionscript rövidítésének megfelelően as kiterjesztéssel találhatóak meg. Ezen belül pont-szintaxissal épülnek fel, tehát például az AbstractView a hu.elte.media.meseszerkeszto.view csomaggal van megadva, ami azt jelenti, hogy a pontok nélküli könyvtárstruktúrában található. A projekt fő file-jait általában Main.asnek hívjuk. A Flex 4.5 mappában a létrehozott projektekhez tartozó általános könyvtárak tartoznak, melyek a fordításhoz alapvetően szükségesek, ezeket a keretrendszer automatikusan hozzáadja a projektekhez. A Common mappában a bin azt a könyvtárat jelenti, ahová a forrásokat a rendszer összecsomagolja egy file-ba, egy swc-be, a többi projekt pedig ezt a file-t linkeli be. Ennek fordítása automatikusan működik. Ha mégsem fordítja le a keretrendszer magától, akkor a menüben a Project->Clean paranccsal tudjuk kényszeríteni. A Desktop és Mobile-ban található Referenced Libraries közé bekerül az előbb említett Common által lefordított swc, mely dinamikus link-el kapcsolódik, tehát automatikusan frissül. Ezen kívül a külső komponensek is ide kerülnek, melyeket a Flash Cs5-el tudunk előállítani, szintén swc formátumban. A bin-debug könyvtárba a rendszer az átmenetileg teszteléshez fordított file-okat másolja, tehát itt swf, xml és apk file-ok fordulhatnak elő. A release-build könyvtárt nem hozza létre automatikusan a rendszer, ezt nekünk kell megtenni. Ide másolja a végleges fordításokat, tehát amikor már nem akarunk tesztelni, hanem egy végső fázist akarunk kiexportálni, ide menti a fordító. Ide az Android apk és az ios ipa file-ja kerül, asztali környezetben pedig az air file. 3.2 Android, ios, asztali környezetben tesztelés, futtatás előfeltételei A Flash builder-ben 3-féleképpen tudjuk tesztelni a programot. Az első, legtöbbször használt a Debug, ahol ki tudjuk választani a platformot, ami lehet Android, ios, és Desktop, azaz asztali. Androidnál két további lehetőségünk is van, egy beépített emulátoron vagy közvetlenül az eszközön tudjuk futtatni a programot. Célszerű hibakeresés céljából emulátorban futtatni, hisz ez a leggyorsabb, és a legfontosabb funkciókat tudjuk tesztelni. A legtöbb hibát itt is fel tudjuk deríteni, ám ami a projekt szempontjából fontos, a touch, sajnos csak az eszközön tudjuk tesztelni. A debug futtatás előnye, hogy a program futtatása közben akár emulátorban, akár az eszközön 15
kapcsolatban áll a fejlesztőkörnyezettel, és láthatjuk az üzeneteket. A Flash-ben a legtöbbször a trace funkciót fogjuk használni, ami hasonló a c++-ban a cout függvényhez, azzal a különbséggel hogy ezt nem a szabványos kimenetre, hanem a console ablakba írja ki. Itt többek közt a futási idejű hibákat is láthatjuk a Debug panelen, a fordítási idejű hibákat pedig a Problems ablakban kapjuk meg. A második lehetőség a Run, ami megegyezik az előbbi Debug-gal, csak itt az üzeneteket nem látjuk. Tulajdonképpen ezt nem is használjuk, hisz nem ad semi plusz információt számunkra. A harmadik az optimalizációnál fontos, a Profile, mely ugyanúgy fut, mint a debug, tehát minden üzenetet látunk, de ezen felül látjuk létrehozott objektumokat, azok számosságát, és a memóriafoglalást, processzorhasználatot, mely segítségével könnyen ellenőrzi tudjuk mindig a memória állapotát, és hogy minden objektum megfelelően felszabadul-e időben. Itt egy nagyon hasznos funkcióval is találkozhatunk a Garbage collection gombbal, ami automatikusan működik az AIR-ben, viszont ha valamiért nem hajtódna végre, itt külön kérhetjük a nem használt objektumok törlését. Ahhoz, hogy Android-os táblán tudjuk tesztelni a programot, azt USB debug módba kell kapcsolni, amihez az eszközön a Beállítások -> Alkalmazások -> Fejlesztés -> USB hibakeresés opciót kell beállítanunk. Ha csatlakoztatjuk a számítógéphez USB-n keresztül az eszközt, a Windows telepíti a megfelelő meghajtót, azonban ha mégsem sikerülne, a Samsung fejlesztői oldaláról lehet letölteni az USB driver-t. Ha még nincs az eszközön az AIR futtatókörnyezet, a Debug-nál kiválaszthatjuk az USB-n keresztüli tesztelést, és így a Flash Builder automatikusan telepíti azt a készülékre a programmal együtt. Az ipad-en sajnos sokkal bonyolultabb a tesztelés, ehhez elő kell fizetnünk az Apple-nél developer-ként, és az eszközhöz készült provision profile-t 26, és egy certificate file-t kell generálnunk, mellyel ki tudjuk exportálni a programot, majd az itunes-on keresztül fel tudjuk tölteni. Sajnos itt a debug opció nem egyből a készülékre telepíti a programot, hanem miután lefordította az ipa kiterjesztésű file-t, kézzel kell rámásolnunk az eszközre, majd hálózaton keresztül tudjuk tesztelni. Az Air nagy előnye, hogy szinte minden funkció ugyanúgy működik bármilyen eszközön, például a kamera elérés, a touch kezelés; ezért elég az Android-os változatot 26 http://developer.apple.com/library/ios/#documentation/xcode/conceptual/iphone_development/128- Managing_Devices_and_Digital_Identities/devices_and_identities.html 16
tesztelnünk, a különbség a jelenlegi fázisban csak annyi hogy 1024x600-as felbontás helyett az ipad 1024x728-as, erre figyelnünk kell az elemek elhelyezésénél. 3.3 MVC (S) Model View Controller (Service) A projekt a Model-View-Controller programozási minta (továbbiakban MVC) felhasználásával lett elkészítve (2. számú melléklet), kiegészítve egy Service-el, melyet szoktak MVCS-nek is hívni. Az MVC tervezési mintát azért választottam, mivel multiplatform programról van szó, fontos volt, hogy a logikai réteg teljesen külön legyen leprogramozva a prezentációs rétegtől. Az MVC tervezési minta alapvető részei: Modell, mely az adatok tárolásáért felelős. Bizonyos adatok megváltozásakor eseményt vált ki, melyet az eseményre feliratkozott nézetek megkapnak, és ennek megfelelően változtatják az állapotukat. Controller, mely a működésért felel. A nézetekben történt felhasználói interakciók után eldönti, hogy mi történjen, megváltoztat bizonyos adatokat a modellben, illetve néha közvetlen a nézetet is tudja módosítani. View, mely a logikai rétegben csak Absztrakt nézeteket jelent, melyeket a konkrét Mobile/Desktop projektekben származtatni kell, hogy tudjuk használni. Ezek fontos funkciókat tartalmaznak, amelyeket előírhatunk hogy a származtatott osztályokban is jelen legyenek (pl. transition műveletek, dispose, illetve a fő ablaknál az alnézetek tárolását, váltását jelentik). 3.4 Az projekt részei, az MVC adaptálása A program MVC tervezési modellt használ, kiegészítve egy Service-el, mely esetünkben a FileService, mely a File-okkal való kommunikációért felelőse. Az MVC logikai rétege, azaz a Model és a kontroller a Common Projektben található, a nézetek, azaz a View-k pedig az egyes alprojektekben, tehát a Desktop és a Mobile-ban találhatóak. Ez elősegíti, hogy az egyes nézetek teljesen függetlenül módosíthatóak legyenek, és külön minden eszközre elkészíthessük a neki megfelelő nézetet, míg az alapvető kontroller közös, tehát a változások a nézetekben is módosulnak. 17
A mobile és a Desktop projektek nem tartalmaznak logikai rétegeket, csak nézeteket, melyek a Common-ban található ősosztályokból származnak, illetve külső komponenseket (pl. képek). Fontos különbség, hogy míg a Desktop projektben csak az, tehát az ehhez tartozó eseményeket tudjuk használni (itt MouseEvent), addig a mobil projektben az érintéshez kapcsolódó eseményeket használjuk (TouchEvent). (A Flashben ilyen esetben MouseEvent-eket is lehet használni, a framework futtatási időben átkonvertálja a touch-okat MouseEvent-re, de ez a sebesség szempontjából rosszabb hatásfokú.) A másik fontos különbség, hogy asztali környezetben és mobilon más-más megjelenítés szükséges, hisz a felbontás a mobil eszközön kisebb, ehhez igazodni kell, ezért más külső komponenseket használunk. A komponensek SWC formátumban érhetőek el a projektben, melyet az Adobe Flash CS5-el készítettem. Ezek tartalmazhatnak képeket, hangokat, bonyolultabb Sprite-okat, MovieClip-eket a hozzájuk tartozó kóddal, funkcionalitással, melyeket egy file-ba csomagol be, és ezt könnyen tudjuk használni a projektben. A program fő osztálya a Main.as, ahol definiáljuk az MVC részeit, létrehozzuk a modellt, a kontrollert, melynek átadjuk a modellt, és az alap nézetet, melynek megadjuk a modellt és a kontrollert is. Mivel a kontroller is vezérelheti közvetlenül a nézetet, a kontroller inicializálásakor átadjuk neki a fő nézetünket, ezek után természetesen a nézetet hozzáadjuk a megjelenítési listához (displaylist). 3.5 A program és a projektek adatainak logikai és fizikai felépítése Egy projekt fizikai tárolása a hozzá tartozó xml-lel és a képekkel történik. Amíg nem mentjük el, ezek egy átmeneti, temp könyvtárban tárolódnak, és csak ha kiválasztjuk a mentést, akkor másolódnak át a képek és az xml, abba a könyvtárba, mely a projekt nevével egyezik. A projekt xml az alapvető adatokkal kezdődik, mint a név, a létrehozás dátuma, a módosítás dátuma. Ezen belül slide-ok különböztetik meg az egyes rajzlapokat, amiken belül element-ek vannak, melyek az egyes rajzokhoz tartoznak. Minden elemhez tartozik egy transform attribútum is, mely azt jelenti milyen x, y pozícióval, és milyen méretekkel rendelkezik az adott objektum. 18
<slide title="slide01"> <elements><element name="image2"> <transform x="0" y="0" width="0" height="0" rotation="0"/></element> </elements> </slide> A képeket az Adobe által javasolt pngencoder osztállyal állítjuk elő, mely bitmapdata-t vár, és a végeredmény ByteArray, amit el tudunk menteni egy megfelelő filestreammel. A képmentés, illetve az xml-ek mentése, betöltése a FileService feladatai. Korábbi verziókban egy projekt felépítését több helyről kellett lekérni, majd a kontroller állította elő az xml-t, végül ezt adta át a fileservice-nek, mely szintén hozzátett az xml-hez a projekt adatait. Ez nagyon kényelmetlen, rosszul módosítható és átláthatatlan kódot eredményezett, ezért a célom, hogy a kontroller ne tartalmazzon xml műveleteket, és a fileservice se foglalkozzon xml feldolgozással. Ezért létrehoztam egy statikus osztályt, az XMLService-t, mely egy adott objektumból xml-t, illetve xml-ből objektumot állít elő, így a kontroller és a fileservice ezen osztályon keresztül alakítja át a megfelelő adatot. Az xml-t át kell alakítanunk, hogy fel tudjuk használni, ezért egy olyan adatszerkezetet kellett kitalálni, ami átlátható, és programozás közben is könnyen kezelhető. Erre ValueObject-eket hoztam létre, azaz olyan objektumokat, melyek csak értéket tárolnak. Egy projekt kiindulási objektuma, a ProjectVO, mely a projekt általános adatain kívül tartalmaz egy vektort, amiben a rajzlapokat mentjük el, azaz a SlideVO-kat. A slide-ok tartalmazzák az alapvető rajzlap adatokat, és szintén egy vektorban tároljuk a rajzlapon tárolható elemeket, azaz az ElementVo-kat, melyek jelen esetben többnyire képek, de a következő verziókban az általánosítás megengedi, hogy ezek videók, Flash file-ok, vagy hangok legyenek. Ez a felépítés gyakorlatilag egy láncolt listához hasonlít, biztosítja számunkra a fejlesztőkörnyezetben a kódkiegészítést, mely programozás közben nagyban megkönnyíti a munkát, illetve mindig számon tudjuk tartan a projekt felépítését. Egyelőre egy projektet az xml, és a képek azonosítanak, illetve a program.xml-ben ezeket eltároljuk, tehát nincs lehetőségünk más helyről importálni projekteket. A továbbfejlesztett verzióban majd lehetőség lesz egy file-ba összecsomagolni a projekthez tartozó részeket. 19
3.6 Nézetek A fő nézet, azaz a MainView a Common-ban már előredefiniált AbstractMainView-ből származik, melynek az AbstractView az ősosztálya. Minden nézetet az AbstractViewból származtatunk, mely előre lekezeli az átmeneteket, így már a konkrét nézetben nem kell ezzel törődnünk. Az AbstractMainView ezen túl még a nézetek váltását is tartalmazza, ami egy régebbi változatban még a MainView része volt, de a logikája ugyanaz minden platformon, így célszerűbb csak egy helyen szerepeltetni. Ezen kívül itt még számon tartjuk az aktív nézetet és a nézetek vektorát. Minden nézet, melyet a MainView-ban létrehozunk, bekerül egy vektorba, mely számon tartja, miket adtunk hozzá a listához, majd a váltásnál ebből a vektorból kérjük le a kívánt nézetet. Az egyes nézetek létrehozása már a MainView feladata, hisz a Common-ban található ősosztály nem ismeri a konkrét nézetek osztályait, ezt minden alprojektnél le kell programoznunk. A következő verzióban meg kell vizsgálni, hogy egyszerűbb, áttekinthetőbb lenne-e, ha minden általános nézetnek lenne saját ős absztrakt osztálya, ezáltal ezeket is a főnézet ősosztályában tudnánk létrehozni. Ezen kívül itt található még, hogy az eszköztáron kiválasztott ikonra mi fusson le, amely azért fontos, hogy itt legyen, mert a rajzolásnál értesítenünk kell a rajz nézetet, hogy mentse el a képet, a többi esetben a kontroller kapja meg ezt az eseményt. A nézetek váltás úgy történik, hogy a kontroller a model-ben átállítja az activeview értéket, melyet egy statikus View osztályból kapunk meg, ami a programozás közben nagy segítség, hisz ide minden nézet fel van jegyezve, tehát sosem tudjuk elgépelni. Miután a modell megkapta az új nézet értéket, egy ApplicationEvent.VIEW_CHANGE eseményt vált ki, amire már a főnézet inicializálásánál feliratkozott az AbstractMainView, és a changeview függvényhez delegáltuk. Itt először megnézem, hogy mi az aktuális nézet: ha ugyanaz, nem történik semmi; ha más, akkor először az aktuális nézet transitionout függvénye fut le, ami az eltűnés animáció, ezután egy transitionoutcomplete-el jelez, hogy végzett, tehát az új nézetet előhívhatjuk. Ez a folyamat nagyon biztos, sokszor tesztelt, nem fordulhat elő hogy több nézet összeakad, hisz amíg animációs fázisban vagyunk, nem történhet más, az animáció végén pedig behozzuk azt a nézetet, amit szeretnénk. Egy hiba lehet, ha a programozó a későbbiekben úgy vesz fel nézetet, hogy nem adja hozzá a vektorhoz, vagy nem veszi fel a View statikus osztályba, és félregépeli. 20
A nézetek ősosztályában fontos művelet még az updatedisplay, melyet meghívva az adott nézet elemeit elrendezzük a megfelelő pozícióba, a setuplisteners és a removelisteners, melyekkel feliratkozunk, illetve leiratkozunk eseményekről, illetve a dipose, mely ha már nincs szükségünk a nézetre, kitöröl belőle mindent és felszabadíjta a memóriát. Ezt minden nézetnél érdemes külön leprogramozni, hisz mindegyik más-más elemeket tartalmaz, amit a legbiztosabb ha kézzel törlünk. 3.7 Kontroller A kontroller felel a program működéséért, ide irányítjuk a felületen, tehát a nézetekben a felhasználói interakciót, itt történik a fileservice-el a kommunikáció, és a kontroller felel a modellben lévő adatok megváltoztatásáért. Az első és legfontosabb függvény az initcontroller, melyről a program indulásánál lesz szó. A loadprogramsettings a fileservice-ből létrehoz egy példányt, majd inicializálja. Attól függően hogy sikeres volt a program beállításainak betöltése, a fileservicehandler fogadja az eseményeket, amely lekéri a projekteket és a modellhez hozzáadja. Ez a nézetek közül a megnyitás nézetnek segítség, hisz nem kell nagy adathalmazból kikeresni milyen projekteket lehet megnyitni, elég csak a nevüket eltárolni. A newprojectselected függvényt a kezdőnézet új ikonja futattja le, aminek hatására a kontroller létrehoz egy átmeneti projektetet, tehát egy ProjectVo típusú objektumot, amit átad a model-nek, mint aktuális projekt. Az openproject egy kiválasztott projektet megnyit, ám ezt nem lehet egyből megtenni, hisz be kell tölteni a képeket, melyeket a fileservice végez, tehát egy olyan eseményre kell feliratkoznunk, ami azt jelenti hogy minden elem be van töltve, ami az onallassetsloaded függvényhez van delegálva. Ez a függvény átadja a modellnek a betöltött projektet, majd az aktuális nézetet a rajzlapok nézetre állítja. A saveactiveproject függvény megnézi hogy van-e átmeneti projekt, ha igen, létrehoz egy új projektet és meghívja a fileservice-nek a projektmentés függvényét, majd a modellben az aktív nézetet a kezdőre állítja. A drawcomplete függvény akkor fut le, amikor a rajznézetben a vissza gombra kattintunk, és el akarjuk menteni a képet. Itt is a FileService végzi a képmentést, a 21
kontroller pedig hozzáadja a képet a model-hez pendingelement névvel, ami azt jelzi hogy egy ilyen elem vár arra, hogy hozzáadják a razjlaphoz. A toolbarhandler figyeli az eszköztár eseményeit, és attól függően, hogy melyik nézetben milyen ikonra kattintottunk, beállítja a kívánt nézetet vagy végrehajtja a megfelelő funkciót. 3.8 Model A modellben tároljuk a program és a projektek adatait. Az activeview, azaz az aktív nézet azt mutatja meg hogy a MainView-nak melyik nézetet kell mutatnia, ezt a kontroller állítja be, a model pedig egy ApplicationEvent.VIEW_CHANGE eseményt vált ki, melyre a fő nézet changeview függvénye fut le. A projectsvector-ban a projekteket tároljuk, de nem az egész felépítését, hanem csak alap információkat, ezáltal a betöltésnél nem kell minden egyes projektet megjelenítenünk az előnézetben, csak a fontosabb adatokat. Az activeproject az éppen aktuálisan megnyitott projektet jelenti, ha ezt átállítjuk, akkor a rajzlapok nézet az előző projektet törli és ezt felépíti. Ez az ApplicationEvent.PROJECT_CHANGE esemény hatására történik meg. Az ActiveSlide, azt mutatja meg, melyik az éppen aktuális rajzlap. Ezt a kontroller is be tudja állítani, de szükség esetén a nézet is át tudja magának állítani, például amikor a nyilakkal lapot váltunk. Az assetcounter egy segédváltozó, ami abban segít, hogy amikor új képet hozunk létre, ne írjunk át egy már meglévő képet, a kép mentésnél mindig léptetjük eggyel, a projekt mentésnél/betöltésnél is számon tartjuk. Az activedrawtool a rajzlap nézetnél az eszköztár aktív rajzeszközét állítja be. 3.9 A program indulása, inicializálás A Main.as inicializálja a kontrollert, mely betölti a program beállításait, amely azt jelenti, hogy létrehozza a file-műveletekért felelős FileService-t, ami ellenőrzi hogy létezik-e az előre megadott útvonalon a program.xml, tehát hogy előszőr fut-e le a program. Ha nem talál ilyen file-t, létrehozza a megfelelő könyvtárstruktúrát, azaz a dokumentumok mappában a MeseSzerkeszto könyvtárat, azon belül pedig a 22
program.xml-t, amelyben a létrehozott projekteket tartom nyilván. Ha már létezik ez a file, leellenőrzi hogy a benne található projektek léteznek-e, azaz validálja az xml felépítését és egyben felépít egy vector-t, melyben a projekteket tárolja. Ha minden rendben ment, tehát már létezik a program.xml, akkor egy PROGRAM_XML_LOADED eseményt vált ki, melyre még a fileservice inicializálása előtt feliratkozott a kontroller. Ezek után a kontroller a filemanagerhandler függényben lekérdezi az előbbi projektek vektorát, majd hozzáadja a projektekte a model-hez. A projektek ProjectVO típusú objektumnak tárolódnak, mely a programozás közben könnyebbséget jelent, hisz sokkal könnyebben számon tudjuk tartani őket. 3.10 Multitouch lehetőségek a Flash platformon A Flash 10.1-től az AIR 2-től már natívan támogatja az érintésérzékeny eszközök kezelését, ezek touch eseményeket váltanak ki, ugyanúgy mint ahogy az egér esetében a MouseEvent-ek kiváltódnak. Egyszere egy, illetve több érintést is meg tud különböztetni, ilyenkor minden egyes ponthoz egy esemény váltódik ki. (Azt, hogy az eszköz hány pont felismerésére képes a Multitouch.maxTouchPoints-al tudjuk lekérdezni; az esetek többségében ez 2). A Flash-ben a touch-ok kezelése a Multitouch osztály segítségével valósul meg, amely fontos tulajdonságokat definiál az aktuális eszközről (futási időben), pl. hogy az eszköz támogatja-e az érintésérzékeny bevitelt, le tudja-e kezelni a gesztusokat, hány pontot érzékel egyszerre. A touch alkalmazás legfontosabb lépése, hogy meghatározzuk a beviteli módot, amellyel azt állítjuk be, milyen eseményeket szeretnénk használni. A MultitochInputMode tartalmazza ezt a 3 lehetőséget. A Touch_Point esetében alapesemények váltódnak ki, mint pl. amikor lenyomjuk az ujjunkat, felemeljük, mozgatjuk. A Gesture esetében pedig a Flash képes felismerni bizonyos gesztusokat, mint pl. ha két ujjunkat letesszük, majd közelítjük egymás felé (ezt többféleképpen is hívhatjuk, zoom, pinch, scale). A gesture eventek gyakorlatilag a touch eventek egy meghatározott sorozata, összessége, ezért saját magunk is könnyen tudunk definiálni gesztusokat. A harmadik lehetőség a None, mely azt jelenti, hogy minden touchevent-et MouseEvent-ként akarunk lekezelni. Ez abban az esetben lehet 23
számunkra érdekes, ha egy külső komponenst úgy írtunk meg hogy TouchEvent-eket használtunk, és ezt Desktop környezetben is szeretnék használni. Mivel a Flash-ben sajnos a GestureEvent-ek nem lettek tökéletesen implementálva, ezért néhány próbálkozás után rájöttem, hogy jobb ha más megoldást keresek a gesztusok felismerésére, mivel nem tudja egyszerre kiváltani a forgatás (Rotate) és a nagyítás (Pinch, zoom), illetve nem érzékeli a Long tap-ot (ami gyakorlatilag olyan, mintha hosszút kattintanánk). Egy nagyon jó implementáció elérhető az interneten, a GestureWorks 27, ezzel is próbálkoztam, és nagyon jó volt a benyomásom róla, viszont nincs ingyenes változata, és nagyon kötött a fejlesztés (előredefiniált TouchSprite-okat lehet használni, ezáltalal nem annyira rugalmas, nem könnyű meglévő rendszerbe beilleszteni, használni). A továbbiakban csak TouchEvent-eket használok majd, a Flash-ben meglévő GestureEvent-et nem használom, ehelyett egy saját osztályt írtam, ami alapvető elemekből dönti el a gesztusokat. Ahhoz hogy megértsük, hogyan tudunk saját gesztusokat definiálni, felismerni, ismernünk kell milyen alap eseményekre tudunk feliratkozni. Minden ilyen esemény a TouchEvent osztályban van definiálva, a fontosabb típusai: TOUCH_BEGIN: Azt jelenti, hogy egy touch-esemény elindult, tehát az ujjunkkal megérintettük a felületet. TOUCH_END: akkor váltódik ki, amikor elemeljük az ujjunkat a felületről. TOUCH_MOVE: Az ujjunkat, miközben a felületen van, elmozdítjuk valamilyen irányba. TOUCH_TAP: Ez felel meg az egérkattintásnak, gyakorlatilag egy gyors begin-end-et jelent. Könnyen látható, hogy ezek közül elég 3 esemény, a Begin, End és a Move, amivel bármilyen gesztust fel tudunk ismerni. De még szükségünk van fontos tulajdonságra, a touchpointid-ra, ami egy egyedi azonosítója az eseménynek: minden egyes érintéshez más-más szám tartozik, ezáltal tudjuk megkülönböztetni őket. Ezenkívül számos tulajdonsággal rendelkezik még az esemény, pl. a pressure, ami azt az erőt adja meg 0 és 1 intervallumban, mekkora erővel nyomtuk a felületet, és a sizex, sizey, mely az érintés szélességét, magasságát adja meg, de ezek számunkra nem fontosak (nem is minden eszköz támogatja). 27 http://gestureworks.com/ 24
Most már meg tudunk különböztetni két eseményt, és külön-külön meg tudjuk mondani, melyik milyen típusú eseményt vált ki. Könnyen látható, hogy ezáltal bármilyen gesztust definiálhatunk, most már csak az a kérdés, hogy hol érdemes ezeket definiálni, hogy kényelmesen tudjuk használni őket, illetve hogyan tudjuk megoldani, hogy több gesztus egyszerre is működjön. Első hallásra nagyon egyszerűnek hangzik, de gondoljunk bele, mi történtik ha egy dupla érintést akarunk felismerni! Double Tap-nél két Tap van egymás után, viszont az első érintés után a Tap kiváltódik, és az arra feliratkozott funkciók lefutnak, tehát nem csak doubletap-et érzékeltünk, ami probléma lehet. 3.11 Konkrét touch megvalósítás, a TouchManager osztály A felismeréshez írtam egy osztályt, amely kezeli a gesztusok felismerését, az objektumok eseményfigyelését. Ez az osztály a Singleton pattern-en alapul, hisz így elég az egész programon belül egyszer létrehozni egy példányt belőle, és bárhol elérjük. Az objektumokat additem-el tudjuk hozzáadni, ami egy Sprite típusú, vagy abból származtatott objektum. Ekkor a TouchManager feliratkozik az elem TouchEvent.TOUCH_BEGIN eseményére, és hozzáköti a start függvényhez. Egy már hozzáadott objektumot a removeitem-el tudunk levenni, ami azt jelenti hogy az osztály elintézi helyettünk az TouchEvent.TOUCH_BEGIN eseményről való leiratkozást. Amikor egy objektum fölött lenyomjuk az ujjunkat, a start függény fut le (a Touch_begin eseményt ehhez delegáltuk), ahol megnézzük, hogy van-e már ezen kívül érintési pont vagy még nincs. Ha nincs, amit az jelez hogy a _downqueue hossza 0, ami egy vector, ahova mindig az a touchpoint-ot hozzáadjuk, akkor hozzáadjuk még a Touch_Move és a Touch_end események figyelését, az update és az end end függvényhez delegálva. Ekkor elindítunk egy taptimer időzítőt, mely azért kell, hogy tudjuk figyelni, hogy egy sima lenyomás történt vagy más (pl. egy Long Tap). Ha úgy emeltük el az ujjunkat hogy ez az időzítő nem ért véget, akkor egy sima Tap történt, viszont ha az időzítő lejárt, és még nem emeltük le az ujjunkat, akkor Long tap. Ennek az idejét a taptimetarget-el tudjuk beállítani, jelen esetben 700 ms. Viszont ha közben elmozdítjuk az ujjunkat, vagy másik ujjunkkal is érintjük a felületet, az már nem ez az esemény, ezért folyamatosan figyelnünk kell. Ha változik a downqueue hossza ez idő 25
alatt vagy elmozdul egy adott értékkel, amit a Move_min_threshold-al tudunk beállítani, akkor leállítjuk az időzítőt. Fontos megjegyezni továbbá, hogy bár elsőre bonyolultnak tűnik az algoritmus, de ha belegondolunk, ilyen eszközökkel nagyon sok saját eseményt ki tudunk találni. A probléma ott kezdődik, amikor olyan eseményekre akarunk feliratkozni, melyek kizárják egymást. Elsőre a sima ujjlenyomás és a gyorsan egymás után ujjlenyomás is úgy tűnt, hogy kivitelezhetetlen, viszont egy időzítővel ez is megoldható. Ha az ujjlenyomás, -felengedés után elindítunk egy példuál 200ms ideig tartó időzítőt, és figyeljük érkezik-e újabb érintés ez idő alatt, akkor könnyen különbséget tudunk tenni. Ha az idő lejárt, egy érintés volt, ha nem járt le és mégegy érintés történt, az double tap. Ez egy kicsi késést jelent a sima érintés után, de ez a 200ms nagyon rövid, általános felhasználásnál nem zavaró. Hasonló analógiával tudunk definiálni n-szeres érintést is, de 3-nál több érintésnek nem nagyon van értelme. Egy másik fontos eleme ennek az osztálynak, hogy hogyan tudjuk lekezelni a forgatást, mozgatást, átméretezést egyszerre. Amikor egy objektum fölött lenyomjuk az ujjunkat, akkor egy Matrixot létrehozunk, ez a downmatrix, az adott objektum transzformációs mátrixát. Ez a Flash-ben egy 3x3-as matrix, melynek elemei az a, b, c, d, tx és a ty. A tx és a ty a legegyszerűbb, ezen számok azt adják meg hogy mennyivel mozdult el x/y irányban az objektum. Az a és a d azt mutatja meg hogy x és y irányban mennyire nőtt a mérete. A b és a c pedig egy x,y irányú ferdeséget. Az identitás matrix megadja az objektum alaphelyzetét, torzításmentesen. Ezzel egyidőben, számon tartunk egy pontokból álló vektort (_touches), melyben a pontok helye aszerint alakul, hogy mikor nyomtuk le őket. Ez a TouchEvent.touchPointID, az értékük pedig azt az x/y koordinátát jelöli, ahol lenyomtuk őket. A nulladik és a második elem az első érintési pont, a első és a harmadik pedig a második érintési pont, melyek segítségével határozzuk meg az eredeti matrix és a tranzformációval létrejött matrix konkatenációját. A pontok halmazon minden update esemény hatására kiszámolunk egy mátrixot. Ha csak egy ujjal nyomtuk le, akkor csak sima mozgatásról lehet szó, tehát nem kell a,b,c,d értéket módosítaunk, elég a tx,ty-t, az eredetivel való konkateánciója pedig az elmozdulást adja meg. Ha két ujjal nyomtuk le, akkor ki kell számolnunk a pontokból az elmozdulás értéket, melyet a MatrixHelper osztály végez. 26
Végül a kapott végleges mátrixból lekérdezhető, hogy milyen mértékben forgattuk el az objektumot, vagy a méretét hogyan változtattuk. Ezek hatására egy Move/Rotate/Scale esemény váltódik ki, ahol átadjuk azt az értéket, a mennyivel változtak. Az osztály végén, a Touch_end hatására az adott érintési pontot levesszük a listából, ha üres a lista, amiben számon tartjuk, akkor az időzítőket is leállítjuk. 3.12 Külső komponensek, képek kezelése A program külső komponensének részei a képek, rajzolásnál a rajzolófelület, az ecset nagyságát beállító panel, melyek a kódot is tartalmazzák. Ezek Flash CS5-ben készültek, ahonnan swc formátumban lettek kimentve, ezáltalál 1 file-t kell csak importálnunk a projektben, ami könnyen átláthatóvá teszi azt, és a public függvényeket, változókat felsorolja számunkra a fejlesztőkörnyezete. Ez a hibakeresésnél is fontos, hiszen elég a Flash-ben tesztelni a komponens részeit, a programunk számára fordított swc már előzetesen le lett tesztelve. A képek a Flash-ben a Library-ban találhatóak, ahol BitmapData-ként szereplenek, és mindegyik egy egyedi névvel azonosítható. Ha ezeket a programban szeretnénk használni, akkor egy megjelenítő konténerhez kell hozzáadnunk. Ha nem akarunk feliratkozni semmilyen eseményre, akkor elég egy Bitmap, és ha csak figyelni akarunk egér vagy touch eseményeket, akkor Sprite szükséges. A Flash található még egy MovieClip nevű osztály is, melynek ősosztálya a Sprite, de ezzel most nem foglalkozunk, hisz csak annyiban tér el, hogy az idővonalat is tudjuk használni, ami egyrészt nem kell nekünk, másrészt az optimalizálásnál ez az első amit átírunk. Tehát például az eszköztár Hátterét az alábbi kódrészlettel tudjuk hozzáadni: var toolbarbackground:bitmap = new Bitmap(new ToolbarBackground(1,1)); Ahol a ToolBarBackground az a BitmapData, amit az swc-ben definiáltunk az 1,1 pedig azt mondja meg, hogy mekkora (viszont azzal hogy 1,1-et adtunk meg automatikusan méretezi számunkra). Ha a rajzoló felületi tervét szeretnénk hozzáadni, akkor ugyanígy kell eljárnunk, azzal a különbséggel, hogy az már eleve Sprite ősosztályból származik, tehát nem kell külön konténerhez hozzáadnunk. 27