České vysoké učení technické v Praze Fakulta elektrotechnická Katedra počítačů
Bakalářská práce
Hra lodě v mobilním prostředí Zdeněk Klíma
Vedoucí práce: Ing. Ondřej Poláček
Studijní program: Softwarové technologie a management Obor: Softwarové inženýrství
červen 2009
ii
Poděkování Na tomto bych rád poděkoval svým rodičům za to, že mi umožnili studovat na vysoké škole a poskytli mi vynikající zázemí. Dále děkuji všem svým přátelům za poskytnutou morální podporu, své přítelkyni za tolerantní přístup a pochopení mé vytíženosti, kterého se mi dostávalo po celou dobu psaní této práce. V neposlední řadě nesmím zapomenout ani na vedoucího práce, Ing. Ondřeje Poláčka a oponenta, Ing. Zdenka Míkovce, Ph.D, za pomoc, podporu a užitečné rady. Závěrem děkuji všem, kteří ke vzniku této práce nějaký způsobem přispěli, a nebyli jmenovitě zmíněni.
iii
iv
Prohlášení Prohlašuji, že jsem svou bakalářskou práci vypracoval samostatně a použil jsem pouze podklady uvedené v přiloženém seznamu. Nemám žádný závažný důvod proti užití tohoto školního díla ve smyslu §60 Zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon)
V Litoměřicích dne 22.května 2009
…………………………………………………………
v
vi
Abstrakt Práce se zabývá vývojem aplikací v mobilním prostředí. Hlavním cílem práce je vyvinout aplikace, která bude elektronickou obdobou známe společenské hry lodě. Aplikace se jmenuje BattleShips, je postavena na platformě J2ME CLCD a MIPD a umožňuje jak hru jednoho hráče proti mobilnímu zařízení, tak síťovou hru dvou hráčů na dvou různých zařízeních komunikujících přes rozhraní Bluetooth. Práce se dále zabývá popisem chybových stavů vzniklých během síťové komunikace a způsobu jejich řešení. Kromě praktických dovedností také práce poskytuje teoretický popis obou hlavních použitých technologií, tedy J2ME a Bluetooth. Důraz je kladen především na popis základních vlastností a principů.
Abstract This work is concentrated on developing applications in mobile environment. The main goal of this work is to developed an application, called BattleShips, which is an electronic form of a famous social game knows as “Lodě”. The application is based on J2ME CLDC and MIDP platform and it provides two types of game, network one-player game against CPU on a local device and two-player game against themselves on two mobile devices using Bluetooth technology for communication. The also describes error states raised in network communication and suggests their solution. Except for practical skills this work also describes and explains main principles and features of both used technologies, J2ME and Bluetooth.
vii
viii
Obsah 1.
Úvod
1
1.1. Motivace vzniku práce
.................................................................................................... 1
1.2. Vytyčení cílů práce ............................................................................................................. 1 1.3. Struktura práce
2.
.................................................................................................................. 2
Technologie J2ME
3
2.1. Úvod ........................................................................................................................................ 3 2.2. Struktura ............................................................................................................................... 4 2.2.1. Konfigurace ........................................................................................................................... 4 2.2.2. Profily
..................................................................................................................................... 7
2.2.3. Volitelné balíčky ................................................................................................................. 7
2.3. Podpora J2ME na jednotlivých zařízeních .............................................................. 8 2.4. MIDP profil .......................................................................................................................... 8 2.4.1. Vlastnosti ..................................................................................................................... 8 2.4.2. Knihovna tříd ............................................................................................................ 9 2.4.3. Bezpečnost ................................................................................................................. 10 2.4.4.Budoucnost ...................................................................................................................... 10 2.5. Programování v J2ME CLDC a MIDP ............................................................................ 11
3.
Technologie Bluetooth
12
3.1. Vývoj standardu ................................................................................................................. 12 3.2. Základní vlastnosti ............................................................................................................ 13 3.3. Architektura Bluetooth ................................................................................................... 14 3.4. Princip přenosu ................................................................................................................. 15 3.4.1. Frekvenční pásmo ................................................................................................................. 15 3.4.2. Typy spojení ........................................................................................................................... 16 3.4.3. Topologie spojení ................................................................................................................. 16
3.5. Bezpečnost
.......................................................................................................................... 17
3.6. Profily ........................................................................................................................................ 19 3.7. Verze Bluetooth ................................................................................................................. 20 3.8. Bluetooth a J2ME ................................................................................................................. 22
ix
4.
Aplikace BattleShips – analýza a návrh implementace
23
4.1. Funkční požadavky ............................................................................................................ 23 4.2. Nefunkční požadavky ....................................................................................................... 24 4.3. Hlubší analýza některých požadavků ....................................................................... 24 4.4. Návrh aplikace ..................................................................................................................... 25
5.
Prezentační vrstva aplikace
27
5.1. Možnosti tvorby GUI v J2ME .......................................................................................... 27 5.1.1. Vysokoúrovňové uživatelské rozhraní ......................................................................... 28 5.1.2. Nízkoúrovňové uživatelské rozhraní ......................................................................... 29
5.2. Frameworky .......................................................................................................................... 29 5.3. GUI aplikace .......................................................................................................................... 30 5.4. Alternativní rozhraní aplikace ..................................................................................... 32 5.4.1. Návrh .......................................................................................................................................... 32 5.4.2. Implementace ...................................................................................................................... 35
7
6.
Business vrstva aplikace
37
6.1. Balíček bussinessTier.gui .............................................................................................. 38 6.2. Balíček bussinessTier.settings ..................................................................................... 38 6.3. Balíček bussinessTier.topten ......................................................................................... 38 6.4. Balíček bussinessTier.btConnection ........................................................................... 39 6.5. Balíček bussinessTier.game ......................................................................................... 40 6.6. Problémy a zajímavé postřehy při vývoji .................................................................. 43
7.
Integrační vrstva aplikace
47
7.1. Integrační vrstva v MVC (Model) ................................................................................ 47 7.2. Možnosti v J2ME ................................................................................................................ 48 7.2.1. Základní myšlenka RMS ......................................................................................... 48 7.2.2. Třídy pro práci s RMS .............................................................................................. 49 7.3. Model v naší aplikaci ....................................................................................................... 50
8.
Testování aplikace
52
8.1. Funkční testování ................................................................................................................ 52
x
8.2. Testování použitelnosti (Usibility testing) obecně ........................................... 52 8.3. Testování použitelnosti naší aplikace ....................................................................... 54 8.3.1. Návrh testu ................................................................................................................. 54 8.3.2. Skutečný průběh ........................................................................................................ 55 8.3.3. Vyhodnocení ............................................................................................................. 61
9.
Závěr
65
9.1. Závěrečné zhodnocení ........................................................................................................ 65 9.2. Možná vylepšení ................................................................................................................. 66
A.
Seznam použité literatury a zdrojů
67
B.
Seznam tabulek
69
C.
Seznam obrázků
70
D. Seznam zkratek
72
E.
Ukázky zdrojového kódu
76
F.
Předtestový dotazník pro test použitelnosti aplikace
82
G.
Potestový dotazník pro test použitelnosti aplikace
84
H. Uživatelská příručka
86
I.
91
Obsah přiloženého CD
xi
1. Úvod
Práce se zabývá vývojem aplikací v mobilním prostředí. V prostředí, kde má každé zařízení omezený výpočetní výkon, paměťové prostředky a prostředky pro interakci s uživatelem jako je velikost zobrazovacího zařízení a prostředky pro vstup od uživatele. Činností, která je s vývojem aplikací, a to nejen mobilních, spjata je testování. Testování je široký pojem, testují se z různých důvodů různé části aplikace. Jednou z oblastí testování je testování uživatelského rozhraní. Jeho cílem je ověřit, jestli námi navržené uživatelské rozhraní je intuitivní, jestli se v něm uživatel vyzná. Této problematice se také bude práce věnovat. Poslední velkou oblastí, kterou se bude práce zabývat je zpřístupnění aplikací osobám zrakově postiženým respektive nevidomým. Jeho princip spočívá ve vytvoření alternativního uživatelského rozhraní založeného na jiných smyslech než na zraku, zejména na sluchu.
1.1. Motivace vzniku práce Konkrétním impulsem pro vznik této práce byla skutečnost, že v době zadávání práce nebylo možné nikde nalézt aplikaci podobnou té, která je implementována v rámci práce jako ilustrace teoretických poznatků. Obecnou motivací, a zároveň předpokladem nutným pro úspěšnou realizaci byl pak dlouhodobý zájem autora o rozšíření obzorů za hranice standardní edice jazyka Java učené stolní počítače a také zájem o tvorbu aplikací ve světě mobilních a vestavěných zařízení s omezenými prostředky a výpočetním výkonem.
1.2. Vytyčení cílů práce Hlavním cílem, který si tato práce klade je vytvoření aplikace pro mobilní zařízení, konkrétně v prostředí J2ME CLDC a MIDP, která bude elektronickou obdobou známe společenské hry lodě. Aplikace ponese jméno BattleShips a bude umožňovat jak hru jednoho hráče proti mobilnímu zařízení, tak síťovou hru dvou hráčů na dvou různých zařízeních komunikujících přes rozhraní Bluetooth. Při tvorbě aplikace budou zohledněny možné chybové stavy vzniklé přerušením síťové komunikace a bude navrhnuto a implementováno jejich řešení. Posledním významným rysem aplikace je, že bude poskytovat kromě klasického uživatelského rozhraní také rozhraní pro zrakově postižené respektive nevidomé. Přesné požadavky a specifikace aplikace budou uvedeny dále v textu. 1
Vedlejšími cíly, které vyplývají z nutnosti nejprve prostudovat obě použité technologie, jsou dva. Poskytnout čtenáři základní vhled v do problematiky programování v mobilním prostředím, zejména pak J2ME a upozornit na problémy, které na programátora ve světě mobilních zařízení čekají. Druhým je poskytnutí základních teoretických znalostí o komunikační technologii Bluetooth.
1.3. Struktura práce Práci lze v podstatě rozdělit na tři základní pomyslné částí, teoretickou, praktickou a hodnotící. Každá část je pak ještě dále členěna. Teoretická část je tvořena převážně kapitolami 2 a 3, kde jsou podrobně rozebrány použité technologie. Kapitola 2 je věnována platformě J2ME. Jsou zde uvedeny okolnosti, jež vedly k jejímu vzniku, struktura a členění včetně základních vlastností a hlavní zásady a principy tvorby aplikací v jedné z jejich větví. Kapitola 3 obsahuje detailní popis druhé z technologií, na jejichž základech je tato práce postavena, konkrétně technologie Bluetooth určená pro přenos dat mezi mobilními zařízeními. Stručně je zde zachycen historický vývoj standardu a detailně jsou zde vysvětleny základní principy, vlastnosti i omezení současné, poslední verze. Nechybí ani předpokládaný vývoj technologie v budoucnu. Praktickou část, která se zabývá implementací ukázkové úlohu, aplikace BattleShips pro mobilní telefony, tvoří kapitoly 4 až 8, které jsou věnovány různým částem vývojového procesu. Poslední, rozhodně ne však nezajímavou, část pak tvoří jakési ohlédnutí za celým vývojem aplikace a zhodnocení, zda bylo dosaženo daných cílů. Dále jsou zde uvedeny zajímavé problémy a úskalí, na které jsem během práce narazil a také doporučení a možná vylepšení pro ty, kteří by chtěli na vývoji aplikace pokračovat.
2
2. Technologie J2ME
2.1. Úvod S technologickým pokrokem při výrobě čipových součástek, zejména pak se stále rostoucím stupněm integrace elektronických součástek a s jejich klesající spotřebou elektrické energie, se na tru začala objevovat digitální zařízení s daleko menšími rozměry, hmotností a spotřebou energie, než byly rozměry klasických počítačů nebo notebooků. Díky této skutečnosti už nebyla zařízení závislá na stálém napájení ze sítě a mohla stát přenosnými. Typickým příkladem takového zařízení je mobilní telefon, který se během své masivní expanze v 80. a hlavně pak 90.letech minulého století stal doslova fenoménem. Dnešní mobilní telefony však mají s těmi původními pramálo společného. Kromě nesrovnatelně menších rozměrů, hmotnosti, úspory energie a s tím spojené výdrže baterie, je to především přechod od analogových NMT sítí, přes sítě typu GSM až k současným 3G sítím, které umožňují navíc i přenos obrazu. Původní černobíle textové displeje, často jen dvouřádkové, byly nahrazeny barevnými, grafickými displeji, běžně schopnými zobrazit až 16 milionů barev a rozlišení 240 x 320 pixelů nebo vyšším. Mobilní telefon tak už dávno přestaly sloužit jen ke svému původnímu účelu, tedy telefonování a později posílání textových zpráv, a v současné době nabízejí obrovský potenciál. Kromě mobilních telefonů se na trhu začala objevovat i jiná zařízení, jako jsou kapesní počítače (Pocket PC), osobní digitální asistenti (PDA) a další, které, díky svému většímu výkonu, především pak většího rozlišení displeje, které dnes běžně dosahuje hodnot 640 x 480 pixelů, nabízejí potenciál ještě vyšší. S rostoucími možnostmi mobilních zařízení, začala být tato oblast zajímavé taky pro vývojáře a softwarové inženýry, kteří začali hledat způsob, jak na mobilních zařízeních nainstalovat a spouštět vlastní aplikace. Samozřejmě jedním z požadavků byla také přenositelnost mezi různými platformami. Cílem bylo, vytvořit technologii umožňující vývoj aplikace, která by mohla běžet stejně dobře na mobilním telefonu jako na kapesním počítači. Jako jedno z možných řešení se nabízelo použití programovacího jazyka Java, který byl poměrně nový a který byl právě vytvářen s ohledem na maximální hardwarovou a softwarovou nezávislost a tudíž maximální přenositelnost. Tehdejší mobilní zařízení však nebyla schopná uspokojit hardwarové nároky, které na ně kladl virtuální stroj Javy. Z počátku firma Sun Microsystems, která stála za vývojem klasické Javy pro osobní počítače, vydávala různé její podmnožiny funkcí, vždy šité na míru konkrétnímu segmentu trhu s mobilními zařízeními. Každé z těchto řešení však přistupovalo jinak k redukci funkcionality a hardwaru mobilního zařízení, což vedlo postupem času ke zmatku a nekompatibilitě aplikací na jednotlivých zařízeních. Firma proto hledala cestu, jak vzniklou situaci vyřešit. A tak byla v roce 1999 představena edice Java 2 Micro Edition, zkráceně J2ME, která si dala za cíl sjednotit všechna předchozí zařízení a unifikovat běhové prostředí pro aplikace na mobilních zařízeních.
3
2.2. Struktura Svět mobilních zařízení je rozmanitý. Jednotlivé druhy zařízení se od sebe mohou diametrálně lišit. Dokonce ani jednotlivé produktu z téhož segmentu nejsou stejné. Jeden mobilní telefon má takové rozlišení displeje, druhý zase jiné. Na jednom telefonu je k dispozici technologie Bluetooth, na druhém není. Některá zařízení je možné ovládat pouze klávesnicí, jiná mají dotykový displej a tak podobně. Obecným problémem, společným všem zařízením napříč celým spektrem produktů je pak relativně nízký výpočetní výkon procesorů, špatné zobrazovací schopnosti a malá operační paměť. V důsledku toho nebylo možné novou edici vytvořit jako jednolitou specifikaci, která by pokrývala celý segment trhu a na všech zařízeních vypadala stejně. Pro dosažení maximálního možného pokrytí různých zařízení, byla základní specifikace omezena jen na velmi malou množinu balíčků, která je společná všem zařízením. Ostatní vlastnosti, které byly pro konkrétní typy mobilních zařízení a pro konkrétní produkty téhož typu různé jsou specifikovány pomocí rozšíření této základní konfigurace. Výsledkem vývoje je struktura složená z konfigurací, profilů a volitelných balíčků. Nyní se na jednotlivé části podíváme podrobně.
2.2.1. Konfigurace J2ME rozlišuje dvě základní výkonnostní třídy mobilních zařízení a pro každou z nich zavádí jednu konfiguraci. Jejich hlavním cílem je definice obecného programového vybavení, společného pro všechna zařízení v dané výkonnostní skupině. 2.2.1.1. Connected Limited Device Configuration (CLDC) Jedná se o základní konfiguraci pro nejmenší a nejméně výkonná mobilní zařízení jako jsou mobilní telefony. Protože programování aplikací pro mobilní telefony je tématem této práce, uvedu podrobnější popis této konfigurace. V době psaní práce byla aktuální verze konfigurace CLDC 1.1. Oproti klasické JVM ze standardní edice Javy jsou zde, právě s ohledem na velmi omezené výčetní prostředky zařízení následující omezení: -
-
-
-
Odstranění většiny chyb a výjimek – byly odstraněny třídy popisující výjimky odvozené od třídy java.lang.error. Nastane-li nějaká chyba KVM (JVM pro tuto verzi konfigurace, viz dále) vyhledá výjimku, které je té nastalé nejpodobnější. Finalizace – není zde provádění automatických úklidových prací jako je uzavření systémových zdrojů před vlastní zrušením objektů pomoci Garbage Collectoru. Vše tedy zůstává na programátorovi. Skupiny vláken a démonické vlákno – přestože samotná vlákna jsou poskytována, není možné vytvářet skupiny vláken, jako je tomu ve standardní edici Javy. Kromě toho není ani poskytování tzv. démonické vlákno, které po svém ukončení automaticky ukončí všechna ostatní vlákna. Programátorsky definované zavaděče tříd – v J2ME je možné použít pouze originální bootstrap a to z důvodu bezpečnosti.
4
Knihovna tříd Protože, jak už bylo řečeno, se jedná o základní konfiguraci společnou pro všechna malá mobilní zařízení, zejména pak mobilní telefony, jsou do specifikace zahrnuty pouze následující balíčky: -
javax.microedition.io java.lang java.util java.io
Balíček javax.microedition.io neobsahuje definici tříd, ale definuje pouze rozhraní, které slouží jako obecný připojovací systém pro zařízení a jak už název nepodívá, jedná se o specifický balíček pro mikro edici Javy a ve standardní Javě není. Další balíčky obsahují některé třídy ze standardní edice. Přehled, které třídy jsou zde k dispozici a ve kterém balíčku se nacházejí uvádí následující tabulka. Balíček
Třídy a rozhraní
java.lang
Boolean, Byte, Character, Class, Double, Float, Integer, Long, Math, Object, Runnable, Runtime, Short, String, StringBuffer, System, Thread, Throwable Calendar, Date, Enumeration, Hashtable, Random, Stack, Timezone, Vector ByteArrayInputStream, ByteArrayOutputStream, DataInput, DataOutput, DataInputSream, DataOutputStream, InputStream, OutputStream, InputStreamReader, OutputStreamWriter, PrintStream, Reader, Writer
java.util java.io
Tabulka 2.1.: Třídy v CLDC konfiguraci
Jelikož zde neexistuje souborový systém, není zde zavedena třída java.lang.Properties. Místo toho každé zařízení implementuje metodu System.getProperty(Stirng key), která poskytuje základní informace o zařízení. Jejich
přehled je zachycen v tabulce 2.2. Vlastnost
Výchozí hodnota
Popis
microedition.platform microedition.encoding microedition.configuration microedition.profiles
Název hostitelské platformy nebo zařízení Standardní kódování znaků Název a verze podporující konfigurace Názvy podporovaných profilů
null "ISO-8859-1" "CLDC-1.1" null
Tabulka 2. 2.: Systémové vlastnosti popisující zařízení
Pro kompletní popis této konfigurace odkazuji případné zájemce na [8].
2.2.1.2. Connected Device Configuration Konfigurace CDC, která je určena pro výkonnější mobilní zařízení, jako jsou kapesní počítače a PDA, je postavena na standardní edici Javy (J2SE), konkrétně na její verzi 1.3. Díky skutečnosti, že při vzniku CDC neexistovaly žádné zdrojové kódy a nebylo tedy nutné brát zřetel na zpětnou kompatibilitu, byly odstraněny třídy a rozhraní Javy, která byla takzvaně zavrhnuta (deprecated). Ve výsledku byly do této konfigurace zahrnuty následující balíčky:
5
-
java.io java.lang java.lang.ref java.lang.reflect java.math java.net java.security java.security.cert java.text java.util java.util.jar java.util.zip java.microedition.io
Podrobný popis CDC konfigurace však přesahuje rámec této práce. Případného zájemce o tuto problematiku odkazuji na [9].
2.2.1.3. Virtuální stroje Jedním ze základních rysů Javy, a to ne jen té mobilní, je fakt, že zdrojový kód programu není při překladu kompilován do nativního kódu procesoru. Výsledkem překladu je takzvaný byte kód. Ten je interpretován virtuálním běhových prostředím, takzvaným Java Virtual Machine (JVM) pracujícím na konkrétním hostitelském zařízení. Skládá se z runtimu, tedy části tvořící vazbu na hardware zařízení a interpretu, který vykonává jednotlivé příkazy bytového kódu. Virtuální mašina, nebo také virtuální stroj, je v J2ME vlastně určena příslušnou konfigurací. Rozeznáváme tedy dva druhy virtuálních strojů. Prvním je Kylobyte Virtual Machine (KVM). Ta je určena pro konfiguraci CLDC. Kvůli maximalizaci počtu hostitelských zařízeních, na kterých je KVM schopná běžet, nejsou na ni, vyjma nároků na dostupnou paměť typ ROM, kladeny žádné požadavky. Druhým typem Compaq Virtual Machine (CVM), který je určen pro konfiguraci CDC. Jelikož je CDC odvozena od J2SE 1.3, je i CVM velmi podobná virtuálnímu stroji z této edice. Má však celkově menší nároky na paměť a správce paměti, takzvaný Garbage Collector je speciálně navřen pro prostředí s omezenými paměťovými prostředky. Přehled základních vlastností obou typů virtuálních strojů shrnuje následující tabulka. Vlastnost Aktuální verze konfigurace Číslo požadavku v rámci JCP ROM – paměť pro VM a její knihovny RAM – paměť pro běh VM Typ procesoru Rychlost procesoru Způsob napájení
KVM
CVM
CLDC 1.1 JSR 139 160 – 512 KB 32 KB 16 i 32 bitový > 16 MHz Bateriový
CDC 1.1 JSR 218 2.,5 MB 2 MB 32 bitový > 32 MHz Síťový
Tabulka 2.3.: Vlastnosti virtuálních mašin
Dodejme, že kromě požadavku na minimální dostupnou paměť, který je striktní, jsou všechny ostatní pouze doporučení a jejich dodržení není striktně vyžadováno.
6
2.2.2. Profily Konfigurace žádným způsobem nedefinuje životní cyklus aplikace, její instalaci, specifikaci uživatelského rozhraní, tedy to, jestli se bude jednat o textový nebo grafický výstup, případně jakým způsobem budou odchytávány události a jak bude zajištěna interakce s uživatelem. Tohle všechno je úkolem profilů. Profily tedy vlastně doplňují a rozšiřují specifikaci o konkrétní rysy jednotlivých typů zařízení. Teprve ve spojení s profily je možné praktické použití technologie J2ME. Pro úplnost přidávám výčet nejpoužívanějších profilů spolu s jejich stručným popisem. Název profilu
Konfig.
Mobile Information Device Profile (MIDP)
CLDC
Personál Digital Assistant Profile (PDAP)
CLDC
Foundation profile
CDC
Remote Method Invocation Profile (RMI)
CDC
Game Profile
CDC
Popis Základní profil pro mobilní telefony. Protože je stěžejním pro tuto práci je jeho popisu věnována celé jedna sekce níže Profil představený v červnu 2004, určený pro PDA. Oproti MIDP klade vyšší nároky na displej a paměť. Zavádí nové balíčky pro práci s uživatelským rozhraním. Základní profil pro CDC konfiguraci. Přidává téměř všechny balíčky, které CDC chybí ve srovnání s J2SE, kromě balíčků pro tvorbu uživatelského rozhraní. Profil je určen především pro set-top boxy, kde je interakce s uživatelem jen velmi omezená a grafické rozhraní tak není třeba. Umožňuje vzdálené volání metod podobně jako je tomu ve standardní edici Javy Jak je už z názvu patrné mělo by se jednat o profil určený pro tvorbu her pod CDC konfigurací. V současné době je však vývoj zastaven
Tabulka 2. 4.: Přehled základních profilů a jejich stručný popis
Podrobný přehled jednotlivých profilů najde případný zájemce na stránkách se specifikací této technologie od společnosti Sun na [3].
2.2.3. Volitelné balíčky Profily umožňují využívat vývojáři ty funkce, které jsou společné pro všechna zařízení z daného segmentu. Ani jednotlivá konkrétní zařízení však nejsou svojí hardwarovou výbavou vždy totožná. Z důvodu omezeného prostrou jak pro běh aplikací, tak pro samotný virtuální stroj nebylo rozumné implementovat i třídy pro přístup všem volitelným hardwarovým součástem povinně v rámci celého profilu. Proto se zavádí ještě další mechanismus členění, tak zvané volitelné balíčky. Typickým příkladem takového volitelného balíčku je balíček javax.bluetooth popsaný v rámci JSR 82. Technologii Bluetooth je podrobně věnována následující kapitola.
7
Vše, co bylo až dosud naspáno, je pro přehlednost zachyceno na následujícím obrázku.
Obrázek 2.1.: Struktura J2ME
2.3. Podpora J2ME na jednotlivých zařízeních Přestože jednou ze základních vlastností Javy je přenositelnost mezi různými platformami, není kompatibilita vždy stoprocentně zajištěna. Důvodem je především nedodržení přesné specifikace při implementaci virtuálních strojů ze strany výrobců mobilních zařízení na úkor jednoduchosti a ceny. Vůbec nejhorší je pak situace na platformě Windows Mobile, kde v současné době neexistuje oficiální javovský virtuální stroj a tedy podpora pro běh Java aplikací. Existují sice virtuální stroje třetích stran, ovšem výsledek je povětšinou nevalný. Na některé rozdíly v implementaci a s tím spojené následné problémy jsem narazil i v průběhu této práce a budou zmíněny v kapitole 6, oddíl 6.6.
2.4. MIDP profil Jak bylo uvedeno v tabulce 4, jedná se o základní profil pro zařízení typu mobilní telefon. 2.4.1. Vlastnosti První specifikace s číslem 1.0 se objevila v září roku 2000. Obsahovala jen omezenou podporu a funkcionalitu a jako první verze také trpěla některými „dětskými nemocemi“. Proto byla listopadu roku 2002 nahrazena verzí 2.0 a ještě později verzí 2.1, která je zatím poslední. S rostoucí funkcionalitou a podporovou pro různé části zařízení se zvětšovali také hardwarové nároky kladené na hostitelské zařízení. Požadavky, které na zařízení klade současná verze specifikace popisuje následující tabulka.
8
Typ
Minimální požadavky
Displej
rozlišení alespoň 96x54 pixelů hloubka barev 1 bit 256 KB trvalé paměti pro vlastní MIDP implementaci 128 KB operační paměti pro běh aplikace 8 KB trvalé paměti pro data klávesnic (telefonní nebo plná) nebo dotykový displej. obousměrný, přerušovaný provoz s omezenou šířkou pásma hardwarová či softwarová schopnost přehrávání tónů
Paměť
Vstupní zařízení Siť Zvuk
Tabulka 2.5.: Přehled minimálních požadavků specifikace MIDP 2.1
2.4.2. Knihovna tříd V následujícím oddílu bude popsáno základní balíčky a třídy, které se v tomto profilu nacházejí. java.util – nově v tomto balíčku přibyly třídy Timer a TimerTask. Jak už název
napovídá jedná se časovač, tedy o nástroj umožňující spouštění periodicky se opakujících událostí. Kód spouštěný při vypršení časovače musí být implementován ve vlastní třídě, která je potomkem třídy TimerTask. Tato třída implementuje rozhraní Runnable a abstraktní metodu run(). Její potomek definuje vlastní obslužný kód právě pomocí překrytí abstraktní metody run. Kód tak bude spuštěn ve vlastním běhovém vlákně. K samotnému spouštění dochází z instance třídy Timer. javax.microedition.io – přidána rozhraní pro podporu dalších komunikačních
protokolů. Nyní jsou podporovány protokoly http, https, datagram, datagram server, soket, server soket, ssl, comm. Další novinkou, která se zdě objevila, je třída PushRegistry, s jejíž pomocí je možné spouštět v konkrétním čase nebo jako reakci na speciální podnět příchozí ze sítě. javax.microedition.lcdui – balíček obsahující třídy pro práci s grafickým
uživatelským rozhraním. Způsoby jeho tvorby v J2ME budou vysvětleny na začátku kapitoly 5, která je věnována tvorbě uživatelského rozhraní pro aplikaci BattleShips. javax.microedition.lcdui.game – jak už samotný název napovídá jedná se o API pro tvorbu her. Základní třídou je třída GameCanvas, která se od klasického Canvasu liší
použitím techniky double bufferingu, a základní myšlenkou je skládání grafiky z několika vrstev. Výsledný objekt je jedním z potomků rozhraní Layer, konkrétně buď TiledLayer nebo Sprite. Kromě toho API obsahuje také podpůrné funkce jako jsou překlápění, rotace a kontrola kolizí s jinými objekty. javax.microedition.media – balíček obsahující API pro přehrávání některých audio
formátů a generování tonů zadané výšky, délky a hlasitosti. Striktně vyžadována je podpora hudebních formátů MIDI a WAV, avšak knihovna umí zpracovávat také formáty MP3 a AU. Základní třídou je třída Manager, která slouží k vytvoření jednotlivých přehrávačů nebo generování tónů. Rozhraní Player, které je implementováno pak slouží k samotnému přehrávání audio souborů, ke kterým je možné přistupovat buď pomocí Media Locatoru nebo pomocí InputStreamu.
9
javax.microedition.media.control – slouží pro ovládání hlasitosti přehrávačů vytvořených pomocí třídy Manager. javax.microedition.midlet – výchozí abstraktní třída společná pro všechny aplikace běžící v MIPD profilu. Podrobněji o problematice viz sekce „Programování v J2ME CLDC a MIDP“. javax.microedition.pki – třída, která byla přidána po zavedení podpory
komunikačního protokolu https. Poskytuje funkce pro ověření, zda server obsahuje platný certifikát. javax.microedition.rms – obsahuje implementaci Record Management Systemu, který
slouží k trvalému ukládání dat, neboť zde není k dispozici souborový systém. Jedná se o jakousi databázi tvořenou seznamem záznamů indexovaných od jedničky. Jednotlivé záznamy jsou pak tvořeny sekvencí bajtů. RMS systém je společný všech aplikacím v rámci zařízení. Jednotlivé databáze musí teda mít unikátní názvy. Podrobný popis způsobu využití RMS bude uveden v kapitole 7.
2.4.3. Bezpečnost Ve verzi 1.0 existoval pouze jeden bezpečnostní mode, takzvaný sandbox. Aplikace tedy měla k dispozici jen minimum systémových prostředků nezbytně nutných pro svůj běh. Pro přístup k ostatním prostředkům, jako jsou například síťové služby a rozhraní, přístup k souborovému systému (pokud byl na daném zařízení k dispozici) a podobně si musela pokaždé vyžádat souhlas uživatele. Tento model zůstal z velké části zachován i ve verzi 2.0 a 2.1. Přesněji řečeno zůstal zachován pro takzvaně nedůvěryhodné sady midletů. Nově zde totiž přibila možnost aplikaci digitálně podepsat X.509. Tím dojde k přeřazení aplikace mezi důvěryhodné midlety, u kterých je možné trvale povolit přístup k různým prostředků zařízení i bez dotazování uživatele. Bohužel opatřování certifikátu je zpoplatněna a jeho platnost je časově omezena.
2.4.4. Budoucnost Původně se předpokládalo vydání nové specifikace, s označením 3.0 někdy v průběhu roku 2006. Situace je však bohužel taková, že ještě v době psaní této práce, tedy v květnu roku 2009 se na vydání MIDP 3.0 stále čeká. Nová verze MIDP profilu by měla přinést hlavně následující zlepšení: -
podpora souběžného běhu více aplikací běh aplikace na pozadí automatické spuštění aplikace po startu zařízení vylepšené uživatelské rozhraní, zejména pak podporu pro tvorbu grafického rozhraní pro zrakově postižené a nevidomé lepší podporu velkých displejů podporu pro používání více displejů rozšířit podporovaná síťová rozhraní
10
2.5. Programování v J2ME CLDC a MIDP Základní třídou pro psaní aplikací je abstraktní třída javax.microedition.midlet. Aplikacím v MIDP se pak podle této třídy označují jako takzvané MIDlety. Třída midlet definuje, kromě jiného, tři abstraktní metody, public void startApp(), public void pauseApp() a public void destroyApp(boolean unconditional), které jsou volané správcem aplikací při spouštění, ukončování a pozastavení aplikace a odpovídají tak tedy jednotlivým stavům, kterými aplikace prochází v rámci svého životního cyklu. Tyto stavy a přechody mezi nimi jsou znázorněny na obrázku 2.5.
Obrázek 2.2.: Životní cyklus midletu
Stavy „Active“ a „Destroyed“ jsou poměrně intuitivní. Za zmínku stojí stav označený jako „Paused“. Současná verze MIDP, tedy 2.1, totiž neumožňuje běh aplikace takzvaně na pozadí, jak ho známe například ze stolních počítačů. Jedná se tedy o stav, do kterého aplikace přejde, pokud nastane nějaká neočekávaná událost, typicky například příchozí hovor, budík a podobně. Na zařízeních, na kterých běží nějaký operační systém, například Symbian, může aplikace do toho stavu přejít rovněž pokud uživatel aplikaci takzvaně minimalizuje – vyvolá aplikaci jinou nebo přejde do hlavního menu. Bývá dobrým zvykem při přechodu do tohoto stavu, pokud je to možné, uvolnit všechny vlastněné systémové prostředky. Každá aplikace v MIDP musí tedy obsahovat definici alespoň jedné neabstraktní třídy, odvozené od třídy Midlet. Programový kód nejjednoduššího midletu je uveden v příloze E, v sekci E.1. Dokumentace ve formě javadocu k profilu MIDP je na [10].
11
3. Technologie Bluetooth
Bluetooth je označení pro rádiový bezdrátový komunikační standard, který slouží pro propojení dvou nebo více zařízení na krátkou vzdálenost. 3.1. Vývoj standardu Technologie dostala jméno po dánském králi Haraldu II, který žil v 10.století a významně se zasloužil o sjednocení Skandinávie, za což se mu dostalo přezdívky Blaatand, v češtině „Modrý zub“. Podobně i návrháři technologie doufali, že se jí podaří sjednotit a standardizovat komunikaci napříč širokým spektrem různých zařízení. Prvopočátky jejího vývoje sahají do roku 1994, kdy byla ve švédské firmě Ericsson (dnes Sony Ericsson) vypracována studie o možnostech náhrady nejrůznějších kabelů mezi mobilním telefonem a periferními zařízeními. V této době bylo naprosto běžné, že každý větší výrobce používal svůj vlastní komunikační standard, který se standardů ostatních výrobců lišil nejen komunikačními protokoly, ale i použitými kabely a koncovkami. To mělo za následek, že leckdy ani dva různé produkty téže firmy nebyly schopny spolu komunikovat, o propojení zařízení jiných výrobců ani nemluvě. Návrháři si dali za cíl, pokusit se přinutit firmy opustit své privátní standardy a přechodem na nový otevřený standard nabídnout uživatelům větší komfort a širší možnosti využití za menší náklady. V roce 1998 byla na základě předchozí iniciativy firmy Ericsson založena skupina BSIG (Bluetooth Special Interest Group), která pracovala na vývoji nové komunikační technologie. Jejími zakládajícími členy společnosti IBM, Intel, Nokia a Thosiba. Později se přidaly ještě firmy 3Com, Lucent, Microsoft a Motorola. Dnes má skupina více než 2 500 členů, což vypovídá o velké důležitosti komunikačního standardu Bluetooth. Ještě v témže roce BSIG zveřejnila první specifikaci standardu známou pod označením Bluetooth 0.7 O rok později byla vypuštěna kompletní specifikace a standardu Bluetooth 1.0 a v roce 2000 se na trhu objevila první zařízení vybavená touto komunikační technologií. V roce 2002 spatřila světlo světa specifikace 1.1, která odstraňovala „dětské nemoci“ nové technologie, ale nepřinesla žádná vylepšení. V letech 2003 a 2004 pak následovaly standardy 1.2 a 2.0, které přinesly vyšší přenosové rychlosti. V současnosti platným standardem je Bluetooth 2.1, který byl vydán v červenci roku 2007. Pro podrobnější popis jednotlivých verzí viz kapitolu 3.7.
12
3.2. Základní vlastnosti Na počátku vývoje byly jasně specifikovány požadavky, které nová technologie musí splňovat. Mezi ty základní patří
minimální rozměry nízké výrobní náklady krátký dosah nízká spotřeba energie automatická konfigurace celosvětová kompatibilita co možná nejvyšší bezpečnost a spolehlivost
Dnešní bluetooth čipy mají rozměry menší než naše dvacetikoruna a výrobní náklady se pohybují někde kolem 5 USD na jeden čip. Problém celosvětové kompatibility byl spojen především s volbou frekvenčního pásma ve kterém bude komunikace probíhat. Bluetooth využívá celosvětově bezlicenční (volně dostupné) pásmo ISM (Industrial Scientific Medical band), tedy kmitočty kolem 2,4 GHz. Díky skutečnosti, že se pro přenos používají rádiové vlny, není zde požadavek přímé viditelnosti u komunikujících zařízení, což výrazně zvyšuje nejen uživatelský komfort, ale také možnost využití této technologie. Na obrázcích 3.1. a 3.2. jsou vidět příklady Bluetooth čipů.
Obr. 3.2.: Průmyslové rozhraní firmy Intronico s modulem Bluetooth
Obr. 3.1.: Miniaturní čip firmy Infineon
Každý čip se skládá z vysokofrekvenčního dílu a řadiče pro základní pásmo. Ten rozhraní mezi čipem a počítačovým systémem. Podle výkonu vysílače vysokofrekvenčního dílu se zařízení dělí do různých výkonových tříd. Na vysílacím výkonu také přímo závisí jednak spotřeba energie a vzdálenost, na kterou je dané zařízení schopno komunikovat, takzvaný dosah. Jsou definováno tři výkonové třídy – 1, 2 a 3. Jejich vlastnosti shrnuje následující tabulka.
13
Výkonová třída
Maximální výstupní výkon
Minimální výstupní výkon
1
100 mW (20 dBm)
1 mW (0 dBm)
2
2,5 mW (4 dBm)
0,25 mW (–6 dBm)
cca 50 m
3
1 mW (0 dBm)
N/A
cca 10 m
Maximální dosah cca 100 m
Tabulka 3.1.: Výkonové třídy Bluetooth zařízení a jejich vlastnosti Kromě vysílacího výkonu a z něj vyplývajících vlastností však mezi jednotlivými třídami žádné rozdíly nejsou a tak je zařízení z jedné třídy bez problémů schopné komunikovat se zařízení z ostatních tříd.
3.3. Architektura Bluetooth Na systém bluetooth je dobré nahlížet jako množinu hardwarových prvků, definic a protokolů sdružených do jednotlivých vrstev, které spolu navzájem spolupracují tím způsobem, že vyšší vrstva využívá služeb vrstvy nižší a tím společně realizují celý přenos. Vrstevnatá architektura je znázorněna na obrázku 3.3. V nejnižší radiové vrstvě (Bluetooth Radio), která odpovídá fyzické vrstvě v síťovém OSI modelu, je definováno kmitočtové pásmo, uspořádání kanálů a přenosové charakteristiky systému. Základní vrstva specifikuje formáty paketů, fyzické a logické kanály a provozní režimy pro přenos dat a hlasu. Rovněž se stará o řízení navazování spojení, řízení komunikace a identifikaci. Ve třetí vrstvě najdeme bloky Audio (hlas) a Link manager (LMP). Obr. 3.3.: Vrstvy systému Bluetooth Blok Audio vychází z doporučení ITU-T a jeho úkolem je zajistit s pomocí služeb poskytovaných nižšími vrstvami přenos hlasu z jednoho zařízení na druhé. Protokol správy spojení (Link Manager) má na starosti ověřování spojení, management buněk a v neposlední řadě vytváření, rušení a konfiguraci spojení. Mezi touto vrstvou a vrstvou protokolu pro řízení a adaptaci logických spojení – L2CAP (Link Layer Control and Adaptation Protocol), která provádí multiplexování protokolů vyšších vrstev a segmentaci paketů se nachází hostitelské řídící rozhraní – HCI (Host Controller Interface). To poskytuje hostitelskému systému standardizovaný komunikační prostředek s bluetooth čipem, díky kterému je možné odstínit hostitelské zařízení, například operační systém na PC, notebooku nebo mobilním telefonu, od specifik hardwarové implementace konkrétního čipu.
14
Služeb poskytovaných L2CAP vrstvou dále využívají komunikační protokoly RFCOMM, TSC a SDP. První z nich, tedy RFCOMM je jednoduchý transportní protokol emulující standardní sériové rozhraní – klasická sériový port. Jeho definice je postavena na specifikaci ETSI TS 07.10 a jeho úkolem je zajistit kompatibilitu aplikací, který pro svou komunikaci využívají právě sériový port. Druhým z řady protokolů na této vrstvě je TSC (Telephony Control protocol Specification), neboli Protokol pro řízení telefonie, který byl navržen pro výměnu řídících signálů při hovorovém spojení mezi zařízeními Bluetooth. Jako příklad může posloužit mobilní telefon a headset. A konečně třetím a posledním protokolem, který se zde nachází je SDP. Ten slouží pro výměnu informací o službách, které jsou dostupné na jednotlivých zařízeních. S jeho může aplikaci zjistit nejen výčet dostupných služeb, ale také i jejich konfiguraci. V poslední vrstvě se vyskytuje množství protokolů, které jsou využívány konkrétními aplikacemi. Například protokol OBEX (Object Exchange Protocol), který byl původně vytvořen pro přenos dat po infračerveném sériovém rozhraní. S jeho pomocí bylo možné vyměňovat mezi jednotlivými zařízeními na přiklad soubory nebo kontakty. Pro umožnění přístupu do klasických počítačových sítí a Internetu je zde implementován taky protokol TCP/IP.
3.4. Princip přenosu dat Tato podkapitola se bude podrobněji zabývat všemi aspekty přenosu dat a vytváření spojení pomocí této radiové technologie.
3.4.1. Frekvenční pásmo Jak už bylo předesláno, pracuje Bluetooth v bezlicenčním radiovém pásmu ISM (Industrial Scientific Medical band), tedy na kmitočtech okolo 2,4 GHz. Celý rozsah pásma je přesně 2,400–2,4835 GHz, avšak nepoužívá se ve všech zemích. Například ve Francii je jeho šířka omezena na 2,4465–2,4835 GHz. Pásmo je rozděleno na 78 menších, které jsou od sebe vzdáleny 1 MHz s tolerancí 75 kHz. Protože se jedná o volně dostupné pásmo, není systém Bluetooth jediný, který jej využívá. Ve stejných frekvenčních oblastech operuje například dobře známý bezdrátový standard Wifi, nebo systém pro přenos hlasu DECT. Pro zvýšení odolnosti vůči interferencím s těmito i dalšími systémy používá standard Bluetooth metodu velmi rychlých kmitočtových skoků SSFH (Spread Spectrum Frequency Hoping). Nominální hodnota frekvence skoků je 1 600 skoků za sekundu. Z toho vyplývá, že vysílač každých 0,625 milisekund mění vysílací frekvenci. Takto časté změny přispívají k vysoké odolnosti spojení. Pokud například dojde ke kolizi s paketem DECT, je Bluetooth blokován pouze 1/1600 s zatímco DECT celou 1 sekundu. Princip frekvenčních skoků během přenosu je znázorněn na obrázku 3.4.
15
3.4.2. Typy spojení Specifikace podporuje synchronní přenos SCO (Synchronous Conneciton Oriented link), který se využívá při přenosu hlasu a časově kritických dat. Jeho rychlost je 64 kbit/s a každá jednotka může mít v jednom okamžiku aktivní až tři taková spojení. Pro přenos ostatních druhů dat je zde zavedena podpora i pro asynchronní Obr. 3.4.: Metoda přepínání frekvencí se čtyřmi bezspojový paketový zařízeními přenos ACL (Asynchronous s kanály A až D Connection-Less link) a to jak symetrický tak asymetrický. Rychlost při symetrickém přenosu je 432 kbit/s oběma směry a 723 kbit/s v jednom směru a 57 kbit/s ve druhém při asymetrickém přenosu. Přenášená data je možné volitelně zabezpečit proti poškození pomocí cyklického kódu a dopředné kontroly chyb. Pro zvýšení bezpečnosti podporuje Bluetooth i procedury autentizace a šifrování – viz podkapitola 3.5.
3.4.3. Topologie spojení Technologie umožňuje zařízením, která jsou v dosahu vytvářet dvě topologicky odlišná spojení. A to buď spojení typu bod – bod (point to point) v případě dvou zařízení nebo spojení bod – více bodů (point to multi point), pokud je zařízení více. Standard umožňuje zařízením v případě dvoubodového spojení kromě obyčejného spojení dokonce i současný přenos hlasu i dat nebo až tři současné kanály pro přenos hlasu. V případě vícebodových spojů je dovoleno pro každé zařízení vytváření obyčejných datových kanálů a k tomu až dvě současná hlasová spojení typu bod – bod. Pokud se zařízení vyskytnou v dosahu začnou vytvářet nějaký druh spojení. Jednotky, jenž mohou být dynamicky připojované a odpojované od sítě, které sdílejí společný přenosový kanál a pracují ve stejném schématu frekvenčních skoků tvoří základní stavební jednotku bluetooth sítě, takzvaný piconet. V každé buňce piconet musí být právě jedno nadřazené zařízení, říká se mu master, které je odpovědné za řízení komunikace. Ostatní zařízení v jedné buňce jsou jemu podřízená, pro ně se zavádí označení slave. Obvykle je pikosíť tvořena osmi zařízeními, avšak rozsáhlejší sítě mohou
16
mít až 255 účastníků. Dodejme ale, že aktivních v jednom okamžiku může být maximálně 8 z nich. Jednotlivé pokosíte (samostatné buňky piconet) se mohou spojovat do větších uskupení zvaných scatternet. Výhody takovéhoto spojení jsou jasné, je to především zvětšení maximální vzdálenosti na kterou je možné přenášet data. Jednotlivé pikosítě jsou na sobě nezávislé a každá má přístup k celé šířce přenosového pásma. Rovněž platí, že každá pico buňka určena jiným schématem kmitočtových přeskoků. Specifikace dovoluje aby jedno zařízení pracovalo současně v jedné buňce jako master a v druhé jako slave. Jednotlivé topologie spojů jsou zachyceny na následujícím obrázku.
Obr. 3.5.: Topologie bluetooth sítí
3.5. Bezpečnost Protože byla tato technologie primárně určena jako náhrada kabelů při komunikaci mezi na krátkou vzdálenost, měla poskytovat také odpovídající bezpečnost komunikace. Jelikož se jedná o radiovou technologii, je zřejmé, že je náchylnější na odposlech a tudíž je jeho zabezpečení obtížnější. Je však třeba hned na začátku předeslat, že v bezdrátové komunikaci patří tento systém mezi nejbezpečnější. Velmi rychlé přeskoky mezi různými kmitočty výrazně přispívají k implicitní bezpečnosti. Za výhodu lze rovněž považovat i krátký dosah sítě. Bezpečnost technologie je postavena na třech základních pilířích. Jsou jimi autentizace (ověření totožnosti) důvěrnost (ochrana před odposloucháváním) autorizace (povolení přístupu k jednotlivým službám) Zařízení Bluetooth je schopno pracovat v jednom z následujících bezpečnostních režimů
17
Bez zabezpečení Nezabezpečený režim, který umožňuje všem ostatním zařízení navázat spojení a komunikaci. Bezpečnost na úrovni služeb Zajišťuje autorizace přístupu ke službám na daném zařízení. Pro každou službu lze definovat práva přístupu – přístupná všem, služba vyžadující pouze autentizaci, služba vyžadující autentizaci i autorizaci. Bezpečnost na úrovni spojení Zařízení iniciuje bezpečnostní principy jako autentizaci a šifrování před navázáním spojení.
Rovněž některé vlastnosti, které měly primárně vyřešit jiné problémy, přispívají k bezpečnosti této komunikační technologie. Například velmi časté kmitočtové skoky během komunikaci nezvyšují pouze spolehlivost systému, ale také výrazně ztěžují podmínky pro odposlouchávání komunikace neautorizovaným subjektem. Jedinečná síťová adresa, která umožňuje kontaktovat dané zařízení, se rovněž používá jako jedna ze složek pro vygenerování náhodného inicializačního klíče. Dalšími složkami jsou PIN a náhodně vygenerované číslo. Při autentizačním procesu dochází k autentizaci zařízení nikoliv uživatele. Používá se takzvaný klíč spoje. Tím může být buď inicializační klíč, nebo alternativně se jím může stát klíč zařízení, který je vygenerován při instalaci zařízení a je stejný pro jakoukoliv komunikaci, nebo kombinační klíč, jenž je generován ve fázi inicializace spojení z klíčů jednotlivých komunikujících zařízení, takže jeho použití je bezpečnější, nebo konečně to může být hlavní klíč. Autentizace používá princip výzva-odpověď. Vyzyvatel zašle druhé straně svoji adresu a obdrží od ní náhodné číslo. Na základě těchto hodnot a sdíleného klíče spoje si obě strany spočítají výsledky, které musí být shodné. Specifikace neřídí, která strana má ověřovat totožnost druhé a tak je jen na aplikaci, jestli bude použita autentizace obousměrná nebo jednosměrná. Kromě autentizace je zde i podpora pro šifrování. Šifrovací klíč, který může mít délku 8 až 128 bitů, se odvozuje od autentizačního ovšem na rozdíl od něj se pro každý přenášený paket generuje znovu. Konkrétní délka šifrovacího klíče musí být dohodnuta oběma stranami předem. Pro vlastní šifrování přenášených dat se používá symetrický tokový algoritmus na bázi posuvného registru s lineární zpětnou vazbou.
18
Jako každá technologie má i Bluetooth svoje bezpečnostní slabiny krátké PIN – čtyřmístné PIN dává šanci je snadno uhodnout chybí metoda distribuce PIN – zadávání ručně je nepraktické a bezdrátové přenášení je z bezpečnostních důvodů nevhodné. délka šifrovacího klíče – často se volí minimální délka slabá autentizace – na základě výzvy a odpovědi, autentizuje se pouze zařízení, ne uživatel zabezpečení omezeno na spoj – chybí zabezpečení koncové komunikace
3.6. Profily Protože byla technologie bluetooth navržena obecně, používá se dnes v různých aplikacích pro přenos různých druhů dat. Každý typ aplikace si však klade různé požadavky a s každým typem dat se musí zacházet trochu jinak. Například při přenosu hlasu z headsetu do telefonu není až zase takový problém, pokud se paket tu a tam někde zatoulá a nedorazí na koncové zařízení. Informace v něm obsažené tvoří tak nepatrný zlomek celého rozhovoru, řekněme v řádu milisekund, což lidské ucho stejně není schopné zaznamenat, důraz je kladen hlavně na rychlost. Naopak při přenosu souborů si nemůžeme dovolit ani doručit pakety v nesprávném pořadí nebo nějaký nedoručit vůbec. Z toho také vyplývá, že při různých aplikacích pracují různé části z celé rozsáhlé specifikace Bluetooth, používají se různé dílčí protokoly a podobně. To jaké konkrétní protokoly se pro daný účel použijí, jaké části budou pracovat a jakým způsobem, to definují právě takzvané profily. Profily tedy zajišťují vzájemnou slučitelnost zařízení na nejvyšší softwarové úrovni. Oby mohla dvě zařízení smysluplně komunikovat, musí obě podporovat stejný profil. Pokud master zjistí, že slave nepodporuje daný profil, komunikace končí. Definovaných profilů je obrovské množství stále přibývají nové. Ve specifikaci Bluetooth 1.1 bylo definovány 13 základních profilů. Mnohé z nich jsou povinné a musí je podporovat každé zařízení. Například uvádím pár známých profilů. Pro kompletní přehled a specifikaci profilů viz [18]. Generic Access Profile (GAP)
Povinný protokol, definuje základní procedury připojení, řízení a bezpečnost. Service Discovery Application Profile (SDAP)
Podpora pro rozpoznávání služeb a výměnu informací o nich mezi zařízeními. Serial Port Profile
Definuje nastavení virtuálních sériových portů pomocí BT - klasická náhrada sériového propojení s rychlostí do 128kbps.
19
Dial-up Networking Profile
Definuje propojení přes BT mezi modemem a BT terminálem (notebookem...). Populární pro připojení k internetu přes BT GSM telefony. LAN Access Profile
Definuje spojení mezi BT terminálovými zařízeními (notebookem, PDA...) a LAN pro následné připojení k internetu (PPP). Generic Object Exchange Profile (GOEP)
Definuje řadu protokolů a procedur pro přenos dat mezi dvěma BT zařízeními (OBEX-standard). Na tomto profilu jsou založeny další modely jako File Transfer a Synchronizace. Object Push Profile
Tento profil využívající GOEP je využit k přenosu malých objektů, např. elektronické vizitky. File Transfer Profile
Tento profil využívající GOEP je využit k přenosu souborů mezi dvěma BT zařízeními.
3.7. Verze Bluetooth Následující podkapitola popisuje podrobněji jednotlivé verze standardu Bluetooth, o kterých byla zmínka na začátku kapitoly.
Bluetooth 0.7
Jedná se o první, dokonce ještě ani nekompletní specifikaci, která byla vydaná krátce po založení BSIG skupiny roku 1998. Spíš než o specifikaci šlo o koncept a hledání řešení, takže ani nebyla implementována v žádný zařízeních. Díky své nekompletnosti vlastně ani nemohla.
Bluetooth 1.0 a 1.0B
První specifikace tohoto standardu, která se dočkala implementace v konkrétních zařízeních. Uvolněna byla v roce 1999. Díky nedotaženému návrhu poměrně velkému množství chyb, které působily problémy s kompatibilitou zařízení od různých výrobců se však výrazněji neprosadila.
Bluetooth 1.1
První verzí standardu, která se dočkala skutečně reálného použití. Zveřejněna byla v roce 2002 a jejím hlavním přínos spočíval v opravě chyb, které se vyskytly ve verzi 1.0.
20
Kromě toho byla také přidána podpora pro nešifrované kanály a indikátor síly přijímaného signálu.
Bluetooth 1.2
Verze 1.2, která publikována v roce 2003 je zpětně kompatibilní s verzí 1.1 oproti které přináší následující výhody rychlejší vyhledávání ostatních zařízení i rychlejší připojení k danému zařízení podpora pro adaptivní kmitočtové skoky – systém AHF (Adaptive Frequency Hopping), který zvyšuje odolnost vůči rušení a tím i jeho spolehlivost – viz část frekvenční pásmo v podkapitole 2.4 vyšší přenosové rychlost, až 721 kbit/s zavádí standardní rozhraní HCI – viz kapitolu „Architektura Bluetooth“ zavádí rozšířenou verzi synchronních spojově orientovaných kanálů pro přenos hlasu a časově kritických dat – systém eSCO (Enhanced Synchronous Connections)
Bluetooth 2.0
Tato verze uvolněná v listopadu roku 2004 je zpětně kompatibilní s verzí 1.x. Hlavním rozdílem oproti předchozím verzím je zavedení technologie EDR (Enhanced Data Rate), která umožňuje několika násobné zvýšení přenosových rychlostí. Maximální udávaná přenosová rychlost je až 3 mbit/s. V praxi technologie dosahuje rychlostí někde kolem 2.1 mbit/s, což ale i tak znamená výrazné zlepšení. Dalším vylepšením bylo snížení energetické náročnosti a zjednodušení multilinkových přenosů díky rozšíření přenosového pásma.
Bluetooth 2.1
Zatím poslední standard, který byl zveřejněn v červenci roku 2007. Opět i zde je zpětná kompatibilita s předchozími verzemi a rovněž přináší některá vylepšení. Především je to podstatná úspora energie. Uvádí se, že s novým standardem bude výdrž až 5x delší než tomu bylo u standardu 2.0. Další novinkou je zlepšení procesu vyhledávání ostatních aktivních zařízení v okolí. Během něho je možné získat o nalezeném zařízení mnohem více informací než dříve. Kromě jména a adresy také seznam dostupných služeb a informace a čase a datu. Závěrem ještě zmiňme, že i zde došlo k navýšení přenosových rychlostí.
V současné době se pracuje na návrhu nového standardu, který by měl být uvolněn v létě roku 2009 pod označením Bluetooth 3.0. Předpokládá se, že díky nové radiové technologii UWB (Ultra-wideband) bude dosaženo velmi výrazné zvýšení přenosových rychlostí, odhady hovoří o maximu 480 mbit/s.
21
3.8. Bluetooth a J2ME J2ME poskytuje rozhraní pro přístup k bluetooth zařízení známé jako JSR 82. S jeho pomocí je možné vytvářet programy, které používají jako komunikační prostředek právě tuto technologii. Pokud chceme v programu se zařízením pracovat, musíme ze všeho nejdřív importovat balíček javax.bluetooth. Nyní už máme přístup k zařízení a můžeme provádět akce jako prohledávání okolí, vyhledávání služeb na nalezených zařízeních, vytváření a rušení spojení a samozřejmě vlastní komunikaci. V programu musíme implementovat rozhraní DiscoveryListener, v němž jsou definovány metody, které volá systém pro obsluhu událostí, které nastanou. Metody, které toto rozhraní definuje jsou deviceDiscovered – volána, pokud je v dosahu nalezeno nějaké aktivní zařízení inquiryCompleted – volána při dokončení prohledávání okolí servicesDiscovered – volána, pokud je na daném zařízení nalezena požadovaná služba serviceSearchCompleted – volána, pokud je dokončeno vyhledávání služeb na daném zařízení Protože volání některých metod jsou blokující je nutné implementovat bluetooth komunikaci ve vlastním vlákně. Možná základní kostra aplikace je ukázaná v příloze E, v sekci E.2. Podrobný popis JSR 82 je k nalezení na [19].
22
4. Aplikace BattleShips – analýza a návrh implementace
Nyní se už pojďme věnovat analýze, návrhu a implementaci doprovodné aplikace. Přesné slovní zadání (které je také uvedeno na vloženém listu) zní: Navrhněte a implementujte na mobilním zařízení hru lodě pro dva hráče a jednoho hráče proti počítači. Zařízení budou komunikovat přes rozhraní bluetooth. Ve své práci uvažujte chybové stavy vzniklé přerušením spojení a ukončením hry jedním z účastníků K aplikaci vytvořte kromě grafického rozhraní i rozhraní přizpůsobené pro nevidomé uživatele. Správnost návrhu aplikace ověřte v testech použitelnosti.
Nyní na základě tohoto slovního popisu sestavíme katalog požadavků, a to jak funkčních tak nefunkčních, neboť je jediný prostředek, podle kterého lze na konci vývojového procesu určit, zda aplikace skutečně dělá, co má a zda bylo dosaženo stanovených cílu.
4.1. Funkční požadavky Funkční požadavky představují specifikaci dílčích činností, které má vytvářená aplikace podporovat respektive umožňovat, jak se má chovat, ale i popis, jak se naopak chovat nesmí. Případně zde může být takové uveden seznam činností, které jsou už naopak nad rámec daného úkolu a které už aplikace nabízet nebude. Uveďme nejprve ty požadavky, které jsou na první pohled zřejmé: FP 1:
Aplikace bude představovat elektronickou verzi známe společenské hry Lodě.
FP 2:
Aplikace bude umožňovat hru jednoho hráče na jednom mobilním zařízení i hru dvou hráčů na dvou zařízeních.
FP 3:
Při síťové hře dvou hráčů budou zařízení pro komunikaci pomocí technologie Bluetooth.
FP 4:
Aplikace bude umět relevantně reagovat na přerušení síťové hry jedním z účastníků, respektive na výpadek Bluetooth spojení.
Kromě požadavků vyplývajících přímo ze zadání by se slušelo, aby aplikace nabízela podobné možnosti, jaké většinou tento typ aplikací, tedy her, nabízí. Přidejme tedy ještě následující funkční požadavky: FP 5:
Aplikace bude vícejazyčná.
FP 6:
Aplikace bude poskytovat volbu obtížnosti lokální hry.
23
FP 7:
Aplikace bude poskytovat volbu počtu lodí flotily.
FP 8:
Aplikace bude umožňovat kromě vizuální prezentace také přehrávání doprovodných zvukových efektů
FP 9:
Aplikace bude umožňovat regulaci hlasitosti přehrávaných zvuků, plus volbu vypnuto/zapnuto.
FP 10: Aplikace bude počítat skóre dosažené během hry a uchovávat 10 nejlepších dosažených výsledků.
4.2. Nefunkční požadavky Nefunkční požadavky slouží ke specifikaci dalších vlastností nebo omezení, která přímo nesouvisí s funkcionalitou aplikace. Typicky se jedná třeba o požadavky na minimální hardwarovou konfiguraci, na které musí být možno aplikaci spustit a provozovat, o požadavky na kompatibilitu aplikace, dostupnost aplikace, spolehlivost nebo o zvolený programovací jazyk, pomocí kterého bude aplikace implementována. Naše nefunkční požadavky vypadají takto: NP 1:
Aplikace bude implementována pomocí J2ME, konkrétně v CLDC konfiguraci a MIDP profilu.
NP 2:
Aplikace bude spustitelná na zařízeních podporujících CLDC konfiguraci ve verzi 1.1 nebo vyšší a MIDP profil ve verzi 2.0 nebo vyšší.
NP 3:
Aplikace bude spustitelná na zařízeních, které mají alespoň QVGA rozlišené displeje (tedy 240 x 320 pixelů) a vyšší.
NP 4:
Pro síťovou hru musí být na obou hostitelských zařízení, které se chtějí hry zúčastnit podporována technologie Bluetooth.
NP 5:
Aplikace poskytne kromě standardního uživatelského rozhraní (výstupu na displej) také rozhraní pro nevidomé uživatele.
4.3. Hlubší analýza některých požadavků Pojďme se nyní podrobně podívat na ty požadavky, které nejsou zcela jednoznačné a přesněji je vymezit a zjistit, co jejich splnění obnáší. FP1 hovoří o tom, že aplikace má představovat elektronickou verzi společenské hry lodě. Bohužel, jak tomu u takto rozšířených lidových společenských her bývá, neexistují nikde jednotná, přesně daná pravidla. Podle autora tedy pojem „hra lodě“ znamená zhruba následující. Hrací plochou je obdélník opatřený souřadným systémem. Každý hráč si ve svém obdélníku rozmístí své vlastní lodě. Tvar a počet lodí je přesně definován a je pro oba hráče stejný. Rozmísťování lodí se provádí tak, aby se žádné dvě lodě nedotýkaly, přičemž na dotek se nepovažuje situace znázorněná na obrázku 4.1.
24
Po rozmístění lodí obou hráčů hra začíná. Cílem hry je potopit soupeřovu flotilu dřív, než on potopí Vás. Střelba probíhá tak, že hráč vždycky zvolí pole, pomocí souřadného systému, kde si myslí, že by mohl mít protihráč umístěnou svoji loď, respektive její část. Druhý z hráčů vždycky po střelbě oznámí prvnímu výsledek. Hráči se ve střelbě střídají po jednom tahu. FP4 požaduje, aby se aplikace uměla vypořádat se situací, kdy jeden z hráčů ukončí síťovou hru nebo když dojde k výpadku spojení. Nejjednodušší varianta, která zde existuje, je v takovém případě informovat uživatele na druhé straně hry a následně ukončit i jeho hru. Popsaná varianta je však značně uživatelsky nepřívětivá. Navíc je třeba si uvědomit, že dojde-li k výpadku spojení například z důvodu překročení maximální vzdálenosti, na kterou jsou zařízení pomocí technologie Bluetooth komunikovat, je to situace, kdy si ani jeden z hráčů ukončení bitvy ve skutečnosti nepřeje. Proto bude mnohem lepší dá uživatelům v takovém případě na výběr co chtějí udělat, jestli si přejí pokusit se o znovu navázaní spojení a pokračování v rozehrané hře, nebo zda chtějí rozehranou hru dohrát na lokálně proti počítači, respektive telefonu nebo zda chtějí hru jednoduše ukončit. Na tomto místě je třeba si uvědomit dvě věci. První je fakt, že při opětovném navazování spojení, je třeba zajistit, aby v tomto režimu bylo možné se připojit pouze k rozehrané hře na straně klienta a aby server akceptoval pouze příslušného klienta, se kterým má rozehranou hru. Druhá věc je, že možnost dát uživateli volbu dohrání rozehrané hry lokálně proti telefonu ve své podstatě znamená, udržovat na obou zařízeních po celou dobu síťové hry popis jak vlastních tak soupeřových lodí a zajistit konzistenci informací, tedy aby na obou zařízeních byl tento popis stejný. obr 4.1. Přípustné umístění
Nakonec zmiňme ještě NP 5. Ten požaduje existenci alternativního rozhraní pro nevidomé uživatele. Základní myšlenkou takového rozhraní je fakt, že všechny informace musí být prezentovány pomocí jiných smyslů než zraku. Této problematice se bude podrobně věnovat sekce 5.3.
4.4. Návrh aplikace Protože je zde požadavek prezentovat informace různou formou (klasické uživatelské rozhraní a rozhraní pro nevidomé uživatele) hodí pro základní strukturu aplikace použít návrhový vzor MVC (Model-View-Controller). MVC člení aplikaci na tři základní části – prezentační vrstvu, vlastní logiku aplikace, takzvanou business vrstvu a datový zdroj zvaný model nebo též integrační vrstva. Princip MVC návrhové vzoru je zachycen na následujícím obrázku.
25
Obrázek 4.2.: Princip návrhové vzoru MVC
Prezentační vrstva, neboli „View“ má za úkol jednak prezentovat výstup aplikace, ale také zachytávat požadavky od uživatele. Ty pak předává dál do business vrstvy aplikace, do „Controlleru“, která je zpracovává a popřípadě volá datový model aplikace, pokud je potřeba nějaká manipulace s daty. Po zpracování požadavku je z controlleru volána opět prezentační vrstva, aby uživateli zobrazila výsledek a nový stav aplikace. Je zřejmé, že při aplikování tohoto modelu, pak není problém vytvořit více forem prezentační vrstvy a podle nastavení programu volat příslušnou z nich. Dodejme ještě, že žádná z vrstev nemusí být, a z pravidla také nebývá, tvořena jen jedinou třídou. Většinou se jedná o několik tříd, které si mezi sebe dělí dílčí úkoly v dané vrstvě. V naší aplikaci bude prezentační vrstva reprezentována balíčkem presentationTier, integrační vrstva balíčkem integrationTier a do business vrstvy spadnou všechny třídy z balíčku bussinessTier.
Popisem jednotlivých vrstev se zabývají kapitoly 5,6 a 7, ve kterých budou uvedeny základní nebo zajímavé body implementace jednotlivých částí.
26
5. Prezentační vrstva aplikace
V této kapitole se budeme zabývat grafickým uživatelským rozhraním pro naší aplikaci. A to jak klasickým, tak i alternativním rozhraním pro nevidomé uživatele.
5.1. Možnosti tvorby GUI v J2ME Nejprve je však potřeba splatit dluh, který máme z kapitoly 2. V sekci 2.4.2. je u popisu jednotlivých balíčků uvedeno, že způsob tvorby uživatelského rozhraní v J2ME bude uveden později. Nyní je ta pravá chvíle. Třídy pro práci s GUI jsou v J2ME umístěny v balíčku javax.microedition.lcdui. J2ME nabízí programátorovi třídy pro tvorbu grafického rozhraní dvojího typu – nízkoúrovňové a vysokoúrovňové. Poměrně omezující vlastností GUI v J2ME je, že není možné API kombinovat, jako je to běžné u GUI knihoven ze světa klasických stolních počítačů. Je sice možné vytvořit v aplikaci jedno okno postavené na High-level API a jiné na Low-level API, ale už není možné si do části okna typu Form vložit například Canvas s vlastním obsahem nebo naopak do Canvasu vložit TextBox pro zadání textu. Obrázek 5.1. ukazuje hierarchii tříd podílejících se na tvorbě uživatelského rozhraní a jejich rozdělní na zmíněné dva typy.
Obrázek 5.1.: Hierarchie tříd pro tvorbu uživatelského rozhraní
27
Základní třídou je třída Display, která reprezentuje displej zařízení. Pomocí její metody setCurrent(Displayable d) je možné zobrazovat na displeji objekty implementující rozhraní Displayble, které společným zastřešením pro oba typy uživatelského rozhraní v J2ME. Nyní se oba podíváme podrobněji. 5.1.1. Vysokoúrovňové uživatelské rozhraní Vysokoúrovňové rozhraní, někdy též označované jako High-level API, je jakousi obdobou AWT nebo Swingu z J2SE v mobilním světě. Oproti těmto však nabízí výrazně omezené možnosti právě s ohledem na omezené výpočetní prostředky a velikost displeje mobilních zařízení. Jeho základem je abstraktní třída Screen. Od ní jsou odvozené třídy, které se mohou objevit na obrazovce zařízení. Nejběžnější a nejčastěji používanou je Form, která představuje obyčejné okno. Třída Alert slouží k zobrazování dialogu a můžeme ji tak přirovnat k MessageBoxům známým z prostředí stolních počítačů. Pomocí třídy TextBox je možné vytvořit okno, umožňující zadávání víceřádkového textu. Třída List slouží k vytvoření seznamu položek, který může být použit na příklad pro tvorbu menu. Instance těchto tříd mohou obsahovat (zobrazovat) další prvky GUI odvozené od abstraktní třídy Item. Těmito prvky jsou například TextField, který slouží buď k zobrazení textu nebo pro vytvoření políčka umožňující jednořádkový vstup, ImageItem pro zobrazení obrázku a další. Interakce s uživatelem je zajištěna pomocí instancí objektů třídy Command a rozhraní CommandListener respektive ItemCommandListener. Každému grafickému prvku lze pomocí metody addCommand(Command c) přiřadit příkazy na které má reagovat. Pomocí metody setCommandListener(CommandListener cl) u prvků implementující dozraní Displayble a setItemCommandListener(ItemCommandListener icl) u prvků odvozených od třídy Item se nastaví objekt implementující toto rozhraní, tedy místo, kde se nacházejí definice funkcí, které jsou volány při volbě příkazu uživatelem. Při vytváření objektů jednotlivých příkazů se vždy uvádí jméno, to bude zobrazeno jako label příkazu, typ příkazu a jeho priorita. Ukázka práce s vysokoúrovňovým rozhraním je v příloze E, v sekci E.3.
Výhody a nevýhody Hlavní výhodou toho rozhraní jeho jednoduchost a nenáročnost na implementaci. Potěšující je také standardní vzhled, který je odvozen od nastavení telefonu, takže aplikace používající toto rozhraní se respektují uživatelské nastavení vzhledu a zobrazovacího motivu. Na druhou stranu nemožnost ovlivnit vzhled zobrazovaných informací může být někdy docela svazující. Za hlavní nevýhodu tohoto API ovšem považuji absenci prostředků k ovlivnění namapování jednotlivých příkazů na softwarové klávesy telefonu a vůbec skutečnost, že není možné zachytávat události klávesnice telefonu.
28
5.1.2. Nízkokoúrovňové uživatelské rozhraní U nízkoúrovňového rozhraní je situace zcela odlišná. Přestože neobsahuje takové množství tříd, nabízí programátorovi daleko větší možnosti. Základní, a téměř také jedinou, třídou je abstraktní třída Canvas. Pro použití si od této třídy vytvoříme potomka, kde předefinujeme abstraktní metodu paint(Graphics g), která je volaná systémem při požadavku na vykreslení respektive překreslení obsahu okna. Dalšími pomocnými třídami jsou pak třídy Image pro manipulaci s obrázky a třída Graphics, která poskytuje jakýsi grafický kontext pomocí kterého možné do okna, kreslit. Zajímavostí je, že kromě okna, lze grafický kontext získat také ke každému obrázku. Lze si například vytvořit nový prázdný obrázek v paměti, pomocí grafického kontextu ho vykreslit a pak až ho zobrazit na displeji. Této techniky se využívá u takzvaného double-bufferingu, aby se zamezilo blikání obrazovky při jejím vykreslování. V paměti se vytvoří nový obrázek stejných rozměrů jako je rozlišení displeje. Od něj se získá grafický kontext pomocí kterého je do něj vykreslený požadovaný obsah. Jakmile je vykreslování dokončeno, je následně celý hotový obrázek vykreslen na displej pomocí kontextu náležícího obrazovce. Kromě vykreslování obrázků osahuje třída Graphics také metody pro kreslení základních geometrických tvarů a textu. Ukázka práce s vysokoúrovňovým rozhraním je v příloze E, v sekci E.4.
Výhody a nevýhody Hlavní výhodou tohoto API je značná flexibilita a možnost vytvoření rozhraní takříkajíc „na míru“. Rovněž byla přidána možnost zachytávat a zpracovávat události z celé klávesnice zařízení. Na druhou stranu jsou tyto výhody vykoupeny faktem, že veškerá zodpovědnost za správné vykreslení, tedy i za rozmístění jednotlivých vykreslovaných prvků je na programátorovi.
5.2. Frameworky Protože práce s nativními prostředky pro tvorbu uživatelského rozhraní neposkytuje dostatečné možnosti v případě High-level API a není příliš pohodlná v případě Low-level API, existují pro usnadnění práce také různé frameworky. Nyní se stručně podíváme na dva nejznámější. Pro pořádek dodejme, že možnosti obou frameworků jsou podstatně širší a neomezují se pouze na podporu pro tvorbu GUI.
J2ME Polish freamework Jedná se o ucelený programový balík pro tvorbu mobilních aplikací založený na platformě J2ME.
29
Jakožto moderní nástroj je založen na návrhovém vzoru MVC a odděluje tedy prezentační vrstvu aplikace od zdroje dat a vlastní logiky. Pro definici vzhledu se zde používá jazyka kaskádových stylů CSS. Kromě klasických komponent z High-level API jsou zde dostupné také nové komponenty jako například TabbedForm nebo TreeItem. K propojení vlastního kódu a designových CSS definicí slouží direktiva #style, která se vkládá do zdrojového kódu. J2ME Polish podporuje CSS box model, tedy můžeme nastavovat okraje, zarovnání, odsazení a další parametry (margin, border, padding). Kromě podpory práce s GUI nabízí framework také vylepšenou podporu pro práci s RMS, funkce pro usnadnění lokalizace aplikace do více jazyků a také vzdálené volání procedur. Velkou výhodou J2ME Polish je, že pro nekomerční použití je dostupný zdarma pod licencí GPL. Pro komerční účely pak definuje svoji vlastní licenci. Více informací je k nalezení na jeho domovské stránce na [21].
TWUIK Druhým známým frameworkem, který je stejně mocný jako první je TWUIK. Jeho velkou výhodou je, že je multiplatformní. Kromě J2ME MIDP a CLDC je možné jej provozovat taky na platformě Blackberry nebo J2ME/Doja 4.x/5.x. Připravuje se dokonce verze pro platformu Windows Mobile 5.0/6.0. Na rozdíl od předchozí se TWUIK soustředí hlavně na prezentační vrstvu aplikace. Nabízí bohaté rozhraní a velké množství grafických prvků jako jsou okna, navigační prvky, layout managery, animace a pohyby. Podporuje také práci s obrázky. Výhoda multiplatformovosti je vykoupena nepříjemným faktem i pro nekomerční použití je framework zpoplatněn. Pouze pro testovací účely je možné zdarma stáhnout časově omezenou trial verzi. Více informací o tomto balíku je k nalezení na [22].
5.3. GUI aplikace Po teoretickém úvodu nyní nadešel čas přikročit k tvorbě vlastního rozhraní naší aplikace. Po předchozím výkladu je jasné, že naše GUI musí být postavené, s jedinou výjimkou (viz dále), na nízkoúrovňovém API. Protože si práce klade za cíl seznámit čtenáře se základy J2ME, tak jsem se z čistě cvičných a demonstračních důvodů nakonec rozhodl nepoužít žádný framework a tvorbu rozhraní realzizovat pouze nativními prostředky dostupnými v J2ME. Jak už bylo řečeno v kapitole 4, všechny třídy podílející se na tvorbě uživatelského rozhraní pro naší aplikaci budou soustředěny v balíčku presentationTier. Ten se dále dělí na balíčky presentationTier.screen, který obsahuje třídy pro vizuální část GUI a presentationTier.sound, kde se nalézají třídy pro přehrávání doprovodných zvukových efektů. Obsahem balíčku pro práci se zvuky je pouze jediná třída SoundPlayer, která má na starosti přehrávání zvuků.
30
V balíčku presentationTier.screen se kromě tříd reprezentujících jednotlivá okna aplikace nacházejí ještě dva „podbalíčky“, kde jsou umístěny třídy pro lokalizaci aplikace a třídy tvořící grafické komponenty zobrazované ve více částech aplikace (v různých oknech). Hierarchie tříd oken je naznačena na následujícím obrázku.
Obrázek 5.2.: Naznačení hierarchie tříd GUI Pro pořádek nejprve dodejme, že na obrázku z prostorových důvodů nejsou znázorněny všechny třídy, kterých je celkem 20. Ve spodní části chybí ještě 7 tříd, které také dědí od třídy AbstractWindow a představují další jednotlivá okna aplikace. Hierarchie a členění tříd je však z obrázku dobře patrné. Základ tvoří abstraktní třída AbstractScreen, která je společným prapředkem téměř všech tříd. Je přímým potomkem třídy Canvas a jejím úkolem je přepnout zobrazení do celoobrazovkového módu a vytvořit základní podklad vyplněný danou barvou pozadí. Kromě toho také obsahuje referenci na aplikační logiku (business vrstvu). Od této třídy jsou odvozené tři další konkrétní třídy, které zobrazují úvodní obrazovky při spouštění aplikace a abstraktní třída AbstractWindow, která slouží jako společný základ všem oknům aplikace. Jejím úkolem je na bílý podklad vytvořený třídou AbstractScreen na kreslit horní pruh s názvem okna a spodní pruh s popisy levého a pravého funkčního tlačítka telefonu. Třídy od ní odvozené, které reprezentují už konkrétní obrazovky, které se objevují na displeji, pak při svém vykreslování v metodě paint(Graphics g) volají nejprve metodu této třídy. Každý z těchto tříd, včetně společné abstraktní, také definuje důležitou metodu calculateLayout(), která je volána při každé změně velikosti okna (i při jeho prvotním rozbrazení) a která má za úkol vypočítat rozmístění prvků. I v této metodě dochází nejdříve k volání téže metody v definici předka. Samotné volání metody calculateLayout() při každé změně velikosti okna je pak zařízeno jejím zavoláním z metody sizeChanged(int w, int h), která je definovaná ve 31
společní abstraktní třídy a která je volána systémem pokud ke změně velikosti okna dojde. Třídy DialogError a NewGame2Form tvoří pak onu výjimku zmíněnou v úvodním slově této sekce. Jejich základem jsou totiž prvky z vysokoúrovňového API. Konkrétně je to třída Form pro NewGame2FormWindow a třída Alert pro DialogError. K jejich použití vedla nutnost vložit do okna prvek pro zadávání textu v případě prvním a snadnější systém prezentace chybových a informačních hlášení v případě druhém.
5.4. Alternativní rozhraní aplikace Nyní, když máme vytvoření klasické uživatelské rozhraní, pojďme se zaměřit na rozhraní alternativní. Vzhledem k tomu, že toto rozhraní má být určeno pro osoby s částečnou nebo úplnou ztrátou zraku, je třeba v tomto rozhraní veškeré informace prezentovat jinou, než vizuální formou. V zásadě jedinou možností, kterou v takovém případě máme, je zvolit audio formu. Informace budeme tedy uživateli sdělovat pomocí řeči popřípadě zvuků.
5.4.1. Návrh Nejprve si řekneme jak by se takové rozhraní mělo v naší aplikaci chovat, jaké informace a jakou formou by mělo prezentovat. Z hlediska prezentovaných informací se uživatel během používání aplikace pohybuje mezi dvěma základními typy oken, na které je potřeba nahlížet poněkud odlišně. První skupinu tvoří okna, kterým bychom mohli říkat třeba „okna pro nastavení“ nebo „okna pro přípravu hry“. Příklady takových oken jsou ukazují obrázky 5.3. až 5.5.
Obr. 5.3.: Nastavovací okno 1
Obr. 5.4.: Nastavovací okno 2
32
Obr. 5.5.: Nastavovací okno 3
V oknech tohoto typu klademe na rozhraní následující požadavky: po načtení okna přečíst obsah okna – tedy názvu okna, levé i pravé funkční klávesy a aktivní položku (pokud se položka skládá z názvu i hodnoty přečíst oboje). Příklad výstupu: Hlavní menu Položky Nová hra, Síň slávy, Nastavení, Nápověda, O aplikaci. Aktivní položka Nová hra. Levá funkční klávesa Ok, pravá funkční klávesa Konec.
při změně polohy kurzoru přečíst buď název popřípadě hodnotu nové položky nebo přehrát zvuk oznamující konec respektive začátek seznamu. Příklad výstupu: Jazyk čeština.
při změně hodnoty v okně pro nastavení přečíst novou hodnotu nebo přehrát zvuk oznamující končenou respektive počáteční položku v možném výčtu. pomocí jedné z kláves vynutit znovu přečtení informací jako v prvním bodě. Příklad výstupu Obtížnost vysoká.
Do druhé skupiny spadají okna, která slouží k prezentování informací během samotné hry. Ta jsou vlastně jen dvě – okno pro rozmístění lodí (obrázek 5.6.) a okno ve kterém probíhá samotná hra (obrázek 5.7.)
Obr. 5.7.: Herní okno
Obr. 5.6.: Okno pro rozmístění lodí
V tomto případě musí rozhraní splňovat tyto požadavky: každý hrací plán je opatřen souřadným systémem. Přesto, že se v klasickém rozhraní souřadnice nezobrazují, není to potřeba, má každé políčko své unikátní jméno, které složeno z označení řádku a sloupce. Sloupce se označují pomocí čísel a pro řádky je použito písmenné označení. 33
po načtení okna přečíst informace, jaký plán je zobrazen, popis funkčních kláves, na jaké pozici je kurzor a kdo je na tahu. Pozice kurzoru bude hlášena pouze v případě, že se hráč nachází v pláne, kde je možné se pohybovat a zároveň je na tahu. Příklady výstupu: Nepřátelské lodě. Nepřátelské lodě Jste na tahu. Na tahu je soupeř. Kurzor na pozici Hektor 8.
při pohybu kurzoru po mapě bude stav políček rozlišován pomocí tří základních zvuků. Šumění moře označuje políčko, které ještě nebylo prozkoumáno. Žbluňknutí signalizuje neúspěšnou střelbu a zvuk požáru označuje místo, kde došlo k zásahu části lodi. Při pohybu bude vždy řečeno jméno políčka a přehrán zvuk Aby nedocházelo ke zbytečnému přehrávání zvuků při vícepolíčkovém přesunu, bude zvuk přehrán až po uvolnění klávesy. V takovém případě mu bude rovněž oznámeno o kolik políček a jakým směrem se přesunul Příklad výstupu: Posun o 3 doleva, pozice Eva 5.Žbluňk!.
po každé střelbě bude uživateli sděleno, kdo střílel, s jakým výsledkem a to, že má stisknout libovolnou klávesu k pokračování ve hře. Příklad výstupu: Vaše střelba. Bum! Stiskněte libovolnou klávesu.
po stisknutí klávesy dojde automaticky k přepnutí do druhého plánu. Uživateli bude v takovém případě oznámeno v jakém plánu se nachází a kdo je na tahu. Pokud se nachází v útočném plánu a je na tahu bude mu zároveň oznámena pozice kurzoru. Příklad výstupu: Nepřátelské lodě. Nepřátelské lodě Jste na tahu. Na tahu je soupeř. Kurzor na pozici Hektor 8.
pro rychlejší pohyb po mapě budou k dispozici dvě horké klávesy. První z nich přesune kurzor na co možná největší neprobádanou oblast. Takovém případě mu bude oznámena pozice kurzoru. Příklad výstupu: Kurzor na pozici Béla 3.
Druhá přesune uživatele na místo, kde se nachází zasažené části ne zcela ještě potopené lodi. V tomto případě také dojde k přehrání údaje, kde se nachází kurzor a kolik potopených částí se v oblasti nachází. Příklad výstupu:
34
Eva 10. Dvě části.
pokud hráč po své střelbě nabude dojmu, že se mu podařilo potopit soupeřovu loď, označí si ji jako potopenou. To budou sloužit pro funkci klávesové zkratky popsané v předchozím bodu – po takto označených lodích se nebude možno pomocí klávesové zkratky pohybovat. Tento způsob byl zvolen proto, aby nevidomému hráči nebyla poskytována výhoda, kterou normální hráč nemá. Představme si situaci, kdy maximální délka nepotopené lodě je 5 políček. Hráč v nějaké oblasti mapy našel loď dlouhou 3 políčka. I když už je loď potopena, v normálním GUI je nutné vystřelit ještě jednou, abychom se ujistili, že to není ona „pětka“. pokud dojde k potopení hráčovy lodě, bude mu oznámeno, kterou loď právě ztratil a kolik lodí mu celkem ještě zbývá. Příklad výstupu Potopena Vaše 3. Ještě zbývá: Pětka 0x, čtyřka 1x, trojka 2x, dvojka 1x, jednička 3x.
pomocí klávesy 1 je možné se ve hře manuálně přepínat mezi svým a soupeřovým plánem lodí. Po přepnutí dojde k přehrání stejných informací jako po načtení okna – viz bod 2. po stisknutí příslušné klávesy dojde přečtení statistiky, kolik a jakých lodí zbývá ještě na obou stranách potopit. Příklad výstupu: Vaše zbývající lodě: Pětka 2x, čtyřka 3x, trojka 0x, dvojka 1x, jednička 1x. Soupeřovy zbývající lodě: Pětka 0x, čtyřka 4x, trojka 4x, dvojka 2x, jednička 0x.
V předcházejících bodech byly shrnuty hlavní rysy alternativního rozhraní v situaci během hraní hry. Rozmísťování lodí vypadá velmi podobně jen s tím rozdílem, že statistika zmíněná v posledním bodu informuje o tom, kolik lodí zbývá ještě rozmístit, že některé funkce, jako například pohyb po částečně potopených lodí nejsou vůbec potřeba a místo střelby je přehráván zvuk, který indikuje, zda byla loď umístěna na danou pozici, či nikoliv. Tuto část není nutné zde rozebírat detailně, neboť je více než pravděpodobné, že nevidomý uživatel téměř vždy využije možnost nechat si lodě rozmístit automaticky.
5.4.2. Implementace Teď když už víme, jak by naše alternativní rozhraní mělo vypadat, podíváme se nyní na způsob implementace.
35
Čtečka displeje Nejběžnějším postupem používaným v takové situaci je nasazení nástroje označovaného jako „čtečka displeje“. Jedná se o utilitu, která je schopna rozpoznávat a pomocí hlasového syntetizéru zvukově reprodukovat texty zobrazené na displeji zařízení. Příkladem takové čtečky je třeba aplikace Mobile Speak, která je určená pro mobilní telefony s operačním systémem Symbian. Dalším, v této oblasti velmi známým nástrojem je Jaws, známá především ze světa klasických počítačů, nicméně existuje i v mobilní verzi. Bližší informace k těmto produktům je možné najít na [23] a [24]. Pokud se rohodneme použí pro implementaci nějakého takovéhoto nástroje, narazíme záhy na řadu problémů. Kromě skutečnosti, že neexistuje verze těchto nástrojů schopná běžet na zařízeních bez operačního systému, tedy vlastně na všech levnějších mobilních telefonech, je tu je ještě jeden daleko závažnější problém. Žádná ze současných čteček není schopná přečíst texty zobrazené pomocí nízkoúrovňového grafického rozhraní. V tomto rozhrnaí nejsou totiž informace, ani texty, zobrazené na displeji v textové podobě, ale mají formu bitmapy vykreslované na plátno třídy Canvas. Z hlediska využití čtečky disleje pro alternativní rozhraní je pro nás tato skutečnost nepřekonatelná. A ne jen pro nás. V současné době trápí tento problém všechny vývojáře snažící se své aplikace přizpůsobit i pro nevidomé uživatele. Řešení však zatím neexistuje. V této se souvislosti je s nadějí vzhlíženo k připravované specifikaci profilu MIDP 3.0, která by měla přinést způsob, jak se tímto problém vypořádat.
Wav soubory Alternativním způsobem by bylo použít jako zdroj zvuků předem připravené soubory typu wav, jejichž přehrávání J2ME umožňuje. Při práci s aplikací existuje totiž pouze konečná množina informací, které je třeba prezentovat. Ta ovšem není nikterak malá, ani pokud bereme v úvahu informace prezentované pouze v jednom jazyce nemluvě o požadavku vícejazyčnosti aplikace.
Závěrem lze tedy říci, že v současné době neexistuje žádný přijatelný způsob implementace takovéhoto alternativního rozhraní.
36
6. Business vrstva aplikace
V následující kapitole se budeme zabývat business vrstvou aplikace. Ta představuje vlastní logiku programu a je zodpovědná za vykonávání toho, k čemu byl program navržen. Není jistě žádoucí, ani možné, abychom zde dopodrobna probrali implementaci všech tříd v této vrstvě. Uvedeme pouze jména tříd, které tuto vrstvu tvoří, stručně popíšeme co mají jednotlivé třídy na starosti a také zmíníme zajímavé úseky kódu a způsoby implementace řešení daného problému. Naše aplikační vrstva je soustředěna v základním balíčku bussinessTier. Ten je dále členěn na jednotlivé podbalíčky, které sdružují třídy odpovědné za určitou část logiky programu. Na obrázku 6.1. je zachycen vztah mezi jednotlivými třídami i jejich zařazení do daných podbalíčků.
Obrázek 6.1.: Závislosti a vztahy mezi třídami v aplikační vrstvě 37
Pojďme se nyní podívat na jednotlivé balíčky a třídy.
6.1. Balíček bussinessTier.gui Balíček bussinessTier.gui obsahuje jen jedinou třídu BattleShipController.java. Její instance se vytváří hned po spuštění midletu ve třídě main.java z balíčku main. Představuje tedy nejen jakýsi pomyslný vstupní bod do aplikační vrstvy, ale také vstupní bod do celého programu. Instance všech ostatních tříd se vytvářejí buď přímo v této třídě, jako je tomu třeba v případě všech grafických oken, nebo ve třídách, jejichž instance byly v objektu třídy BattleShipsContoller.java vytvořeny. Jejím hlavním úkolem je především zajistit interakci s uživatelem, tedy zajistit příslušnou reakci na události generované v jednotlivých oknech aplikace. Nejčastěji používanými metodami v této třídě jsou tedy metody previousScreen(), nextScreen(), displayScreen(int screen) a privátní metoda displayScreen().
6.2. Balíček bussinessTier.settings Rovněž tento balíček obsahuje pouze jedinou třídu, konkrétně Settings.java. Její instance reprezentuje nastavení aplikace. Základem třídy je pole, které obsahuje hodnoty jednotlivých položek nastavení. Údaje obsažené v tomto poli mohou být použity buď přímo jako vlastní hodnota dané položky, tak je tomu u nastavení hlasitosti zvuku, nebo jako index do dalších polí, ve kterých jsou uloženy možné hodnoty k dané položce nastavení. Kromě toho obsahuje tato třída také metody pro zjištění respektive změnu jednotlivých položek nastavení, metodu, která zjistí, jestli došlo ke změně nějaké z položek nastavení a podobně. Instance této třídy je vytvořená ve třídě SettingsDAO.java a je naplněná buď hodnotami načtenými z RMS nebo z výchozími hodnotami, pokud se v RMS uložené nastavení nenachází, nebo se z nějakého důvodu nepodaří načíst.
6.3. Balíček bussinessTier.topten Třetí a poslední balíček, ve kterém se skrývá jen jediná třída. Tou je třída Topten.java, která, jak už název napovídá reprezentuje objekt nejlepšího skóre.
Základ třídy tvoří dvourozměrné pole řetězců. To v prvním sloupci obsahuje jména nejlepších hráčů a ve druhém jimi dosažené skóre. Dále se zde nachází metody, které umožňují zjistit jednotlivé údaje, zjistit jestli došlo ke změně nejlepších výsledků a samozřejmě také metodu, která vloží do tabulky na patřičné místo nové nejlepší skóre.
38
6.4. Balíček bussinessTier.btConnection Třídy v tomto balíčku mají na starosti síťovou komunikaci přes rozhraní bluetooth, tedy navázání spojení a po té i vlastní komunikaci během hry. Balíček obsahuje následující třídy.
BtConnection.java
Objekt této třídy reprezentuje v aplikaci vlastní BT spojení. Základním datovým členem této třídy jsou datové proudy DataInputStream a DataOutputStream pro čtení a zápis dat. Kromě toho obsahuje taky síťové adresy obou uzlů spojení, URL pro připojení a jméno hry. Z metod jmenujme metody sendData(String data) a sendData(int data) pro poslání dat a receiveStringData() a receiveIntData() pro čtení dat. Samozřejmě nesmí chybět ani metody pro uzavření spojení, přístup k informačním datovým položkám třídy. Tyto informační datové složky slouží hlavně v případě, kdy je potřeba znovu navázat ztracené spojení. V takovém případě je potřeba zajistit, aby se klient mohl připojit pouze na ten server, od kterého byl odpojen a aby server akceptoval pouze klienta, který k němu byl předtím připojen.
BtServer.java
Třída použitá při navazování BT spojení na straně serveru. Protože téměř veškeré operace spojené s bluetooth komunikací jsou blokující, musejí být implementovány ve vlastním vlákně. Třída tedy implementuje rozhraní Runnable a v metodě run() definuje postup pro navázání spojení používaný na straně serveru. Na začátku navazovacího procesu je pak ve třídě vytvořen objekt třídy Thread, jemuž je předán odkaz na metodu run(), kde jsou definované příkazy, které se mají v tomto vlákně provést. V našem případě jsou to příkazy pro navázání BT spojení. Po úspěšném navázání spojení dojde k vytvoření instance třídy BtConnection.java (viz výše) nesoucí informace o spojení a metody pro komunikaci. Tato instance je na závěr předána do třídy Game.java a Enemy.java, kde dochází k vlastnímu posílání dat z jednoho telefonu na druhý během hry.
BtClient.java
Poslední třída v tomto balíčku je zodpovědná za navázaní spojení na straně klienta. Klient při navazování spojení musí provést následující úkony: prohledat okolí a nalézt v něm všechna aktivní BT zařízení. na každém nalezeném zařízení spustit prohledávání služeb a zjistit jestli poskytuje hledanou službu (jestli na něm běží server). navázat vlastní spojení s vybraným zařízením. I zde platí zásada, že vlastní navazování spojení musí být implementované ve vlastním vlákně.
39
Třída implementuje rozhraní DiscoveryListener, které obsahuje tyto 4 metody . deviceDiscovered(RemoteDevice btDevice, DeviceClass cod); inquiryCompleted(int discType); servicesDiscovered(int transID, ServiceRecord[] servRecord); serviceSearchCompleted(int transID, int respCode);
Jednotlivé metody jsou volány systémem pokud nastane příslušná událost. Nalezení aktivního zařízení, dokončení průzkumu okolí, nalezení služby na testovaném zařízení a dokončení vyhledávání služeb na zařízení. Oproti ukázkovým příkladům práce s tímto rozhraním od společnosti Sun Microsystems zde muselo být použito jedno vlákno navíc. Více se této skutečnosti budeme věnovat v této kapitole, v sekci 6.6.
6.5. Balíček bussinessTier.game Poslední a zároveň nejdůležitější balíček, který se v aplikační vrstvě nachází. Pomocí tříd, které jsou v něm definovány je realizována vlastní hra. A to jak lokální pro jednoho hráče, tak síťová. Balíček obsahuje následující třídy:
OceanPosition.java
Pomocí této třídy je v aplikaci reprezentována poloha (umístění) v souřadném systému na bitevním plánu. Základními datovými členy třídy jsou dvě proměnné typu int, které reprezentují řádkový a sloupcový index. Kromě toho třída dále obsahuje metody pomocí kterých je možné vypočítat sousední pozice, pokud existují a metodu pro porovnání dvou pozic na mapě, pro zjištění shody.
OceanField.java
Třída reprezentující jedno políčko na bitevní mapě. Informace o pozici políčka na výsledné mapě je vyjádřena pomocí objektu předchozí třídy. Kromě toho třída také obsahuje informace o stavu políčka (jestli je na něm loď, jestli na dané políčko už bylo vystřeleno a podobně), jméno políčka a také odkaz na část lodi, která se na něm nachází. Pomocí metod, definovaných v této třídě je pak možné zjišťovat stav políčka, pokusit se na něj umístit část lodi, vystřelit na danou pozici a ještě další pomocné úkoly.
AbstractShip.java
Třída je společným předkem všech skutečných lodí, které se ve hře vyskytují. Už na tomto místě jsou definovány všechny potřebné metody pro práci s lodí. Její potomci AircraftCarrier.java, Destroyer.java, HeavyCruiser.java,
40
LightCruiser.java a Submarine.java, pak pouze definují dvě metody, které jsou v této
třídě abstraktní, pro výpočet pozice jednotlivých částí lodí a pro výpočet okolí lodi. Základním datovým členem je pole objektů třídy OceanField, které odkazuje na jednotlivá políčka na mapě, na kterých se nachází daná loď. Kromě toho také obsahuje dvě pole objektů OceanPosition, kde jsou uchované souřadnice těchto políček a souřadnice políček z okolí lodi, dále odkaz na mapu (objekt třídy Ocean), ve které se nachází, jméno, velikost lodi a orientaci lodi (horizontální nebo vertikální umístění). Pomocí z této třídy metod je pak možné zjistit informace o umístění lodi, její orientaci, jestli už došlo k potopení lodi, je možné změnit orientaci a samozřejmě umístit loď na danou pozici. Umísťování probíhá následujícím. Každá loď má se skládá z několika částí. Vždy jedna z nich je označena jako takzvaný kapitánský můstek. Při umisťování je pak kapitánský můstek umístěn na pozici kurzoru a od této pozice se pak dopočítávají pozice ostatních částí a pozice okolí lodi.
Ocean.java
Objekt této třídy reprezentuje v aplikaci bitevní mapu. K základním datovým členům patří dvourozměrné pole objektů třídy OceanField, které uchovává odkazy na políčka tvořící vlastní mapu a dále pole objektů třídy AbstractShip, které představuje lodě na této mapě. Kromě toho nese třída také informace o celkových rozměrech mapy a o počtu už rozmístěných lodí (využívá se při rozmísťování lodí) Pomocí metod, které nám tato třída nabízí je možné kromě čtení různých stavových informací také otáčet právě umísťovanou lodí, umístit loď na danou pozici, vystřelit na danou pozici nebo vygenerovat automatické umístění lodí pomocí metody generateShipsFormation(). Algoritmus pro rozmísťování použitý v této metodě se musel vypořádat s problémem nedostatku paměti. Podrobněji bude tato situace rozebrána dále v této kapitole, konkrétně v sekci 6.6.
Enemy.java
Touto třídou je v aplikaci reprezentován protihráč. A to jak lokální, tak síťový. Třída umožňuje tři základní typy protihráče. lokální s nízkou obtížností lokální hra s vysokou obtížností síťová hra Při každé hře se využívají jiné datové složky a metody.
lokální s nízkou obtížnosti Nejjednodušší algoritmus na vyhledávání a potápění lodí. Není zde brát zřetel na předchozí výsledek střelby ani na délku největší lodi, která ještě není potopena. Algoritmus pouze náhodně volí políčka, kam zkouší střelbu. Jedinou podmínkou je, že musí být zvoleno políčko, které ještě není zasažené. Algoritmus výběru volného políčka pracuje následujícím způsobem. Základem je náhodné generování dvou čísel, která představují řádkový a sloupcový index. Aby se
41
zamezilo situaci, kdy bude algoritmus stále generovat pozice už obsazené, je definován počet pokusů, během kterých se algoritmus snaží náhodně najít volnou pozici. Pokud se mu to nepodaří, například z důvodu pokročilé fáze hry, dojde ještě jednou k vygenerování dvojice čísel určující pozici a od této pozice je pak systematickým prohledáváním (zleva doprava a shora dolů) nalezena první volná pozice a tam je vystřeleno. Základní datové členy, které se zde používají, a které se zároveň používají i v ostatních typech hry, jsou objekt třídy Game reprezentující hru (viz další třída), a rozměry hrací plochy, rowCount a columnCount. Metodou implementující algoritmus pro určení políček ke střelbě je lowSkill().
lokální hra s vysokou obtížností Vysoká úroveň lokální hry se pracuje ze začátku stejně jako v případě předchozím. Nejprve pouze náhodně volí políčka a čeká na první zásah. Jakmile je zasažena část lodi, nastává druhá etapa – kompletní potopení lodi. V této fázi se postupuje tak, že je náhodně vybrán směr, ve kterém se budou hledat další části lodi. Pak je tímto směrem stříleno a dokud je střelba úspěšná pokračuje se tímto směrem. Jakmile se narazí na prázdný oceán, algoritmus se vrací zpět na místo prvního zásahu a zkouší směr opačný. V případě, že ani v jednom směru nedošlo k zásahu, přechází algoritmus na střelbu v další ose roviny, kde se postupuje stejným způsobem. Pokud v první ose došlo k více než jednomu zásahu, není třeba zkoušet druhou osu, neboť žádná z lodí neleží najednou ve více řádcích a více sloupcích. Algoritmus také bere v potaz délku největší dosud nepotopené lodi. To znamená, že pokud jsou zasažené 3 části a víme, že všechny lodě velikosti 5 a 4 už byly potopeny, fáze potápění lodi končí a algoritmus přechází opět do režimu vyhledávání další lodi. Kromě datových členů použitých i v prvním kroku se zde navíc používají objekt třídy Stack s názvem shipParts, kam se ukládají již zasažené části právě potápěné lodi, pole celých čísel countsOfShips, kde jsou uloženy počty zbývajících lodí jednotlivých rozměrů, číselná proměnná mode, která říká v jaké fázi (vyhledávání x potápění) se algoritmus nachází, celočíselná proměnná direction, která udává směr od první zasažené části, který se prozkoumává a pár dalších pomocných proměnných. Metodou která tvoří vstup do daného algoritmu je highSkill(). Zbytek algoritmu pak tvoří metody z ní volané a to přímo nebo i nepřímo.
síťová hra Tento typ hry se od dvou předchozích zásadně liší. Jedná se o hru dvou lidí proti sobě a tak zde není potřeba žádná umělá inteligence. Na druhou stranu je potřeba zajistit čtení respektive posílání dat po síti. Základním stavebním kamenem v tomto případě je opět vlákno. V tomto vlákně neustále běží cyklus, který čte data ze vstupního proudu. Zápis dat do proudu není blokující operací, proto nemusí být implementován ve vlastním vlákně. Jakmile dojde ve vlákně k přečtení dat (tahu protihráče), vlákno se uspí. Po dobu uživatelova přemýšlení je uspané. Jakmile uživatel provede tah, jsou data odeslána po síti a bezprostředně potom, dochází k probuzení čtecího vlákna, které čeká na tah protihráče. Celý cyklus se neustále opakuje, dokud jedna strana nezvítězí nebo hru neukončí.
42
Z datových členů jsou v tomto případě nejdůležitější objekt třídy BtConnection, který reprezentuje síťové spojení a objekt třídy Thread, který představuje běhové čtecí vlákno. Nejdůležitější metodou je metoda run(), ve které je implementace čtecího cyklu. Dále se zde používají metody startEnemy() a stopEnemy() pro spuštění a zastavení vlákna a metoda convertToLocalEnemy(Settings settings), která v případě potřeby převede rozehranou síťovou hru na lokální.
Game.java
Poslední třída, která se v tomto balíčku nachází, reprezentuje objekt samotné hry. Základním datovým členem, který obsahuje, je dvouprvkové pole objektů třídy Ocean, které představují jednotlivé mapy – hráčovu a soupeřovu. Kromě toho také nese informace o hře, které byly zadány uživatelem při samotném vytváření hry, jako typ hry, způsob rozmístění lodí, jméno hráče a podobně. Rovněž obsahuje odkaz na objekt třídy Enemy.java, který reprezentuje protihráče (viz výše) a případně na objekt reprezentující BT spojení, pokud se jedná o síťovou hru. V neposlední řadě taky obsahuje referenci na prezentační vrstvu aplikace, konkrétně na okno zobrazující průběh hry. Většina metod, definovaných v této třídě má formu takzvaných delegátů. Po svém zavolání pouze zavolají tutéž metodu definovanou ve třídě Ocean, popřípadě pak na konci vrátí její výsledek. Mimo inicializačních metod, jsou zde také metody pro odstartování hry, pro střelbu hráče i soupeře, pro umístění lodí, pro přístup k informacím o hře a podobně.
6.6. Problémy a zajímavé postřehy při vývoji. Nic v životě nejde úplně hladce a každá práce s sebou přináší určitě těžkosti. Ani zde tomu nebylo jinak, proto zde uvádím problémy, které jsem musel během své práce řešit a také zajímavé postřehy, které jsem učinil. První poznatek, ke kterému dojde začínající programátor dojde velmi brzy, je velmi obtížní způsob debugování mobilní aplikace. Na mobilních zařízeních totiž není nic jako konsole, kam by bylo možné vypisovat ladící výstupu a některá zařízení dokonce ani nezobrazují aspoň názvy výjimek, ke kterým došlo. Při chybě aplikace prostě pouze zamrzne. Tato skutečnost je ještě umocněna druhým zjištěním, které jsem učinil, a sice že testování aplikace v počítačovém emulátoru vypovídá jen velmi málo o chování aplikace ve skutečném mobilním zařízení. Počítačové emulátory mají většinou k dispozici téměř veškeré prostředky počítače, na kterém běží, především větší paměť. Často se tedy stává, že program v emulátoru pracuje bezchybně ale při testech na skutečném zařízení dojde k jeho pádu. Věcí s tímto související, která je podstatně zajímavější a která také nastala, je opačná situace. Úsek kódu, který v emulátoru nepracoval zcela správně ale při testech na skutečných zařízeních se potíže neobjevily. Při emulování konkrétních hardwarových prostředků nemusí být implementace emulátoru přesná. Závěrem, který z těchto skutečností vyplývá je rada testovat vždy přímo na skutečných zařízeních a to velmi často. 43
Dalším nepříjemným faktem, který se v praxi ukázal byl problém s omezenou pamětí pro běžící aplikaci. Toto omezení je sice na první pohled zřejmé a je jasné, že v mobilním prostředí paměť dříve či později dojít musí. Musím se ale přiznat, že mě překvapilo, že k tomu došlo tak brzy. Původní implementace grafického rozhraní totiž počítala s takzvaným cachováním jednotlivých oken. To znamená, že jednou vytvořené okno (objekt třídy) nebylo odstraněno z paměti ani po odstranění okna z obrazovky. Tím by odpadlo vypočítávání layoutu prvků okna při dalším zobrazení okna, což mělo vést k jeho rychlejšímu vykreslení. Na jednom ze zařízení však stačila 3 otevřená okna a aplikace skončila s výjimkou OutOfMemoryError. Předchozí zkušenost významně ovlivnila výběr algoritmu pro generování automatického rozmístění lodí. Tuto skutečnost jsme krátce zmiňovali už v sekci 6.5. při popisu třídy Ocean.java. Správný postup v takovém případě je vytvořit permutace, tedy každou loď postupně prostřídat na všech možných pozicích, a z těchto permutací pak náhodně jednu vybrat. Tím je jistě zaručena determinističnost algoritmu. Je ale jasné, že pro uložení všech permutací bylo potřeba velké množství paměti a téměř jistě by došlo opět k překročení dostupné paměti. Proto musel být nakonec zvolen jiný postup. Pro každou loď je náhodně vygenerována poloha kapitánského můstku a pak následně dopočítaný pozice ostatních částí lodi. Pak algoritmus zkusí loď na tuto pozici umístit. Pokud se mu to podaří, celý postup se opakuje u další lodi v pořadí. Pokud ne, pokud by se lodě překrývaly nebo dotýkaly, je vygenerována nová pozice. V takto zvoleném algoritmu teoreticky existuje možnost, že při určitém počtu lodí a určitém rozmístění už nebude možno další loď nikam. Pravděpodobnost je sice vzhledem k celkovému počtu lodí a velikosti hrací plochy poměrně malá, ale není nulová. K jejímu dalšímu snížení je proto přidáno do algoritmu následující vylepšení. Na umístění jedné lodi je definován maximální počet pokusů. Pokud se nepodaří loď v daném počtu pokusů umístit, dojde k resetování pozic všech předešlých lodí a rozmísťování začne od začátku.
Poslední problém se vyskytl při implementaci bluetooth komunikace na straně klienta, konkrétně ve fázi navazování spojení. Zatímco na straně serveru je navazování spojení jednoduché, server inicializuje BT adaptér a čeká na příchozí připojení, klient musí během navazování spojení provést podstatně více operací. Po inicializaci BT zařízení musí nejprve prohledat okolí a nalézt všechna ostatní aktivní BT zařízení v dosahu. Po skončení vyhledávání zařízení je potřeba každé zařízení otestovat přítomnost hledané službou, ke které se chce připojit. Službou rozumíme příslušný program na druhém zařízení. Po prohledání všech zařízení uživatel zvolí, ke kterému konkrétnímu zařízení (serveru) se má klient připojit. Následně pak naváže s příslušným zařízením spojení. Třída LocalDevice definuje statickou metodu getProperty(string property), pomocí které lze zjišťovat různé vlastnosti zařízení související s rozhraním bluetooth.
44
Vlastnost s názvem bluetooth.sd.trans.max udává, kolik na kolika zařízeních současně může být spuštěno vyhledávání služeb. U většiny zařízení je hodnota tohoto parametru rovna 1, což v praxi znamená, že v jednom okamžiku je možné prohledávat pouze jedno zařízení. Při pokusu o spuštění dalšího prohledávání sice nedojde k chybě, ale volání příslušné funkce je jednoduše ignorováno. Z toho plyne, že před každým dalším prohledáváním je nutné počkat na dokončení téže předcházející operace. Vlákno, ze kterého je prohledávání spouštěno je nutné po každém spuštění pozastavit. Pokračovat v činnosti (tedy spustit prohledávání dalšího zařízení) je možné až po jeho dokončení. Vyhledávání služeb se spouští instanční metodou searchServices(…) třídy DiscoveryAgent definovanou v JSR 82 API. Po jejím zavolání je automaticky vytvořeno další vlákno, které toto prohledávání provádí. Jako parametr je funkci předán odkaz na implementaci rozhraní DiscoveryListener O nalezení služby respektive skončení prohledávání pak vlákno informuje zpětným voláním metod servicesDiscovered(…) a serviceSearchCompleted(…), kterou jsou definovány právě v rozhraní DiscoveryListener. Podle tutoriálů od společnosti Sun, implementuje rozhraní DiscoveryListener objekt, který je vykonáván v hlavním běhovém vlákně aplikace. Situace tedy vypadá následovně:
Obrázek 6.2.: Vzorové řešení implementace na straně klienta.
Při aplikaci tohoto modelu však došlo na zařízeních s operačním systémem Symbian k uváznutí aplikace. Metoda serviceSearchCompleted(…) nebyla nikdy zavolána. Implementace j2ME pod Symbianem zřejmě není schopná volat metody objektů ve vláknu které je zablokované (není tedy ve stavu „run“ nebo „ready to run“). První zmínka o tomto problému byla v kapitole 6, v sekci 6.4. při popisu třídy BtClient.java.
45
Pro vyřešení problému muselo být přidáno další vlákno, ze kterého je vyhledávání zařízení spouštěno. To má za následek, že hlavní běhové vlákno, které implementuje metody z rozhraní DiscoveryListener, už není uspáváno a volání těchto metod proběhne i pod Symbianem. Grafické řešení je znázorněno na následujícím obrázku.
Obrázek 6.3.: Řešení problému implementace klienta.
46
7. Integrační vrstva aplikace
Poslední částí aplikace a zároveň poslední vrstvou MVC, kterou zbývá probrat je vrstva integrační. V této kapitole si popíšeme její účel, podíváme se, jaké možnosti nám v této souvislosti nabízí J2ME a na závěr si ukážeme praktické použití v naší aplikaci.
7.1. Integrační vrstva v MVC (Model) Každá sofistikovanější aplikace potřebuje i po svém ukončení uchovávat větší či menší množství dat. Místa, kam si aplikace data odkládá mohou být různá. Nejpoužívanější v tomto směru je buď prosté uložení na disk ve formě souboru nebo uložení do nějakého databázového systému. Co je ale téměř všem těmto alternativám společné je fakt, že vesměs žádná z nich není schopna uchovat data v objektové podobě, ale většina dnešních aplikací je psaná objektovou formou a s objekty tedy pracuje. Úkolem integrační vrstvy je zajistit konverzi z objektové do neobjektové formy při ukládání dat a obrácenou konverzi při jejich opětovném načítání. Znalý čtenář může namítnout, že přece existují objektové databázové systémy a také možnost takzvané serialiazace dat. Serializace dat respektive objektů znamená převedení vnitřní struktury objektu na lineární sekvenci, označované někdy jako proud, symbolů zpravidla bytů, se kterou je možné v daném prostředí (disk, databáze, přenos po síti apod.) pracovat. Ano, obě tyto možnosti sice opravdu existují, nicméně objektové databáze se používají jen velmi zřídka, většina dnešních databází je relačních a serializace je technika, které není ve všech programovacích jazycích dostupná. Například v J2ME ji nenajdeme. Navíc je třeba si uvědomit, že i při jejich použití dochází ke konverzi objektu na sekvenci bytů, neboť počítačový disk umí pracovat jen s byty a ne s objekty. Rozdíl je ale v tom, že tato konverze je programátorovi dané aplikace skrytá a probíhá implicitně Nemusí se tedy o ni starat. Pokud tedy máme jednu z výše zmíněných technik k dispozic, je náš úkol vytvořit integrační vrstvu aplikace značně zjednodušený. Ta bude obsahovat pouze serializovaný zápis objektu disk respektive zápis do objektové databáze při ukládání dat a zpětné přečtení dat z úložiště, takzvanou deserializaci v případě načítaní dat. Pokud takové štěstí nemáme je třeba v integrační vrstvě postupně zapsat na disk respektive do databáze jednotlivé datové položky objektu a při nahrávání dat je zase přečíst. V tomto případě je životně důležité stanovit a posléze také dodržet pořadí v jakém budou jednotlivé položky zapisovány respektive čteny. Neexistuje totiž žádný způsob, kterým by bylo možné zjistit, jakou položku jsme právě z disku přečetli.
47
7.2. Možnosti v J2ME Co se týče způsobu uchovávání dat, jsou možnosti v J2ME značně omezené. Základním nedostatkem je, že J2ME, hlavně z důvodu bezpečnosti, neposkytuje nativně přístup k systému souborů daného zařízení. Existují, podobně jako pro přístup k bluetooth rozhraní volitelný baliček, konkrétně se jedná o JSR 75, který umožňuje přístup k filesystému zařízení, ovšem ne všichni výrobci ho do svých zařízení implementují. Ale i pokud jeho podporu v konkrétním zařízení najdeme je jeho používání spojeno s nutností povolit uživatelsky každý přístup, tedy čtení i zápis, k položkám na disku. Způsob práce s tímto API může případný zájemce nalézt na [25]. To je hlavní důvod, proč J2ME nenabízí techniku serializace – není v podstatě kam serializovat. A tak jedinou možností pro ukládání dat, která nám v J2ME zůstává je Record Management Systém (RMS), který byl stručně zmíněn v sekci 2.4.2. Nyní se na něj podíváme podrobněji.
7.2.1. Základní myšlenka RMS Systém slouží k ukládání uživatelských dat. Jeho velikost je však poměrně omezená, pohybuje se v řádek desítek nebo stovek kilobytů. Základní myšlenka systému RMS, do češtiny se název překládá jako „Systém správy záznamů“, je zachycena na obrázku 7.1.
Obrázek 7.1.: Architektura RMS systému
Celý systém se skládá z jednotlivých databází.. Databáze, nebo také úložiště záznamů (Rekord Store) je přístupná pouze midletům patřícím do téže sady, do které patří midlet, který danou databázi vytvořil. Pro pořádek dodejme, že sadu midletů může tvořit i jeden jediný midlet. Toto omezení je důsledkem snahy zabránit rozšíření virů na mobilních telefonech a zajistit co nejvyšší úroveň zabezpečení. Každá databáze je tvořena seznamem jednotlivých záznamů a musí mít unikátní jméno. Zajímavostí je, že tyto záznamy jsou indexovány od 1. To může činit z počátku
48
potíže, neboť pole téměř ve všech programovacích jazycích jsou standardně indexovány od 0. Každý záznam je reprezentován polem bytů, které představují vlastní uložená data. Konzistence dat je zajištěna na úrovni implementace RMS. Všechny operace na úložištěm jsou atomické. KVM tedy zodpovídá za to, že záznam bude uložený respektive přečtený úplně nebo vůbec. Žádný stav jako „částečně uložený“ tedy neexistuje. Implementace je rovněž zodpovědná za zachování dat při vypnutí zařízení i při vyjmutí baterie. Pokud dojde k odinstalování sady midletů ze zařízení, jsou automaticky odstraněny také její databáze.
7.2.2. Třídy pro práci s RMS Jak už bylo dříve řečeno, třídy pro práci s RMS se nacházejí v balíčku javax.microedition.rms.
Základní třídou reprezentující databázi systému RMS je třída RecordStore. K otevření databáze slouží statická metoda této třídy openRecordStore(String recordStoreName, boolean createIfNecessary). Druhý parametr napovídá, že pomocí této metody je také možné příslušnou databázi vytvořit, pokud ještě neexistuje. Zavření databáze se provádí pomocí instanční metody closeRecordStore(). Základní zásada, která při otvírání a zavírání databáze platí je, že aby došlo ke skutečnému uzavření, musí být metoda closeRecordStore() zavolána tolikrát, kolikrát byla zavolána metoda openRecordSore(…). Pro čtení a zápis položek do databáze je výhodné použít vstupní a výstupní proudy z balíčku java.io. Konkrétně to jsou ByteArrayOutputStream a DataOutputStream pro zápis a ByteArrayOutputStream a DataOutputStream pro čtení. Pro třídění záznamů slouží rozhraní RecordComparator. To definuje jedinou metodu compare(byte[] b1, byte[] b2), kde b1 a b2 jsou porovnávané záznamy. K filtrování záznamů je určeno rozhraní RecordFilter. Rovněž i toto rozhraní definuje jedinou metodu, a to matches(byte[] candidate). Pokud si budeme přát vybrat z databáze položky, které budou obsahovat pouze ty, jenž vyhoví našemu filtru a navíc budou setříděné, zavoláme statickou metodu enumerateRecords(RecordFilter filter, RecordComparator comparator, boolean keepUpdated) definovanou ve třídě RecordStore a předáme ji naši implementaci filtru a
komparátoru. Ukázkový zdrojový kód práce s RMS se nachází na [26], kompletní dokumentace tříd jednotlivých tříd pak na [10].
49
7.3. Model v naší aplikaci I naše aplikace bude potřeba uchovávat některé informace. Konkrétně se jedná o nastavení aplikace nejlepší výsledky. RMS v našem případě obsahuje jednu databázi pojmenovanou „BattleShips“, která obsahuje dva záznamy. V prvním je uloženo nastavení aplikace a ve druhém seznam nejlepších výsledků. Třídy zodpovědné za implementaci modelu jsou soustředěny v balíčku integrationTier. Jedná se o třídy DbConnection.java, SettingsDAO.java a ToptenDAO.java. Vtahy mezi třídami ilustruje následující obrázek. Základní třídou, která přímo pracuje v RMS je třída DbConnection, která obsahuje metody pro vytvoření databáze, připojení a odpojení od databáze, jejího resetování a odstranění a pro zápis a čtení záznamů. Jednotlivé údaje, se kterými třída pracuje jsou ji předávány v řetězcové podobě. Třídy SettingsDAO a ToptenDAO při samotném přístupu k RMS využívají jejich služeb. SettingsDAO je zodpovědná za načtení respektive uložení nastavení aplikace. Nastavení je v databázi uloženo ve
Obrázek 7.2.: Struktura baličku integrationTier formátu: hodnota1;hodnota2;hodnota3; …
kde jednotlivé hodnoty představují buď konkrétní číslo použité jako hodnotu u dané položky nastavení, tak je tomu například u zvuku, nebo index do pole přípustných hodnot dané položky, tak je tomu ve všech ostatních případech. Třída obsahuje dvě metody loadSettingsFromDB() a saveSettingsToDB(). Při načítání nastavení dochází k přečtení záznamu z databáze a rozparsování načteného řetězce na jednolité položky. Jejich hodnoty jsou pak použity pro vytvoření instance třídy Settings, která reprezentuje nastavení aplikace – viz výše. Při jeho ukládání je naopak objekt typu Settings převeden na řetězec a ten je pak zapsán do databáze. Třída ToptenDAO pracuje na totožném principu jen s tím rozdílem, že manipuluje s objekty třídy Topten, který reprezentuje tabulku s nejlepším skóre. To je v databázi uloženo v tomto formátu: jmeno1,skore1;jmeno2,skore2;jmeno3,skore3; …
50
Při návrhu každé z tříd v této vrstvě je použito návrhového vzoru Singleton (jedináček). Tento vzor umožňuje od dané třídy vytvořit maximálně jednu instanci. Není jistě vhodné vytvářet například více objektů, které reprezentují nastavení. Každá třída obsahuje pouze privátní konstruktor. Tím je zaručeno, že nebude možné vytvářet objekty této třídy zvenku. Každá třída dále obsahuje třídní proměnnou, ve které uchovává odkaz na vytvořený objekt a třídní metodu, pomocí které je možné vytvořit instanci. V těle této metody se nejdříve zkontroluje obsah třídní proměnné. Pokud je rovný hodnotě null, znamená to, že instance dosud neexistuje a v tomto případě dojde k zavolání konstruktoru. Odkaz na vytvořenou instanci je uložen do dané proměnné a zároveň je vrácen volajícímu. Pokud hodnota proměnné není null, instance už byla vytvořena a není nutné volat konstruktor. Dojde pouze k vrácení obsahu proměnné volajícímu.
51
8. Testování aplikace
Důležitou součástí vývojového procesu každé aplikace je testování. Je to komplexní proces během kterého se jednak ověřuje, zda program opravdu dělá, co má, hledají se chyby v implementaci a také jestli je při samotném užívání přehledný a uživatelsky přívětivý. Pokud má být testování opravdovým přínosem musí začínat už téměř na začátku vývoje a končit až před vlastním nasazením softwaru do ostrého provozu. Na straně zákazníka. S postupujícím vývojem pak jeho podíl na celkovém času narůstá. Rozeznáváme dva základní druhy testování, a to funkční testování a testování použitelnosti.
8.1. Funkční testování Funkční testování je část zaměřená na funkcionalitu a implementaci systému. Zde se ověřuje splnění zadaných požadavků a hledají se chyby v chování programu, které jsou po tom následně opravovány a znovu testovány. Základními pojmy v této oblasti jsou verifikace a validace. Verifikace znamená ověření, že produkt implementuje dané funkce správně. Je to tedy v podstatě odpověď na otázku: „Vytvořili jsme produkt správně?“. Oproti tomu validace je výrazem pro ověření, zda aplikace odpovídá požadavkům zákazníka. Je teda odpovědí na otázku: „Vytvořili jsme správný produkt?“. Funkční testování začíná jednotkovými testy, kdy se samostatně otestují jednotlivé moduly. Poté následuje integrační test, který ověřuje návrh základní programové struktury a spolupráci jednotlivých modulů. Předposlední fází je provedení takzvaného validačního testu, ve které právě dojde k ověření program splňuje požadavky zákazníka a to jak na chování, tak na funkcionalitu, tak i na provedení. Proces testování je zakončen provedením systémové testu, kdy je systém testován v kombinaci s ostatními faktory, jako jsou uživatelé hardware, různé další systémy, se kterými ten náš spolupracuje a podobně. Systémový test se zpravidla provádí už přímo v prostředí, kde bude nakonec probíhat ostrý provoz, tedy u zákazníka. Podrobný popis této problematiky však přesahuje rámec této práce. My se v naší práci budeme soustředit hlavně na druhou část, na testování použitelnosti.
8.2. Testování použitelnosti (Usibility testing) obecně Naprogramovat správně správnou aplikaci je sice důležité, nicméně ani to nemusí být zárukou spokojenosti zákazníka. Důležité je, aby se zákazník respektive uživatel uměl v námi vytvořené aplikaci orientovat, rozuměl informacím, které mu aplikaci prezentuje a byl vždy snadno a rychle schopen najít právě ty informace, které potřebuje. 52
Problém přehlednosti a srozumitelnosti je spojen s návrhem uživatelského rozhraní aplikace. Jedním ze způsobů, jak ověřit, zda-li námi navržené GUI je uživatelsky přívětivé spočívá právě v provedení testů použitelnosti. Účelem tedy je ověřit správnost návrhu grafického rozhraní aplikace popřípadě nalezení „slabých“ míst, která by mohla uživatele mást a komplikovat jim ovládání aplikace. Princip provádění testu použitelnosti je následující. Na začátku je dána, většinou vyplyne už z požadavků na aplikaci, cílová skupina uživatelů. Z této skupiny je vybrán reprezentativní vzorek uživatelů, který se testu zúčastní. Každý z testovaných uživatelů nejprve vyplní takzvaný předtestový dotazník, který je zaměřen na zjištění informací, které mohou nějakým způsobem ovlivnit způsob užívání aplikace, jako je například věk, vzdělání, role v rámci užívání systému, prostředí a podobně. Poté mu bude předán seznam úkolů, které má postupně vykonat. U každého úkolu bude zaznamenáno jestli a jak byl úkol splněn případně problémy nebo jiné zajímavé události, které nastaly. Na závěr pak ještě uživatel vyplní potestový dotazník, který je zaměřen na zjištění jeho dojmů a zkušeností z práce s aplikací. Často používanou technikou pro zaznamenávání informací o průběhu testu je vizuální záznam pomocí video techniky, který může sloužit k pozdější analýza a tak k odhalení i těch skutečností, které moderátor v průběhu samotného testu není schopen postřehnout. Aby byl tento záznam skutečným přínosem muselo by se jednat nejen o záznam uživatele samotného jako takového, jeho gest, výrazů ve tváři a podobně, ale také o souběžný záznam dění na obrazovce zařízení, pořízený pomocí softwaru speciálně vyvinutého k tomuto účelu. Vlastní návrh testu, tedy dokument, podle něhož je test prováděn se skládá z následujících části setup testu – obsahuje popis testované aplikace, cílové skupiny uživatelů, zařízení použitých při testu a vlastní průběh testu. předtestový dotazník – obsahuje otázky na zjištění informací o uživateli seznam úkolů – seznam úkolů, které má uživatel provést včetně popisu průběhu a předpokládaných problémů, které by mohly nastat potestový dotazník – obsahuje otázky zaměřené na zkušenosti a dojmy z práce s aplikací
Po provedení testu jsou získané poznatky vyhodnoceny a na jejich základě je sestavena závěrečná zpráva, která jednak popisuje a shrnuje průběh testu a jeho výsledky a také stanoví případná doporučení na úpravu grafického rozhraní.
53
8.3. Testování použitelnosti naší aplikace
Získané poznatky nyní aplikujeme v praxi při testování naší aplikace.
8.3.1. Návrh testu
Cíle testu Cílem testu je ověřit uživatelské rozhraní aplikace BattleShips, které je popsáno v příloze H, a najít v něm slabá místa. Jedná se o ty částí, které nejsou intuitivní a ve kterých se uživatel ztrácí. Pomocí testu bychom je měli odhalit, najít konkrétní příčinu problému a na základě získaných informací se pokusit najít a implementovat řešení.
Testovaná aplikace BattleShips 1.0 je hra pro mobilní telefony, které je elektronickou verzí populární hry Lodě známé například ze školních lavic. Jde o hru pro dva hráče, každý má svou flotilu lodí rozmístěných v obdélníkovém poli. Cílem hry je potopit soupeřovu flotilu dřív než on potopí Vás. BattleShips umožňuje jak hru jednoho hráče proti umělé inteligenci telefon, tak dvou hráčů proti sobě na dvou telefonech. V takovém případě je potřeba pro komunikaci mezi telefony technologie bluetooth.
Cílová skupina uživatelů Cílovou skupinu tvoří především mladší uživatelé, přibližně do 35 let, kteří často a rádi používají mobilní telefon a to ne jen k jeho původnímu účelu, ale především k zábavě. Na uživatele nejsou, kromě základních dovedností práce s mobilním telefonem, popřípadě počítačem, kladeny žádné speciální nároky. Cílem je navrhnout takové uživatelské rozhraní, aby obsluhu aplikace BattleShips zvládl každý uživatel z cílové skupiny bez rozdílu věku, pohlaví, či vzdělání.
Setup testu Hra je implementovaná v J2ME, konkrétně v konfiguraci CLDC 1.1 (JSR 139) a MIDP 2.0 profilu (JSR 118), takže teoreticky může běžet na kterémkoliv telefonu podporující tuto technologii. Současný návrh grafického uživatelského rozhraní však vznáší na zařízení další omezující podmínku – požaduje, aby zařízení mělo displej s rozlišením QVGA (tedy 240 x 320 pixelů) nebo vyšším. Pro hru dvou hráčů je rovněž vyžadována přítomnost technologie Bluetooth (JSR 82).
54
V našem testu budou použita následující zařízení, která splňují všechny výše uvedené podmínky. • •
Nokia 5320 XpressMusic specifikace výrobce na www.nokia.cz Nokia 6300 specifikace výrobce na www.nokia.cz
Předpokládaný průběh testu Předpokládaný průběh testu se v našem případě nijak neliší od obecných principů popsaných v sekci 8.2., jen s tím rozdílem, že k zaznamenávání průběhu testu nebude použito video záznamů a záznamu obrazovky.
Předtestový a potestový dotazník Předtestový dotazník je obsažen v příloze F a potestový se nachází v příloze G.
8.3.2. Skutečný průběh
Testu se zúčastnilo celkem 5 uživatelů obou pohlaví, základního, středoškolského i vysokoškolského vzdělání. V následující tabulce jsou shrnuty odpovědi na nejdůležitější otázky z předtestového dotazníku. věk 16 22 32 21 22
P1 P2 P3 P4 P5
pohlaví vzdělání muž Žena muž žena muž
základní bakalář magistr bakalář bakalář
povolání student student programátor student student
Tabulka 8.1.:Výsledky předtestového dotazníku
Číselné hodnocení odpovídá následující stupnici
0 = vůbec 1 = zřídka 2 = ne moc často 3 = často 4 = velmi často 5 = pořad
55
používá mobil 5 5 4 3 2
úroveň 2 3 2 2 1
hraje hry 4 0 2 2 2
typ hry 1 hráč 1 hráč 1 hráč 1 hráč 2 hráči
Někteří z nich sami sebe označilo s souvislosti s prací s mobilním telefonem za začátečníky, jiní za experta, takže můžeme prohlásit, že se tato skupinu alespoň blíží reprezentativnímu vzorku. V této části se podíváme na to, jak si jednotliví uživatelé vedli při jednotlivých úkolech. • úkol A: Spusťte aplikaci s anglickým rozhraním a zapnutým zvukem Uživatel spustí aplikaci a po zmizení úvodní animace si na v první obrazovce vybere jazyk a na druhé nastavení zvuku. Možné problémy - žádné
Skutečný průběh Skutečný průběh odpovídal předpokládanému, nevyskytly se žádné problémy.
• úkol B: Ukončete aplikaci Po spuštění aplikace uživatel klepne na tlačítko ukončit. Možné problémy - žádné
Skutečný průběh Skutečný průběh odpovídal předpokládanému, nevyskytly se žádné problémy.
• úkol C: Zjistěte jméno a skóre 3.nejlepšího hráče V hlavním menu aplikace uživatel zvolí položku „Síň slávy“. Možné problémy - nespojení si, že „Síň slávy“ a „Nejlepší skóre“ je jedno a to samé - zmatení uživatele, pokud seznam výsledků bude prázdný
56
Skutečný průběh Zde byl předpokládán problém, že by uživatel bude zmaten pokud budou tabulka nejlepšího skóre prázdná. To se však ani v jednom případě nepotvrdilo. Naopak se zde ale objevil problém, který spočívá v nečíslování řádků tabulky, uživatelé museli tedy řádky odpočítávat. Každý z účastníků namítl, že by měli být řádky očíslované.
• úkol D: Nastavte hlasitost na 75 a obtížnost na vysokou úroveň Pomocí hlavního menu se uživatel přepne do okna nastavením a příslušném řádku nastaví požadovanou hodnotu. Možné problémy - žádné
Skutečný průběh Skutečný průběh odpovídal předpokládanému, nevyskytly se žádné problémy.
• úkol E: Zjistěte datum vytvoření aplikace Výběrem položky „O aplikaci“ v hlavním menu se uživatel dostane na požadovanou stránku. Možné problémy - nezkušenost uživatele, kde takové informace hledat (tento druh informací většinou běžného uživatele nezajímá)
Skutečný průběh Úkol proběhl proti původním předpokladům bezproblémově. Předpokládaný problém, že uživatel nebude vědět, kde takové informace hledat nenastal ani v jednom případě. Pouze P4 se nejdříve pokoušel hledat tuto informaci v nápovědě, přičemž ale už na začátku prohlásil, že se informace nachází buď v položce „Nápověda“ nebo v položce „O aplikaci“.
57
• úkol F: Načtěte výchozí nastavení V okně pro nastavení vybere uživatel položku „načíst výchozí“ a pomocí klávesy „načíst“ provede načtení. Po té pomocí klávesy „Ok“ nastavení uloží. Možné problémy - nevědomost popřípadě zmatení uživatele, že musí po načtení nové nastavení ještě potvrdit.
Skutečný průběh Splnění úkolu v tomto případě neproběhlo vůbec bezproblémově. Prvním problémem, který se objevil byl fakt, že P3 vůbec netušil, co se pod označením „výchozí nastavení“ skrývá, kde to hledat a k čemu je to dobré. Také zde u účastníků P2, P3 a P došlo k výskytu očekávaného problému, a sice zmatenosti uživatele, že po načtení výchozího nastavení musí nové nastavení ještě potvrdit. To je poměrně zajímavý fakt, neboť při změně jednotlivých položek nastavení je použito stejného principu – uživatel nejprve změní hodnotu a pak levou funkční klávesou nové nastavení uloží. S tím, ale žádný z uživatelů problém neměl.
• úkol G: Zjistěte jakými klávesami se aplikace ovládá Nápověda je v aplikaci členěna do témat. Mezi jednotlivými tématy se přepíná pomocí levé a pravé šipky na křížovém ovladači. V textboxu pod nadpisem tématu se pak zobrazuje daný text. Uživatel se pomocí hlavního menu přepne do okna „nápověda“, kde vybere příslušné téma a textovém okně se mu zobrazí text nápovědy. Možné problémy - orientace v ovládání okna – výběr tématu šipkami vlevo/vpravo, listování v textu šipkami nahoru/dolu
Skutečný průběh Úkol g ukázal jednu z velkých slabin navrženého GUI. Všichni testovaní uživatelé okamžitě a bez problémů pochopili, že stránkování zobrazeného textu se provádí pomocí šipek nahoru a dolů. Za všem trvalo poměrně velmi dlouho dobu, než vůbec zpozorovali členění do témat a našli způsob přepínání mezi tématy.
58
• úkol H: Zahrajte si hru pro 1 hráče a lodě si rozmístěte sami Pomocí položky „nová hra“ v hlavním menu aplikace uživatel začne vytváření nové hry. Postupně projde 3 obrazovky a zvolí příslušné parametry. Možné problémy - zmatení uživatele kvůli grafickému vzhledu jedné obrazovky a rozmístěním kláves v tomto okně. V jednom místě bylo nutné použít vysokoúrovňové GUI, kde programátor nemá vzhled pod kontrolou.
Skutečný průběh K mému velkému překvapení ani v jednom případě nenastal předpokládaný problém. Všichni uživatelé situaci spojenou s použitím různých GUI API bez problémů zvládli a dokonce se ani nepozastavovali nad rozdílným vzhledem. Drobný problém při tomto úkolu nastal po dokončení rozmísťování lodí. Účastníkovi P2 chviličku trvalo, než zjistil, že pro pokračování musí kliknout ještě na tlačítko „OK“.
• úkol I: Během hry změňte nastavení zvuku Během hry uživatel stiskne klávesu menu a v následném menu vybere položku nastavení. Nakonec v okně s volbou nastavení vybere příslušnou položku. Možné problémy - žádné Skutečný průběh Skutečný průběh odpovídal předpokládanému, nevyskytly se žádné problémy.
• úkol J: Ukončete rozehranou hru Během rozehrané hry stiskne uživatel příslušnou klávesu a potvrdí dialog Možné problémy - žádné Skutečný průběh Skutečný průběh odpovídal předpokládanému, nevyskytly se žádné problémy.
59
• úkol K: Zahrajte si hru pro dva hráče, použijte automatické rozmístění lodí. Pomocí položky „nová hra“ v hlavním menu aplikace uživatel začne vytváření nové hry. Postupně projde 3 obrazovky a zvolí příslušné parametry. Měl by být vznesen dotaz ze strany uživatele, jestli má při vytváření nové hry působit jako server. Pro úplnost postupně budeme zkoušet obě varianty. Možné problémy - zmatení uživatele kvůli grafickému vzhledu jedné obrazovky a rozmístěním kláves v tomto okně. V jednom místě bylo nutné použít vysokoúrovňové GUI, kde programátor nemá vzhled pod kontrolou. - neznalost principu klient – server - možné zmatení uživatele v případě, že se tento vystupuje v navazování spojení v roli klienta a bude se snažit vyhledat hru i když ta ještě nebyla vytvořena.
Skutečný průběh Ani zde se neobjevil předpokládaný problém spojený s odlišným vzhledem jednoho okna. Za to u druhého předpokládaného problému bylo tušení správné. Ukázalo se, že uživatelé, kteří nejsou z oboru IT, neznají princip navazování spojení klient – server. Tato označení jim nic neříkala.
• úkol L: Po výpadku Bluetooth spojení ho navažte znovu a pokračujte ve hře Po výpadku spojení se uživateli na obrazovce objeví hlášení popisující chybový stav. Jeho zobrazení dojde buď okamžitě po výpadku spojení a to v případě, že uživatel čeká na tah protihráče, nebo až v okamžiku, kdy se pokusí vystřelit. Z možných nabídek na obrazovce vybere pak příslušnou možnost a znovu naváže spojení. Možné problémy - možné zmatení uživatele v případě, že se tento vystupuje v navazování spojení v roli klienta a bude se snažit vyhledat hru i když ta ještě nebyla znovu vytvořena.
Skutečný průběh Zde byl předpokládán problém, že uživatel, který vystupuje v roli klienta bude zmaten, pokud bude při znovu připojování rychlejší, než ten, kdo vystupuje jako server. V takovém případě totiž nebude na straně klienta pochopitelně nalezena žádná hra. Obavy se však ukázaly liché. Uživatelé si s touto situací poradili.
60
• úkol M: Po výpadku Bluetooth spojení dohrajte hru lokálně. Po výpadku spojení se uživateli na obrazovce objeví hlášení popisující chybový stav. Jeho zobrazení dojde buď okamžitě po výpadku spojení a to v případě, že uživatel čeká na tah protihráče, nebo až v okamžiku, kdy se pokusí vystřelit. Z možných nabídek na obrazovce vybere pak příslušnou možnost. Možné problémy - žádné
Skutečný průběh Skutečný průběh odpovídal předpokládanému, nevyskytly se žádné problémy.
8.3.3. Vyhodnocení testu Nyní je čas vyhodnotit získané poznatky. V této části bude uveden seznam skutečně nalezených problémů, včetně jejich důležitosti a návrhu řešení a výsledky potestové dotazníku.
Seznam problémů odhalených testováním • problém 1: Nečíslování řádků v seznamu nejlepších výsledků popis: Pokud si uživatel přeje zjistit na jakém místě se umístil, musí řádky v seznamu ručně odpočítávat. To je sice možné, ale rozhodně ne pohodlné. priorita: 2/5 možná řešení: - řešení problému je v tomto případě jednoduché, stačí do výpisu přidat číslování řádků. Tím by měl být problém spolehlivě odstraněn. Z hlediska implementace se jedná poměrně o velmi málo náročnou úpravu. • problém 2: Potvrzení výchozího nastavení popis: Pokud uživatel potřebuje načíst výchozí nastavení, zvolí příslušnou položku v nastavovacím okně. Po načtení výchozích hodnot je však ještě jednou potřeba
61
stisknout levou funkční klávesu aby došlo k uložení nastavení a návratu do hlavního okna. Ukázalo se, že uživatelé na tuto filozofii nejsou zvyklí. priorita: 3/5 možná řešení: - prvním řešením by mohlo být lépe uživatele na tuto skutečnost upozornit. - druhým způsobem, jak se s daným problém vypořádat by byla úprava rozhraní tak, aby po načtení výchozích hodnot automaticky došlo k jejich potvrzení. Tento postup nás ale zbavuje možnosti celou akci stornovat, jako je to možné teď po stisknutí pravé funkční klávesy. • problém 3: Neznalost termínu a smyslu výchozího nastavení popis: u jednoho s uživatelů se objevil problém, že nevěděl, co se za termínem výchozí nastavení skrývá a k čemu je to dobré. priorita: 0/5 možná řešení: - to ale není problém návrhu GUI. Termín výchozí nastavení je běžně používán i u jiných systémů ve světě stolních počítačů. V tomto případě není možné udělat vůbec nic.
• problém 4: Ovládání okna s nápovědou popis: Toto je nejzávažnější problém celého GUI. Jedná se o skutečnost, že nápověda je v aplikaci členěna do témat. Mezi tématy je možné se v okně přepínat pomocí levé a pravé šipky. Uživatelé si však díky velkému textboxu, který je na stránce dominující tohoto členění a nutnosti zvolit příslušné téma nevšimnou. priorita: 5/5 možná řešení: - celá situace je o to horší, že ani ve spolupráci s uživateli nebylo nalezeno žádné přijatelné řešení. Všichni se pouze shodli na tom, že současné řešení není příliš šťastné, ale žádné relevantní návrhy, jak situaci vylepšit nepřinesli. Jediné co se tak dá dělat, je lépe zvýraznit nadpis s tématem.
62
• problém 5: Nezalost principů klinet – server popis: Ukázalo se, že uživatelé, kteří nejsou z oboru IT, neznají princip navazování spojení klient – server. Tato označení jim nic neříkala. priorita: 5/5 možná řešení: - po dohodě, bylo inkriminované okno upraveno tak, jak ukazují následující obrázky.
Obr. 8.1.: Okno před úpravou
Obr. 8.2.: Okno po úpravě
Výsledky potestového dotazníku
P1 P2 P3 P4 P5
otázka otázka otázka otázka otázka otázka otázka a b c d e f h 1 1 2 2 3 1 2 1 1 1 1 2 3 1 1 2 3 2 3 1 1 1 2 2 2 2 3 2 1 2 1 3 1 2 2 1 1,6 1,8 2 2,2 2 1,6
Tabulka 8.2.:Výsledky potestového dotazníku
Pro hodnocení byla použita stupnice jako ve škole (1 = nejlepší, 5 = nejhorší).
63
Závěr Z výsledků podtextového dotazníku vyplývají některé zajímavé věci. Jednoznačně nejlepším místem aplikace respektive jejího grafického rozhraní je hlavní menu. Na druhou stranu to je část, na které není zase tak moc co zkazit. Naopak nejhorším místem je okno s nápovědou. To je poměrně závažný problém, má také v seznamu problémů nejvyšší možnou prioritu a je potřeba před opravdovým nasazením aplikace nalézt nějaké uspokojivé řešení. Z tabulky je také vidět, že všechny hodnocené části mají výslednou známku lepší než 2,5 proto je závěrem tedy možné, i přes některé problémy, označit grafické rozhraní z hlediska jeho návrhu za poměrně vydařené.
64
9. Závěr
Poslední kapitola má úlohu sumarizační. Zhodnotíme zde průběh celé práce, co se povedlo, co naopak méně.a nebude chybět ani část s doporučeními, jak pokračovat a co by se dalo vylepšit jako námět pro další práce.
9.1. Závěrečné zhodnocení. Hlavním cíl práce, tedy implementace hry lodě v mobilním prostředí byl splněn. Aplikace BattleShips je hotová a funční . Co aplikace umožňuje • • • • •
umožňuje lokální hru proti CPU ve dvou úrovních obtížnosti, umožňuje síťovou hru dvou hráčů s využitím komunikačního rozhraní Bluetooth. při síťové hře je aplikace schopna rozponat a reagovat na případné výpadky sítě. podporuje lokalizaci do různých jazyků. pro aplikaci je navrhnuto kromě klasického uživatelského rozhraní také rozhraní pro zrakově postižené a nevidomé osoby.
Co ještě chybí • •
lokalizace do francouzského a německého jazyka. alternativní uživatelské rozhraní je pouze ve stádiu návrhu, implementace z důvodů popsaných v kapitole 5, sekci 5.4.2 chybí
Aplikace také ukazuje konkrétní způsob programování platformě J2ME CLDC a MIDP a může posloužit nejen jako základ pro další rozšiřování, ale především ke svému hlavnímu účelu, tedy k zábavě a zkrácení volného času. Vzhledem k rozsáhlosti aplikace, asi 11 500 řádků kódu, je v měn možné najít dostatečnou inspiraci a příklady způsobu práce s J2ME. Podružným cílem bakalářské práce pak bylo prostudovat a poskytnout čtenáři základní teoretické znalosti i praktické dovednosti programování aplikací v mobilním prostředí na platformě J2ME CLDC a MIDP s využitím komunikační technologie Bluetooth. Kapitoly 2 a 3 poskytují čtenáři poměrně podrobný popis obou technologii. Jde zde možné nalézt vysvětlení základních principů i poměrně pokročilých vlastností. Rovněž jsou pro zájemce uvedeny odkazy, je možné nalézt další informace k jednotlivým tématům. Kapitola 4 a následující kapitoly popisují problémy a nástrahy, které na programátora číhají a na co je třeba si dát pozor.
65
9.2. Možná vylepšení Možná vylepšení aplikace lze pomyslně rozdělit do dvou skupin. První skupinu tvoří ta vylepšení, jež do aplikace nepřinášejí žádnou novou funkcionalitu, pouze odstraňují některá omezení nebo hardwarové požadavky. •
Sem rozhodně patří vylepšení implementace grafického rozhraní. Současná implementace totiž vyžaduje pro chod rozlišení displeje 240 x 320 pixelů nebo vyšší. Řešením by bylo zavést do GUI mechanismus scrollování například pomocí následující techniky.
•
Výstup grafického rozhraní je bufferovaný. To znamená, že obsah je okna je nejdříve vykreslen do obrázku rozměrů obrazovky. Řešením by bylo vytvořit buffer přesně na míru danému obsahu okna, tedy klidně i větší a na obrazovku pak vykreslit pouze jeho příslušnou část. Další možností, je použití některého z frameworků, kde je scrollování už vyřešeno.
Tou druhou skupinou jsou vylepšení, která rozšiřují stávající možnosti aplikace. Zde je pole opravdu široké. •
Hezkou vlastností by bylo rozšíření aplikace o možnost posílání zpráv mezi hráči při síťové hře. Implementace by ani nemusela být nijak zvlášť náročná. Stačilo by pouze přidat další okno, ve pro zobrazení komunikace a čtecí síťové vlákno upravit tak, aby se po přijmutí dat ze sítě neuspalo, ale rovnou přešlo zase do režimu čtení.
•
Další možností, která se nabízí jako rozšíření je třeba přidání další úrovně obtížnosti jako přechod mezi současnou nízkou a vysokou. Tato nová prostřední úroveň by se mohla chovat například stejně jako vysoká, akorát by nebrala v potaz délku největší nepotopené lodi.
•
Jako poslední možnosti zmiňme třeba možnost uložení rozehrané hry. Jasné je, že jako úložiště by musel být použit systém RMS a je tedy otázkou, zda-li bychom při ukládání nenarazili na problém jeho omezené kapacity.
66
A. Seznam použité literatury a zdrojů
[1]
Qusay H. Mahmoud. Naučte se Java 2 Micro Edition. Grada Publishing, a.s., Praha 2002
[2]
Sun Microsystems. Domovská stránka společnosti. http://www.sun.com/, květen 2009
[3]
Sun Microsystems. Domovská stránka J2ME technologie http://java.sun.com/javame/index.jsp, květen 2009
[4]
Petr Dytrych. Bakalářská práce „Programování Java aplikací pro mobilní telefony - hra Piškvorky“. ČVUT FEL, Katedra počítačů. Praha 2008 https://dip.felk.cvut.cz/browse/pdfcache/dytryp1_2008bach.pdf
[5]
Vratislav Fišer. Bakalářská práce „Mobilní průvodce studiem“. ČVUT FEL, Katedra počítačů. Praha 2008 https://dip.felk.cvut.cz/browse/pdfcache/fiserv2_2008bach.pdf
[6]
Tomáš Valenta. Bakalářská práce „Využití Bluetooth přenosu v J2ME aplikacích BT Messenger“. ČVUT FEL, Katedra počítačů. Praha 2006 https://dip.felk.cvut.cz/browse/pdfcache/valent2_2006bach.pdf
[7]
prezentace připravená pro výukové účely na Matematicko-fyzikální fakultě Univerzity Karlovy http://dsrg.mff.cuni.cz/~hnetynka/teaching/vsjava/slides2009/java10.pdf
[8]
Sun Microsystems. Specifikace CLDC konfigurace. http://java.sun.com/products/cldc/, květen 2009
[9]
Sun Microsystems. Specifikace CDC konfigurace. http://java.sun.com/javame/technology/cdc/index.jsp, květen 2009
[10]
Sun Microsystems. JavaDoc dokumentace k MIDP profilu. http://java.sun.com/javame/reference/apis/jsr118/, květen 2009
[11]
Jan Hájek. Článek „Standard Bluetooth: vývoj, princip a možnosti využití“. Časopis Automatizace. http://www.automatizace.cz/article.php?a=639, duben 2005
[12]
Ing. Jiří Svoboda. Článek „Principy a perspektivy technologie Bluetooth“, ČVUT FEL, Katedra telekomunikační techniky. Praha, duben 2004. www.jirkasvoboda.com/publikace/publikace_1.pdf
67
[13]
Michael Novák. Dvoudílný seriál „Znáte modrý zub?“. Serveru notebook.cz http://notebook.cz/aktuality/tech/2003/bluetooth_01.html, http://notebook.cz/aktuality/tech/2003/bluetooth_02.html, leden 2003
[14]
Ondřej Pohl. Článek „Bluetooth tajemství zbavené. Jak fungují profily?“. Server mobil.idnes.cz http://mobil.idnes.cz/bluetooth-tajemstvi-zbavene-jak-funguji-profily-fb0-/svetmobilu.asp?c=A080222_182731_svet-mobilu_onp, únor 2008
[15]
Petr Bartošík. Článek „Standard pro bezdrátovou komunikaci Bluetooth“. Server odbornecasopisy.cz http://www.odbornecasopisy.cz/index.php?id_document=33560, květen 2001
[16]
Článek „Bluetooth“. Serveru pc-it.cz http://www.pc-it.cz/index.php?doc=112
[17]
Oficiální specifikace Bluetooth technologie. Server Bluetooth.org https://www.bluetooth.org/, prosinec 2008.
[18]
Oficiální dokumentace Bluetooth profilů. http://www.kobe.cz/inshop/download/Bluetooth_11_Profiles.pdf, únor 2001
[19]
Sun Microsystem. Dokumentace k JSR 82 API. http://java.sun.com/javame/reference/apis/jsr082/, http://developers.sun.com/mobility/midp/articles/bluetooth1/, prosinec 2008
[20]
Článek „MIDP User Interface APIs“ o tvorbě uživatelského rozhraní v MIDP. Serveru stardeveloper.com. http://www.stardeveloper.com/articles/display.html?article=2002121101&pag e=2, květen 2009
[21]
Domovská stránka frameworku J2ME Polish http://www.j2mepolish.org/cms/, květen 2009
[22]
Tricastmedia. Domovská stránka frameworku TWUIK. http://www.tricastmedia.com/twuik/, květen 2009
[23]
Codefactory. Domovská stránka aplikace Mobile Speak http://www.codefactory.es/en/products.asp?id=24, květen 2009
[24]
Freedom Scientific. Domovská stránka projektu Jaws. http://www.freedomscientific.com/products/fs/jaws-product-page.asp, květen 2009
[25]
Sun Microsystems. Dokumentace k JSR 75 API. http://developers.sun.com/mobility/apis/articles/fileconnection/, květen 2009
[26]
Lucie Rút Bittnerová. Článek „J2ME v kostce - persistence dat“. Serveru interval.cz http://interval.cz/clanky/j2me-v-kostce-persistence-dat/, únor 2003
68
B. Seznam tabulek
tabulka 2.1. Třídy v CLDC konfiguraci tabulka 2.2. Systémové vlastnosti popisující zařízení tabulka 2.3. Vlastnosti virtuálních mašin tabulka 2.4. Přehled základních profilů a jejich stručný popis tabulka 2.5. Přehled minimálních požadavků specifikace MIDP 2.1 tabulka 3.1. Výkonové třídy Bluetooth zařízení a jejich vlastnosti tabulka 8.1. Výsledky předtestového dotazníku tabulka 8.2. Výsledky potestového dotazníku
69
C. Seznam obrázků
obrázek 2.1.
Struktura J2ME
obrázek 2.2.
Životní cyklus midletu
obrázek 3.1.
Miniaturní čip firmy Infineon
obrázek 3.2.
Průmyslové rozhraní firmy Intronico s modulem Bluetooth
obrázek 3.3.
Vrstvy systému Bluetooth
obrázek 3.4.
Metoda přepínání frekvencí se čtyřmi zařízeními
obrázek 3.5.
Topologie bluetooth sítí
obrázek 4.1.
Přípustné umístění
obrázek 4.2.
Princip návrhové vzoru MVC
obrázek 5.1.
Hierarchie tříd pro tvorbu uživatelského rozhraní
obrázek 5.2.
Naznačení hierarchie tříd GUI
obrázek 5.3.
Nastavovací okno 1
obrázek 5.4.
Nastavovací okno 2
obrázek 5.5.
Nastavovací okno 3
obrázek 5.6.
Okno pro rozmístění lodí
obrázek 5.7.
Herní okno
obrázek 6.1.
Závislosti a vztahy mezi třídami v aplikační vrstvě
obrázek 6.2.
Vzorové řešení implementace na straně klienta
obrázek 6.3.
Řešení problému implementace klienta
obrázek 7.1.
Architektura RMS systému
obrázek 7.2.
Struktura baličku integrationTier
obrázek 8.1.
Okno před úpravou
obrázek 8.2.
Okno po úpravě
obrázek H.1.
Úvodní animace
obrázek H.2.
Volba jazyka
obrázek H.3.
Nastavení zvuku
obrázek H.4.
Hlavní menu 70
obrázek H.5.
Okno „O aplikaci
obrázek H.6.
Nejlepší výsledky
obrázek H.7.
Okno nápovědy
obrázek H.8.
Okno „Nastavení“
obrázek H.9.
Tvorba lokální hry 1
obrázek H.10. Tvorba lokální hry 2 obrázek H.11. Tvorba lokální hry 3 obrázek H.12. Útočný pohled obrázek H.13. Obranný pohled obrázek H.14. Pauza obrázek H.15. Statistiky obrázek H.16. Tvorba síťové hry obrázek H.17. Čekání na protihráče obrázek H.18. Připojení ke hře obrázek H.19. Výpadek spojení
71
D. Seznam zkratek
3G – Third generation Označení pro standardů pro nejnovější telekomunikační hardware a mobilní sítě. ACL – Asynchronous Connection-Less link Jeden ze dvou způsobů přenosu dat definovaných ve standardu Bluetooth určený především pro přenos jiných, než hlasových dat. AHF - Adaptive Frequency Hopping Metoda používaná při bezdrátovém přenosu ke zvýšení odolnosti proti rušení. Pracuje na principu změny vysílací frekvence na obou stranách podle předem dohodnutého scénáře. API – Application Programming Interface Rozhraní poskytované systémem nebo jeho částí, které je možno využít při programování aplikace. AU Jednoduchý formát hudebník souborů vyvinutý firmou Sun Microsystems AWT – Abstract Window Toolkit Jedno ze dvou rozhraní ve standardní javě pro tvorbu uživatelského rozhraní, BSIG – Bluetooth Special Interest Group Skupina založená firmou Ericsson, která pracovala na vývoji technologie Bluetooth. BT - Bluetooth Zkratka používaná pro zkrácení názvu této technologie. CDC – Connected Device Configuration Konfigurace v prostředí J2ME určená pro výkonnější mobilní zařízení. CLDC – Connected Limited Device Configuration Konfigurace v prostředí J2ME určená pro méně výkonné mobilní zařízení CVM – Compact Virtual Machine Virtuální stroj javy pro konfiguraci CDC. DECT – Digital Enhanced Cordless Telecommunications Standart pro domácí bezdrátové telefony využívající pro transfer dat širokopásmový bezdrátový přenos. EDR – Enhanced Data Rate Technologie zavedená ve specifikaci Bluetooth 2.0 umožňující rychlejší přenos dat.
72
eSCO – Enhanced Synchronous Connections Rozšířenou verzi synchronních spojově orientovaných kanálů pro přenos hlasu a časově kritických dat ve specifikaci Bluetooth. ETSI - European Telecommunications Standards Institute Nezávislá, nezisková organizace tvořící standardy používané v telekomunikačním průmyslu. ETSI TS – ETSI Technical Specification Dokument vydaný ETSI obsahující závazné požadavky pro rychlé zavedení do praxe, který byl schválen technickým výborem, který ho vydal. GPL – General Public License Software šířený pod licencí GPL je možno volně používat, modifikovat i šířit, ale za předpokladu, že tento software bude šířen bezplatně (případně za distribuční náklady) s možností získat bezplatně zdrojové kódy. Toto opatření se týká nejen samotného softwaru, ale i softwaru, který je od něj odvozen. GSM – Global System for Mobile Communications Dnes nejpoužívanější standart pro mobilní komunikaci a mobilní sítě. GUI – Graphical User Interface Část aplikace která je zodpovědná za interakci s uživatelem a zobrazení informací. http – Hypertext Transfer Protocol Secure Nadstavba nad internetovým protokolem pro přenos internetových stránek, která umožňuje zabezpečit přenos pomocí asymetrického šifrování. IP – Internet Protocol Datový protokol používaný pro přenos dat v paletových sítích a k adresaci zařízení v nich. ISM – Industrial Scientific Medical band Celosvětově bezlicenční frekvenční pásmo o kmitočtu kolem 2,4 GHz. ITU – International Telecommunication Union Jenda z mezinárodních standardizačních organizací. ITU-T Část ITU, která se soustředí na vytváření technických specifikací pro telekomunikační systémy, sítě a služby, včetně jejich provozu, fungování a údržbu. J2ME – Java To Micro Edition Edice jazyka Java pro mobilní zařízení. J2SE – Java To Standart Edition Edice jazyka Java pro stolní počítače.
73
JSR – Java Specification Request Dokument specifikující využití nové technologie přidané do Javy JVM – Java Virtual Machine Virtuální stroj pro standardní edici javy, interpret příkazů javy.
KVM – Kilobite Virtual Machine Virtuální stroj javy pro CLDC konfiguraci. LAN – Local Area Network Označení pro počítačové sítě pokrývající malé geografické území. MIDI – Musical Instrument Digital Interface Musical Instrument Digital Interfaceje mezinárodní standard používaný v hudebním průmyslu jako elektronický komunikační protokol, který dovoluje hudebním nástrojům, počítačům i dalším přístrojům komunikovat v reálném čase prostřednictvím definovaného sériového rozhraní. MIDP – Mobile Information Device Profile Profil rozšiřující konfiguraci CLDC. MP3 Ztrátový kompresní formát sloužící k uložení zvukových dat na počítači. MVC – Model View Controller Návrhový vzor, který se používá pro oddělení vlastní logiky aplikace od způsobu prezentace informací. NMT – Nordic Mobile Telephony Analogový standart pro mobilní sítě první generace. OSI – Open Systems Interconnection Referenční model definující způsob síťového propojování jednotlivých počítačových systémů. Jeho základem je rozčlenění úlohu na jednotlivé vrstvy a každý má za úkol zajistit určitou elementární část. Každá vyšší vrstva při tom využívá služeb vrstvy nižší. PDA – Personal Digital assistant Malý kapesní počítač původně určený k organizaci času a úkolů. Dnešní PDA však zvládají kromě této také řadu dalších činností jako práci s fotografiemi, přístup na internet, práci s dokumenty a podobně. PIN – Personal Identification Number Jedinečný identifikátor, pomocí kterého je možné se autorizovat. PPP – Point-to-Point Protocol Komunikační protokol linkové vrstvy, používaný pro přímé spojení mezi dvěma síťovými uzly. Umožňuje autentizaci, šifrování a kompresi.
74
ROM – Read-Only Memory Zkratka pro typ paměti s neměnným obsahem. Používá se zejména pro uložení BIOSu nebo firmwaru zařízení. SCO – Synchronous Conneciton Oriented link Druhý způsob přenosu dat definovaných ve standardu Bluetooth. Jeho základem je spojově orientovaný přenos. To znamená, že je nutné nejdříve vytvořit komunikační kanál, kterým pak všechna data proudí. Využívá se pro přenos časově kritických dat. TCP – Transmission Control Protocol Základní protokol transportní vrstvy síťového OSI modelu. Protokol umožňuje vytváření spojovacích kanálů a zaručuje doručení paketů. USD – United States dollar Americká měna. UWB – Ultra-wideband Radiová technologie pracující na nízkých napěťových úrovních používající k přenosu velkou část radiového spektra. WAV – Waveform audio format Zvukový formát pro ukládání zvuku na počítači vytvořený firmami IBM a Microsoft.
75
E. Ukázky zdrojového kódu
E.1. Základní kód midletu import javax.microedition.midlet.*; public class Midlet extends MIDlet { public void startApp() { } public void pauseApp() { } public void destroyApp(boolean unconditional) { } }
E.2. Jeden z možných základní kódů midletu pro rozhraní Bluetooth
Soubor MyApplication.java import javax.microedition.midlet.*; public class MyApplication extends MIDlet { public void startApp() { } public void pauseApp() { } public void destroyApp(boolean unconditional) { } }
Soubor BtKomunikace.java import import import import import
javax.bluetooth.*; javax.microedition.io.*; java.io.DataInputStream; java.io.DataOutputStream; java.io.IOException;
public class BtKomunikace implements Runnable, DiscoveryListener
76
{ public BtKomunikace() { } public void start() { vlakno.start(); } public void stop() { try { vlakno.join(); } catch (InterruptedException e) { e.printStackTrace(); } } public void run() { /* Inicializace zařízení */ /* Spuštění prohledávání okolí*/ synchronized (this) { try { wait(); } catch (InterruptedException e) { } } /* Vyhledání služeb na nalezených zařízeních */ synchronized (this) { try { wait(); } catch (InterruptedException e) { } } /* vlastní komunikace pokud se povedlo navázat spojení */ } public void deviceDiscovered(RemoteDevice btDevice, DeviceClass cod) { /* nalezeno zařízení v dosahu */ } public void inquiryCompleted(int vysledek)
77
{ switch (vysledek) { case DiscoveryListener.INQUIRY_COMPLETED: /* pokud prohledávání skončilo normálním způsobem */ break; case DiscoveryListener.INQUIRY_ERROR: /* pokud během porhledávání došlo k nějaké chybě */ break; case DiscoveryListener.INQUIRY_TERMINATED: /* pokud prohledávání bylo přerušeno programem respektive uživatelem */ break; } synchronized (this) { notify(); } } public void servicesDiscovered(int transID, ServiceRecord[] servRecord) { /* Pokud byla na daném zařízení nalezena hledáná služba */ } public void serviceSearchCompleted(int transID, int vysledek) { switch(vysledek) { case DiscoveryListener.SERVICE_SEARCH_COMPLETED: /* Prohledávání služeb na zařízení skončilo */ break; case DiscoveryListener.SERVICE_SEARCH_DEVICE_NOT_REACHABLE: /* zařízení nebylo možné prohledat, protože není v dosahu*/ break; case DiscoveryListener.SERVICE_SEARCH_ERROR: /* Během prohledávání se vyskytla chyba */ break; case DiscoveryListener.SERVICE_SEARCH_NO_RECORDS: /* Na zařízení nejsou žádné služby */
78
break; case DiscoveryListener.SERVICE_SEARCH_TERMINATED: /* Vyhledávání přerušeno programem respektive uživatelem */ break; } if ( ... ) { /* pokud skončilo prohledávání posledního zařízení */ synchronized (this) { notify(); } } } }
E.3. Příklad použití vysokoúrovňového GUI import import import import import import import import
javax.microedition.lcdui.Command; javax.microedition.lcdui.CommandListener; javax.microedition.lcdui.Display; javax.microedition.lcdui.Displayable; javax.microedition.lcdui.Form; javax.microedition.lcdui.StringItem; javax.microedition.lcdui.TextField; javax.microedition.midlet.*;
public class Midlet extends MIDlet implements CommandListener { private Display display = null; private Form form = null; private TextField textField = null; private StringItem label = null; private Command showCommand = null; private Command exitCommand = null; public void startApp() { display = Display.getDisplay(this); form = new Form("My window"); textField = new TextField("Your name", null, 50, TextField.ANY); label = new StringItem("Your name is", null); showCommand = new Command("Show", Command.SCREEN, 0); exitCommand = new Command("Exit", Command.EXIT, 0); form.addCommand(showCommand); form.addCommand(exitCommand); form.setCommandListener(this); form.append(textField); form.append(label); display.setCurrent(form); }
79
public void pauseApp() { } public void destroyApp(boolean unconditional) { notifyDestroyed(); } public void commandAction(Command c, Displayable d) { if (c == exitCommand) { this.destroyApp(true); } else if (c == showCommand) { String text = textField.getString(); label.setText(text); } } }
E.4. Příklad použití nízkoúrovňového GUI Soubor MyWindow.java import javax.microedition.lcdui.Canvas; import javax.microedition.lcdui.Graphics; import javax.microedition.lcdui.Image; public class MyWindow extends Canvas { private Midlet midlet = null; private Image screenBuffer = null; private Graphics bufferGraphics = null; public MyWindow(Midlet midlet) { this.midlet = midlet; setFullScreenMode(true); screenBuffer = Image.createImage(getWidth(), getHeight()); bufferGraphics = screenBuffer.getGraphics(); } protected void paint(Graphics g) { bufferGraphics.setColor(0, 0, 255); bufferGraphics.fillRect(0, 0, screenBuffer.getWidth(), screenBuffer.getHeight()); bufferGraphics.setColor(255, 255, 255); bufferGraphics.drawString("Hello world", 20, 20, Graphics.TOP | Graphics.LEFT); g.drawImage(screenBuffer, 0, 0, Graphics.TOP | Graphics.LEFT); } protected void keyPressed(int key)
80
{ if (key == KEY_NUM5) { midlet.destroyApp(true); } } }
Soubor Midlet.java import javax.microedition.lcdui.Display; import javax.microedition.midlet.*; public class Midlet extends MIDlet { private Display display = null; private MyWindow window = null; public void startApp() { display = Display.getDisplay(this); window = new MyWindow(this); display.setCurrent(window); } public void pauseApp() { } public void destroyApp(boolean unconditional) { notifyDestroyed(); } }
81
F. Předtestový dotazník pro test použitelnosti aplikace
a) Kolik ve Vám let?
b) Jste muž nebo žena?
c) Jaké je vaše vzdělání?
základní vyučen středoškolské (maturita) bakalář magistr a výš
d) Jaké je vaše povolání?
e) Jak často používáte mobilní telefon?
pořád velmi často často ne moc často zřídka vůbec
f) Jak sám(a) sebe hodnotíte z pohledu práce s mobilem? začátečník pokročilý expert g) Jaký mobilní telefon vlastníte
82
h) Očíslujte činnosti podle toho, jak často je na mobilu provádíte. (0 = vůbec, 1 = zřídka, 2 = ne moc často, 3 = často, 4 = velmi často, 5 = stále) ___ ___ ___ ___ ___ ___
telefonování psaní zpráv kalendář, poznámky a úkoly wap, internet a email multimedia hry
i) Jak často hrajete na mobilu hry?
pořád velmi často často ne moc často zřídka vůbec
j) Jaký druh her nejčastěji na mobilu hrajete?
logické sportovní strategie simulátory akční
k) Které z následujících variant dáváte přednost? hra pro 1 hráče hra pro více hráčů
83
G. Potestový dotazník pro test použitelnosti aplikace
a) Jak se vám pracovalo v hlavním menu aplikace?
velmi dobře dobře průměrně špatně katastrofálně
b) Jak se vám pracovalo s aplikací během vytváření nové hry pro 1 hráče?
velmi dobře dobře průměrně špatně katastrofálně
c) Jak se vám pracovalo s aplikací během vytváření nové hry pro 2 hráče?
velmi dobře dobře průměrně špatně katastrofálně
d) Jak se vám pracovalo v okně pro úpravu nastavení?
velmi dobře dobře průměrně špatně katastrofálně
e) Jak se vám pracovalo v nápovědě pro aplikaci?
velmi dobře dobře průměrně špatně katastrofálně
84
f) Jak se vám pracovalo s aplikací během vlastní hry?
velmi dobře dobře průměrně špatně katastrofálně
g) Kterou část aplikace považujete z hlediska přívětivosti uživatelského rozhraní za nejlepší a kterou naopak za nejhorší
h) Jak na vás působí barevné provedení aplikace?
velmi dobře dobře průměrně špatně katastrofálně
i) Zde můžete napsat vaše další dojmy z práce s aplikací
85
H. Uživatelská příručka
Pokud uživatel aplikaci spustí, objeví se nejprve úvodní animace (obrázek H.1.). Po uplynutí 5 vteřin nebo stisknutí libovolné klávesy animace zmizí a následují další obrazovky, kde si uživatel zvolí jazyk a jestli chce zapnout nebo vypnout zvuk (obrázky H.2. a H.3.)
Obr. H.1.: Úvodní animace
Obr. H.2.: Volba jazyka
Obr. H.3.: Nastavení zvuku
Po provedení úvodních voleb se uživatel dostane do hlavního menu aplikace, tak jak je zachyceno na obrázku H.4. Odtud má pak přístup ke všem funkcím aplikace. V položce „O aplikaci“ se skrývají informace jako jméno autora, verze, programu, datum vytvoření a podobně. Vzhled obrazovky je zachycen na obrázku H.5. Položka „Síň slávy“ ukrývá seznam nejlepších výsledků dosažených během námořních bitev. U každého výsledku se eviduje jméno hráče a jeho skóre. Konkrétní vzhled tabulky a okna je na obrázku H.6. Pokud uživatel potřebuje pomoc a zobrazit nápovědu, nechť tak učiní výběrem stejnojmenné položky. Vzhled nápovědního okna ukazuje obrázek H.7. Nápověda je rozdělena do jednotlivých témat. Mezi Obr. H.4.: Hlavní menu tématy lze listovat pomocí kláves 4 a 6 nebo šipkou doleva a doprava. Text nápovědy k příslušnému tématu se pak zobrazuj ve textovém poli, které tvoří většinu obsahu stránky. Stránkování textu je možné pomocí kláves2 a 8 nebo šipkami nahoru a dolů.
86
Obr. H.5.: Okno „O aplikaci“
Obr. H.6.: Nejlepší výsledky
Obr. H.7.: Okno nápovědy
V aplikaci je také možno měnit různá nastavení. Všechno volby, které je možno nastavovat jsou sdruženy v okně, které se skrývá za položko „Nastavení“. Jeho vzhled ukazuje obrázek H.8. Volba položek se provádí klávesami 2 a 5 popřípadě šipkami nahoru a dolů. Volba hodnot položky se pak provádí pomocí kláves 4 a 6 a šipkami vlevo a vpravo. Po úpravě příslušného nastavení je potřeba stisknout klávesu „Ok“. Tím dojde k uložení nové konfigurace. Zvláštní položkou je položka „Výchozí nastavení“. Jejím úkolem je obnovit defaultní nastavení aplikace. Pokud na ni uživatel najede změní se text levé funkční klávesy z „Ok“ na „Načti“. Po potvrzení bude výchozí nastavení načteno. I zde je potřeba na závěr ještě kliknout na „Ok“, aby opět došlo k uložení nového nastavení. Obr. H.8.: Okno „Nastavení“
Nyní ještě zbývá popsat to nejdůležitější, tedy založení nového a následné hraní. Nová hra se vytváří klepnutím na položku „Nová hra“ v hlavním menu. Její popis musíme rozdělit na tři části, podle toho jakou hru vytváříme, jestli lokální, nebo síťovou, kde hru zakládáme a nebo síťovou, kde se připojujeme ke hře, kterou vytvořil druhý hráč. Nejprve si popíšeme tvorbu lokální hry a u ostatních dvou typů uvedeme jen rozdíly. Vytvoření této hry se skládá ze 3 kroků. Postup znázorňují obrázky H.9. až H.11.
87
Obr. H.9.: Tvorba lokální hry 1
Obr. H.10.: Tvorba lokální hry 2
Obr. H.11.: Tvorba lokální hry 3
V prvním okně vybereme jak budou rozmístěny lodě, jestli náhodně nebo uživatelsky a jaký typ hry chceme. Teď vytváříme lokální hru. Poté klepneme na klávesu „Ok“ a přejdeme do dalšího okno. Zde zadáme pouze naše jméno a pokračujeme dál. Třetí okno slouží k rozmístění lodí. V tomto případě jsme zvolili rozmístění automatické, takže klikneme jen na tlačítko „Ok“ pro pokračování. V případě, že bychom v prvním okně zvolili ruční rozmístění, objevovali se teď v okně postupně jednotlivé lodě (od největší po nejmenší) a my bychom je pomocí kláves 2, 4, 6 a 8 respektive šipkami vlevo, vpravo, nahoru a dolů přesunuli na námi zamýšlenou pozice. Pro změnu orientace lodi slouží klávesa 1. Jakmile jsme s pozicí lodi spokojeni, stiskneme klávesu 5, tím bude loď na dané pozici umístěna. Na závěr je opět nutné stisknout klávesu „Ok“, která nás přenese do vlastní hry.
Herní okno má dva pohledy mezi kterými je možné se přepínat pomocí klávesy 1. Pohledy jsou znázorněny na obrázcích H.12. a H.13. V útočném pohledu koukáme na soupeřovy lodě, tedy na ty, které se snažíme potopit. Obranný pohled poskytuje informace o tom, kolik našich lodí už soupeř potopil a kolik jich ještě zbývá.
Obr. H.12.: Útočný pohled
Obr. H.13.: Obranný pohled
88
Pokud jsme v útočném pohledu a jsme na tahu můžeme se pohybovat po mapě střílet. Ovládání je stejné
jako v případě rozmisťování lodí akorát klávesa 5, respektive střed křížového ovladače neslouží k umístění lodě, ale ke střelbě. Pokud během hry stiskneme levou funkční klávesu, dojde k pozastavení hry (pauze). Přepneme se tím do herního menu, které je zobrazeno na obrázku H.14. Po volbě položky pokračovat nebo stisknutí pravé funkční klávesy se opět vrátíme zpět do hry. Kromě toho, jsou z tohoto okna dostupné také některé další funkce jako je nastavení nebo nápověda.
Jakmile jeden z hráčů potopí soupeřovy lodě, hra končí. Na konci hry je zobrazeno okno, kde jsou Obr. H.14.:Pauza Obr. H.15.:Statistiky různé statistiky obou stran jako je počet střel, úspěšnost střelby a podobně. Vhled okna ukazuje obrázek H.15.
Nakonec zbývá ještě popsat jak se vytváří síťová hra. Pokud vytváříme hru pro dva hráče je nutné v prvním okně zvolit jiný typ hry, jak ukazuje obrázek H.16. Následně je potřeba ve spodní části hry vybrat, zda budeme hru vytvářet nebo se k ní připojovat. Pokud vybereme druhou možnost, v dalším okně, kde zadáváme svoje jméno, musíme ještě zadat také jméno hry. Pak rozmístíme lodě a po kliknutí na „Ok“, přejdeme do okna, kde hru vytvoříme a počkáme na Obr. H.16.:Tvorba síťové připojení protihráče. Vzhled Obr. H.17.:Čekání na hry protihráče okna ukazuje obrázek H.17. Jakmile je tento připojen, klepneme na levou funkční klávesu, jejíž popis se změní na „Ok“ a přejdeme do vlastní hry.
Pokud nechceme hru vytvářet, ale naopak se k ní připojovat, vybereme v obrazovce H.16. první volbu. Jako další obrazovka se nám neobjeví okno pro zadání jména hráče, jako je na obrázku H.10., ale okno pro vyhledání a připojení se k vytvoření hře. Jeho vzhled je demonstrován na obrázku H.18.
89
Okno je zpočátku prázdné. Nejprve klepneme na levou funkční klávesu a spustíme vyhledávání her. Jakmile je vyhledávání dokončeno, může okno vypadat například tak, jak ukazuje obrázek H.18. Je na něm vidět jediná nalezená hra s názvem „aaa“ na zařízení „Wireless Toolkit“. Po kliknutí na klávesu „Připojit“ se k dané hře připojíme. Nakonec klepneme ještě jednou na levou funkční klávesu, jejíž popis se mezi tím změní na „Ok“. Tím přejdeme do další fáze přípravy ke hře, kde zadáme jméno a pak rozmístíme lodě stejně jako při lokální hře. Obr. H.18.:Připojení ke hře Během síťové hry může dojít k výpadku Bluetooth spojení. V takovém případě se oběma hráčům objeví na obrazovce okno upozorňující na tuto skutečnost (obrázek H.19.). Ono zároveň nabízí způsoby, jak tuto situaci vyřešit. Výběrem položky „Znovu připojit“ dojde k opětovnému navázání spojení, jak je popsáno výše, v výjimkou toho, že nedochází k zadávání jmen na straně zakladatele hry a k rozmísťování lodí ani na jedné straně. Hra pokračuje tam, kde skončila. Druhou možností je dohrání hry lokálně. V takovém případě převezme mobilní zařízení hru za druhého hráče. Poslední možností je ukončení hry, která uživatele vrací zpět do hlavního menu. Obr. H.19.:Výpadek spojení
90
I. Obsah přiloženého CD
adresář se spustitelnou aplikací
dist/ BattleShips.jar
JAR soubor aplikace
BattleShips.jad
JAD soubor aplikace
projekt/ BattleShips.zip
adresář se zazipovaným projektem kompletní zazipovaný projekt pro Netbeans 6.5 adresář se zdrojovými kódy
src/ bussinessTier/
zdrojové kódy aplikační vrstvy
integrationTier/
zdrojové kódy integrační vrstvy
main/
zdrojový kód spouštěcí třídy main
presentationTier/
zdrojové kódy prezentační vrstvy adresář obsahující text bakalářské práce
text/ podklady/
adresář s podklady pro text práce
eap_projekt/
adresář s projektem pro Enterprise Architekt 7.1
obrazky/
adresář s obrázky použitými v textu
klimaz1_2009bach.doc
text ve formátu DOC
klimaz1_2009bach.pdf
text ve formátu PDF
91
