Úvod - gjgt · web viewÚvod do vývoja mobilných aplikácií mobilné aplikácie sú v tejto...
TRANSCRIPT
Gymnázium Jozefa Gregora TajovskéhoTajovského 25, 974 01 Banská Bystrica
STREDOŠKOLSKÁ ODBORNÁ ČINNOSŤ
č. odboru: 11Informatika
AIRDANCE – realizácia multiplatformovej aplikácie typu klient – server
Riešiteľ2013 Juraj PančíkSlovenská Ľupča ročník štúdia: tretí
Gymnázium Jozefa Gregora TajovskéhoTajovského 25, 974 01 Banská Bystrica
STREDOŠKOLSKÁ ODBORNÁ ČINNOSŤ
č. odboru: 11Informatika
AIRDANCE – realizácia multiplatformovej aplikácie typu klient – server
Riešiteľ2013 Juraj PančíkSlovenská Ľupča ročník štúdia: tretí
KonzultantDoc. RNDr. Juraj Pančík, CSc.
Čestné prehlásenie
Ja, Juraj Pančík, čestne prehlasujem, že som prácu „AIRDANCE – realizácia multiplatformovej aplikácie typu klient – server“ vypracoval sám za pomoci uvedenej literatúry.
V Slovenskej Ľupči, 1. marca 2013
Juraj Pančík
Poďakovanie
Chcem sa poďakovať mojim rodičom za všetku podporu pri tvorbe tejto práce. Vytvárajú mi
doma prijemné prostredie, kde veľmi rád pracujem. Sú ochotní tolerovať, že neraz ostávam
do neskorého večera za počítačom.
Mojim spolužiakom a triednej učiteľke z Gymnázia Jozefa Gregora Tajovského za ich vždy
prítomnú podporu a motiváciu.
Obsah
1 Úvod.........................................................................................................................3
2 Problematika a prehľad literatúry............................................................................4
2.1 Úvod do vývoja mobilných aplikácií................................................................4
2.2 Definícia pojmov aplikácia a mobilná aplikácia..............................................4
2.3 Definícia architektúry klient – server...............................................................4
2.4 Definícia platformy...........................................................................................4
2.5 Definícia multiplatformovej mobilnej aplikácie..............................................5
2.6 Životný cyklus aplikácie...................................................................................5
2.7 Správa požiadaviek a procesné modely............................................................5
2.8 Modelovanie aplikácií v jazyku UML..............................................................6
3 Ciele práce...............................................................................................................7
3.1 Hlavný cieľ práce.............................................................................................7
3.2 Čiastkové ciele práce........................................................................................7
4 Materiál a metodika.................................................................................................8
4.1 Opis vývoja AIRDANCE.................................................................................8
4.2 Opis projektu AIRDANCE.............................................................................11
5 Výsledky práce.......................................................................................................16
6 Závery práce a diskusia..........................................................................................17
7 Zhrnutie..................................................................................................................18
8 Resumé...................................................................................................................19
9 Zoznam použitej literatúry.....................................................................................20
10 Zoznam príloh a obsah DVD-ROM/elektronickej prílohy................................21
2
1 Úvod
V každodennom živote sa v rozvinutých krajinách stretávame s viacerými
elektronickými zariadeniami, ktoré sú založené na nových mobilných platformách.
Zvládnutie uceleného riešenia pre vývoj na tieto platformy by poskytovalo ohromnú
príležitosť na pracovnom trhu a zároveň zefektívnenie prác v existujúcich organizáciách.
Mobilné aplikácie poskytujú pre ešte neznámych a mladých vývojárov, takých ako
som ja, jedinečnú možnosť ako sa presadiť a možno spôsob, ako si na seba v budúcnosti
zarobiť.
Predmetom tejto práce je opis kompletného procesu vývoja multiplatformovej
mobilnej aplikácie - hry, typu klient – server s názvom AIRDANCE. Zmysel použitia
architektúry typu klient – server som videl v čoraz väčšej potrebe používateľov po sociálnom
kontakte pri používaní mobilných aplikácií. Navyše, prezentovaná mobilná aplikácia je hra,
kde je takýto kontakt preferovaný. Multiplatformová aplikácia spočíva v tom, že mnou
navrhnutá aplikácia je spustiteľná na rôznych platformách, t.j. operačných systémoch (napr.
smartfón s operačným systémom Android alebo personálny počítač s operačným systémom
Windows alebo Linux a podobne).
Cieľom predkladanej práce je nielen navrhnúť a zrealizovať multiplatformovú
aplikáciu AIRDANCE, ale aj zrealizovať efektívne riešenia pre všetky problémy, ktoré sa
pri takomto vývoji môžu vyskytnúť. Každý, kto si prečíta túto prácu, by mal dostať prehľad
o základných problémoch a ich riešeniach pri multiplatformovom vývoji.
Skúsenosti s vývojom hry pre mobilné zariadenia som mal už pred začatím projektu
AIRDANCE (operačný systém Android, hra Meteorites – dá sa stiahnuť z Google Play).
Chcel som sa však vo vývojárskej práci zdokonaliť a postupovať a pracovať podľa určitých
princípov vývoja softvéru (Pančík, 2012).
V druhej kapitole sa venujem definícii pojmov, sú tam opísané niektoré zo
základných postupov pri vývoji mobilných aplikácií. Tretia kapitola jasne a stručne deklaruje
hlavný a vedľajšie ciele tejto práce. Ďalej, v štvrtej kapitole, je popísaná kompletná metodika
vývoja, od požiadaviek, ktoré vyplývajú z cieľov práce, cez ich rozvoj až ku ich finálnej
implementácii aplikácie. Práca nerieši len teoretickú úroveň problému, ale aj praktickú.
Výsledky práce, závery a diskusia sa nachádzajú za štvrtou kapitolou.
3
2 Problematika a prehľad literatúry
2.1 Úvod do vývoja mobilných aplikácií
Mobilné aplikácie sú v tejto dobe veľmi rozšírené a je to ideálna cesta pre mladých
vývojárov na získanie nových zákazníkov. Atraktívnosť tejto mobilnej platformy však
predstavuje nové problémy. Často je väčšina problematiky zdokumentovaná priamo od
výrobcu mobilnej platformy, avšak počas vývoja a testovania sa prakticky nedá nenaraziť na
problémy, ktoré sú jedinečné pre dané zariadenie. Je veľmi veľa typov mobilných zariadení,
ktoré majú rozdielne veľkosti obrazoviek, rôzne veľkosti pamäte RAM alebo aj rôzny výkon
grafického procesora a výpočtového procesora. Nehovoríme o rozdielnych rozhraniach medzi
jednotlivými komponentmi zariadenia, ako napríklad kamera, prístup k internetu alebo
zvukové a grafické drajvre. Vývoj je veľmi náročný, ale dobre navrhnutý systém je schopný
fungovať na väčšine zariadení bez problémov.
2.2 Definícia pojmov aplikácia a mobilná aplikácia
Aplikácia je súhrn programov, jedného alebo viacerých. Programy sa špecializujú na
jednotlivé aktivity, ako vykreslenie na obrazovku alebo načítavanie z dát. Program je
formulácia jedného alebo viacerých algoritmov v programovacom jazyku. Algoritmus
vyznačuje presný a jednoznačný postup na vyriešenie konkrétneho problému. Dôležitosť
algoritmu je v tom, že ho môžeme viac krát opakovať a má deterministický výsledok na
základe vstupu (Pour, a iní, 2009) .
2.3 Definícia architektúry klient – server
Aplikácia klienta (ďalej len klient) je aplikácia, ktorá je spustená u koncového
používateľa. Server je služobná aplikácia (ďalej len server) pre klientsku aplikáciu, zaisťuje
mu spracovanie jeho špecializovaných požiadaviek. U serverov sa predpokladá, že sú
spustené ihneď po štarte operačného systému, aby boli trvalo dostupné klientom. Klient má
preddefinovaný súbor požiadaviek a server je navrhnutý a zrealizovaný na základe znalosti
tohto súboru, preto server je veľmi úzko spätý s klientom (Pour, a iní, 2009) .
2.4 Definícia platformy
Platforma zahŕňa hardvérovú architektúru a softvérový programový rámec, ktorého
kombinácia umožňuje aplikačnému softvéru (t.j. aplikácii) beh. Platformy zvyčajne obsahujú
operačný systém, programovací jazyk a grafické rozhranie pre používateľa (WIKI, 2013).
4
2.5 Definícia multiplatformovej mobilnej aplikácie
Multiplatformová mobilná aplikácia je schopná bežať na viacerých platformách,
v našom prípade je aspoň jedna z nich mobilná. Napríklad, to môže byť platforma
personálneho počítača PC a Android, teda mobilná, platforma.
2.6 Životný cyklus aplikácie
Aplikácia od svojho počiatku prechádza svojimi vývojovými fázami a po určitej dobe svojho
chodu a rozvoja sa vracia na svoj začiatok, kde sa pripravuje vyššia úroveň aplikácie pre danú
oblasť, založená na nových aktuálnych technológiách a zodpovedá celkom novým potrebám
používateľov (Arlow, a iní, 2008).
Životný cyklus aplikácie sa delí takto:
1. Plánovanie a príprava aplikácie
2. Analýza a návrh aplikácie
3. Implementácia aplikácie
4. Zavedenie do chodu, migrácia
5. Chod a používanie aplikácie
6. Rozvoj a optimalizácia aplikácie
2.7 Správa požiadaviek a procesné modely
Rozlišujeme dva typy požiadaviek:
Funkčné – špecifikujú požiadavky na funkčnosť systému
Nefunkčné – špecifikujú isté vlastnosti systému, prípadne podmienky
obmedzujúce fungovanie systému.
Požiadavky by mali vyjadrovať to, čo bude systém ponúkať, a nie ako by to mal robiť.
Požiadavka je teda špecifikácia funkcie alebo vlastnosti systému. Zlyhanie správy
požiadaviek môže viesť ku kompletnému zlyhaniu funkčnosti projektu (Kanisová, a iní,
2007).
Procesné modely sa rozdeľujú na diagram hierarchie procesov a diagram procesných
vlákien. Diagram hierarchie procesov rozkladá procesný rozpad systému a pomáha nám
ujasniť rozsah vyvíjaného systému, jeho modularitu a vzájomné súvislosti medzi
jednotlivými procesmi na ich najvyššej úrovni. Diagram procesných vlákien je veľmi
zrozumiteľný aj pre človeka ktorý o ňom nikdy nepočul. Touto technikou modelujeme
udalosti, ktoré inicializujú spúšťanie firemných procesov a taktiež výsledok procesu.
5
Procesný reťazec je začatý vstupnou udalosťou a ukončený procesným výsledkom (Kanisová,
a iní, 2007).
2.8 Modelovanie aplikácií v jazyku UML
Modelovací jazyk UML (Unified Modeling Language, Zjednotený Modelovací Jazyk)
je výsledkom snaženia analytikov a dizajnérov o nájdenie metódy ktorá efektívne a
prehľadne umožní popísať objektovo orientovanú analýzu a návrh. K tomuto slúžia grafické
diagramy. Jazyk UML poskytuje možnosť modelovať jednoduché aj zložité aplikácie
jednotným jazykom. Vizuálne modely sú veľmi jednoducho pochopiteľné a možno ich
jednoducho navrhnúť. Je to jazyk na vizualizáciu, špecifikáciu, stavbu a dokumentáciu
softvérových systémov (Kanisová, a iní, 2007) (Arlow, a iní, 2008).
6
3 Ciele práce
3.1 Hlavný cieľ práce
Hlavným cieľom práce je navrhnúť a zrealizovať aplikáciu – hru typu klient – server
s názvom AIRDANCE, kde klient bude spustiteľný a zároveň plne funkčný na viacerých
platformách. To znamená, že naša aplikácia musí mať rovnaké, deterministické správanie na
počítači typu PC a aj na mobilnom zariadení s operačným systémom Android. Klient musí
byť schopný pracovať nezávisle od servera a ak je možné sa pripojiť na server, asynchrónne
bude aktualizovať a získavať dáta, ktoré sa následne klientom zobrazia. Server musí byť
schopný fungovať nepretržite a odpovedať na požiadavky od viacerých klientov.
3.2 Čiastkové ciele práce
1. Klient sa musí vedieť prispôsobiť na všetky typy obrazoviek (displejov),
pretože nemôžeme dopredu predpokladať aké parametre bude mať platforma
na ktorej je klient spustený.
2. Ako grafická aplikácia, je nutné čo najviac optimalizovať spôsob
vykresľovania pre čo najlepší výsledok a plynulosť aj na starších zariadeniach
každej platformy.
3. Klient je perzistentný, to znamená, že ukladá svoje dáta na disk tak, aby vedel
z nich obnoviť stav po znovu spustení.
4. Server by mal byť odolný na pokusy o narušenie bezpečnosti a taktiež by mal
vedieť vyhodnotiť, kedy je vstup od klienta nesprávny, to znamená, že nebol
odoslaný od autentického klienta.
5. Komunikácia medzi serverom a klientom musí byť ochránená pred rušením
siete a jej výpadkami.
6. Server počíta s nečakanými vypnutiami, napríklad kvôli výpadku elektrickej
energie, a preto by mal pravidelne zálohovať všetky uložené dáta klientov a po
výpadku by mal byt schopný ich znova načítať.
7
4 Materiál a metodika
4.1 Opis vývoja AIRDANCE
4.1.1 Požiadavky na AIRDANCE
Ako prvú vec si potrebujeme zadefinovať súbor požiadaviek pre klientsku aplikáciu:
1. Aplikácia musí byť spustiteľný a plne funkčný program na rôznych
platformách, t.j. pod Windows a na mobilných zariadeniach so systémom
Android
2. Musí existovať grafické rozhranie na vykresľovanie aplikácie
3. Aplikácia sa bude prispôsobovať veľkosti okna v ktorom beží
4. Aplikácia sa vie pripojiť na server, vie poslať a získať z neho dáta
5. Aplikácia ukladá svoj stav na lokálny disk, aby sa vedela doňho po opätovnom
spustení dostať
6. Chceme urobiť interaktívnu aplikáciu, konkrétne jednoduchú hru, používateľ
bude dvoma prstami ovládať naklonenie svojho vznášadla a stúpať cez
náhodne generovaný „level“, a ak narazí do steny, odošle svoje skóre na server
pod ľubovoľným menom, ktoré zadá
Ďalej nasledujú požiadavky aplikácie určenej pre server:
1. Server musí byť program spustiteľný na operačnom systéme typu Linux kvôli
jeho jednoduchému hostingu (bezproblémový chod a inštalácia serverového
programu)
2. Server ukladá svoj stav na lokálny disk v časovom intervale kvôli menšiemu
zaťaženiu
3. Server by mal byť schopný odpovedať viacerým klientom naraz, bez
uprednostňovania jednotlivých klientov
4. Server môže bežať nepretržite aj niekoľko dní bez reštartu
5. Server musí zachytávať pokusy o narušenie integrity a bezpečnosti servera,
ktoré efektívne eliminuje a zároveň informuje o nich správcu
6. Server odpovedá klientovi na žiadosti o výške skóre pre meno, alebo
všeobecne vráti klientovi určitý počet najvyšších skóre, tiež prijíma správy
o navýšení skóre
8
4.1.2 Analýza
Klient by mal byť založený na jednotnej báze kódu, ktorá bude pracovať s knižnicou
ktorá skrýva do seba dve rozdielne implementácie ľubovoľnej jej funkcie pre každú
platformu. Takto sme schopní neduplikovať kód aplikácie, a veľmi sa zjednodušuje vývoj.
Grafická knižnica by mala byť čo najrýchlejšia pre každú platformu. Dáta ukladané na
lokálny disk musia byť uložené v binárnej alebo textovej forme. Aplikácia musí zachytávať
vstup a mať prístup na internet.
Server ukladá svoj stav na disk tiež v binárnom alebo textovom formáte. Po štarte
servera musí najprv načítať dáta, až potom začne vybavovať žiadosti. Tiež musí ukladať
logovacie výpisy na disk, aby mal ku ním správca jednoduchý prístup.
4.1.3 Návrh
Ako ideálne riešenie pre klienta je použiť voľne dostupné knižnice, ktoré umožňujú
multiplatformový vývoj. Tieto knižnice poskytujú základný prístup ku jednotnej grafickej
knižnici pre všetky platformy, zachytávanie vstupu a výstupu zvuku. Ako grafickú knižnicu
je vhodné použiť takú, ktorá používa rasterizáciu ako kresliaci proces a táto je akcelerovaná
grafickým procesorom. Je to najefektívnejšia metóda a aj najrýchlejšia, hlavne na pomalších
Android zariadeniach. Dáta sa jednoduchšie ukladajú v textovej forme, a preto ich stačí držať
všetky, ktoré chceme uchovať, v jednom objekte a tento ich vždy zoserializuje do reťazca
znakov, ktorý sa dá následne jednoducho uložiť. Aplikácia by mala fungovať aj bez prístupu
na internet.
Server bude tiež svoje dáta ukladať v textovom formáte a všetky jeho dáta budú
uložené v jednom objekte, ktorý sa následne pri ukladaní na disk, zoserializuje. Keďže miesto
na disku nie je neobmedzené, server musí kontrolovať pri ukladaní, či netreba uvoľniť miesto
pre kompletné uloženie dát.
4.1.4 Implementácia
Čo sa týka programovacieho jazyku, ideálna voľba je Java, pretože je flexibilná
a dokáže okamžite fungovať na všetkých zariadeniach s implementovanou Java Virtual
Machine. Pre Javu je ako multiplatformová knižnica dostupná open-source knižnica
LibGDX, ktorá má zjednotený vstup a poskytuje vhodnú jednotnú grafickú rasterizačnú
knižnicu OpenGL a jednotnú zvukovú knižnicu OpenAL. Je určená pre vývoj aplikácií
a preto ma množstvo pomocných funkcií pre vývoj herných aplikácií. Na ukladanie dát je
možno použiť formát JSON, ktorý je často používaný aj na webových stránkach
9
využívajúcich JavaScript. Ak chceme serializovať a deserializovať formát JSON v Jave,
oplatí sa použiť knižnicu Gson kvôli jej malej veľkosti. Dáta by mali byť ukladané priebežne,
nakoľko používateľ môže ukončiť aplikáciu v ktoromkoľvek momente. Hra sa skladá
z obrazoviek, ako napríklad hlavná obrazovka, alebo obrazovka hry. Tieto obrazovky
obsahujú prvky používateľského rozhrania ako tlačidlá, ktoré sa budú prispôsobovať veľkosti
obrazovky v ktorej beží aplikácia. Všetko iné, ako prvky používateľského rozhrania, budú len
adekvátne zmenšené alebo zväčšené. Na pripojenie ku serveru možno použiť TCP protokol,
ktorý zaručuje bezchybný presun informácií medzi klientom a serverom. Ak sa chceme
vyhnúť natívnej implementácie TCP protokolu v Jave, môžem použiť knižnicu KryoNet.
Server použije tiež Gson serializáciu a KryoNet na odpovedanie klientom. Dáta bude
ukladať vo forme rotovacích súborov, to znamená, že naraz bude uložených napríklad
posledných 5 dní. Ak server potrebuje načítať dáta, jednoducho prevezme poslednú zálohu.
Vypisovanie logovacích zápisov bude tiež vo forme rotovacích súborov.
4.1.5 Testovanie
Testovanie klienta prebehne na Windowse a viacerých Android zariadeniach. Klient
musí minimálne byť spustiteľný, hrateľný a musí sa vedieť pripojiť na server, odoslať
a získať z neho dáta. Prvky používateľského rozhrania musia byť plne viditeľné a dobre
rozložené na každej obrazovke aplikácie. Zlyhanie tejto podmienky by znamenalo možnosť,
že bude aplikácia nepoužiteľná na niektorých zariadeniach. Ak má byť klientska aplikácia
uverejnená, treba vytvoriť zoznam minimálnych požiadaviek na zariadenie, aby sa potom
dala vylúčiť podpora istých zariadení.
Server musí spĺňať viacero podmienok, musí vždy spracovať všetok vstup ktorý
dostane, a deterministicky musí vrátiť rovnaký výstup pre každú žiadosť od klienta. Ďalej by
mal byť schopný zvládnuť viacero klientov naraz, server by tiež mal byť schopný sa vrátiť do
stavu pred výpadkom, preto treba testovať aj tieto varianty.
10
4.2 Opis projektu AIRDANCE
4.2.1 Zahájenie
Na zahájenie potrebujeme pripraviť všetky potrebné nástroje. Nainštalujeme vývojové
prostredie Netbeans, na vývoj a spúšťanie aplikácií na Androide Eclipse SDK + ADT Plugin,
Android SDK, program na prácu s grafikou GIMP, program na prácu so zvukom Audacity.
Veľmi užitočná vec pri väčších projektoch je aj verziovanie kódu, my sme použili Git
s hostovaním na BitBucket.org. Stiahneme knižnice LibGDX, KryoNet, Gson a sme
pripravený na vývoj.
4.2.2 Plánovanie projektu
Keďže z návrhu možno vidieť, že server bude maličká aplikácia oproti klientskej, je
rozumným krokom začať vývoj najprv s klientom a keď je hotový z väčšej časti klient,
možno pristúpiť ku vývoju servera.
V klientovi bude najprv na implementovaná základná štruktúra LibGDX, následne
začne implementácia tzv. „engin-u“ (jadra) hry, ktorý sa bude starať o celú hernú logiku.
Herná logika sa skladá z náhodného generovania levelov, fyzikálnej simulácie vznášadla a
detekcii kolízií so stenami levelu. Hra bude prakticky jeden level, ktorý sa vždy vygeneruje
dopredu podľa potreby. Ide o to, ako keby vznášadlo letelo cez neustále sa meniacu jaskyňu.
Potrebné bude procedurálne generovať prekážky pred sebou a zároveň zabúdať prekážky za
sebou, aby sa limitovalo množstvo využitej pamäte pre hernú logiku. Jaskyňa môže byť
zložená z horizontálnych obdĺžnikov na ľavej a pravej strane, ktoré budú vždy rovnako
vysoké. Na detekciu kolízií budeme používať polygón definovaný okrajmi nášho vznášadla
a spomenuté prekážkové obdĺžniky. Ak je prienik polygónu s niektorým prekážkovým
obdĺžnikom, môžeme povedať, že vznášadlo zhavarovalo a malo by vybuchnúť, teda hra sa
skončí. Keď bude implementovaná kompletná herná logika, to znamená už možno letieť, buď
dvoma prstami na zariadení Android alebo ľavou a pravou šípkou na Windowse cez náhodne
generovaný level, bude sa dať naraziť do steny, po čom hra skončí, začnú sa pridávať herné
prvky, ako ukladanie záznamov, t.j. akú najväčšiu vzdialenosť vznášadlo prešlo bez
narazenia a bonusové predmety so skóre, ktoré sa dajú zbierať. Skóre sa potom sčítava a hráč
si môže zaň zakúpiť vylepšenia vznášadla alebo iný výzor vznášadla. Rekord vzdialenosti
a skóre budú ukladané na disk a budú sa uchovávať medzi jednotlivými spusteniami
aplikácie. Potom sa môže pristúpiť ku implementácii prvkov používateľského rozhrania ako
sú tlačidlá, alebo text na obrazovke, vytváraniu samotných obrazoviek a aj zvukových
11
efektov. Takto je prakticky takmer celá klientska aplikácia hotová a môžeme pristúpiť ku
vývoju servera. Server bude mať voči klientovi nasledovné správanie: po tom ako sa klient
pripojí, pošle mu náhodne vygenerovaný identifikačný kľúč, ktorým sa musí vždy klient
identifikovať. Potom môže klient pracovať so serverom troma rôznymi spôsobmi. Buď si
vyžiada od serveru skóre najvyšších niekoľko miest pre časový interval vo formáte
<deň/týždeň/mesiac>, alebo si vyžiada skóre od serveru pre všetky mená ktoré začínajú
textom, ktorý klient zadal tiež pre formát <deň/týždeň/mesiac>, alebo pridá skóre pre nejaké
meno. Server drží pre každé meno tieto premenné, sčítané skóre a hodnotu rekordnej
vzdialenosti, drží ich trikrát pre deň, týždeň a mesiac. Každý deň, týždeň a mesiac sa o
polnoci vymažú pre daný časový interval všetky údaje. Potom si uloží na disk stav, a ak je
záloh viac ako zadaná konštanta, vymaže tú poslednú existujúcu.
4.2.3 Realizácia projektu
Hlavná kostra grafickej knižnice LibGDX sa skladá zo šiestich členských funkcií –
inicializácia aplikácie, vykreslenie aplikácie, zmena veľkosti aplikácie, prerušenie aplikácie,
pokračovanie po prerušení aplikácie a ukončenie aplikácie. Vykreslenie bude volané najviac
60 krát za sekundu, takže nie je nutné implementovať vlastný časovač. V štarte aplikácie
načítame všetky grafické podklady, aby sme ich následne vedeli vykresľovať, uvoľníme ich
z pamäte až keď sa aplikácia ukončí. To isté platí aj pre zvukové súbory. Všetko ostatné bude
uložené v objekte obrazovka, ktorý bude mať členské funkcie – inicializácia, aktualizácia,
vykreslenie hry, vykreslenie prvkov používateľského rozhrania a ukončenie. Rasterizácia
používa na vykresľovanie matice, konkrétne projekčnú maticu, pohľadovú maticu a svetovú
maticu. Keď máme bod v priestore a vynásobíme ho týmito troma maticami, dostaneme
súradnice x a y ktoré reprezentujú pozíciu na obrazovke. Svetová matica slúži na posunutie
bodu v priestore, pohľadová matica zas upraví polohu bodu podľa toho ako by sme ju videli
a projekčná prevedie bod na finálne dve súradnice. LibGDX poskytuje pomocný objekt
ortografická kamera ktorá pomáha pre dvojrozmerné priestory vytvoriť pohľadovú maticu.
Toto nám umožňuje jednoducho približovať a odďaľovať pohľad. Preto budú v aplikácii
existovať dve ortografické kamery. Jedna bude slúžiť na vykreslenie herného sveta, to
znamená bude sa pohybovať a odďaľovať podľa veľkosti obrazovky, aby sa na každej
obrazovke približne vykreslila rovnaká časť herného sveta. Druhá bude pre prvky
používateľského rozhrania, bude vždy centrovaná na stred obrazovky. Vykresľovanie
aplikácie bude prebiehať takto:
1. Zachytí sa všetok vstup z klávesnice a myšky
12
2. Zavolá sa metóda aktualizácia na objekt obrazovky, ktorá ju aktualizuje aj na
základe vstupu
3. Vyčistí sa obrazovka od posledného vykresleného obrázku
4. Ako pohľadová matica sa nastaví tá ktorú vygeneruje herná ortografická
kamera
5. Zavolá sa metóda vykreslenie hry ktorá vykreslí engine hry
6. Pohľadová matica sa zmení na ortografickú kameru pre prvky
používateľského rozhrania
7. Zavolá sa metóda vykreslenie prvkov používateľského rozhrania
Obrazovka môže počas svojej aktualizácie zmeniť aktuálnu obrazovku za inú,
napríklad používateľ v obrazovke hlavného menu stlačí tlačidlo na spustenie hry, obrazovka
hlavného menu oznámi, že terajšia obrazovka sa má zmeniť na obrazovku hlavnej hry a už od
ďalšieho vykreslenia je aktuálna obrazovka hlavnej hry. Takto sa zabalí každá obrazovka do
vlastného objektu a zjednodušuje vývoj pre jednotlivé obrazovky. V konečnej hre je
implementovaných niekoľko rôznych obrazoviek ale poďme sa bližšie pozrieť na realizáciu
obrazovky rebríčka skóre a obrazovky hlavnej hry. Obrazovka hlavnej hry obsahuje engine
v ktorom je zakomponovaná celá logika hry, ďalej obsahuje prvky používateľského
rozhrania. Engine obsahuje viacero komponentov:
Level Manager sa stará o generovanie levelu a zisťuje či nejaký bod koliduje
s levelom
Entity Manager obsahuje všetky entity, v tomto prípade to je vznášadlo alebo jeho
časti
Collision Manager pri každej aktualizácii skontroluje či žiadny s bodov ktorý definuje
polygón vznášadla nekoliduje
Particle Manager sa stará o vizuálne efekty, ako napríklad výbuchy
Čo sa týka používateľského rozhrania, všetky prvky sú zadefinované pomocou
horizontálneho priradenia a vertikálneho priradenia. To znamená že tlačidlo môžeme
napríklad umiestniť horizontálne zľava posunuté o 50 pixlov a vertikálne zo spodku posunuté
o 25 pixlov. Tlačidlo je teda vždy zarovnané, nezáleží na veľkosti obrazovky, problém však
nastáva, ak by bola obrazovka tak malá, že by sa niektoré tlačidla mali prekrývať. Preto sme
implementovali nasledujúce riešenie. Ak je veľkosť obrazovky menšia ako 800 pixlov na
šírku alebo 480 pixlov na výšku, obidve ortografické kamery ostanú na veľkosti 800 pixlov
a 480 pixlov a následne sa premietnu na menšiu obrazovku. To znamená, že ak je obrazovka
13
menšia, používateľské rozhranie sa prestane zarovnávať a namiesto toho je zarovnané podľa
obrazovky 800 krát 480 pixlov akurát sa proporčne zmenší, tak aby presne pasovalo na
obrazovku. Uveďme si príklad, máme tlačidlo zarovnané z ľavého horného rohu o 10 pixlov
doľava a 10 pixlov dole. Používateľ má obrazovku o veľkosti 800x480 a tlačidlo je
zarovnané rovnako ako zadefinované. Obrazovka sa zmení na 1280x800 a tlačidlo stále
nezmení svoju veľkosť ani pozíciu. Avšak obrazovka sa následne zmení na 320x240 kde sa
tlačidlo zarovná podľa 800x480 a celý obraz sa zmenší na 320x240. Všetky prvky
používateľského rozhrania sú navrhnuté tak, aby fungovali pre 800x480. Týmto spôsobom je
zaručené že na všetkých veľkostiach obrazovky sa nebudú prekrývať. Avšak pri Android
zariadeniach narazíme aj na iný problém. Ak sú fyzicky dve obrazovky rovnako veľké,
neznamená to, že majú rovnaké rozlíšenie obrazovky, teda ak toto zanedbám, na niektorých
zariadeniach môžu byť tlačidla menšie. Preto pri spustení aplikácie je nutné zaznamenať dots
per ich hodnotu a ak je nutné, trošku ju zmenšiť. Potom stačí veľkosť tlačidla, jeho veľkosť
posunutia vynásobiť touto hodnotou, a naša aplikácia sa stáva DPI Independent, čo
v preklade znamená, že tlačidla budú mať rovnakú veľkosť na dvoch zariadeniach, ktoré
majú rovnakú fyzickú veľkosť displeja ale rozdielne hodnoty dpi. Týmto by sme mohli
ukončiť obrazovku hlavnej hry a prejsť ku obrazovke rebríčka skóre. Táto obrazovka
obsahuje viacero tlačidiel, ale podstatné je získavanie dát zo servera. Je nutné aby hra bola
responzívna aj keď chce vyžiadať dáta zo servera. Preto treba presunúť celé získavanie na
separátne vlákno procesora. Vlákno reprezentuje proces v počítači, vieme počúvať hudbu
a surfovať internet bez toho, aby sa hudba zasekávala, pretože dekódovanie hudby prebieha
na jednom threade a zas surfovanie na druhom. Presne rovnako je nutné, aby sa to správalo
pri získavaní dát. Vyžiadame dáta a zároveň ukazujeme používateľovi že aplikácia čaká na
odpoveď zo servera. Rovnaký princíp sa použije aj pri odosielaní dát. Použitie vlákien
predstavuje niekoľko synchronizačných problémov, ktoré treba vyriešiť, inak by sa aplikácia
mohla správať nedeterministicky. Ešte za zmienku pri klientovi stojí spôsob ako ukladá dáta
na disk. Všetky sú uložené v objekte profile ktorý je raz za sekundu skontrolovaný, či sa
v ňom niečo zmenilo. Ak áno, cez knižnicu Gson je zoserializovaný do reťazca znakov, ktorý
je triviálne uložiť na disk. Pri štarte aplikácie je zas profil deserializovaný zo súboru na disku,
ak existuje, čím sa uchováva stav medzi spusteniami. A takto sa dostávame ku realizácii
serveru. Najprv si presne zadefinujme čo bude server a klient medzi sebou posielať. Je to
správa o identikačnom kľúči klienta, správa o získaní skóre pre vrchných niekoľko skóre
alebo správa o navýšení skóre pre dané meno. Server teda pri spustení najprv skontroluje
súbor, v ktorom je uložený zoznám posledných záloh. Ak súbor existuje a nie je prázdny,
14
server deserializuje, znova s pomocou knižnice Gson, dáta a nastaví ich do svojho skladu.
Následne server otvorí TCP socket na porte 54555 a začne prijímať správy. O túto časť sa
stará KryoNet, poskytuje jednoduché rozhranie na odosielanie a príjem dát, s jedinou
nevýhodou, že server bude spracovávať dáta len na jednom threade. To je však zanedbateľné
pri malej aplikácii ako je táto. Server ma zapnutý timer ktorý oznamuje kedy má server
resetovať dáta pre deň, týždeň a mesiac. Timer tiež určuje kedy sa majú zoserializovať dáta
na disk. Po dokončení prác nasleduje poriadne pretestovanie každého komponentu.
O testovanie serveru sa postará jednoduchý klient, ktorý vygeneruje niekoľko mien a tie
pošle na server, následne server musí pre každú správu o stave skóre korektne odpovedať. Čo
sa týka testovania viacerých platforiem, je dôležité otestovať každú obrazovku hry na
viacerých počítačoch a zároveň aj na viacerých Android zariadeniach, ideálne na zariadení
s rozlíšením menším, rovným a väčším ako 800 pixlov na šírku a 480 na výšku.
4.2.4 Ukončenie
Po realizácii projektu ostáva ešte server niekde spustiť, teda nájsť miesto pre hosting.
Keďže server sa správa ako normálna Java SE aplikácia, nie je možné nájsť hosting zadarmo.
V čase písania práce je server spustený u mňa doma na maličkom počítači o veľkosti
kreditnej karty tzv. Raspberry Pi. Je to veľmi slabučký server, aj keď úplne ideálny pre
testovacie účely. Server by sme chceli časom presunúť na cloudový hosting od Amazon Web
Services, kde je prvý rok zadarmo. Keďže aplikácia je plne funkčná na Android zariadeniach,
ďalším krokom je uverejnenie na Google Play Store aby si to mohla stiahnuť široká
verejnosť.
15
5 Výsledky práce
Po ukončení prác nám vznikla hrateľná interaktívna multiplatformová aplikácia
s architektúrou klient - server s názvom AIRDANCE.
Aplikácia klient pozostáva z okolo 9500 riadkov kódu v programovacom jazyku
JAVA a aplikácia server z okolo 900 riadkov v JAVA, ktoré som sám napísal a odladil.
S pomocou hardvérovo akcelerovaného rasterizátora vykresľuje klientská aplikácia
AIRDANCE grafické podklady dodané v bežných formátoch. Prehráva hudbu a zvukové
efekty. Obsahuje kompletný herný systém, kde hráč môže preposielať svoje skóre na server,
vie zo serveru získať svoje skóre a skóre ostatných hráčov. Obsahuje náhodne generované
úrovne s prekážkami, vznášadlo, ktoré je založené na fyzikálnej simulácii a používateľ je
schopný svoje vznášadlo vylepšovať alebo meniť jeho výzor.
Klient je multiplatformovaný, funguje na väčšine dostupných počítačoch a navyše na
Android zariadeniach.
Zrealizovaný server AIRDANCE je schopný dlhodobého behu, zálohy vitálnych dát
a vie odpovedať viacerým klientom naraz. Klientská aplikácia sa okrem iného prispôsobuje
všetkým typom obrazoviek, čo je hlavne ideálne pre zariadenia Android. Z pohľadu
objektovo orientovaného dizajnu, dostáva sa nám do rúk projekt s jednoduchou údržbou a s
ľahkým rozvojom funkcionality do budúcnosti.
16
6 Závery práce a diskusia
Po dokončení aplikácie môžeme skonštatovať, že hlavný cieľ projektu AIRDANCE je
splnený. Úspešne sa nám podarilo zrealizovať aplikáciu – hru s architektúrou klient – server
a navyše to, že klient je spustiteľný na viacerých platformách. Podporuje až dokonca 4
platformy: Windows, Linux, Mac, Android.
Čo sa týka vedľajších cieľov, možno povedať, že boli tiež takmer všetky splnené.
Avšak, stále sa nájdu zariadenia, kde aplikácia nie je úplne funkčná, dosť často sa vyskytujú
problémy s klávesnicou na platforme Android alebo problémy s rýchlosťou behu programu.
Aj keď sa klient prispôsobí všetkým typom obrazoviek, pri istých konfiguráciách by sa
mohlo stať, že obraz by bol nepekne roztiahnutý. Položené základy riešenia prvkov
používateľského rozhrania je škálovateľný aj pre nové typy prvkov.
Práca prináša unikátny spôsob riešenia problému optimalizácie pre rôzne veľkosti
obrazovky a dal by sa využiť pri vývoji nielen mobilných aplikácií. Multiplatformovosť ako
taká, je veľmi dôležitý koncept hlavne pri vývoji. Stolný počítač je veľmi rýchly a vývoj len
na ňom nás ušetrí zbytočného presunu binárnych spustiteľných súborov na platformu pre
ktorú vyvíjame. Takto je prakticky možné vyvinúť drvivú väčšinu aplikácie na počítači
a potom ju len spustiť na zariadení s operačným systémom Android.
Server nie je až na toľko robustný, a môže sa v budúcnosti stať, že bude nestabilný.
Tiež nie je maximálne zabezpečený, a používateľ by bol schopný neférovo meniť skóre, aj
keď to je už riziko, ktoré prichádza s tým, že v architektúre máme anonymných klientov. Ak
sa pozrieme na ostatných vývojárov aplikácií pre Android, možno povedať, že sa stýkavajú
s rovnakými problémami a čo sa týka konkrétneho vzťahu klient – server, je teoreticky
nemožné vyvinúť odolný systém pred všetkými útokmi.
Ďalší rozvoj pre túto aplikáciu typu klient – server vidíme v rozširovaní podpory
platforiem. Práve teraz knižnica podporuje aj platformy HTML5 a iOS, akurát na podporu je
potrebné urobiť isté zmeny v kóde, ktoré môžu meniť kompletne celú architektúru aplikácie.
Server má potenciál pre veľký rozvoj a keďže je presne zadefinovaný súbor správ ako sa
môže klient a server dorozumieť, môžeme navrhnúť a vyvinúť kompletne nový server
a pritom spraviť len minimálne zmeny na klientovi. Ak sa stane že útoky na server budú
príliš časté, budeme musieť pristúpiť ku autorizácii klienta cez email a heslo.
17
7 Zhrnutie
Práca sa zaoberá kompletným vývojom multiplatformovej softvérovej aplikácie – hry
s architektúrou klient - server s názvom AIRDANCE, a to od počiatočnej definície
požiadaviek aplikácie až po samotnú implementáciu a testovanie. Multiplatformovosť prináša
so sebou niekoľko problémov, ktoré sme museli počas práce efektívne vyriešiť. Nakoľko
aplikácia je aj interaktívna, presnejšie hra, optimalizácia je veľmi potrebná a taktiež zaručenie
rovnakej hernej skúsenosti pre všetky typy platforiem a zariadení. Jeden zo závažných
problémov je podpora viacero typov veľkostí obrazoviek, ktorý je však elegantne vyriešený.
Úspešne je zrealizovaný typ aplikácie klient – server, kde server vybavuje špecifické žiadosti
od klienta a je dlhodobo dostupný a obsluhuje viac klientov naraz. Klient aj server využívajú
na svoju realizáciu niekoľko knižníc, čo urýchľuje vývoj a predstavuje menšiu chybovosť ako
pri písaní vlastných knižníc.
18
8 Resumé
Project is focusing on definite solution for developing cross-platform software
application with name AIRDANCE, from the initial definition of application requirements to
implementation of them and final testing. Developing for several platforms at the same time
is not an easy task and brings a lot of problems with it. This work presents an elegant solution
to most of them. Because the application is also an interactive game, optimization for
different kinds of hardware is required and so is the need for the same game experience on
every platform and device. One of the more serious issues is the support for multiple screen
sizes. This one is solved by nice and scalable solution. Successfully a client – server type of
application is created, where server is responding to specific requests from clients. Server is
capable of long up-times and serving multiple clients at the same time. Both, client and the
server, are built on several open-source libraries, which speeds up the development process
and is less error-prone than writing custom libraries from scratch.
19
9 Zoznam použitej literatúry
Arlow, Jim a Neustadt, Ila. 2008. UML2 a unifikovaný proces vývoje aplikací.
Brno : Computer Press, a.s., 2008. ISBN 978-80-251-1503-9.
Gson. 2012. [Online] 2012. http://code.google.com/p/google-gson/.
Kanisová, Hana a Muller, Miroslav. 2007. UML zrozumitelne. Brno : Computer
Press, a.s., 2007. ISBN 80-251-1083-4.
KryoNet. 2012. [Online] 2012. http://code.google.com/p/kryonet/.
LibGDX. 2013. [Online] 2013. http://code.google.com/p/libgdx/.
Pančík, J. 2012. Meteorites - Android Apps on Google Play. Google Play . [Online]
2012. [Dátum: 01. 03 2013.] https://play.google.com/store/apps/details?
id=com.pancik.android.meteorites&hl=en.
Pour, Gála a Šedivá. 2009. Podniková informatika. Praha : GRADA Publishing,a.s.,
2009. ISBN 978-80-247-2615-1.
WIKI. 2013. Computing platform. [Online] 2013. [Dátum: 28. 2 2013.]
http://en.wikipedia.org/wiki/Computing_platform.
20
10 Zoznam príloh a obsah DVD-ROM/elektronickej prílohy
Obsah DVD-ROM/elektronickej prílohy
Táto práca obsahuje prílohu, fyzicky na priloženom DVD-ROM nosiči, elektronicky
v priloženom .ZIP súbore.
V prílohe sa nachádza spustiteľná verzia hry pre platformu PC, v súbore NAVOD.txt
je opísaný postup ako spustiť hru na operačných systémoch Windows, Linux a Mac. Taktiež
sa nachádza verzia pre Android zariadenia vo forme .apk súboru. Okrem toto sa tam
nachádza samotná práca a obrázky z prílohy.
Zoznam príloh
Obrázok 1 Architektúra klient - server........................................................................22
Obrázok 2 Zobrazenie obrazovky hry AIRDANCE....................................................22
Obrázok 3 UML diagram - Diagram tried klientského programu AIRDANCE..........23
Obrázok 4 UML diagram - Diagram aktivít klientského programu (LibGDX, 2013).24
21
Obrázok 1 Architektúra klient - server
(vlastné spracovanie)
Obrázok 2 Zobrazenie obrazovky hry AIRDANCE
(vlastné spracovanie)
22
Obrázok 3 UML diagram - Diagram tried klientského programu AIRDANCE
23
Obrázok 4 UML diagram - Diagram aktivít klientského programu (LibGDX, 2013)
24