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./B09/1/KMR-2010-0003.
1
Tartalomjegyzék 1
2
3
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
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
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-et1, 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 UMPC2 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-t7 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ú, Linuxra9 é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 Tab10 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 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/ 6
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 12
http://teamlabor.inf.elte.hu/ 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-at14 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 14
http://www.adobe.com/hu/products/air/ http://www.adobe.com/devnet/actionscript/articles/actionscript3_overview.html
7
az AIR SDK-ra15 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 720 , Mac OS X és Linux
operációs
rendszer
alatt
fut
http://www.adobe.com/products/air/systemreqs/
,
a
pontosabb
címen
lehet
specifikációt
a
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/ 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 16
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-on21 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 1má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, BlackBerry25 é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 http://www.ecma-international.org/publications/standards/Ecma-262.htm 24 http://www.eclipse.org/ 25 http://us.blackberry.com/ 23
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-t26, é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/128Managing_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">
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
ApplicationEvent.VIEW_CHANGE
az
új
nézet
értéket,
egy
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 GestureWorks27, 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
3.13 Tesztelési esetek A tesztelés célja a külső komponensek, a program egyes részeinek és az egész program működésének fejlesztése, hibák kizárása, illetve az új funkciók implementálása után az újonnan felmerült hibák javítása, kiszűrése. Nagyon fontos az előzetes tesztelés, lehetőség szerint minden futási időben felmerülő hiba kijavítása, hiszen a célközönség, tehát a programomban az óvodás gyermekek, nem tudnak olyan visszajelzéseket adni, mint egy átlagos program során. Sőt számukra egy hiba, melyet mi egyből felismerünk, nem is feltűnő, viszont meghatározza a programhoz fűződő élményeiket. Néhány példával szeretném illusztrálni a fent leírtakat. A program kezdeti szakaszában nem lehetett különbséget tenni, hogy az ecset vagy a festékesvödör van kiválasztva, ezért amikor az ecsettel akartak rajzolni, véletlen a festékesvödörrel kitöltöttek egy egész lapot. Ez nyilvánvalóan hiba, mivel ők azt hitték, az ecset van kiválasztva (ezt tekinthetjük egy felület-tervezési hibának), viszont ők ezt egyből ki tudták javítani azzal hogy a fehér színt kiválasztva újra kitöltötték a területet, mintha nem is történt volna semmi. A másik jellemző hiba file-mentés során jelentkezett, amikor valamiért nem mentett a program, vagy túl hosszú ideig mentett, ezáltal több gombot is megnyomtak. Az első hiba, nyilván a FileService osztályban keresendő, és már a tesztelés alatt felderíthető és súlyos, tehát erre sokkal több figyelmet szenteltem. A másik hiba megoldáda egyrészt a mentési folyamat optimalizálása, de mindenek előtt a felület blokkolása, amivel a felhasználót értesíteni tudjuk, hogy a program dolgozik, és a gombokat le is tiltjuk.
3.13.1 A fehér doboz tesztelés A főbb funkciók tesztelését emelném ki, melyek a program szempontjából kritikusak lehetnek. 1. Nézetváltások tesztelése csomag
hu.elte.media.meseszerkeszto.view
osztály
AbstractMainView
függvény
getView(view:String = null):AbstractView
28
Itt azt vizsgáljuk meg, hogy megfelelően működik-e a nézetek átváltása. Célunk, hogy ha a modellben megváltozik az aktuális nézet értéke, akkor a MainViewban is a getView függvény a megfelelő nézetre váltson. Mivel a nézeteket egyesével hozzá kell adni, előfordulhat, hogy valamit elgépelünk és a nézet, amire váltani akarunk nem létezik. Ez hibás működés, melyre a program kiírja a fejlesztőnek a hibát, majd alaphelyzetben a kezdőképernyőre tér vissza, minden más esetben, ha létezik a megfelelő nézet, helyesen betölti. A funkciót minden új nézet esetén le kell tesztelni. 2. Program adatainak betöltése csomag
hu.elte.media.meseszerkeszto.service
osztály
FileService
függvény
loadProgramXml ():void
A program adatainak betöltése nagyon fontos függvény, hisz ha hibásan működik, akkor blokkolnunk kell mindent, tehát a program el sem indul. Ha nem így tennénk, az file-szinten is hibás működést idézhetne elő. A lehetséges hiba, ha nincs is olyan xml, amit be akarna tölteni, ezt már előbb lekezeljük, ez esetben létrehozzuk automatikusan. A betöltés olyan szempontból kritikus művelet, hogy lezárhatja a file-t rendszerszinten, tehát gondoskodnunk kell arról hogy minden esetben bezárjuk a FileStream-et: ezt egy try,catch blokk finally ágával biztosítjuk. Egy plusz ellenőrzés is bekerült ebbe a függvénybe, mely nem a file betöltésének ellenőrzését, hanem a tartalmának helyességét vizsgálja. Ez az isValidProgramXml függvény, mely ha hamis értékkel tér vissza, akkor egy PROGRAM_XML_ERROR eseményt vált ki, ellenkező esetben betölti a projekteket. Erre azért van szükség, mert számon tartjuk az összes projektet, és ha egy projektet kézzel a felhasználó kitöröl, akkor a program nem fogja találni. Később a továbbfejlesztésben ezt kiküszöbölhetjük azzal hogy a program egyszerűen azokat a projekteket amiket nem talál, kitöröl ebből az xml-ből.
29
3. Projekt betöltése csomag
hu.elte.media.meseszerkeszto.service
osztály
FileService
függvény
loadProject(projectVO:ProjectVo):void
A projekt betöltése függvény egy project Value Object-et vár paraméterül, és a feladata hogy a megadott projekt xml-jét, és az xml-ben végigmenve az összes képet betöltse. A megnyitás itt is egy try-catch blokkban található, amivel a hibákat ki tudjuk szűrni, a finally blokkban pedig bezárjuk a filestream-et. Ha nem találja a file-t, a finally blokkba jut és nem történik semmi, a program nem áll le, a fejlesztőnek ezt az esetet le kell kezelni. 4. Projekt Mentése csomag
hu.elte.media.meseszerkeszto.service
osztály
FileService
függvény
saveProject():void
A projekt mentése során figyelnünk kell arra, hogy már mentett projektről van-e szó, vagy még átmeneti, tehát nem mentettük eddig. Ha átmeneti, akkor előszőr a createNewProject függvényt kell meghívni, ellenkező esetben a saveProject nem csinál semmit. Itt fontos megvizsgálni hogy minden esetben ugyanazt az xml-t kaptuk, amilyet a megfelelő objektumhoz várunk, ezt minden esetben ellenőriznünk kell. Az xml mentésnél és betöltésnél elég egyszerűen tudjuk ellenőrizni a működést, hisz a projectVo-kból visszakövethető milyen Xml-t várunk. Ezeket unit tesztekkel tudjuk ellenőrizni. 5. Kép mentése csomag
hu.elte.media.meseszerkeszto.service
osztály
FileService
függvény
saveBitmap(_bitmap:Bitmap, _name:String):void
A kép mentése manuális módon ellenőrizhető, tehát egy rajz után megnézzük, milyen png-t mentett a program. Ehhez unit tesztet nem könnyű írni, ezért a 30
manuális ellenőrzés a legmegfelelőbb. Hibás működést idézhet elő ha nem adjuk át a képet, vagy a nevét, de ebben az esetben a Flash már fordítási időben hibát ad, tehát futási időben nem lehet probléma.
3.13.2 Fekete doboz tesztelés A fekete doboz tesztelést elvégezhetjük az emulátorban és az eszközön is. Az emulátorban sajnos a touch-tesztek nem kivitelezhetőek, azokat minden esetben az eszközön kell megvizsgálni. Ezekben a tesztekben nagy segítség volt hogy a gyermekek tesztelték közvetlenül is, hisz így sok olyan hiba előjött, ami a fejlesztés közben nem. Főleg a felület érzékenységével, pontosságával voltak problémák, melyeket minden ovis teszt után javítottunk. Itt már kritikus hibák nem léptek fel, hisz azokat fordítási időben, illetve a függvények tesztelésével már megoldottuk.
3.14 Optimalizáció A Flash-ről általában az embereknek az optimalizálatlanság jut eszébe, és gyakran a hibás működés. Ez elsősorban annak tudható be, hogy nagyon könnyű Flash-ben fejleszteni, ezáltal pár nap tanulás után bárki el tudja kezdeni, alapvető programozási ismeretek nélkül. A hibakeresés, tesztelés mellett nagy figyelmet kell szentelnünk az optimalizációra (a mobil-on futó projektekben hatványozottan igaz ez, hisz ott sokkal kisebb a processzor teljesítménye, és a memóriával is óvatosan kell bánnunk), amihez feltétlenül ismernünk kell a Flash által nyújtott lehetőségeket, és naprakészen ismernünk kell a új verziókban megjelent lehetőségeket. Az optimalizáció a fejlesztés idejében általában folyamatos, tehát minden új funkció programozása közben már eleve úgy írjuk a függvényeket, változókat, hogy a lehető legkisebb memóriát foglalják el, és minél gyorsabban hajtsák végre az adott feladatot. Léteznek olyan eljárások, amit csak a program végén ajánlatos elvégezni, hogy a program egészét ne változtassuk, tehát a működésben ne változtassunk.
31
3.14.1 Array, Vector típusok Sok helyen használtam a programban Array-t, mely a Flash-ben régóta jelenlévő, kényelmesen használható, rengeteg nélkülözhetetlen funkcióval ellátott tömb. A Flash 10-es verziójában bevezették a Vector típust, mely sokkal gyorsabb, és gyakorlatilag ugyanazokkat a funkciókat tudja mint az Array, viszont egy megkötés van, csak azonos típusú elemeket tartalmazhat. A mostani verzióban ezért már mindenhol Vector-t használok, ami jelentős sebességkülönbséget jelent.
3.14.2 MovieClip, Sprite, Bitmap A Flash-ben a leggyakrabban használt osztály a MovieClip, ám ez foglalja a legtöbb memóriát, ami sok esetben szükségtelen. Ha nem akarjuk használni az idővonalat a Flash-ben, és dinamikus változókat létrehozni benne, akkor a Sprite sokkal jobb választás (ami a MovieClip ősosztálya). A Sprite a legszűkebb olyan osztály, melynek az egér és érintés eseményeire fel tudunk iratkozni, de ha ezekre nincs szükségünk, akkor a Shape és a Bitmap osztály is megfelelő. A kettő között az a különbség hogy a Shape osztály tartalmaz egy graphics objektumot, amibe futási időben tudunk vektorosan rajzolni. Sok helyen a Bitmap osztályt használtam, és ahol szükségem volt az események kezelésére, ott a Sprite-ot. Általánosságban elmondható hogy mindig a legszűkebb osztályt használjuk, felesleges minden objektumot MovieClip típusúra állítani. Ezen kívül van még egy nagyon fontos művelet, melyet főleg mobil platformon használok, a cacheAsBitmap és a cacheAsBitmapMatrix. A cacheAsBitmap gyakorlatilag azt segíti, hogy a memóriában létrehoz egy bitmap-ot arról a megjelenítő objektumról, amire beállítjuk, ezután sokkal gyorsabban tudjuk mozgatni, de ha forgatni vagy méretezni akarjuk, mindig új képet állít elő, ami nagyban lassítja a programot. Ezzel ellentétben a cacheAsBitmapMatrix ezen felül megengedi, hogy változtassuk a méretét, és forgassuk is.
3.14.3 Átméretezés, forgatás Az előző verziókban megfigyeltem, hogy ha elforgatjuk a készüléket, akkor egy Event.OrientChanged esemény lefutott, amit az updateDisplay-hez kötöttem, ezáltal minden elem újrapozicionálódott, és a mérete is változott. Ez nagyon sok processzoridőt 32
és memóriát elvesz, ezért az új verzióban ezt kivettem, helyette csak egy állásban lehet használni a programot, ami úgy vettem észre még sokkal jobban használható, hisz nem zavarja össze a felhasználót, hogy milyen irányba forgatta az eszközt.
3.14.4 MouseEvent, TouchEvent A Flash-ben ha az egér által kiváltatott események helyett, azaz a MouseEvent helyett, az érintésérzékeny eseményeket figyeljük (TouchEvent) , gyorsulást figyelhetünk meg, hiszen érintőképernyős esetben is működik a MouseEvent, viszont futási időben a Flash-nek át kell konvertálnia TouchEvent-re, ami plussz időt jelent.
3.14.5 Memóriakezelés, nem használt objektumok törlése Az egyik legfontosabb optimalizáció, a memória felügyelete, tehát ne hagyjunk semmit a memóriában, amit nem használunk már, illetve ha egy objektum eseményeit nem akarjuk tovább figyelni, iratkozzunk le róla. Általában ez elég nehéz és sok időt vesz igénybe, ha csak utólag foglalkozunk vele, ezért ezt folyamatosan szem előtt kell tartani. Előre definiálnunk kell az osztályokban olyan függvényt, mely kivülről meghívva törli a megfelelő objektumokat és rá való hivatkozásokat, ez nálam a dispose(). Azt, hogy ez megfelelően működik, minden esetben a profiler nézetben tudjuk ellenőrizni, amely megmutatja hogy egy osztályból hány példány jött létre és mennyi a memóriafoglalása. A dispose() függvény az objektumokat törli, tehát null-ra állítja az értékét, ami előtt szükség lehet őt levenni a megjelenítő listáról, illetve törölni az eseményeit.
3.15 Továbbfejlesztési lehetőségek Az órai konzultációk, és az óvodai tesztelések során rengeteg ötlet és továbbfejlesztési lehetőség merült fel, mely már nem kerülhetett bele a programba, de későbbiekben megvalósítható. Az egyik ilyen lehetőség, ami talán a program pegagógiai felhasználását legjobban elősegíti, a kezelőfelület finomhangolásának beállítása. Ez egy külön ablakban 33
valósulna meg, ahol be lehet állítani korcsoportok szerint az eszközök lehetőségeit. Például alacsonyabb korosztályban úgy láttuk hogy a 16 szín elég, ám idősebb korban lehetőség lenne sokkal több szín elhelyezésére, akár egy color picker segítségével. Ezen kívül a fiatalabb korosztály gyakran alkalmazza a lehetőséget hogy új lapokat hozzon létre, illetve hogy mozgassa a szereplőket, átmérezette őket, ezt is le lehetne tiltani, illetve engedélyezni. Ezeket a beállításokat egy xml-ben tárolhatnánk előre definiálva, mely ugyanúgy a dokumentumok mappában lenne megtalálható. A hang készítése is egy érdekes továbbfejlesztés, ahol saját hangokat tudunk felvenni. Ez asztali környezetben és tablet-en is működne, hisz az AIR támogatja a mikforon használatát. A probléma a tárolás lenne, de ez történhetne mp3-ban, amit szintén meg lehet valósítani. A rajzok módosítása egyelőre a mozgatást, méretváltoztatást, forgatást tartalmazza, de a program további verzióiban lehetőség lenne animációk készítésére is, utána pedig ezen animációk lejátszására egyben. A konzultációk alatt felmerült a fényképezés lehetősége, mely már más programokban megvalósult és a gyermekek nagyon szerették. Asztali környezetben ez történhetne kamerával, a Galaxy tab, illetve az iPad 2 pedig tartalmaz beépített kamerát, mellyel nagyon könnyen lehetne saját fotókat készíteni. Ezek a képek utána a rajzlapra kerülnének, ahol módosítani, átszinezni lehetne őket, illetve egyes részleteket kitörölni. A rajzok egyelőre egyedi rajzok, tehát csak rajzonként 1 db-ot tartalmazhat egy projekt, amit szeretnénk duplikálni, ez a továbbfejlesztés közvetlenül az óvodai tesztelés közben jött elő. Ezen kívül ami még a rajhoz kapcsolódik, hogy tudjunk külső képeket is betölteni, egy könyvtárból, ahova a szülők tudnának előre megrajzolt elemeket helyezni.
34
4 Felhasznált irodalom
1. http://www.microsoft.com/presspass/press/2002/Jun02/0625TechXUmbrellaPR.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.engadget.com/2010/01/27/the-apple-ipad/ , letöltés ideje: 2011.04.28. 10:30 4. http://www.adobe.com/devnet/actionscript/articles/actionscript3_overview.html, letöltés ideje: 2011. 05. 10. 17:00 5. http://help.adobe.com/en_US/flashbuilder/using/index.html, letöltés ideje: 2011. 05. 10. 17:00 6. http://help.adobe.com/en_US/flex/mobileapps/index.html, letöltés ideje: 2011. 05. 10. 17:00
35
Mellékletek 1. számú melléklet: Képek a programból
1.1 Nyitóképernyő az új és a megnyitás ikonnal
1.2 Projektek böngészése nézet, 3 létező projekttel
36
1.3 Rajzlapok nézet, 4 létrehozott rajzlappal
1.4 Rajzlap nézet, melyen az ecset sárga színnel aktív
37
1.5 Rajzlap, rajzolás közben, fehér ecsettel kiválasztva
1.6 Rajzlapok nézet, a kész rajzzal,
38
1.7 A hosszú érintésre felugró műveletek a rajzlapok nézeten
39
2. számú melléklet: A program felépítése, osztálydiagrammok
Az MVC felépítése
40
A program osztálydiagrammja
41
3. számú melléklet: Képek a fejlesztőkörnyezetről
42
