Programování Java aplikací pro mobilní telefony - hra Piškvorky

České vysoké učení technické v Praze Fakulta elektrotechnická

Bakalářská práce

Programování Java aplikací pro mobilní telefony - hra Piškvorky Petr Dytrych

Vedoucí práce: Doc. RNDr. Josef Kolář, CSc.

Studijní program: Elektrotechnika a informatika strukturovaný bakalářský Obor: Informatika a výpočetní technika červen 2008

iv

Poděkování V první řadě bych velmi rád poděkoval Doc. Josefu Kolářovi z katedry počítačů při fakultě elektrotechnické na ČVUT a Ing. Dušanu Kožušníkovi z firmy COMPELSON Trade, s.r.o. za jejich cenné rady, náměty, a zejména čas, který si na mne a mé dotazy při tvorbě této práce udělali. Dále bych na tomto místě poděkoval své přítelkyni Petře Novotné za pečlivou korekturu, která významně přispěla ke zkvalitnění textu práce a svým rodičům za toleranci a podporu v průběhu vývoje bakalářské práce. v

vi

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 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ů. V Chomutově dne 3.7.2007. vii

viii

Abstrakt Práce si klade za cíl seznámit čtenáře s problematikou tvorby aplikací v programovacím jazyku Java pro mobilní telefony. Bude se zejména soustředit na zpracování odlišností mezi standardní a mobilní edicí Javy, vzájemnou kompatibilitu aplikací mezi různými typy telefonů a na možnosti bezdrátové komunikace – zejména pak na propojení pomocí Bluetooth zařízení. Jako ukázková aplikace byla zpracována stolní hra Piškvorky využívající Bluetooth spojení pro online hru dvou hráčů proti sobě.

Abstract The goal of this work is to inform reader about problems of application creation in programming language Java for mobile phones. It will be concentrated on differences between standard and mobile edition of Java, reciprocal compatibility of applications between various types of phones and at possibilities of wireless communication – especially at connection via Bluetooth device. As an example application was created a desktop game TicTacToe (also known as Noughts & Crosses) using Bluetooth connection for on-line playing of two players against each other. ix

x

Obsah

1. Úvod

1

1.1. Historie Javy ............................................................................................................................. 1 1.2. Zrození J2ME ............................................................................................................................ 2 1.3. Motivace pro vznik této práce ................................................................................................. 3

2. Specifikace cílů

5

2.1. Požadavky na implementaci .................................................................................................... 5 2.2. Struktura bakalářské práce ve vztahu k vytyčeným požadavkům ........................................... 6

3. Představení platformy J2ME

7

3.1. Základní přehled....................................................................................................................... 7 3.2. Virtuální stroje ......................................................................................................................... 8 3.2.1. Kilobyte Virtual Machine ............................................................................................. 8 3.2.2. Compact Virtual Machine ............................................................................................ 8 3.3. Konfigurace .............................................................................................................................. 9 3.3.1. Connected Limited Device Configuration .................................................................... 9 3.3.2. Connected Device Configuration ............................................................................... 11 3.4. Profily ..................................................................................................................................... 11 3.4.1. Mobile Information Device Profile ............................................................................. 11 3.4.2. Zjištěné rozdíly v implementaci profilu MIDP ............................................................ 15 3.4.3. Jiné profily konfigurací CLDC a CDC ........................................................................... 17 3.5. Volitelné balíčky ..................................................................................................................... 17 3.5.1. Java API for Bluetooth Wireless Technology (JABWT) ............................................... 17 3.5.2. Další zajímavé volitelné balíčky pro J2ME ................................................................. 20

4. Analýza a návrh implementace

21

4.1. Specifikační termíny ............................................................................................................... 21 4.2. Funkční požadavky ................................................................................................................. 21 4.3. Návrh implementace.............................................................................................................. 22 4.3.1. Obecné komponenty.................................................................................................. 22 4.3.2. Menu.......................................................................................................................... 23 4.3.3. Navázání spojení........................................................................................................ 23 4.3.4. Hra ............................................................................................................................. 24 4.4. Volba vývojového prostředí ................................................................................................... 24 4.5. Návrh diagramu tříd ............................................................................................................... 25

xi

5. Realizace

27

5.1. Představení aplikace .............................................................................................................. 27 5.2. Popis tříd a nejdůležitějších metod........................................................................................ 28 5.2.1. BluetoothServer.java ................................................................................................. 29 5.2.2. BluetoothClient.java (InquiryListener, ServiceListener) ............................................. 29 5.2.3. BluetoothConnection.java ......................................................................................... 29 5.2.4. AcknowledgeTask.java .............................................................................................. 30 5.2.5. LayerManaging.java .................................................................................................. 30 5.2.6. SpriteAnimationTask.java.......................................................................................... 31 5.2.7. GatoMidlet.java......................................................................................................... 31 5.2.8. GatoMenuCanvas.java .............................................................................................. 31 5.2.9. GatoGameCanvas.java .............................................................................................. 32 5.3. Zajímavé poznatky ................................................................................................................. 33

6. Testování

35

6.1. Funkční testování (Functional Testing) .................................................................................. 36 6.2. Testování použitelnosti (Usability Testing) ............................................................................ 36

7. Závěr

39

7.1. Možná vylepšení .................................................................................................................... 39 7.2. Zhodnocení splnění cílů BP .................................................................................................... 40 7.3. Osobní přínos ......................................................................................................................... 40

A. Seznam použité literatury

43

B. Seznam obrázků

45

C. Seznam tabulek

47

D. Seznam zkratek

49

E. Uživatelská příručka

51

F. Obsah přiloženého CD

55

xii

xiii

xiv

1. Úvod

1.1. Historie Javy Na počátku devadesátých let společnost Sun Microsystems vytvořila nový programovací jazyk Oak, který byl určen pro výrobky spotřební elektroniky, jež hojně využívaly software. Na základě zkušeností s jazykem C++ byl Oak vyvinut tak, aby co nejvíce eliminoval chyby vytvářené samotnými programátory. Tohoto cíle dosahoval zachycením více chyb při kompilaci a odstraněním některých „problematických“ rysů jazyka C – ukazatelé, správa paměti řízená programátorem, apod.

Obr. 1-1 – Star7

Prvním prototypem využívajícím tento jazyk byl přenosný domácí ovladač Star7. Jednalo se o malé ruční zařízení s dotykovou obrazovkou a vestavěnou bezdrátovou sítí, díky níž mohlo být používáno jako dálkové ovládání pro televizi a video. Bohužel se neobjevila očekávaná poptávka po tomto druhu zařízení a ke spotřebitelům se na bázi Oak nedostalo ani jediné. Ve stejné době se však rozšířilo obecné povědomí o Internetu, což mělo za následek zvýšení poptávku po softwaru na prohlížení webové sítě. Společnost Sun na to reagovala přejmenováním jazyka Oak na Java1 a jeho použitím pro vývoj přenositelného prohlížeče HotJava. V roce 1995 pak společnost Sun prodala licenci na Javu firmě Netscape, která ji začlenila do vlastního webového prohlížeče. Ten ve své době představoval nespornou jedničku na trhu a tak se svět seznámil s javovými aplety. Nezávislost na platformě vzbudila během několika let zájem komerčních koncových uživatelů, kteří si stále více uvědomovali potenciál Javy jako vývojové platformy pro samostatné aplikace. Ty mohly být psány pouze jednou a běžely jak na systémech s Windows, tak i na unixových systémech, čímž se snížily náklady na vývoj softwaru. Aby společnost Sun náležitě zareagovala na potřeby vývojářů produkujících aplikace pro koncové uživatele, kteří jsou zvyklí na bohatá uživatelská rozhraní, rozšířila rozsah javové platformy. Tato doplněná verze obsahuje sady knihoven pro mnohem propracovanější grafická rozhraní, než jaké měly knihovny používané k vývoji původních appletů. Než k tomu došlo, bylo nutné Javu rozčlenit do několika větví. Standardní funkcionalita, vyžadovaná jako minimální podpora pro běh libovolného prostředí Javy, je v balíku s názvem Java 2 Standard Edition (J2SE). Společnost Sun taktéž registrovala rostoucí zájem o použití Javy při vývoji na podnikové úrovni a v prostředí aplikačních serverů, a proto vznikla verze Java 2 Enterprise Edition (J2EE), která je dnes konkurencí k velmi známe technologii .NET od společnosti Microsoft.

1

Při hledání patentů zatěžujících jméno Oak bylo zjištěno, že toto slovo obsahuje už jiný programovací jazyk. Vznikl tedy název Java,

který byl údajně odvozen od slangového výrazu pro kávu (Peet's Java), kterou pili tvůrci jazyka v jedné z místních kaváren. 1

1.

Úvod

1.2. Zrození J2ME Požadavky Javy na hostitelské prostředí se zvyšovaly s každou novou verzí (aktuálně verze 1.6). Ačkoli má tedy J2SE původ v softwaru pro výrobky spotřební elektroniky, vyžaduje nyní příliš mnoho paměti a výkonu procesoru, než aby vytvářela schůdné řešení pro tuto oblast. Ironií osudu je, že zatímco společnost Sun vyvíjela Javu pro Internet a komerční programování, rostla opět poptávka po Javě aplikovatelné na menší zařízení (dokonce i na čipové karty), což ji vracelo zpět ke kořenům. Společnost Sun odpověděla vývojem několika platforem Javy s podmnožinou funkcí, které byly vždy šity na míru určitého souvislého segmentu trhu. Všechny verze přistupovaly jiným způsobem k redukování systémových požadavků tak, aby se nevyčerpaly dostupné hardwarové prostředky. V jistém smyslu proto každá z nich reprezentovala účelové řešení daného problému. Proto Sun Microsystems v červnu roku 1999 představila edici Java 2 Micro Edition (J2ME), jejímž záměrem bylo v dohledné době nahradit dřívější produkty a unifikovat jednotlivá řešení. Na rozdíl od oblastí stolních počítačů a serverů, které využívají J2SE a J2EE, zahrnuje svět spotřební elektroniky daleko rozmanitější škálu zařízení se značně diferencovanými schopnostmi, takže pro ně není možné vytvořit jediný softwarový produkt. J2ME proto není jednou entitou, ale souborem specifikací, jež definují určitou část platformy a nějakou oblast spotřebních zařízení. Podmnožina úplného programovacího prostředí Javy pro určité zařízení se definuje jedním nebo více profily, které rozšiřují základní schopnosti konfigurací. Konfigurace a profily, které se hodí pro dané zařízení, závisejí na povaze hardwaru i na cílové oblasti trhu. Jejich rozdělení, základní vlastnosti a rysy budou popsány později. Servery

Servery

TV Set-Top box

Mobilní telefony

Enterprise PC

Desktopové PC

High-End PDA

Low-End PDA

Smart karty

Vestavěná zařízení Volitelné balíčky

Volitelné balíčky

Java 2 Enterprise Edition


Java 2

balíčky

Profily

Standard Edition

Volitelné

Profily Konfigurace CDC

Konfigurace CLDC

JVM

JVM

CVM

KVM

Java 2 Micro Edition Obr. 1-2 – Schéma rozdělení jednotlivých edic Javy 2

Java Card Card VM

1.

Úvod

1.3. Motivace pro vznik této práce Nedlouho po představení J2ME se nejčastěji skloňovanou oblastí staly aplikace vyvíjené v profilu MIDP (Mobile Information Device Profile), který rozšiřuje konfiguraci CLDC (Connected Limited Device Configuration). Tento profil byl navržen pro běh na mobilních zařízeních, jimiž jsou například obousměrné pagery a digitální asistenti PDA. V současnosti je ale nejvíce rozšířen na mobilních telefonech, což je hlavním důvodem zájmu jak mezi tvůrci softwaru, tak i u samotných uživatelů. Aplikace vytvořené tímto programovacím prostředím se nazývají MIDlety a díky dobře propracovanému a neustále doplňovanému API (Application Programming Interface) umožňují v podstatě neomezené rozšíření funkcí samotného telefonu. Nejsilnější doménou se pak stal vývoj her a to nejen ve verzi jednoho hráče proti umělé inteligenci, ale i na poli síťových her, kdy spolu soupeří dva uživatelé on-line přes v dnešní době už velmi rozšířené Bluetooth spojení. Hlavním motivem pro vznik této práce je seznámení se s možnostmi programování mobilních aplikací a vytvoření ukázkového MIDletu, kterým by byla síťová hra využívající právě zmíněné Bluetooth spojení.

Obr. 1-3 – Screenshot z ukázkové hry pro mobilní telefon

3

1.

4

Úvod

2. Specifikace cílů

2.1. Požadavky na implementaci Jako optimální aplikace pro splnění těchto cílů byly vybrány celosvětově známé Piškvorky. V angličtině nese tato hra název TicTacToe, ale můžete se setkat i s pojmenováním Noughts & Crosses. Ani jeden z uvedených názvu není příliš tvárný, a tak byl projekt pro pracovní potřeby přejmenován na Gato. Stále se jedná o stejnou hru, pouze název byl vypůjčen ze španělštiny, kde v překladu označuje hru na kočku a myš. Nyní ale zpět k samotným požadavkům. Nejprve bude důležité seznámit se specifickými vlastnostmi „mobilní“ Javy a odhadnout jaké vlastnosti může mít aplikace vyvíjená pro tento segment trhu. Speciálně pak bude kladen důraz na možnosti bezdrátové komunikace přes Bluetooth zařízení, které v dnešní době obsahuje většina nových mobilních telefonů. Také bude nutné zjistit rozdíly ve způsobu implementace profilu MIDP a určit vzájemnou kompatibilitu aplikací na různých typech konkrétních telefonů. Zkoumáním veřejně dostupných her i jiných užitečných programů byla vytvořena hrubá kostra požadavků, které by výsledná aplikace měla splňovat. Následuje jejich výčet s krátkým popisem dané problematiky: -

Propracované grafické uživatelské rozhraní – grafický vzhled je prvním aspektem, který ovlivní výsledný dojem celé aplikace na koncového uživatele. Mnohdy rozhoduje o úspěchu či neúspěchu celého projektu.

-

Odchycení běžných uživatelských událostí – absolutní samozřejmostí jsou reakce na stisky kláves, běžné prostředky pro ovládání hry (menu, nastavení, help) a poskytnutí intuitivních informací o aktuálním stavu spuštěného programu. Třešničkou na dortu pak může být možnost ovládat aplikaci pomocí pera u přístrojů s dotykovou obrazovkou.

-

Odchycení neobvyklých uživatelských událostí – jelikož se bude jednat o síťovou hru, je potřeba řešit možný výskyt následujících událostí: nahodilé či násilné zrušení navázaného bezdrátového spojení, pozastavení hry v době, kdy jeden z hráčů právě přijímá hovor, apod.

-

Vytvoření univerzálního programu pro všechny typy telefonů – velmi netriviálním cílem pak bude snaha o vytvoření takové aplikace, která poběží beze změny na jakémkoliv typu telefonu podporující práci s Bluetooth. Současný trend při vývoji her a nejen jich je následující: vytvoří se téměř kompletní produkt, který se upravuje podle specifických vlastností jednotlivých telefonů – velikosti displeje, způsobu ovládání, hardwarových prostředků, dostupné paměti, atd.

-

Použití angličtiny – ačkoliv trh v oblasti mobilních her zaznamenává dramatický růst, je důležité, aby aplikace oslovila co nejvíce uživatelů, a proto jako hlavní jazyk byla zvolena angličtina.

5

2.

Specifikace cílů

Při hledání hotových implementací byly navíc rámcově specifikovány požadavky, bez nichž vytvořená hra nebude na cílovém hostitelském prostředí fungovat. Bližší popis těchto atributů bude následovat později, ale nyní je zde vyjmenujme pro úplnost: -

Konfigurace CLDC ve verzi 1.1

-

Profil MIDP ve verzi 2.0

-

Java APIs for Bluetooth 1.0

Nebude-li uvedeno jinak, míníme při dalším použití těchto zkratek verzi, jež je uvedena v tomto výčtu.

2.2. Struktura bakalářské práce ve vztahu k vytyčeným požadavkům Úvodem je nutno uvést, že se od čtenáře očekává alespoň základní znalost J2SE a tudíž je obeznámen s takovými výrazy a zkratkami, jako jsou metody, třídy, balíčky, JVM, JSR, apod. Práce bude rozdělena do několika částí, které nás provedou jednotlivými kroky vývoje jednoduché aplikace. Nejprve představíme důležité vlastnosti J2ME z hlediska potřebných znalostí pro psaní programů na mobilní telefony. Podíváme se blíže na jednotlivé konfigurace a profily zahrnuté v této edici Javy. Speciálně rozebereme profil MIDP a uvedeme výčet zjištěných rozdílů v jeho implementaci mezi nejznámějšími výrobci telefonů – Nokia, Sony-Ericsson, Siemens, Motorola. Do tohoto teoretického úvodu bude nutno přidat i základní přehled možností dalšího funkčního rozšíření programového vybavení pro konkrétní potřeby vývojářů, speciálně pak pro práci s Bluetooth zařízením. Později ve čtvrté kapitole představíme hrubou analýzu zadání a návrh způsobu implementace. Zvážíme, co konkrétně by výsledný produkt měl splňovat a jakým způsobem těchto cílů dosáhnout. Čtenář bude navíc krátce seznámen i se zvolenými nástroji, které byly při práci na programu použity. V pořadí pátá kapitola již přinese samotný popis vyvinuté hry a shrne hlavní problémy a události, které se během práce na programu vyskytly. Představeny budou jednotlivé třídy a jejich nejdůležitější metody, které budou mít velký význam pro chod samotného MIDletu. Následně bude aplikace testována, ale vzhledem k rozsahu hry se budeme z pohledů vývojářů soustředit pouze na obyčejné testování funkčnosti. U výsledného programu také provedeme test použitelnosti na vybraném vzorku uživatelů. Dále by v úvahu připadal jednotkový test a zajímavé by byly i výsledky získané zátěžovým testováním v porovnání s podobnými typy her. Tyto testy však do práce nebudou zahrnuty. V závěrečné kapitole shrneme možná vylepšení, na něž se během vývoje přišlo, ale jejichž implementace by byla nad rámec výše uvedených požadavků. Celkovým zhodnocením výsledků bude pak tato práce ukončena.

6

3. Představení platformy J2ME

3.1. Základní přehled Jak již bylo řečeno, vznikla potřeba sjednotit různé odnože Javy pro malá zařízení, která nezvládají systémové nároky standardní edice. Jedná se o přístroje s rozmanitými, ale zároveň i velmi omezenými vlastnostmi, a proto nebylo možné vytvořit jedinou specifikaci pokrývající celý segment trhu. Největším problémem pak byly například špatné zobrazovací schopnosti, komplikovaný způsob ovládání, malá operační paměť a nízký výpočetní výkon. Aby se těmto vlastnostem mohla J2ME přizpůsobit, bylo nutné omezit balíčky výchozí specifikace Javy jen na ty nejdůležitější. Navíc zde vznikla potřeba přidání takových balíčků, které by podporovaly práci se specifickými vlastnostmi těchto zařízení, a tak se mobilní Java rozčlenila na různé konfigurace a profily. Pro lepší přehled vztahů v tomto pracovním prostředí je přiložen obrázek 4. Personal


Profily

Konfigurace

MIDP

PDAP

Mobile Information Device Profile

Personal Digital Assistant Profile

Profile Personal

RMI

Game

Basic Profile

Profile

Profile

Foundation Profile

CLDC

CDC

Connected Limited Device Configuration

Connected Device Configuration

KVM

CVM

Kilobyte Virtual Machine

Compact Virtual Machine

Virtuální stroje

Obr. 3-1 – Základní přehled architektury J2ME

Centrum tvoří javový virtuální stroj, který pracuje na hostitelském operačním systému zařízení. Tvoří ho runtime, což je část realizující vazbu na hardware, a interpret, který vykonává bytový kód. Nad ním je postavena specifická konfigurace skládající se z programových knihoven, které zajišťují nejjednodušší operace, jež jsou na daném zařízení prováděny. Pomyslný vrchol konfigurace tvoří jeden či více profilů, které obsahují doplňkové knihovny pro práci s podobnými funkcemi příbuzných zařízení. Aby bylo možné přidávat podporu nových technologií, vznikají tzv. volitelné balíčky, které je dále rozšiřují. Ty jsou tvořeny aplikačním rozhraním, které může ovládat specifické funkce daného přístroje, jako například Bluetooth nebo zvukové a grafické rozhraní. 7

3.

Představení platformy J2ME

Ale pozor, sám výrobce při implementaci virtuálního stroje rozhodne, jaké volitelné balíčky budou podporovány a se kterými vlastnostmi telefonu budeme moci pracovat. Může se tedy stát, že ačkoliv hostitelská platforma disponuje Bluetooth zařízením, není práce s ním podporována z důvodu chybějící knihovny, která nebyla do zařízení implementována.

3.2. Virtuální stroje Jak bude později uvedeno, obě konfigurace na obrázku 4 mají své charakteristické rysy, díky kterým se odlišují od standardní edice. Kvůli těmto odlišnostem je u každé z nich zapotřebí jiná JVM než ta, na kterou jsme zvyklí u J2SE.

3.2.1. Kilobyte Virtual Machine Po hardwarové stránce definuje CLDC minimální výkonnostní požadavky tak, aby cílové zařízení umožňovalo implementaci VM s redukovanými funkcemi v rámci jeho omezených prostředků. Vlastnosti samotného virtuálního stroje jsou pak popsány částmi úplné JVM, které tato konfigurace podporovat nemusí a zároveň částmi, na něž se vztahují různá omezení. Společnost Sun poskytuje jako referenční implementaci k této konfiguraci stroj známý jako KVM (Kilobyte Virtual Machine), avšak výrobci zařízení nejsou nuceni k tomu, aby na něm své produkty zakládali. Mohou použít jakýkoliv jiný virtuální stroj, který splňuje požadované funkce dle CLDC. Takovým je například J9 vyvinutý společností IBM2. Aby se maximalizoval počet hostitelských platforem, na které lze tuto konfiguraci implementovat, nejsou kromě požadavků na dostupnou pevnou paměť (ROM) kladeny téměř žádné nároky. Například vůbec není předpokládána přítomnost displeje, mechanizmu pro uživatelský vstup nebo paměti pro data samotné aplikace.

3.2.2. Compact Virtual Machine Už jen okrajově představíme i druhý virtuální stroj vyvinutý dle konfigurace CDC. Ten je velmi podobný tomu, který známe ze standardní edice Javy verze 1.3. Ve skutečnosti musí jakákoliv VM pro CDC podporovat veškeré funkce popsané ve druhém vydání specifikace JVM od společnosti Sun. Má však menší nároky na paměť a obsahuje správce paměti navrženého pro práci v prostředí s omezenou pamětí. Kromě údaje o požadované paměti mají ostatní požadavky na hardware uvedené v tabulce 1 pouze formu doporučení. Jejich splnění však není očekáváno.

2

Bude-li v další části této práce použita zkratka KVM, platí vše i pro kterýkoliv jiný virtuální stroj vyhovující specifikaci CLDC.

8

3.

Aktuální verze konfigurace Číslo požadavku v rámci JCP ROM – Paměť pro VM a její knihovny RAM – Paměť pro běh samotné VM Typ procesoru Rychlost procesoru Způsob napájení Konektivita


KVM CLDC 1.1 JSR 139 160 kB 32 kB 16 bitový 8-32 MHz Bateriový Omezená, většinou HTTP

CVM CDC 1.1 JSR 218 2,5 MB 2 MB 32 bitový > 32 MHz Síťový Stálá, většinou TCP/IP

Tab. 3-1 – Vlastnosti virtuálních strojů v J2ME

3.3. Konfigurace Hlavním cílem konfigurací však není samotné vymezení hardwarových požadavků, ale definice obecného programového vybavení pro určité skupiny zařízení. Konfigurace taktéž nepopisuje způsob instalace aplikací, jejich životní cyklus, funkcionalitu uživatelského rozhraní, odchyt událostí ani způsob interakce uživatele s programem, respektive se zařízením samotným. Tyto oblasti bývají specifikovány v profilech, k nimž se dostaneme později. Jak už bylo řečeno, v J2ME rozlišujeme dvě konfigurace.

3.3.1. Connected Limited Device Configuration Ačkoliv CLDC ve verzi 1.1 povoluje mnohé, co jeho předchůdce zakazoval, jsou z důvodu snížení nároků na hardware a úspory paměťového prostoru uplatňována oproti verzi J2SE tato hlavní omezení: -

Finalizace – KVM neumožňuje provést úklidové práce s objekty (např. uzavření zdrojů) před vlastním zrušením objektu pomocí GC (Garbage Collector).

-

Neobsahuje většinu chyb a výjimek – jelikož se od aplikací v Javě neočekává, že se zotaví z vyvolaných výjimek odvozených ze třídy java.lang.Error, neobsahuje CLCD a tudíž i virtuální stroj většinu tříd, které „chyby“ reprezentovaly. Nastane-li takto odstraněná výjimka, KVM se pokusí vyhledat a vyhodit takovou chybu, jež je nejbližší té, která nastala. Dále jsou pak odstraněny tyto funkce:

-

Skupiny vláken a démoni – samotná vlákna poskytována jsou, ale nelze vytvořit skupiny vláken. Tento nedostatek lze odstranit vytvořením kolekce objektů vláken. Navíc není poskytováno ani démonové vlákno – tj. takové, které automaticky skončí po doběhu všech nedémonových vláken ve VM.

-

Reflexe – odstranění funkcí souvisejících s reflexí vede k úspoře paměti, protože se tak ruší povinnosti určovat, zda k nim samotný aplikační kód vlastní přístupová práva.

-

Uživatelem definované zavaděče tříd – z důvodu bezpečnosti lze použít pouze originální „bootstrap“ zavaděč, který nesmí být nahrazen, rekonfigurován nebo programově přetížen na úrovni metod. 9

3.


Knihovny tříd Aby bylo možné provozovat tuto konfiguraci na maximálním množství zařízení, jsou do specifikace zahrnuty pouze následující balíčky – javax.microedition.io, java.lang, java.util, java.io.

První uvedený obsahuje rozhraní, které pracuje nezávisle na specifických rysech zařízení

jako obecný připojovací systém a v J2SE se s ním nesetkáte. Ze zbylých, dobře známých balíčků, využívá CLCD pouze třicet devět tříd – viz tabulka 2. Ostatní byly zejména kvůli omezení paměti a bezpečnosti odstraněny. Následující oddíl krátce popíše hlavní aspekty vyjmenovaných balíčků a případně uvede jejich změny oproti svému originálu ve standardní Javě. java.lang java.util java.io

Třídy 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 Tab. 3-2 – Třídy zděděné konfigurací CLDC z J2SE

javax.microedition.io

– tento balíček je natolik obecný, že nezavádí žádné nové třídy pro I/O

a připojení k síti. Cílem je, aby ho profily na bázi CLDC využívaly jako společný mechanizmus pro přístup do sítě, nehledě na protokol, kterým se chceme připojit. Je-li spojení úspěšné, vrátí níže uvedená metoda objekt, který hostitelské prostředí zavede do jednoho z obecných rozhraní pro připojení. Zde jsou příklady obecného a konkrétního požadavku na spojení: -

Connector.open("<protocol>:
;<parameters>");

-

Connector.open("http://www.fel.cvut.cz:port");

-

Connector.open("datagram://129.144.111.222:2800");

-

Connector.open("comm:0;baudrate=9600"); java.lang

– obsahuje pouze necelou polovinu tříd ze svého protějšku v J2SE. Nejdůležitější

výčet pozměněných vlastností tohoto balíčku je v podstatě shodný s body uvedenými na předchozí stránce. Avšak jedna zajímavost tu je. Numerické třídy jsou přímo odvozeny od třídy Object a nikoli od Number. Detailnější rozbor změn tohoto balíčku naleznete ve zdroji [4]. java.util –

z oblasti kolekcí obsahuje tento balíček pouze následující třídy – Hashtable,

Stack, Vector, Enumeration.

Jedná se o podmnožinu tříd reprezentující kolekce dostupné v JDK

ve verzi 1.1. Systém kolekcí známý z Javy 2 nebylo kvůli omezeným hardwarovým prostředkům možno implementovat. Součástí je také podmnožina funkcí z tříd Date, TimeZone a Calendar, které pracují s datem a časem. Pro zachování minimálních nároků na hostující platformu je však vyžadována podpora pouze jednoho časového pásma, kterým je standardně GMT (Greenwich Mean Time). Třída Date je pak obalem dlouhé hodnoty, která reprezentuje datum a čas jako odchylku od 00:00 dne 1. ledna 1970 GMT. java.io

– jediné vstupní a výstupní proudy, jež lze připojit na zdroj nebo cíl dat, jsou ByteAr-

rayInputStream, ByteArrayOutputStream. 10

Pokud tyto „streamy“ obalíme pomocí DataInput-

3.

Sream


respektive DataOutputStream, mohou poskytovat způsob, jak přenášet a ukládat primitivní

datové typy Javy. Přístup ke všem ostatním zdrojům dat je poskytován privátními implementacemi tříd InputStream a OutputStream. Virtuální stroje z důvodu absence souborového systému nezavádí třídu java.lang.Properties, avšak každé zařízení zpřístupňuje metodou System.getPorperty(String key) tyto vlastnosti: microedition.platform microedition.encoding microedition.configuration microedition.profiles

Popis Název hostitelské platformy nebo zařízení Standardní kódování znaků Název a verze podporující konfigurace Názvy podporovaných profilů

Standardní hodnota null "ISO-8859-1" "CLDC-1.1" null

Tab. 3-3 – Systémové vlastnosti

3.3.2. Connected Device Configuration Jak už bylo řečeno v kapitole 3.2.2., je tato konfigurace postavena na J2SE ve verzi 1.3. Protože při vzniku CDC neexistovaly žádné staré kódy aplikací na této bázi, nemusel se brát ohled na požadavek zpětné slučitelnosti programů. Využila se tedy příležitost a odstranila se ta rozhraní Javy, jež byla zavržena (deprecated). Do CDC byly zahrnuty tyto balíčky: 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.

Více informací o CDC naleznete na [5].

3.4. Profily Není příliš pravděpodobné, že by vývojář aplikací psal software pracující jen s konfiguracemi CLDC a CDC, protože například neobsahují nic, co by umožňovalo interakci s uživatelem nebo práci se sítí a úložnými zařízeními. Záměrem bylo pouze poskytnutí základní vrstvy, na níž lze aplikovat řadu profilů poskytujících další programové prostředky. V dnešní době je nejznámějším zástupcem profil MIDP ve verzi 2.0 určený především pro svět mobilních telefonů.

3.4.1. Mobile Information Device Profile Na konci roku 2002 byla vydána nová specifikace profilu MIDP, jenž byl vyvinut v rámci procesu JCP (Java Comunity Proces) jako požadavek s označením JSR 118. Oproti první verzi došlo k rozšíření oblastí týkajících se bezpečnosti, uživatelských rozhraní a sítí. Přibyla také API určená pro tvůrce her a pro práci s multimédii. Nová verze obsahuje téměř dvakrát více tříd než její předchůdkyně, a tudíž zvýšila své nároky na paměť zařízení – viz tabulka 4, kde jsou tučně zvýrazněny změny hardwarových požadavků oproti MIDP 1.0. Kromě novinek existují také vlastnosti, které zde bohužel nenajdeme. Mezi ně patří přístup k telefonnímu seznamu, posílaní SMS zpráv, zahájení telefonního hovoru nebo přístup k datům v telefonu jako k souborovému systému. 11

3.

Paměť

Displej

Vstupní zařízení Síť Zvuk


Minimální požadavky 256 kB (původně 128) trvalé paměti pro MIDP implementaci 128 kB (původně 32) dočasné paměti pro běh aplikace 8 kB trvalé paměti pro data aplikací rozlišení alespoň 96x54 pixelů hloubka barev: 1 bit přibližně čtvercový poměr stran pixelů telefonní klávesy 0-9 nebo plná klávesnice nebo dotykový displej obousměrný (přerušovaný) síťový provoz, s omezenou šířkou pásma schopnost přehrávat tóny, ať už hardwarově či softwarově Tab. 3-4 – Hardwarové požadavky profilu MIDP 2.0

Všímavý čtenář v tomto výčtu jistě zaznamenal vznik požadavků na displej a vstupní zařízení, které konfigurace nedefinovaly. Tato novinka zavedla možnost interakce s uživatelem, což se projevilo i v rozšířeném programovém vybavení. Knihovny tříd Specifikace MIDP 2.0 nevyžaduje žádnou konkrétní verzi CLDC, je ovšem předpokládáno, že většina zařízení bude obsahovat verzi 1.1. Proto například balíček java.lang neobsahuje třídy reprezentující proměnné double a float. Jejich podporu buď zajistí přímo konfigurace, která je na zařízení implementována, nebo je nebude možné využít. Většina balíčků však zůstala oproti svým předchůdcům nezměněna. Některé byly upraveny, jiné zcela nově přidány. Podívejme se tedy na nejdůležitější aspekty tohoto profilu oproti konfiguracím CLDC: java.lang

– na rozdíl od CLDC 1.1 neimplementuje třídy Double a Float

java.util

– nově je tento balíček rozšířen o třídy Timer a TimerTask. Ty slouží jako nástroj pro

spouštění cyklicky se opakujících událostí. Kód, který má být spuštěn při vypršení časovače, musí být implementován jako potomek TimerTasku a volán pomocí instance třídy Timer. To nám umožní běh jednoho či více úkolů ve vyhrazeném vláknu na pozadí aplikace. javax.microedition.io

– přibyla rozhraní pro práci s dalšími protokoly. Nyní jsou podporo-

vány komunikace přes protokoly http, https, datagram, datagram server, soket, server soket, ssl, comm. Od zařízení samotného jsou však specifikací vyžadovány pouze http a https. Další novinkou je třída PushRegistry, která umožňuje spuštění aplikace buď v konkrétním časovém okamžiku, nebo jako reakci na speciální příchozí spojení ze sítě. javax.microedition.lcdui

– z důvodu zahrnutí displeje mezi hardwarové požadavky vznikl

balíček pro uživatelské rozhraní, který byl následně ve verzi 2.0 rozšířen. Grafické objekty vytvořené tímto balíčkem dělíme na tzv. vysokoúrovňové a nízkoúrovňové. První uvedené poskytují dostatečný počet funkcí pro relativně nenáročnou tvorbu MIDletů, jež fungují v nezměněné podobě na mnoha zařízeních. Bohužel jsme omezeni použitím objektů od těchto tříd: Alert, ChoiseGroup, DataField, Form, Guage, Item, List, Spacer, TextBox, TextField

a Ticker, a zároveň máme jen

velmi malou kontrolu nad jejich vlastním vzhledem. Opakem jsou nízkoúrovňové komponenty, díky nimž máme zajištěn přístup k obrazovce na úrovni pixelů, což ale od programátora vyžaduje 12

3.


mnohem větší úsilí při jejich tvorbě. Tyto komponenty se sestavují pomocí metod tříd Canvas a Graphics.

Za nejpodstatnější novinku lze však považovat možnost vytvářet si vlastní formulářové položky jako potomky třídy CustomItem. Tyto položky jsou stejně nízkoúrovňové jako třída Canvas, ale přístup k událostem klávesnice mají zcela ve své moci stejně jako svůj vzhled. Nově také není potřeba využívat balíčky knihoven implementované přímo od výrobců jen proto, aby třída Canvas měla k dispozici celý displej a ne jen jeho část, tak jak tomu bylo například u telefonů Nokia. To je zajištěno díky metodě Canvas.setFullScreenMode(boolean mode). javax.microedition.lcdui.game

– hlavní myšlenkou tohoto nového balíčku určeného zejmé-

na pro vývoj her, je skládání grafiky aplikace z několika vrstev. Ta reprezentuje viditelný objekt, který je potomkem rozhraní Layer. Jeho konkrétní implementace má v profilu MIDP dvě podoby – třída TiledLayer a třída Sprite. Například u scény znázorňující svět pod vodou by jednu vrstvu tvořilo pozadí, druhou ryba plující sem a tam a třetí například potápěč. Pro reprezentaci pozadí je vhodná třída TiledLayer, která ho poskládá jako mozaiku z dlaždic. Ty se vytvoří pomocí konstruktoru vrstvy, jenž je vyřeže z grafických souborů png nebo gif. Některé dlaždice mohou být i animované pomocí sekvence snímků, které se na dané pozici budou „přehrávat“. Aby plující ryba a potápěč nepůsobili ve svém pohybu staticky, použijeme pro jejich tvorbu třídu Sprite, která nám podobně jako u animovaných dlaždic umožňuje nastavit sekvenci obrázků, které budou v tomto případě využity pro imitaci jejich pohybu (např. pohyb ploutví). Tato třída navíc poskytuje několik podpůrných metod, jako jsou rotace, překlápění, a kontroly kolizí s jinými objekty typu Sprite, TiledLayer nebo i s obyčejnými obrázky, a proto je vhodná pro tvorbu takovýchto grafických elementů. Pro tyto novinky již není vhodné používat obyčejné plátno Canvas, ale nové herní GameCanvas. To obsahuje speciální bafr (off-screen buffer), v němž se grafika hry nejdříve vykreslí mimo obrazovku a teprve po zavolání metody flushGraphics() se jeho obsah naráz zobrazí na displeji. Zjednodušení práce se skupinami vrstev přináší třída LayerManager. Přidáním vrstvy do tohoto správce pomocí metod append(Layer vrstva), insert(Layer vsrtva, int index) nám umožní po zavolání paint(Graphics g, int x, int y) vykreslit všechny vrstvy najednou. javax.microedition.media

– toto API je malou podmnožinou známého Mobile Media API, ale

obsahuje funkce určené pouze pro audio. Po telefonech samotných je pak vyžadována podpora hudebních formátů WAV a MIDI, ale knihovna umí zpracovat i formáty AU a MP3. Základní třída Manager

slouží pro vytváření jednotlivých přehrávačů a jednoduchou reprodukci tónů se zadanou

výškou a délkou trvání pomocí metody playTone(int ton, int delka, int hlasitost). Rozhraní Player pak umožňuje přehrání audio souborů, k nimž se přistupuje pomocí Media Locatoru nebo vytvořením InputStreamu.

13

3.


javax.microedition.media.control VolumeControl

– ovládá funkce pro práci médií poskytnutím rozhraní

pro ovládání hlasitosti přehrávačů, a také rozhraním ToneControl, které umožňuje

přehrávání sekvence monotónních tónů. javax.microedition.midlet

– abstraktní třída MIDlet

z tohoto balíčku je rodičem pro všechny aplikace, které chtějí v profilu MIDP běžet. Taková aplikace pak musí obsahovat alespoň jednu třídu, jež je jejím potomkem, a implementuje abstraktní metody startApp(), pauseApp(), destroyApp(), které reprezentují aktuální stav spuštěné aplikace. Vztahy a přechody mezi těmito stavy reprezentuje obrázek 5. javax.microedition.pki

Obr. 3-2 – Životní cyklus MIDletu

– z důvodu přidání komunikačního protokolu https, je potřeba, aby

uživatel aplikace mohl zjistit, zda je na serveru, se kterým komunikuje, platný certifikát. K tomu slouží rozhraní pro zjištění důležitých údajů o certifikátu, jako je vlastník, certifikační autorita, která jej vydala, a datum platnosti. javax.microedition.rms

– jedinou novinkou u trvale uložených dat je možnost jejich sdílení i

mezi MIDlety z jiných sad, ovšem pouze za předpokladu, že to majitel dat povolí. Bezpečnost V MIDP 1.0 byl pouze jeden bezpečnostní režim – aplikace běžící v sandboxu, která sama od sebe nemohla přistupovat k síťovému rozhraní bez vyžádaného svolení od uživatele. Tento režim byl zachován i v MIDP 2.0 pro nedůvěryhodné sady MIDletů. Druhou bezpečnostní variantou je podepsání programu s použitím certifikátu X.509, čímž se přesune (pokud všechny kontroly při instalaci proběhnou správně) do kategorie důvěryhodných sad MIDletů. Důvěryhodné sady pak mohou používat citlivá rozhraní přístrojů, kterými jsou všechny síťové protokoly a PushRegistry. Závěrem Již v průběhu roku 2006 měla být vydána nová specifikace MIDP 3.0, ale dosud není hotova. Měla by definovat a rozšiřovat následující oblasti, které byly zaneseny do žádosti JSR 271: -

souběžný běh více aplikací na jedné VM

-

automatické spuštění aplikace po startu zařízení

-

běh aplikace na pozadí

-

zlepšit předefinovaná uživatelská rozhraní

-

zlepšit podporu velkých displejů

-

povolit používání druhých displejů

-

rozšířit podporovaná síťová rozhraní

-

definice dalších způsobů instalování aplikací (nyní specifikováno pouze OTA – Over The Air) 14

3.


3.4.2. Zjištěné rozdíly v implementaci profilu MIDP Jelikož oblast vstupních zařízení není, jak ukázala tabulka 4, konkrétně specifikována. Záleží na samotných výrobcích telefonů, jakým způsobem předávají programovému vybavení informace o stisku kláves do nízkoúrovňových komponent, které jsou při tvorbě aplikací obvykle použity. To samozřejmě vede ke vzniku různých odlišností při implementaci této problematiky, ačkoliv mnoho zařízení disponuje absolutně shodnou nebo velmi podobnou klávesnicí té, kterou vidíme na obrázku 6. Specifikací profilu MIDP jsou vyžadovány

Obr. 3-3 – Standardní

pouze klávesy 0 až 9, hvězdička a mřížka. Telefony pak zpravidla mají i levý a

rozložení kláves

pravý softkey umístěný pod displejem, a směrové „šipky“ s prostředním tlačítkem. Klávesy pro zahájení a ukončení hovoru nejsou pro profil MIDP poskytovány, jelikož MIDletům není umožněno vytvářet telefonická spojení. Přijetí informace o stisku klávesy a jejím vlastním kódu se liší zejména mezi výrobci, ale například u telefonů značky Motorola byl zaznamenán rozdíl i mezi jednotlivými typy. První způsob, jak k tomuto problému tvůrci přistupují, je dán specifikací MIDP 1.0. Předání informace o události se provádí automatickým vyvoláním metody void keyPressed(int key) z třídy Canvas, kde parametr key udává číselný kód stisknuté klávesy. Tyto číselné konstanty se obvykle dále překládají metodou getGameAction(int key) do akcí reprezentovaných v tabulce 5. Číselný kód 1 2 5 6 8 9 10 11 12 35 42

Akce UP LEFT RIGHT DOWN FIRE GAME_A GAME_B GAME_C GAME_D KEY_POUND (#) KEY_STAR (*)

Číselný kód 48 49 50 51 52 53 54 55 56 57

Akce KEY_NUM0 KEY_NUM1 KEY_NUM2 KEY_NUM3 KEY_NUM4 KEY_NUM5 KEY_NUM6 KEY_NUM7 KEY_NUM8 KEY_NUM9

Tab. 3-5 – Standardní kódy kláves a herních akcí dle třídy Canvas

Samotná metoda by pak mohla vypadat takto: protected void keyPressed(int key){ // správné použití if (getGameAction(key) == Canvas.FIRE){ … } // funkční, ale nevhodné použití if (key == 50) { … } // nefunkční použití if(key == Canvas.FIRE){ … } }

Druhý způsob, jakým zjistit, že byla nějaká klávesa stisknuta, představuje metoda getKeyStates(),

kterou získá třída rozšiřující dříve zmíněný GameCanvas z MIDP 2.0. Návratovou hodnotou

je pak číselný kód naposledy použitého tlačítka od posledního volání této metody. Pokud žádné ta15

3.


kové nebylo, je tato hodnota rovna 0, v jiném případě vrátí bez dalšího mapování hodnotu rovnou jedné z konstant v tabulce 6. Číselný kód 2 4 32 64 256

Akce UP_PRESSED LEFT_PRESSED RIGHT_PRESSED DOWN_PRESSED FIRE_PRESSED

Číselný kód 512 1024 2048 2096

Akce GAME_A_PRESSED GAME_B_PRESSED GAME_C_PRESSED GAME_D_PRESSED

Tab. 3-6 - Standardní kódy kláves a herních akcí dle třídy GameCanvas

Programový kód by pak mohl vypadat takto: while(ture){ int action = getKeyStates(); switch(action){ case FIRE_PRESSED: { … } break; } }

Následující tabulky, které reprezentují standardní klávesnici z obrázku 6, ukážou, jaké kódy kláves byly u telefonů jednotlivých výrobců během implementace hry Piškvorky odhaleny. Červeně jsou hodnoty vrácené metodou keyPressed(int key), modře metodou getKeyStates(). Záporné hodnoty si pak definoval každý výrobce sám a jsou taktéž získány metodou keyPressed. -6 4 49 4 -

2 256 64 2 256 64 48

-7

-6

32

4 51 32 -

49 4 55 -

Tab. 3-7 – Klávesy telefonů Nokia

2 256 64 2 256 64 48

-7 32 51 32 57 -

Tab. 3-8 – Klávesy telefonů Sony-Ericsson

-1 -61 49 52 55 42

-59 -26 -60 50 53 56 48

-7 -62 51 54 57 35

Tab. 3-9 – Klávesy telefonů Siemens

-21

2 4

1024 4 256 42

-22

-21

32 64 2 4096 64 48/512

4 2048 32 256 35/256

Tab. 3-10 – Klávesy telefonů Motorola řad A1, A4, A6

512 4 4096 42

2 256 64 2 2048 64 48/512

-22 32 1024 32 256 35/256

Tab. 3-11 – Klávesy telefonů Motorola řad A3, A5

Shrňme nejdůležitější poznatky získané z tohoto výčtu. Unifikovaný přístup ke všem běžně používaným klávesám má jako jediný výrobce telefonů Siemens. Ostatní značky kombinují obě výše uvedené metody. Navíc pro některá tlačítka vrací hodnotu do obou z nich. Jiní výrobci naopak u 16

3.


svých telefonů neimplementují některé klávesy vůbec, ačkoliv by podle specifikace měli. Největší překvapení ovšem přináší tabulka 10, která skutečně neobsahuje chybu, jelikož Motorola u svých telefonů z řad A1, A4, A6 neposkytuje středové tlačítko joysticku, ačkoliv ho zařízení mají. To je pak v programu nahrazeno například klávesou 5. Závěrem uveďme, že rozhraní CommandListener z balíčku javax.microedition.lcdui, které slouží také pro odchyt uživatelských událostí, je určeno pouze pro vysokoúrovňově komponenty.

3.4.3. Jiné profily konfigurací CLDC a CDC PDAP (PDA Optional Packages) – tento profil určený pro PDA byl dokončen v červnu 2004. Stejně jako MIDP funguje na zařízení s KVM a CLDC, ale klade vyšší nároky na displej a paměť, a nabízí nové balíčky pro uživatelské rozhraní a práci s daty. Následující profily, jejichž strukturu znázorňuje obrázek 4 na straně 6, jsou určeny pro konfiguraci CDC: Základový profil (Foundation Profile) – přidává většinu základních tříd a balíčků, které CDC chybí oproti standardní edici, ale neobsahuje žádné uživatelské rozhraní, ani knihovny java.beans, java.rmi a java.sql. Je určen pro zařízení typu set-top box, kde dochází jen k velmi primitivnímu typu interakce s uživatelem a není tedy zapotřebí režie grafických rozhraní. Taktéž tvoří základ pro další rozšiřující profily. Osobní základový profil (Personal Basic Profile), Osobní profil (Personal Profile) – cílem obou profilů je poskytovat náhradní uživatelské rozhraní na bázi Java 2 za platformu PersonalJava, která byla odvozena z JDK 1.1.8. RMI profil (Remote Method Invocation) – přidává k základnímu profilu vzdálené volání metod kompatibilních s rozhraním standardní edice (knihovna java.rmi). Herní profil (Game Profile) – jak už název napovídá, měl by tento profil poskytovat podporu vývoje her pro CDC, ale v současné době je jeho vývoj pozastaven.

3.5. Volitelné balíčky Volitelné balíčky J2ME umožňují programovému jádru využívat ty specifické funkce hostitelského prostředí, které základní knihovny konfigurací a profilů standardně nepodporují. Tím razantně rozšiřují možnosti vyvíjených programů, ale zároveň snižují jejich přenositelnost. Například aplikace kompletně postavená na Mobile 3D Graphics API zaujme na první pohled každého vývojáře, ale po zjištění, že toto API není podporováno u většiny zařízení, je jeho použití zavrhnuto.

3.5.1. Java API for Bluetooth Wireless Technology (JABWT) Sama technologie Bluetooth je specifikována standardem IEEE 802.15.1. Svou definicí je určena k bezdrátovému spojení na frekvenci 2,4 GHz mezi dvěma nebo více elektronickými zařízeními, a tudíž spadá do kategorie osobních počítačových sítí, tzv. PAN (Personal Area Network). Jednotlivá 17

3.


zařízení jsou identifikována pomocí své adresy BT_ADDR (BlueTooth Device Address), podobně jako jsou MAC adresou určovány počítače v Ethernetu. Bluetooth se vyskytuje v několika vývojových verzích – 1.0, 1.1, 1.2, 2.0, 2.1, z nichž v současnosti nejpoužívanější je třetí jmenovaná, která má přenosovou rychlost 721 kbit/s a maximální šířku pásma 2,1 Mbit/s. Centrem této technologie je tzv. Bluetooth Protocol Stack, jehož architekturu můžete vidět na obrázku 7.

Obr. 3-4 – Bluetooth Protocol Stack, převzato z [7]

Tento zásobník protokolů je členěn na několik vrstev skládajících se z protokolů jádra, protokolů nahrazujících kabelové spojení, protokolů mobilní kontroly a adaptivních protokolů. Nám však stačí zaujmout obecnější pohled a rozdělit výše znázorněné schéma na dvě komponenty: -

hostující prostředí (spodní vrstva) – zajistí samotné navázaní spojení a přenos dat

-

hostující kontrolér (horní vrstva) – spolupracuje přímo s programovým vybavením Obě komponenty pak odděluje HCI (Host Control Interface), které zajišťuje interakci mezi nimi.

Ve skutečnosti se jedná o rozhraní separující hardwarovou a softwarovou část implementace, ale u velmi omezených zařízení, jakými jsou například headsety, může být veškerá funkcionalita obsažena jen na úrovni hardwaru a firmwaru, a tudíž HCI neobsahují. Aby mohlo zařízení podporovat Bluetooth technologii, musí hostující platforma navíc implementovat jeden nebo více profilů. Těch je v současné době 28 a každý z nich definuje návrhový vzor, jakým bude v dané oblasti použití navazována vzájemná komunikace, čímž odstraňují případnou nekompatibilitu výrobků různých značek určených pro stejné použití. Jelikož rozsah Bluetooth specifikace zahrnuje mnoho vrstev protokolů a profilů, rozhodla expertní skupina, která vytvářela JABWT v rámci JSR 82, o zahrnutí jen těch nejdůležitějších. Jako hlavní cíl si pak kladla budoucí rozšiřitelnost o nově vzniklé Bluetooth profily, které budou založeny na protokolech L2CAP a OBEX. Toto JSR proto popisuje využití pouze následujících částí Bluetooth specifikace ve verzi 1.1, nad kterou je postaven: -

datový přenos (audio přenos není podporován)

-

protokoly – L2CAP, RFCOMM, SDP, OBEX

-

profily – GAP, SDAP, SPP, GOEP

-

schopnosti – registrace služeb, vyhledávání zařízení a jejich služeb, navázaní spojení přes uvedené protokoly, řízení veškerých aktivit na bezpečné úrovni 18

3.


Tabulky 12, 13 uvádějí základní popis jednotlivých protokolů, respektive profilů3. Obrázek 8 pak znázorňuje vztahy mezi vyžadovanými profily. L2CAP

RFCOMM SDP OBEX

Popis protokolu Tvoří základ všech „vyšších“ protokolů Fragmentuje a defragmentuje data na pakety a zpět Multiplexuje data pro lepší vytížení linky Emuluje RS-232 sériový port Umožňuje až šedesát současných připojení bluetooth přístrojů Vyhledává služby na vzdáleném zařízení Umožňuje obecnou výměnu objektů v binární podobě Tab. 3-12 – Popis protokolů z Bluetooth specifikace

GAP SPP SDAP GOEP

Popis profilu Tvoří základ všech profilů a tím zaručuje všeobecnou kompatibilitu Definuje základní funkcionalitu – nastavení L2CAP linek, vyhledávání vzdálených zařízení Zajišťuje správnou emulaci sériového portu na RFCOMM protokolu Popisuje, jak se mají vyhledávat služby na vzdáleném zařízení pomocí protokolu SDP Vytváří základ dalších profilů zabývajících se výměnou dat nad protokolem OBEX Tab. 3-13 – Popis profilů z Bluetooth specifikace Generic Access Profile

TSC-BIN based Profiles Cordless Phone

SDAP

Intercom Profile

Serial port profile Dial-up Networking

Generic Object Exchange Profile

Fax Profile

File Transfer

Headset Profile LAN Access Profile

Object Push Synchronization

Obr. 3-5 – Vztahy mezi Bluetooth profily

Po samotném zařízení je pak vyžadována konfigurace CLDC nebo CDC, 512 kB dostupné paměti nad jejich hardwarové požadavky a samozřejmě podpora Bluetooth komunikačního hardwaru s potřebnými protokoly. Není tedy požadován kterýkoli konkrétní J2ME profil. Knihovny tříd Java aplikační rozhraní pro bezdrátovou Bluetooth technologii se skládá ze dvou knihoven – javax.bluetooth, javax.obex.

Jedna pracuje nad funkcemi protokolu L2CAP, druhá nad protoko-

lem OBEX. Obě jsou definovány nezávisle na sobě, ale poskytují v podstatě totožné funkce, které můžeme klasifikovat do tří hlavních kategorií: správa, vyhledávání a komunikace. Funkce věnující se správě umožňují převzetí kontroly nad lokálním Bluetooth zařízením a specifikují úroveň viditelnosti telefonu pro své okolí. Taktéž se starají o registraci poskytovaných služeb, které bude jiný uživatel využívat. Druhá kategorie zahrnuje vyhledání vzdálených zařízení a 3

Úplný název jednotlivých zkratek naleznete v příloze D. 19

3.


jimi nabízených služeb. Poslední se pak věnuje navázání spojení a jeho obsluze při samotné komunikaci. Čtenáře, kterého zajímá bližší popis tříd a jejich metod, odkazuji na zdroj [7] od strany 19 a zdroj [19]. Implementace Bluetooth Bohužel ne všechny telefony, které ve svém vybavení mají Bluetooth zařízení, ho poskytují i pro J2ME aplikace. Tak tomu je kupříkladu u telefonů Sony-Ericsson K700i. Rozsáhlý, avšak ne zcela kompletní seznam telefonů podporující JABWT dohledáte ve zdroji [15]. Jak bylo dříve uvedeno, jsou zmíněné knihovny separátní, takže výrobce telefonů může implementovat jak obě dvě, tak i libovolně jen jednu z nich. Například výrobce telefonů značky Nokia nepodporuje balíček javax.obex, čímž ho v podstatě staví mimo veškerý zájem tvůrců a pozornost je tak věnovaná pouze na javax.bluetooth.

3.5.2. Další zajímavé volitelné balíčky pro J2ME Chcete-li zjistit, zda Váš telefon podporuje některý z následujících balíčků, podívejte se na [15]. JSR 75 JSR 120, JSR 205 JSR 135 JS4 184 JSR 226, JSR 287 JSR 239

Název PDA Optional Packages Wireless Messaging API 1.0 a 2.0 Java Mobile Media API Mobile 3D Graphics API Scalable 2D Vector Graphics 1.0 a 2.0 Java Bindings for OpenGL ES

Stručný popis Umožňuje vývojářům kompletní přístup k file systému a k organizéru telefonu. Definují rozhraní pro příjem a posílaní MMS zpráv, které mohou obsahovat text, zvuk a obrázky. Významně rozšiřuje schopnosti původního balíčku, který je obsažen v MIDP 2.0. Obsahuje 30 tříd určených pro vývoj her a aplikací v 3D prostředí. Zajišťují podporu dvou-dimenzionální statické i animované vektorové grafiky. Podpora OpenGL technologie pro 2D a 3D grafiku.

Tab. 3-14 – Další volitelné balíčky J2ME

Ani jedna z verzí specifikace profilu MIDP neobsahuje API pro odesílání SMS zpráv. Pokud takovou službu přeci jen chcete využít, máte dvě možnosti. Buď knihovny dodané přímo výrobcem, pokud SMSky podporují, anebo Wireless Messaging API, které umožňuje odeslat textovou nebo binární zprávu. Samotný systém odesílání pomocí tohoto balíčku je jednoduchý: import javax.wireless.messaging.MessageConnection; import javax.wireless.messaging.TextMessage; import javax.microedition.io.Connector; sendMessage(String text, String number){ String addr = "sms://"+number; try{ MessageConnection conn = (MessageConnection) Connector.open(addr) TextMessage message = (TextMessage) conn.newMessage(MessageConnection.TEXT_MESSAGE); message.setAddress(addr); message.setPayloadText(text); smsconn.send(message); smsconn.close(); }catch (Exception e){ System.out.println("SMS se nepodarilo odeslat"); } } 20

4. Analýza a návrh implementace

Vývoj softwaru v oblasti her je tak rozvinutý, že již nelze přijít s čímkoliv novým, a proto se při vývoji aplikace budeme držet osvědčených a standardních postupů. Uživatel tak nebude překvapen například neobvyklým rozdělením položek menu nebo způsobem ovládání samotné hry. Dle zadání této práce má být pro demonstraci zvládnuté problematiky vytvořena samostatná anebo síťová hra. První oblast by přinesla zajímavé zkušenosti s vytvářením a implementací inteligentního algoritmu hrajícího proti uživateli. Ten by ale raději, podle zjištěných ohlasů, uvítal hru proti živé osobě. A proto, jak už z předešlých kapitol vyplývá, se budeme soustředit na vývoj síťové hry, jež by takovou možnost nabízela. Částečně předpřipravíme podmínky pro možné budoucí rozšíření hry o verzi jednoho hráče proti „počítači“.

4.1. Specifikační termíny Pro sjednocení terminologie specifikující funkční požadavky nadefinujeme pevné výrazy, které přesně určí, co podporováno bude, co by mohlo být a co nikoli. MUSÍ NESMÍ MĚLA BY NEMUSÍ

Definice Tvoří absolutní požadavek. Tvoří absolutní zákaz. Udává nepovinný požadavek, který implementace podporovat nemusí (ačkoliv jeho pozdější využití by mohlo být vyžadováno). Udává požadavek, se kterým implementace nemusí počítat. Tab. 4-1 – Specifikační termíny

4.2. Funkční požadavky Výsledným produktem bude stolní hra Piškvorky splňující běžná pravidla, která jsou specifikována například ve zdroji [20]. Aplikace je určená pro běh na mobilních telefonech, jež musí podporovat následující technologie: konfigurace CLDC 1.1, profil MIDP 2.0, volitelný balíček javax.Bluetooth a z důvodů dále uvedených grafických požadavků musí splňovat alespoň tyto hardwarové vlastnosti: velikost displeje 128x128, počet barev 256, telefonní nebo plná klávesnice. Finální aplikace by měla podporovat používání dotykového pera, respektive dotykového displeje. Programový kód musí být univerzální a bez jakýchkoliv změn přenositelný na jiný typ telefonu podporující Bluetooth, a proto nesmí využívat jakékoliv nestandardní knihovny tříd implementované nad rámec uvedené konfigurace a profilu. Kód musí respektovat rozdílné velikosti displejů a odlišné kódy kláves u jednotlivých výrobců. Veškeré texty zobrazované uživateli musí být v anglickém jazyce. Aplikace nemusí podporovat jiné jazyky. 21

4.

Analýza a návrh implementace

Hra musí být rozdělena na menu a hru samotnou. Menu musí obsahovat tyto položky: New Local Game, New Bluetooth Game, Help, Settings, Author´s Info, Exit. Hra by měla zobrazovat tyto informace: hráč, který je aktuálně na tahu a čas uplynuvší od začátku hry. Musí umožnit bezpečné odpojení z právě probíhající hry. Program musí být po grafické stránce jednotný. Samotná hra musí být postavena na nízkoúrovňových komponentách, a proto i menu by mělo být nízkoúrovňové. Aplikace nesmí používat SVG (Scalable Vector Graphics) grafiku, protože by tím využívala nestandardní volitelný balíček. Výsledná hra by měla v adekvátních případech (výhra/prohra, umístění symbolu, posun políčka) přehrávat zvuky a případně vibrovat. Navázání komunikace by mělo proběhnout tak, že jeden z účastníků vytvoří server, který bude čekat na připojení klienta. Aplikace nesmí povolit vstup třetí osoby do hry. Pokud jeden z hráčů násilně ukončí běh MIDletu (většinou podržením červeného tlačítka), oponent by o tom měl být informován. Pokud jeden z hráčů přijme během hry hovor, oponent o tom musí být informován a musí mu být umožněno se z takto přerušené hry bezpečně odpojit, bude-li o to mít zájem. Po skončení hovoru musí být umožněno pokračování hry. Při výhře/prohře musí být uživatelům umožněno pokračovat novou hrou bez potřeby nového startu serveru a připojení klienta.

4.3. Návrh implementace 4.3.1. Obecné komponenty Nejdříve je nutné zamyslet se nad vznikem obecně využitelných komponent, které budou sloužit jako šablony u konkrétních problematik. Takovou šablonou pak může být často využívaná funkce, která by svou implementací do více tříd zbytečně prodloužila a znepřehlednila programový kód. V našem případě se jedná o tvorbu často se opakujících grafických elementů, které jsou reprezentovány pomocí vrstev (třída TiledLayer) nebo animovaných symbolů (třída Sprite). Pro využití těchto technologií hovoří zejména podpůrné metody, které nám umožňují absolutní kontrolu nad rozložením a chováním jednotlivých prvků těchto objektů. Například menu, které by své položky znázorňovalo pomocí grafických ikon, může být rozčleněno tak, že každá jeho úroveň by byla tvořena právě jednou vrstvou. Viditelná by pak byla pouze aktivní úroveň. Jiný přístup, využívající shodnou programovou konstrukci, se uplatňuje i u samotné hrací plochy skládající se z dlaždic, respektive herních políček, uspořádaných v jedné vrstvě. Po umístění herního symbolu dojde k náhradě jedné dlaždice za jinou, čímž se změní obsah vybraného políčka na křížek nebo kolečko. Jako zástupce druhého typu opakujících se elementů můžeme uvést tzv. animované selektory, které by mohly sloužit pro výběr položek v menu nebo pro pohyb v samotném herním poli. Dosáhneme tak jisté úrovně animace a program nebude působit staticky. 22

4.


Třída implementující odchyt kláves by taktéž mohla tvořit zvláštní komponentu, avšak její funkce by se lišila podle aktuálního stavu aplikace – menu, navazování komunikace, hra. Nedosáhlo by se očekávaného zkrácení programového kódu, a navíc tím vzniká potřeba zvláštní signalizace, která specifikuje právě spuštěnou část hry.

4.3.2. Menu Menu hry by mělo uživatele oslovit a působit na něj nestatickým dojmem. Pro implementaci jsou zvažovány dvě možné úpravy. První možnost by obsahovala grafickou ikonu pro každou položku v menu a pro správné pochopení jejího významu by vypisovala i krátký textový popis v záhlaví nebo zápatí displeje. Druhá možnost by byla postavena na opačném principu. Obsahovala by graficky upravený font, kterým se vypíšou položky menu na displej, a ty by doplnila jedna významová ikona zobrazená v rohu displeje měnící se podle aktuálního výběru. Z hlediska požadované univerzality bude zvolena první možnost, jelikož je vhodnější pro lepší rozmístění položek na displeji tak, aby bylo dosaženo nezávislosti na jeho velikosti. Pro položky Help a Author´s Info, které budou uživateli sdělovat informace v textové podobě, je nutné vytvořit metody zajišťující univerzální zalamování slov pro jakoukoliv šířku displeje.

4.3.3. Navázání spojení Jelikož knihovna javax.obex není podporována na telefonech Nokia, bude pro vzájemnou komunikaci mezi telefony využito protokolu L2CAP a nad ním postaveného API. V každém telefonu bude možno vytvořit jak server, tak klienta. Uživatel pak v menu pod položkou New Bluetooth Game zvolí, v jakém módu se má aplikace spustit. Dle obecně známého modelu je pro úspěšné navázání komunikace mezi síťovými prvky nutné nejdříve kompletně nastartovat server. Tato činnost u mobilního telefonu zahrnuje převzetí kontroly nad Bluetooth zařízením, nastavení viditelnosti pro okolí, zaregistrování poskytované služby (hry Piškvorky) a otevření příchozího portu, na který se později klient bude připojovat. O aktuálním stavu inicializace zařízení má být uživatel informován. Též má mít možnost tuto činnost ukončit a vrátit se do hlavního menu. Na straně klienta, který se následně připojí, bude navázání komunikace zahrnovat tyto úkony: převzetí kontroly nad Bluetooth zařízením telefonu, vyhledávání dosažitelných zařízení a jimi poskytovaných služeb. Pokud bude nalezen server připravený na spuštění hry, proběhne synchronizace a samotný start. O aktuálním stavu inicializace zařízení má být uživatel informován a má mít možnost tuto činnost ukončit a vrátit se do hlavního menu. Nedojde-li k navázání spojení, měl by uživatel nalézt potřebné informace řešící tento problém v menu v sekci Help. Mezi časté chyby, které vyvolají chybu programu, lze zařadit zákaz viditelnosti telefonu pro okolní zařízení.

23

4.


4.3.4. Hra Jelikož je herní plocha vykreslována na obou telefonech zvlášť, mohou uživatelé používat stejné symboly nezávisle na sobě. Pro jedno střetnutí je zvoleno pole o velikosti 20x20 políček a startovní pozice bude index 10-10, který se vycentruje na střed displeje podle jeho rozlišení. Čtyři sta políček umožní i velmi rozsáhlou hru, ale je zjevné, že takové množství dlaždic se na jeden displej nevměstná, a proto bude herní plátno posunovatelné. Informaci o aktuálním stavu hry bude poskytovat textový popisek v záhlaví displeje. Kdo je právě na tahu, bude specifikováno pomocí hlášky „You“ anebo „Opponent“. Bude zde také uveden čas, který uplynul od začátku hry. Ten se nesmí inkrementovat po dobu, kdy je hra přerušena, tzn. při příchozím hovoru na straně jednoho z hráčů. Pro lepší přehlednost při výhře/prohře by měla být výherní kombinace pěti symbolů v řadě nějakým způsobem zvýrazněna. Vhodných možností je mnoho. Jako optimální se jeví způsob, kdy daných pět symbolů bude problikávat a telefon se rozvibruje.

4.4. Volba vývojového prostředí Pro vývoj aplikací v programovacím jazyku Java jsou v dnešní době nejčastěji používána vývojová prostředí NetBeans a Eclipse. U obou je nespornou výhodou fakt, že jsou distribuovány jako opensource a jsou volně ke stažení na webových stránkách výrobců. My se však soustředíme pouze na platformu J2ME a pro tu byla nalezena lepší podpora u prvně zmiňovaného IDE (Integrated Development Environment). Po naistalování kompletní verze NetBeans již tento produkt obsahuje Mobility Pack sloužící pro vývoj aplikací, které poběží na mobilních telefonech a PDA. Je vhodný pro psaní, testování i debagování aplikací určených pro mikro edici Javy. Zároveň integruje podporu profilu MIDP 2.0 a konfiguraci CLDC 1.1 a CDC, což mu umožní našeptávat a vhodně doplňovat programový kód pro urychlení vývoje. Jednoduchá je také implementace tzv. emulátorů, které simulují běh mobilního telefonu přímo v počítači a usnadňují tak potřebné testování. Ty bývají ke stažení na vývojářských stránkách jednotlivých výrobců telefonů, viz [12]. Umožňují rychlé funkční testování napsaného kódu, avšak nemohou kompletně nahradit fyzický přístroj, a proto je nutné v závěru projektu testovat běh aplikace přímo na telefonech samotných. Zejména jedná-li se o síťovou aplikaci, která musí komunikovat nezávisle na typu a značce telefonu. Další praktické komponenty prostředí NetBeans, které pro náš vývoj ale použity nebudou, jsou Visual Mobile Designer a Mobile Game Builder. První umožňuje grafický vývoj aplikací v okénkovém designéru pomocí předpřipravených komponent, které NetBeans nabízí. Druhý slouží pro tvorbu rozsáhlých herních scén a animovaných ikon. Jejich bližší popis naleznete ve zdroji [13].

24

4.

4.5.


Návrh diagramu tříd

Obr. 4-1 – Návrh diagramu tříd

25

4.

26


5. Realizace

Výsledná podoba aplikace, která Vám bude nyní představena, by měla splňovat veškeré požadavky uvedené v předchozí části. Již nyní vzniklo několik nápadů co zlepšit či přidat, ale to už ponecháme na případné další rozšíření aplikace. Tyto podněty ke zlepšení uvedeme pro inspiraci v závěrečné kapitole této práce. Nyní si pojďme ukázat aktuální podobu hry.

5.1. Představení aplikace První, s čím přijde uživatel do styku, je menu aplikace. Obsahuje šest ikon reprezentujících základní položky dle funkčních požadavků. Pro pohyb mezi nimi je použit animovaný selektor, který dvakrát za sekundu mění svůj stav z tenkého na silný. Při přesunu do další úrovně menu odjíždí aktuální vrstva vpravo mimo displej, zatímco nová vrstva se vysouvá zleva směrem na střed. Kromě položky New Local Game, která je pouze předpřipravená pro možné rozšíření hry, jsou ostatní ikony aktivní. Zde je popis jejich funkčnosti: -

Obr. 5-1 – Menu hry

New Bluetooth Game – slouží pro zahájení síťové hry. Uživatel nejdříve specifikuje, zda bude vystupovat jako server nebo klient, a poté si zvolí herní symbol, který bude používat. Ve hře je první na tahu vždy server.

-

Help – popíše, jakým způsobem aplikaci ovládat a jak postupovat v případě, že se nedaří navázat spojení mezi dvěma telefony. Vykreslovaný text se zalamuje v závislosti na šířce displeje.

-

Info – uvede základní informace o autorovi a programu samotném.

-

Settings – umožní zapnout nebo vypnout vibrace a melodii. Vibrace telefonu jsou standardně zapnuty a využívá se jich při výhře, respektive prohře jako doplňku pro zvýraznění nastalé situace. Naopak melodie je při startu aplikace vypnuta, jelikož se očekává, že protihráči budou v jedné místnosti a spuštěním programu by se telefony navzájem přehlušovaly. Případná změna obou nastavení zůstává platná pouze po dobu jednoho běhu programu a při příštím startu se opět vrátí do původních hodnot.

-

Exit – umožní bezpečné opuštění aplikace stejně jako soft key umístěný vpravo pod displejem.

Plocha herního pole je 20x20 políček, přičemž každé z nich má hrany dlouhé 16 pixelů. Aktuálně vykreslená je pouze ta část herního plátna, která se vejde na displej. Hráči vlastnící telefon s větším displejem tak mají oproti jiným nepatrnou výhodu. Posun obrazovky nastane, pokud by se animovaný selektor při dalším pohybu stranou vysunul mimo okraj obrazovky. Popis aktuálního stavu hry, tak jak 27

5.

Realizace

to vyžadují funkční požadavky, reflektuje záhlaví hrací plochy. Chce-li uživatel opustit rozehranou hru, stiskne kterýkoliv ze soft keyů a potvrdí zobrazenou upozorňovací zprávu dané akce – „Give up game?“. To na straně oponenta vyvolá výherní stav vynucený odpojením soupeře a zobrazí text „Opponent gave up. You WIN!“. Pokud se jeden z hráčů tímto způsobem vzdá, je předpokládáno, že již dále nechce pokračovat ve hře a oběma telefonům je nabídnut přechod zpět do menu nebo ukončení celé aplikace. Jiným přístupem, který nebyl realizován, je stav, kdy by chtěl hráč touto metodou vzdát viditelně prohranou hru a začít znovu.

Obr. 5-2 – Herní pole

Při obvyklém způsobu výhry je kombinace pěti výherních symbolů zvýrazněna trojitým probliknutím a uvedeným rozvibrováním telefonu. Oběma hráčům je pak nabídnuta možnost zahájení nové hry. Odmítne-li jeden z nich, druhý je o tom informován. Příchozí telefonní hovor vyvolá u protihráče hlášku „Opponent has a call. Wait or give up game.“ a způsobí pozastavení času měřeného od začátku hry. Pokud oponent vyčká, je po skončení hovoru automaticky obnoven běh hry na místě, kde předtím skončil. V případě, že se odpojí, je příjemce hovoru po jeho ukončení o této skutečnosti informován. Oproti funkčním požadavkům je umožněno nastartovat klienta dříve než server. Klient cyklicky prohledává své okolí a nalezne-li nějaké Bluetooth zařízení, zjistí, zda poskytuje jako registrovanou službu hru Piškvorky. Pokud tomu tak není, je celý proces spuštěn znovu. Po úspěšném navázání komunikace se na obou telefonech ve zvláštním vlákně spustí úloha, která každé tři sekundy zašle zprávu typu „ack“. Za situace, kdy více jak tři tyto zprávy nejsou doručeny, respektive nedorazí na protihráčův telefon, který je očekává, bere se navázané spojení za ztracené. Uživatel je o tom informován hláškou „Connection lost. What to do?“ a je mu nabídnut návrat zpět do menu nebo ukončení hry. Veškeré grafické ikony, které byly v aplikaci použity, jsou bezplatně získány ze zdroje [17].

5.2. Popis tříd a nejdůležitějších metod Oproti diagramu z obrázku 9 došlo k rozšíření aplikace o třídu BluetoothConnection, které je předáno samotné řízení komunikace od tříd BluetoothServer a BluetoothClient po úspěšném navázání spojení. Její hlavní funkcí je vyhodnocení příchozí zprávy a následné vyvolání odpovídající reakce na lokálním zařízení. Nově též vznikla třída AcknowledgeTask, která zajišťuje odeslání a příjem výše zmíněných zpráv typu „ack“. Jako optimální způsob pro pochopení funkčnosti jednotlivých metod programu je doporučeno nahlédnout do vytvořené dokumentace javadoc, kterou naleznete na přiloženém CD. Standardně zformátovaný kód aplikace má přibližně dva a půl tisíce řádků, a proto zde popíšeme pouze základní stavební kameny jednotlivých tříd. Funkce parametrů nebudou vysvětlovány v případě, kdy se jedná o metody knihovních tříd, jejichž popis naleznete ve standardní dokumentaci API na adrese [18] nebo [19]. 28

5.

Realizace

5.2.1. BluetoothServer.java Vytvoření serveru není z hlediska programového kódu náročné. Aplikace převezme kontrolu nad Bluetooth přístrojem telefonu, nastaví jeho viditelnost pro okolí a otevře příchozí port na specifikovaném URL. LocalDevice local_device = LocalDevice.getLocalDevice(); local_device.setDiscoverable(DiscoveryAgent.LIAC); String url = "btl2cap://localhost:00000000000010008000006057028A06"; L2CAPConnectionNotifier notify = (L2CAPConnectionNotifier) Connector.open(url); L2CAPConnection con = notify.acceptAndOpen();

Informace o stavu navazování komunikace jsou předávány do třídy GatoGameCavnas, která je vypisuje na displej.

5.2.2. BluetoothClient.java (InquiryListener, ServiceListener) Tento soubor ve svém těle zahrnuje další dvě třídy, které uživatel využívá při navazování komunikace, a proto zde budou popsány společně. Třída BluetoothClient nejdříve inicializuje samotné Bluetooth zařízení tím, že nad ním opět převezme kontrolu a následně si vytvoří agenta pro prohledávání okolního prostředí. LocalDevice local_device = LocalDevice.getLocalDevice(); DiscoveryAgent disc_agent = local_device.getDiscoveryAgent();

Poté je pokračováno s vyhledávacím procesem, který se skládá ze dvou částí. První je zajištěna vnořenou třídou InquiryListener a slouží pro vyhledání vzdálených přístrojů, jež jsou v dosahu. Druhá část na takto nalezených zařízeních zkoumá pomocí třídy ServiceListener přítomnost herního serveru hry Piškvorky. Pokud není server nalezen, probíhá celý proces od začátku. Je-li hledání úspěšné, vyzvedne si klient URL adresu prvního telefonu, který ve svém okolí naleznul a připojí se na něj. String url = serv_listener.service.getConnectionURL(0, false); L2CAPConnection con = (L2CAPConnection) Connector.open(url);

To znamená, že uživateli není nabízena možnost výběru v případě, kdy je v jeho okolí více funkčních serverů. Informace o stavu navazování komunikace jsou předávány do třídy GatoGameCavnas,

která je vypisuje na displej.

5.2.3. BluetoothConnection.java Po navázání komunikace je spuštěno separované vlákno třídy BluetoothConnection, které začne pomocí metody receive(byte [] inBuf) přijímat pakety dat. Tato metoda je takzvaně blokující, což znamená, že vyčkává na příchozí zprávu a nezatěžuje tak svou činností hlavní vlákno programu, které vykresluje hrací plochu a vyhodnocuje stisky kláves. Samotná data jsou přijata v podobě bajtů, které jsou dále překládány na běžný textový řetězec následujícím příkazem: String msg = new String(inBuf, 0, inBuf.length).trim();

29

5.

Realizace

Vyhodnocením tohoto řetězce pomocí metody equals("nejaky_text") a klauzulí if-else je rozhodnuto o vyvolání příslušného stavu ve třídě GatoGameCanvas. Po ukončení hry zajistí metoda close()uzavření

komunikačního kanálu.

5.2.4. AcknowledgeTask.java Jelikož je potomkem třídy TimerTask, umožňuje automatické spouštění její metody run() po uplynutí doby dané třetím parametrem v příkazu scheduleAtFixedRate(acknowledgeTask, 0, 3000).

Tato hodnota obsahující časový údaj v milisekundách zde zastupuje časový spínač, který

provedení úlohy zajistí. Nejdříve se odešle zpráva „ack“ a následně se testuje, zda byla během posledních tří sekund přijata stejná signalizace z protihráčova telefonu. Pokud přijata není a stane se tak třikrát po sobě, je ve třídě GatoGameCanvas vyvolán stav reprezentující ztrátu spojení a hra je ukončena.

5.2.5. LayerManaging.java Jak již sám název napovídá, jedná se o komponentu sloužící jako manažer pro tvorbu grafických elementů, které do aplikace vkládáme odděleně. Ty tvoří vrstvy složené z ikon, se kterými se setkáváme zejména v menu, a animovaných selektorů, jež nám umožňují pohyb mezi políčky herního plátna a mezi položkami menu. Chce-li nějaká třída požádat o vytvoření prvně zmiňovaného prvku, vytvoří si proměnnou typu TiledLayer,

kterou zinicializuje voláním metody getTiledLayer(int layer, TiledLayer tl,

int WI, int HE, int tile, char fileSign, int posX, int posY, boolean visible),

kde

hodnoty parametrů mají tento význam: -

layer

– identifikační číslo vrstvy, které je využito pro specifikování způsobu, jakým budou

jednotlivé dlaždice naplněny odkaz na instanci objektu TiledLayer, který chceme vytvořit

-

tl –

-

WI

– počet dlaždic vrstvy v X-ové ose

-

HE

– počet dlaždic vrstvy v Y-nové ose

-

tile

-

fileSign

-

posX

– počáteční umístění vrstvy v X-ové ose po její inicializaci

-

posY

– počáteční umístění vrstvy v Y-nové ose po její inicializaci

-

visible

– šířka a výška jedné dlaždice (komponenta tudíž podporuje pouze čtvercové dlaždice) – specifikuje zdrojový soubor, ze kterého budou dlaždice vyřezávány

– specifikuje, zda bude daná vrstva viditelná

Pro tvorbu selektorů použijeme metodu getSprite(int layer, Sprite sp, int[] spSeq, int posX, int posY, boolean visible),

-

layer

která je v některých bodech podobná předcházející:

– tento parametr přímo determinuje, jaký typ selektoru se má vytvořit, respektive ze

kterého zdrojového souboru se budou obrázky načítat a jaká bude jejich velikost -

spSeq 30

– definuje posloupnost obrázků, tvořící animaci selektoru

5.

Realizace

-

posX

– počáteční umístění vrstvy v X-ové ose po její inicializaci

-

posY

– počáteční umístění vrstvy v Y-nové ose po její inicializaci

-

visible

– specifikuje, zda bude daná vrstva viditelná

5.2.6. SpriteAnimationTask.java Tato úloha poskytuje jednoduchou podpůrnou činnost pro animaci selektorů. Je potomkem třídy TimerTask

a tudíž je umožněno její automatické vyvolání po vypršení časovače, stejně jako tomu

bylo u AcknowledgeTask.java v kapitole 5.2.4. Jakmile tato událost nastane, je zajištěn přechod na další snímek v sekvenci, která byla specifikována při jejich tvorbě. Jsme-li v sekvenci u konce, pokračuje se přirozeně od začátku.

5.2.7. GatoMidlet.java Spouštěcí třída aplikace, která rozšiřuje abstraktní třídu MIDlet a implementuje její metody volané při změně stavu programu – startApp(), pauseApp() a destroyApp(). Ačkoliv má veřejný konstruktor, v programu existuje pouze jedna její instance, což umožňuje vytvořit statický odkaz na její obsah, který lze získat pomocí vytvořené metody getInstance(). Tuto třídu lze v našem případě považovat za jakousi nadtřídu všech ostatních, protože pomocí ní přecházíme mezi jednotlivými stavy programu – menu, samotná hra. Dále zajišťuje základní nastavení programu, respektive definuje, zda bude hra ozvučena a zda bude při výhře/prohře vibrovat. Tyto vlastnosti se při každém startu aplikace resetují na původní hodnoty, protože není využíváno RMS (Record Management System) záznamů, které slouží pro dlouhodobé uložení statických informací Java aplikací na mobilních telefonech.

5.2.8. GatoMenuCanvas.java Tato třída reprezentuje veškeré programové prostředky pro práci s menu. Slouží jak pro vykreslení a správu grafiky, tak i pro obsluhu jednotlivých kláves. Její běh, který soustředíme do jednoho vlákna, je odstartován po inicializaci potřebných datových struktur, mezi něž se řadí zejména zmiňované vrstvy. Menu hry jich obsahuje celkem sedm a slouží jako: -

Pozadí

-

Úvodní menu

-

Výběr síťového módu hry

-

Výběr herního symbolu

-

Nastavení aplikace

-

Neviditelná vrstva použitá při vykreslování textu sekce „Help“ a „Author´s Info“

-

Animovaný selektor pro výběr položek

Další významnou větví je obsluha stisku kláves. Ta je zde zajištěna dvojím způsobem tak, jak to bylo popsáno v kapitole 3.4.2. Obě metody vyhodnocují, jaká klávesa nebo směr joysticku byl pou31

5.

Realizace

žit a podle toho volají metody upPressed(), downPressed(), leftPressed(), rightPressed, firePressed(), softLeftPressed()

a ().

První čtyři zajišťují pohyb selektoru ve směrech, které lze zajisté intuitivně odvodit. Další v pořadí pak podle aktuálního stavu menu může odstartovat samotnou hru nebo ukončit celou aplikaci, ale především slouží pro vyvolání animace přechodu do další úrovně menu pomocí metody animateMenuIn(TiledLayer tlIn, TiledLayer tlOut).

Předposlední metoda je využita, pokud se

chce uživatel vrátit zpět o úroveň výš. Pro tento účel je zde inverzní funkce animateMenuBack(TiledLayer tlOut, TiledLayer tlIn).

Uvedené parametry tlOut a tlIn přirozeně repre-

zentují vrstvy menu, které z displeje odjíždí a přijíždí. A konečně softRightPressed() zajišťuje ukončení aplikace. To však pouze v případě, že se právě nacházíme v úvodním menu. Mezi zajímavé komponenty této třídy lze zařadit i metody drawMessage(String message) a drawWord(String message, int begin, int end),

které ve vzájemné kooperaci vykreslují a

zalamují text předaný parametrem message univerzálně podle šířky displeje. Indexy begin a end pak určují pozici začátku a konce aktuálního slova v textu. Zbylé třídní metody pak zpravidla sdružují často se opakující funkce použité při tvorbě grafických elementů, což zkracuje a zpřehledňuje programový kód.

5.2.9. GatoGameCanvas.java Jedná se zřejmě o nejdůležitější část celého programu, která zajišťuje běh hry. Opět je zde po nastavení potřebných proměnných v konstruktoru třídy spuštěno separované vlákno aplikace. To ve svém počátku nastartuje, dle předchozího výběru uživatele, inicializaci požadovaného módu Bluetooth připojení. Samotná hra je pak zahájena až po navázání úspěšného spojení dvou telefonů, přičemž je spolu s tímto okamžikem spuštěno i odesílání zpráv typu „ack“, které byly popsány v kapitole 5.2.4. Během cyklického běhu vlákna je stejně jako v předchozím případě testován stisk kláves. Též dochází k vykreslování grafiky do off-screen bufferu, který je v závěru každého cyklu „vypláchnut“ na displej pomocí metody flushGraphics(). Jakmile je hráčem umístěn herní symbol do hrací plochy, spustí se v metodě control(int sh) test, který vrací hodnotu true, pokud je daná pozice součástí výherní kombinace. Ta může nastat ve čtyřech směrech znázorněných na obrázku 12, kde červeně zbarvené pole představuje právě umístěný křížek nebo kolečko. Je-li nepřerušená řada pěti symbolů detekována, odešle se protihráči speciální typ zprávy, která jako obvykle obsahuje souřadnice umístěného symbolu, a navíc vyvolá animaci výherní posloupnosti.

32

Obr. 5-3 – Výherní směry

5.

Realizace

5.3. Zajímavé poznatky Během vývoje došlo ke zjištění, že telefony nemusí být před spuštěním hry takzvaně spárované. Tato činnost se sama provede při prvním kontaktu během navazování herní komunikace. Uživatelé jsou pouze vyzváni k zadání číselných klíčů, podle kterých se navzájem identifikují. S tím souvisí problém, který nastal během instalace Piškvorek na telefony značky Nokia. Mnoho jejích typů nepodporuje přímou instalaci programů zkopírováním zkompilovaných Java souborů s příponou „jar“ prostřednictvím Bluetooth spojení z počítače. Pro tuto činnost se musí použít speciální, volně šiřitelný software Nokia PC Suite, který lze stáhnout ze stránek výrobce. Před instalací se provede spárování počítače a telefonu, což způsobí, že chce-li uživatel okamžitě vyzkoušet nově nainstalovanou hru, nedojde k navázání spojení s protihráčem, ačkoliv se koncová zařízení navzájem „vidí“. Důvodem je stále probíhající komunikace s počítačem. Ve většině případů řeší tuto situaci vypnutí a zapnutí Bluetooth zařízení na straně uživatele hry nebo spárování telefonů před prvním spuštěním aplikace. Na tomto místě ještě dodejme, že bezproblémové navázání komunikace trvá průměrně patnáct až dvacet sekund.

33

5.

34

Realizace

6. Testování

Testování jako takové není jednorázovou akcí, ale probíhá v rámci celého procesu vývoje. Cílem je chyby v softwaru objevit, nikoli poukázat na to, že v něm nejsou. Jestliže nalezneme jen velmi málo chyb, neznamená to, že je software dokonalý, ale pravděpodobně je prováděno špatné testování. V jistých případech je optimální nechat tuto činnost na nezúčastněné třetí straně. Typů testů je samozřejmě velké množství, ale pro tak malý projekt, jakým je hra Piškvorky, postačí, pokud se jakožto vývojáři budeme soustředit na obyčejné funkční testování. To budeme provádět manuálním procházením možných stavů hry, nejlépe dle předem připravených a promyšlených scénářů. Obvykle je dobré pokusit se také o vyvolání nestandardních situací chováním, které běžný uživatel neprovádí. V našem případě by se mohlo jednat o rychlé po sobě jdoucí pseudonáhodné stisky kláves zejména v okamžicích, kdy je předpokládáno, že uživatel pouze pasivně přijímá informace z displeje. Pochopitelně již během vývoje došlo k odstranění mnoha chyb, jež byly nalezeny při prezentování průběžných verzí aplikace. Mezi nejvýraznější pak lze zařadit tyto: -

V programovém kódu byla nevhodně použita metoda ready(), která testovala, zda jsou na otevřeném Bluetooth spojení nějaká data k přijetí. Ta zajistila, že metoda recieve(byte [] inBuf)

neblokovala běh vlákna, ve kterém byla zavolána. Jelikož tato činnost probíhala

v odděleném vlákně, docházelo k neustálému testování příchozího spojení a zbytečně se tak vyčerpávaly výpočetní prostředky. V extrémních případech nastala situace, kdy bylo omezeno samotné vykreslování grafiky aplikace. -

Dále docházelo k nekorektnímu uzavření komunikačního kanálu po ukončení rozehrané hry a odchodu zpět do menu. To mělo za následek znemožnění startu nového serveru a klienta hry bez restartování celého programu.

-

Chybová situace také nastala v momentě, kdy klientská strana spustila vyhledávání herního serveru hry Piškvorky a v jejím okolí se nacházelo jiné aktivní Bluetooth zařízení. Program po jeho detekování automaticky předpokládal, že našel očekávaný objekt svého zájmu a informoval uživatele o nalezení protihráčova telefonu. Po nezdaru při hledání samotné hry byl chybně ukončen celý proces prohledávání okolí.

-

Během příchozího hovoru zvolil oponent možnost odpojení ze hry a následně se rozhodoval, zda chce celý program ukončit nebo se vrátit do menu. Pokud byl v tuto chvíli hovor ukončen, došlo na straně oponenta k nevyžádanému znovuspuštění hry, ačkoliv příjemce hovoru byl informován o tom, že se protihráč odpojil.

-

Nedostatečně řešená situace nastala též v případě, kdy se hrající telefony vzdálily natolik, že došlo ke ztrátě spojení. Vznikla proto dříve uvedená úloha detekující existenci aktivního spojení. 35

6.

Testování

6.1. Funkční testování (Functional Testing) Ve výčtu výše uvedených odstraněných chyb, výjimek a různých hraničních případů by bylo možno dlouze pokračovat. Raději se však soustřeďme na testování finální verze programu. To nejdříve probíhalo na emulátorech několika typů všech obecně známých výrobců – Nokia, Sony-Ericsson, Motorola, Siemens. Rozhodně není nutné, abychom zde předváděli schopnost aplikace navázat spojení, hrát hru a následně ji prohlásili za bezchybnou. Raději se pokusíme v reálném nasazení navodit situace, které nejsou vhodně programově ošetřeny. Při testování byly použity tyto typy telefonů: Nokia 6230, Nokia 6230i, Nokia 6300, Nokia N90, Siemens SK65, Sony-Ericsson K750, Sony-Ericsson K530i. Během testování lokálního běhu programu byly odhaleny tyto chyby: -

Několikrát nedošlo k zobrazení textového obsahu položek „Help“ a „Author´s Info“ po dokončení animace z hlavního menu. Tato chyba se vyskytovala v náhodném sledu a nepodařilo se odhalit podnět, který ji vyvolává. Přechod do těchto sekcí menu je tedy nevhodně ošetřen nebo nedostatečně kontrolován.

-

Pokud uživatel stiskem potvrzovacího tlačítka vybere kteroukoli nabídku v hlavním menu aplikace a v krátkém okamžiku poté taktéž stiskne pravý soft key, který slouží k opuštění programu, je původní volba „přebita“ novou a hra se ukončí. Pravý soft key je tedy příliš pozdě vyřazen z činnosti.

-

Opakem je situace, kdy necháme animaci do nové úrovně menu provést. V okamžiku, kdy je tento přechod dokončen, stiskneme krátce levý soft key, který slouží pro návrat do nadřazeného menu. Tato činnost nemá za následek vyvolání zpětné animace, ale způsobí vykreslení špatného nadpisu aktuální vrstvy menu. Tento nadpis je převzat z nadřazené úrovně, do které by nás stisk klávesy měl vrátit. Levý soft key je tedy příliš brzy uveden v činnost.

Při testování síťové činnosti byly zjištěny tyto nedostatky: -

Vytvoří-li jeden z hráčů herní server a během čekání na klienta přijme hovor, je stále umožněno navázání spojení (pokud byly dříve telefony spárovány). Chybou v tomto případě je, že klient není po připojení do hry o situaci na druhé straně informován tak, jak k tomu běžně dochází kdykoliv během hry.

Zajisté by se našlo mnoho dalších chyb v závislosti na tom, kolik času se do této činnosti vloží. Čím větší a nákladnější projekt je, tím vyšší nároky by na jeho funkční testování měly být kladeny. Z našeho pohledu bude ale zajímavější výsledek testování, které bude prováděno přímo běžnými zákazníky.

6.2. Testování použitelnosti (Usability Testing) Ze strany vývojáře, který tvoří aplikaci od jejích počátků, se veškeré rozmístění prvků zdá intuitivní. Realita je ovšem jiná, a proto ke zjištění, zda je uživatelské rozhraní lehce ovladatelné a dobře pochopitelné, využíváme testování použitelnosti, které je prováděno typickým koncovým uživatelem. Tomu 36

6.

Testování

zadáme sadu úkolů a sledujeme, jak si při jejich řešení poradí. Základní oblasti, jež následně vyhodnocujeme, jsou: -

čas, který vyřešení úloh vyžadovalo

-

počet chyb, kterých se při jejich řešení uživatel dopustil

-

subjektivní pocit uživatele po dokončení testu

V našem případě bude tento typ testování probíhat současně u dvou osob, které mají běžné zkušenosti s elektronickými přístroji. Budou mít za úkol nalézt předem nainstalovanou hru Piškvorky ve svém mobilním telefonu, seznámit se s grafickým rozhraním a následně spustit a sehrát hru. Nastane-li krizová situace, při které si nebudou vědět rady, pokusí se ji vyřešit samy. Později mohou požádat o radu přítomného moderátora znajícího kompletní rozhraní hry. Během testu bylo získáno mnoho podnětů, na jejichž základě vzniklo několik nápadů pro různá vylepšení, ale ty už ponecháme na případném budoucím rozšíření aplikace. Jediné, co se dodatečně změnilo, byla sekce „Help“. Ta je nyní lépe strukturovaná a obsahuje více informací.

Ačkoliv byly při řešení prvního úkolu očekávány problémy, prokázaly oba subjekty dobrou znalost svých přístrojů a vyřešily tento úkol uspokojivě rychle. Následně jim byl ponechán čas pro seznámení s aplikací. Prohlédly si jednotlivé položky menu, zkoušely měnit nastavení hry a zběžně pročetly sekci „Help“ a „Author´s Info“. Závěr – Jediná připomínka, která byla v této fázi prezentována, se týkala nastavení. Separované ikony pro odlišení funkcí zapnutí a vypnutí jednotlivých položek by se daly sloučit do jedné pozice a měnily by se podle jejich aktuálního stavu.

Problémy nastaly až při startu samotné hry. Přestože oba uživatelé při své práci běžně používají počítač, hierarchická struktura server-klient pro navázání spojení jim není vlastní. Z pozdějších reakcí vyplynulo, že ke zhoršení situace také přispěly nevhodné grafické ikony, kdy server je reprezentován zámkem a klient klíčem, který se do zámku zasune. Závěr – Alternativní model pro reprezentaci jednotlivých módů hry byl zvažován, ale konkrétní řešení ve spojení s uživateli nebylo nalezeno.

Po osvětlení významu dané síťové struktury se přešlo k prvnímu pokusu o navázání spojení. Ten byl z důvodů uvedených v kapitole 5.3 bohužel neúspěšný. Jelikož uživatelé při prvním běhu programu netušili, kolik času je potřeba pro navázání spojení, bezvýsledně vyčkávali po dlouhou dobu, zda hra začne. Pokud by v této situaci opětovně nezasáhnul moderátor, nastal by konec testu, protože řešení daného problému nebylo v sekci „Help“ dostatečně vysvětleno. Při druhém pokusu již celý proces připojování proběhnul v pořádku a hra byla spuštěna.

37

6.

Testování

Závěr – Východisko z celé situace může přinést časový limit, během kterého musí dojít k navázání komunikace, jinak bude uživatel vrácen zpět do menu. Optimální hodnotou by mohlo být šedesát sekund a aktuální stav odpočítávání času by se zobrazoval klientovi na displeji.

První kontakt s herním prostředím byl relativně pozitivní, ale během několika minut se objevily návrhy, jak ho zpříjemnit. V globále se jednalo o náměty, které se dotýkaly momentu, kdy je protihráčův symbol umístěn na náš displej nebo v horším případě, kdy je položen mimo výřez aktuálně zobrazené plochy. Jestliže v tuto chvíli hráč promýšlí svůj další tah a je plně soustředěn na rozložení křížků a koleček na hrací ploše, pravděpodobně si nevšimne informace v pravém horním rohu, která ho upozorňuje, že je na tahu. Tak se tomu stalo i u testovaných subjektů. Závěr – Vzniklo několik podnětů, jak tento problém řešit. Prvně uvedeným bylo krátkodobé zobrazení hlášky „YOU“ na středu hrací plochy při změně stavu hry. To by se dalo rozšířit o vibraci a eventuální zablikání umístěného symbolu. V případě, kdy je tento symbol navíc položen mimo displej, může nastat posun hrací plochy tak, aby byl protihráčův tah viditelný.

Poslední otázkou zůstává, zda by si oba uživatelé poradili s instalací hry do mobilního telefonu například podle návodu, který je uveden v příloze E – Uživatelské příručka.

Na stupnici od jedné do pěti, kde jednička je nejlepší a pětka nejhorší, dostala aplikace známku za dva. Celkový dojem byl velmi dobrý, ale podle uvedených připomínek je zjevné, že se ještě nemůže jednat o kompletní komerční produkt. V úplném závěru byla uživatelům položena otázka, zda by si testovaný produkt koupili a případně za jakou cenu. Oba se shodli, že ano a nabízené částky byly 30 a 50 Kč, které zhruba odpovídají obvyklým cenám aplikací v tomto segmentu trhu. Atraktivní pro ně byla zejména možnost sehrát partii kdykoliv a kdekoliv by chtěli. Člověk tak nemusí přemýšlet, zda si kupříkladu k věcem na pláž má přibalit čtverečkovaný papír pro případ, že by si chtěl Piškvorky zahrát. Velké plus, které by samozřejmě navýšilo nabízenou částku, je v potenciálu rozšíření aplikace na sadu her.

38

7. Závěr

7.1. Možná vylepšení Případný další vývoj můžeme z obecného hlediska rozdělit do dvou základních větví. Jednou by bylo rozšíření samotné hry o další novinky a druhou úprava programového kódu, který se zejména díky nevhodným programovým konstrukcím stal těžkopádným a zbytečně nabobtnalým. Do první kategorie můžeme zařadit tyto ideje: -

Pro úplnost programu je třeba rozšířit aplikaci o možnost hry jednoho hráče proti uměle vytvořenému algoritmu – Single player mód.

-

Problémem, který není nijak ošetřen a nastane zejména u malých displejů, je stav, kdy protihráč umístí svůj symbol mimo výřez naší aktuálně zobrazené plochy. Uživatel díky informaci v záhlaví zjistí, že je na tahu, ale bohužel už se nedozví, kde je protihráčům symbol umístěn a musí ho sám hledat. Řešení by mohl tvořit automatický přesun selektoru na pozici, kde hrál soupeř, což by současně vyvolalo adekvátní posun hrací plochy.

-

Určitá skupina uživatelů by také ocenila možnost ovládání aplikace pomocí dotykového pera.

-

U mobilních aplikací je standardem uvítací obrazovka (splashscreen), kterou zde zatím nenaleznete. Měla by obsahovat základní informace o produktu a autorovi. Z pohledu uživatele se jedná o komponentu, která ho spíše zdržuje, než zajímá, a proto zatím nebyla implementována.

-

Hodnoty v nastavení aplikace by měly zůstat pevně dané i po znovuspuštění aplikace.

-

Pro porovnání schopností hráčů by mohla být zavedena dlouhodobá statistika výher a proher.

-

Uživateli by měl být nabídnut seznam dostupných herních serverů v jeho okolí, respektive nemělo by docházet k připojování na první úspěšně nalezené zařízení.

-

Větší zájem uživatelů by přineslo rozšíření aplikace na sadu her, které lze hrát přes Bluetooth mezi dvěma hráči – šachy, dáma, lodě, renju, apod.

V oblasti programového kódu by se další vývoj měl soustředit na tyto oblasti: -

Primárně musí být odstraněny chyby uvedené v kapitole 6.1.

-

Přepracovat kostru programu do přechodového automatu namísto neustálého vyhodnocování proměnných typu boolean.

-

Provést centralizaci textu a číselných konstant do zvláštní třídy.

-

Využít vláknově bezpečné vykreslování grafického rozhraní pomocí metody callSerially(Runnable runnable).

-

Pomocí systémové vlastnosti microedition.platform detekovat typ hostitelského prostředí (Nokia, Sony-Erocsson, atd.), na kterém aplikace běží a od toho odvodit způsob ovládání.

-

Pro dlouhodobé uložení potřebných informací vytvořit třídu pracující s RMS záznamy. 39

7.

Závěr

7.2. Zhodnocení splnění cílů BP Pro demonstraci zvládnuté problematiky měla být implementována ukázková aplikace Piškvorky v alespoň jedné z těchto dvou variant: -

v offline verzi pro jednoho hráče s vestavěnou herní logikou protihráče

-

v online verzi pro dva hráče s podporou serveru

Vývoj, který se soustředil na druhou variantu, byl tak zjednodušen o implementaci umělého algoritmu, ale musel se potýkat s problémy, které mohou nastat při síťové komunikaci. Tím spíše, že do běhu programu současně zasahují dva uživatelé, což přináší mnohem více hraničních situací. Složitost jejich odstranění navíc rostla i s nezanedbatelným zpožděním, které při přenosu dat skrz Bluetooth vzniká. Hlavním cílem pak byla snaha o vytvoření univerzálního programu, který poběží na všech typech telefonů nezávisle na velikosti displeje nebo odlišných číselných kódech kláves při použití nízkoúrovňových komponent. To se podařilo, ale výsledný kód aplikace je tak zatížen o nepotřebné informace, které vždy využije jen ten či onen typ telefonu. Dále musela být zvolena kompromisní velikost grafických elementů, aby i uživatelé s malými displeji mohli bez problémů ovládat menu a hrát hru. To způsobilo, že někde vypadají tyto prvky příliš malé a jinde naopak příliš velké. Z výše uvedených závěrů vyplývá, že při komerční tvorbě mobilních aplikací není vhodné psát pouze jeden programový kód s jedním typem rozlišení grafických elementů. Pro tvorbu takovýchto aplikací je dobré vytvořit základní kostru programu, nad kterou dojde k rozšíření o konkrétní specifika jednotlivých typů telefonů. Uživateli je následně nabídnuta verze určená přesně pro jeho přístroj.

7.3. Osobní přínos Výslednou kvalitu programu také ovlivnila nevhodná a nedostatečně provedená analýza před zahájením samotného vývoje programu. Tato zkušenost, která je u podobných studentských prací běžná, bude pro mne zajisté dobrým přínosem do budoucna. Další zkušeností, kterou jsem si během vývoje osvojil, je práce s texty psanými v angličtině. Bohužel ne vše, co člověk při seznamování s novou technologií potřebuje prostudovat, nalezne v českém jazyce. Zvláště jedná-li se o tak specifickou oblast, jakou jsou mobilní aplikace. Z pohledu vývojáře pak byl největším přínosem test prováděný koncovými uživateli. Programátor si až v této chvíli uvědomí, co je a co není v celkové struktuře programu důležité. Také jsem rád, že jsem si vyzkoušel tvorbu programových konstrukcí, které pracují s Bluetooth připojením. Tento typ bezdrátové komunikace nabývá v dnešní době na významu a předpokládám, že jsem se s ním nesetkal naposledy. Dle ohlasu okolí na mou aplikaci jsem došel k subjektivnímu názoru, že za současné situace ani v blízké budoucnosti nebude programování v J2ME pro mobilní telefony příliš komerčně perspektivní. Schopnější uživatel si na Internetu vyhledá velké množství volně dostupných her včetně těch síťových, a nemá důvod, aby za ně platil. Navíc pro nemálo lidí je hraní her na telefonech velkou neznámou, 40

7.

Závěr

natož aby si k této činnosti na svém přístroji zapínali Bluetooth. Přínos této práce pro mne spočívá zejména v přístupu k novým technologiím, které neovládám. Má-li člověk chuť a zájem (v dnešní době také i čas), veškeré potřebné informace nalezne. Dále záleží už pouze na něm, jak velkým odborníkem pro danou oblast se stane. Stále totiž platí rčení, které zejména v oblasti softwarových informačních technologií nabývá zajímavého rozměru: „Kolik jazyků znáš, tolikrát jsi člověkem“.

41

7.

42

Závěr

A. Seznam použité literatury

[1]

Topley, K.: J2ME v kostce – pohotová referenční příručka. Grada Publishing, a.s., Praha, 2004.

[2]

Qusay, H. M.: Naučte se Java 2 Micro Edition. Grada Publishing, a.s., Praha, 2002.

[3]

Herout, P.: Učebnice jazyka Java. Kopp, České Budějovice, 2003.

[4]

Specifikace konfigurací CLDC 1.0 a 1.1 http://jcp.org/en/jsr/detail?id=30 http://jcp.org/en/jsr/detail?id=139

[5]

Specifikace konfigurace CDC 1.0 a 1.1 http://www.jcp.org/en/jsr/detail?id=36 http://www.jcp.org/en/jsr/detail?id=218

[6]

Specifikace profilů MIDP 1.0 a 2.0 http://jcp.org/en/jsr/detail?id=37 http://jcp.org/en/jsr/detail?id=118

[7]

Specifikace Java API for Bluetooth http://jcp.org/en/jsr/detail?id=82

[8]

Specifikace Bluetooth technologie http://bluetooth.com/Bluetooth/Technology/Works/

[9]

Seriály o programování aplikací pro J2ME http://interval.cz/vyvoj-aplikaci/j2me/ http://www.pcsvet.cz/java/

[10] Série článků o J2ME a Bluetooth na anglické a české Wikipedii http://en.wikipedia.org/wiki/Java_ME http://en.wikipedia.org/wiki/Connected_Limited_Device_Configuration http://en.wikipedia.org/wiki/Mobile_Information_Device_Profile http://en.wikipedia.org/wiki/JSR-82 http://en.wikipedia.org/wiki/Bluetooth http://en.wikipedia.org/wiki/Bluetooth_profiles http://en.wikipedia.org/wiki/Bluetooth_protocol http://en.wikipedia.org/wiki/Java_Community_Process http://cs.wikipedia.org/wiki/J2ME http://cs.wikipedia.org/wiki/Bluetooth http://cs.wikipedia.org/wiki/Bluetooth_protokol [11] Developerské stránky profilu MIDP od společnosti SUN http://developers.sun.com/mobility/midp/index.html http://java.sun.com/products/midp/ http://java.sun.com/products/cldc/ [12] Developerské stránky výrobců mobilních telefonů http://forum.nokia.com/ http://developer.sonyericsson.com http://developer.motorola.com/ http://developers.samsungmobile.com http://www.siemensmania.cz/ 43

A.

Seznam použité literatury

[13] Developerské stránky k NetBeans Mobility Pack 5.5 http://www.netbeans.org/kb/55/mobility.html http://wiki.netbeans.org/JavaME [14] Představení funkcí poskytovaných vývojovým prostředím NetBeans pro tvorbu v J2ME http://www.netbeans.org/features/javame/index.html [15] Databáze mobilních zařízení http://devices.j2mepolish.org/interactivedb/searchdevices.faces [16] Přehled novinek v MIDP 2.0 http://nb.vse.cz/~zelenyj/it380/eseje/xticm07/midp20.htm [17] Archiv volně šiřitelných ikon http://www.iconarchive.com/ [18] Dokumentace aplikačního rozhraní profilu MIDP http://java.sun.com/javame/reference/apis/jsr118/ [19] Dokumentace aplikačního rozhraní JSR82 (Bluetooth API a OBEX API) http://java.sun.com/javame/reference/apis/jsr082/ [20] Pravidla hry Piškvorky http://www.deskovehry.info/pravidla/piskvorky.htm

Všechny webové zdroje byly k 7.7.2008 funkční.

44

B. Seznam obrázků

Obr. 1-1 – Star7 .................................................................................................................................... 1 Obr. 1-2 – Schéma rozdělení jednotlivých edic Javy ........................................................................... 2 Obr. 1-3 – Screenshot z ukázkové hry pro mobilní telefon .................................................................. 3

Obr. 3-1 – Základní přehled architektury J2ME .................................................................................. 7 Obr. 3-2 – Životní cyklus MIDletu .................................................................................................... 14 Obr. 3-3 – Standardní rozložení kláves .............................................................................................. 15 Obr. 3-4 – Bluetooth Protocol Stack, převzato z [7] .......................................................................... 18 Obr. 3-5 – Vztahy mezi Bluetooth profily, převzato z [7] ................................................................. 19

Obr. 4-1 – Návrh diagramu tříd .......................................................................................................... 25

Obr. 5-1 – Menu hry ........................................................................................................................... 27 Obr. 5-2 – Herní pole ......................................................................................................................... 28 Obr. 5-3 – Výherní směry .................................................................................................................. 32

Obr. E-1 – Nastavení přístupových práv rozhraní Bluetooth na počítači........................................... 53 Obr. E-2 – Průvodce pro přenos souborů pomocí rozhraní Bluetooth ............................................... 53 Obr. E-3 – Zadaní číselného kódu ...................................................................................................... 53 Obr. E-4 – Založení hry...................................................................................................................... 54

45

B.

46

Seznam obrázků

C. Seznam tabulek

Tab. 3-1 – Vlastnosti virtuálních strojů v J2ME .................................................................................. 9 Tab. 3-2 – Třídy zděděné konfigurací CLDC z J2SE ........................................................................ 10 Tab. 3-3 – Systémové vlastnosti......................................................................................................... 11 Tab. 3-4 – Hardwarové požadavky profilu MIDP 2.0........................................................................ 12 Tab. 3-5 – Standardní kódy kláves a herních akcí dle třídy Canvas .................................................. 15 Tab. 3-6 - Standardní kódy kláves a herních akcí dle třídy GameCanvas.......................................... 16 Tab. 3-7 – Klávesy telefonů Nokia .................................................................................................... 16 Tab. 3-8 – Klávesy telefonů Sony-Ericsson ....................................................................................... 16 Tab. 3-9 – Klávesy telefonů Siemens ................................................................................................. 16 Tab. 3-10 – Klávesy telefonů Motorola řad A1, A4, A6 .................................................................... 16 Tab. 3-11 – Klávesy telefonů Motorola řad A3, A5........................................................................... 16 Tab. 3-12 – Popis protokolů z Bluetooth specifikace......................................................................... 19 Tab. 3-13 – Popis profilů z Bluetooth specifikace ............................................................................. 19 Tab. 3-14 – Další volitelné balíčky J2ME .......................................................................................... 20

Tab. 4-1 – Specifikační termíny ......................................................................................................... 21

Tab. E-1 – Přehled všech předdefinovaných atributů souboru manifest.mf a deskriptoru aplikace .. 51 Tab. E-2 – MIME typ souboru jad a jar ............................................................................................. 52

47

C.

48

Seznam tabulek

D. Seznam zkratek

API Application Programming Interface, programové rozhraní aplikace CDC Connected Device Configuration, konfigurace v prostředí J2ME CLDC Connected Limited Device Configuration, konfigurace v prostředí J2ME CVM Compact Virtual Machine, virtuální javový stroj pro konfiguraci CDC GAP Generic Access Profile, základní profil pro všechny profily definované ve specifikaci Bluetooth GC Garbage collection, část programovacího jazyka, která vyhledává nepoužívané části paměti pro jejich další využití GIF Graphics Interchange Format, grafický formát určený pro rastrovou grafiku GMT Greenwich Mean Time, čas platný v pásmu nultého poledníku HCI Host Controller Interface, zajišťuje komunikaci mezi hardwarem a softwarem Bluetooth přístroje IDE Integrated development environment, vývojové prostředí usnadňující tvorbu programů JCP Java Comunnity Process, proces používaný k vývoji nových součástí platformy Java JDK Java Development Kit, soubor základních nástrojů pro vývoj aplikací na platformě Java JSR Java Specification Request, dokument specifikující využití nové technologie přidané do Javy JVM Java Virtual Machine, virtuální javový stroj pro standardní edici Javy J2EE Java 2 Enterprise Edition, edice programovacího jazyku Java J2ME Java 2 Micro Edition, edice programovacího jazyku Java J2SE Java 2 Standard Edition, edice programovacího jazyku Java KVM Kilobyte Virtual Machine, virtuální javový stroj pro konfiguraci CLDC L2CAP Logical Link Control and Adaptation Protocol, Bluetooth protokol pro správu přenosů dat MAC Media Access Control, jedinečný identifikátor síťového zařízení MIDlet, aplikace podle standardu MIDP MIDP Mobile Information Device Profile, profil rozšiřující konfiguraci CLDC MIME Multipurpose Internet Mail Extensions, standard umožňující zasílání dat různých formátů OBEX OBject EXhange, Bluetooth protokol pro výměnu objektů v binární podobě OTA Over The Air, definuje oficiální způsob, jak instaloval MIDlety na telefony PAN Personal Area Network, síť dosahem několika metrů PNG Portable Network Graphics, grafický formát určený pro bezeztrátovou kompresi rastrové grafiky RFCOMM Radio Frequency Communication, Bluetooth protokol emulující sériový port RS-232 RMS Record Management System, systém pro přístup k dlouhodobě uloženým záznamům SDAP Service Discovery Application Profile, Bluetooth profil specifikující, jak vyhledat registrované služby na vzdálených zařízeních 49

D.

Seznam zkratek

SDP Service Discovery Application Profile, Bluetooth protokol pro vyhledání vzdálených zařízení SPP Serial Port Profile, Bluetooth profil specifikující použití protokolu RFCOMM GOEP Generic OBject EXchange Profile, základní datový Bleutooth profil

50

E. Uživatelská příručka

Následující text byl z části převzat ze zdroje http://interval.cz/clanky/j2me-v-kostce-jak-dostataplikaci-do-telefonu/ (funkční k 7.7.2008). Zabalení aplikace - teorie Aplikace se skládá ze dvou základních souborů, které mají strukturu danou specifikací MIDP. Jsou to deskriptor aplikace a JAR soubor. Této dvojici souborů se říká sada MIDletů (midlet suite). V JAR souboru je zabalen jeden či více MIDletů. Tento soubor obsahuje: -

Manifest soubor

-

Java třídy pro MIDlety

-

Ostatní zdroje jako například obrázky

Manifest soubor se v JAR souboru nachází v adresáři META-INF a jmenuje se manifest.mf. Má, stejně jako deskriptor aplikace, formát jméno_atributu: hodnota atributu a musí obsahovat všechny povinné atributy, kterými jsou MIDlet-Name, MIDlet-Version, MIDlet-Vendor, MIDlet- pro každý MIDlet, MicroEdition-Profile, MicroEdition-Configuration. Pokud některý z nich nebude zahrnut, mohou telefony tuto sadu MIDletů odmítnou. Přehled všech předdefinovaných atributů sady MIDletů s ukazuje následující tabulka: MIDlet-Name MIDlet-Version MIDlet-Vendor MIDlet-Icon MIDlet-Description MIDlet-Info-URL MIDlet- MIDlet-Jar-URL MIDlet-Jar-Size MIDlet-Data-Size MicroEdition-Profile MicroEdition-Configuration

Popis atributu Název sady MIDletů, kterým se identifikuje uživateli. Specifikuje verzi sady MIDletů používanou při aktualizaci aplikace. Poskytovatel sady MIDletů Jméno png souboru uvnitř JAR souboru, který je použit jako ikona aplikace. Popis sady MIDletů. URL, kde je možné najít další informace o této sadě MIDletů. Jméno, ikona a název hlavní třídy n-tého MIDletu. Odděleno čárkami URL, odkud je možné stáhnout jar soubor této sady MIDletů. Velikost JAR souboru. Minimální velikost paměti, kterou tato sada MIDletů potřebuje pro uložení trvalých dat. Požadovaný J2ME profil, např. MIDP-1.0 Požadovaná J2ME konfigurace, např. CLDC-1.0

Tab. E-1 – Přehled všech předdefinovaných atributů souboru manifest.mf a deskriptoru aplikace

Deskriptor aplikace je textový soubor, který má stejný formát jako manifest soubor. Jmenuje se jmeno_sady_MIDletu.jad. Při instalaci sady MIDletů se nejprve do telefonu přenese deskriptor aplikace a JAR soubor se nahrává podle atributů v něm obsažených. Následující atributy jsou povinné – MIDletName, MIDlet-Version, MIDlet-Vendor, MIDlet-Jar-URL, MIDlet-Jar-Size. Kromě povinných atributů může deskriptor obsahovat další libovolné atributy, které nezačínají řetězcem MIDlet. K těmto atributům má programátor přístup metodou getAppProperty(String key) z 51

E.

Uživatelská příručka

třídy MIDlet. Pozor na to, že telefony značky Siemens umějí načíst atribut maximálně 255 znaků dlouhý. Také není dobrým nápadem vkládat do manifestu české znaky. Zabalení aplikace - praxe V praxi za Vás zabalení zdrojových souborů provádí vývojové prostředí. To umožňuje vytvoření více projektových konfigurací, které specifikují, jaké informace mají být přibaleny do deskriptoru a manifestu v závislosti na tom, pro který typ telefonu je aktuálně aplikace kompilována. Instalace Existuje několik způsobů, jak nahrát aplikaci do telefonu, z nichž každý telefon podporuje odlišnou podmnožinu. Možnosti jsou následující: -

Datový kabel

-

Infračervený port

-

Bluetooth

-

OTA (Over The Air neboli vzduchem) - wap

Dle specifikace profilu MIDP je OTA jediným oficiálním způsobem jak aplikaci do telefonu nahrát. Abyste ji mohli z Internetu stáhnout, potřebujete soubory jar a jad umístit na http server. Na něm pak musí být správně nastavený MIME typ, aby je software v telefonu dokázal rozpoznat – viz tabulka 17. Teď už jen stačí zkopírovat deskriptor a JAR na Váš server a zadat do telefonu adresu deskriptoru. .jad .jar

MIME typ text/vnd.sun.j2me.app-descriptor application/java-archive Tab. E-2 – MIME typ souboru jad a jar

Nejpříjemnějším způsobem jak aplikaci nainstalovat, je ovšem pomocí Bluetooth spojení z počítače za předpokladu, že Vám telefon to umožní. Postup je následující: 1. Aktivovat Bluetooth zařízení na počítači i telefonu. 2. U obou zařízení povolit viditelnost pro okolí. Mobilní telefon nabízí tuto možnost většinou ve stejném menu, kde se Bluetooth zapíná. U počítače s operačním systémem Windows XP přejdeme do Ovládacích panelů, kde vybereme položku „Zařízení Bluetooth“. V záložce „Možnosti“ nastavíme stejné hodnoty jako na obrázku 13. 3. Následně pravým tlačítkem klikneme na soubor s příponou jar, zvolíme položku „Odeslat“ a v rozbaleném kontextovém menu vybereme „Zařízení Bluetooth“. Pokud vše proběhlo v pořádku, objeví se nám průvodce pro přenos souborů pomocí rozhraní Bluetooth – viz obrázek 14. 4. Poté stiskneme tlačítko „Procházet“, které spustí vyhledávání aktivních Bluetooth zařízení v okolí počítače. Nově otevřeno okno „Vybrat Bluetooth zařízení“ by nám mělo nabídnout mobilní zařízení, na které chceme aplikaci nahrát. Klikněte na něj a výběr potvrďte tlačítkem „OK“. 5. Nyní je doporučeno zadat číselný kód použitý pro identifikaci účastníků komunikace. V našem případě jsme použili standardní sekvenci 1234 tak, jak to vidíte na obrázku 15. 52

Obr. E-1 – Nastavení přístupových práv rozhraní Bluetooth na počítači

Obr. E-2 – Průvodce pro přenos souborů pomocí rozhraní Bluetooth

Obr. E-3 – Zadaní číselného kódu

53

E.

Uživatelská příručka

6. Počítač se v této chvíli pokusí spojit s mobilním telefonem. Ten se nejdříve zeptá, zda může přijmout spojení od neznámého zařízení. Pokud nabídku přijmete, jste vyzváni k zadání výše uvedeného číselného kódu, což má za následek spárování počítače a mobilního telefonu. 7. Poté již dojde ke zkopírování dat a vše je hotovo. Případně na některých telefonech je ještě uživatel dotázán, zda se má aplikace nainstalovat. Ovládání Nahoru – klávesa 2 nebo odpovídající pohyb joystickem Dolu – klávesa 8 nebo odpovídající pohyb joystickem Vlevo – klávesa 4 nebo odpovídající pohyb joystickem Vpravo – klávesa 6 nebo odpovídající pohyb joystickem Potvrzení - klávesa 5 nebo odpovídající pohyb joystickem Ukončení programu – pravý soft key v základním menu nebo stisk odpovídající ikony. Opuštění rozehrané hry – levý i pravý soft key Založení hry

Obr. E-4 – Založení hry

54

F. Obsah přiloženého CD

Na přiložené médiu naleznete následující složky, které obsahují: Aplikace\ – zkompilované soubory Gato.jad a Gato.jar reprezentující finální podobu aplikace Javadoc\ – standardně vygenerovaná dokumentace programového kódu v českém jazyce Projekt\ – zkomprimovaný projekt z IDE NetBeans Text BP\ – text bakalářské práce ve formátu pdf a docx (Microsoft Word 2007) Zdrojové soubory\Gato\ – zdrojové soubory programu Zdrojové soubory\Graphics\ – grafické a hudební soubory použité v programu

55

F.

56

Obsah přiloženého CD

Programování Java aplikací pro mobilní telefony - hra Piškvorky

Recommend Documents