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

Transkript

1 České vysoké učení technické v Praze Fakulta Elektrotechnická Bakalářská práce Messenger pro mobilní telefony implementovaný v J2ME s vlastním Java serverem Michal Doubek Vedoucí práce: Doc. RNDr. Josef Kolář, CSc. Studijní program : Elektrotechnika a informatika strukturovaný bakalářský Obor: Informatika a výpočetní technika srpen 2007

2 ii

3 Poděkování: Na tomto místě bych chtěl poděkovat všem, kteří mi jakýmkoliv způsobem pomáhali při vzniku této práce. Zvláště bych pak chtěl poděkovat panu Ing. Dušanu Kožušníkovi a panu Csachovi za správné nasměrování a pomoc při práci na tomto projektu. iii

4 iv

5 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ů (autorský zákon). V Praze dne v

6 vi

7 Anotace: Tato práce se zabývá J2ME, jejím vývojem, specifiky a odlišnostmi od J2SE. Jako ukázka je pak přiložena aplikace Messenger s vlastním Java serverem. Aplikace je nejprve zanalyzována, kde je i uveden výčet technologií a nástrojů, které byly pro implementaci použity a na závěr popsána samotná realizace s testováním na dvou modelech mobilních telefonů. Summary: This project deal with J2ME, historical development, specificities in contrast to J2SE. There is enclosed application Messenger with own Java server like illustration. At first application is analyzed connected with enumeration of technologies and tools, which were used for implementation of this application. Realization and testing on two models of cell phones is described in the end. vii

8 viii

9 OBSAH Seznam obrázků Seznam tabulek xi xiii 1. Úvod c 2. J2ME c c STRUČNÉ SEZNÁMENÍ S JAZYKEM J c Trocha historie Charakteristika J2ME SPECIFIKA c c c c c c c c c c c c c c c c c c CLDC a CDC Knihovny tříd CLDC a odlišnosti jednotlivých balíčků od J2SE Přehled balíčků MIDP Virtuální stroj VM Síťové možností J2ME Bezpečnost midletů Struktura souborů a jejich význam Rozdíly MIDP 1.0 a SHRNUTÍ J2ME Ukázková aplikace (Messenger) ANALÝZA A NÁVRH ŘEŠENÍ Klient Server Databáze REALIZACE c Potřebné programové vybavení c Realizace databáze c Java soubory serveru c Java soubory klienta c 3.3. TESTOVÁNÍ c Emulátory c Zkušební data c Dva uživatelské scénáře c Kompatibilita c 4. Závěr Seznam literatury 24 A Seznam použitých zkratek c B Uživatelská příručka 27 C Obsah přiloženého CD c ix

10 x

11 Seznam obrázků 2-1 Schéma tří základních Java platforem J2ME složení vrstev Schéma souborů tvořící JAR Schéma OTA ER Model Přehled souborů serveru Přehled souborů klienta Navigace příkazů 19 B-1 Uživatelská příručka - spuštění aplikace 27 B-2 Uživatelská příručka - přihlášení uživatele 28 B-3 Uživatelská příručka - vytvoření/odeslání zprávy 28 B-4 Uživatelská příručka - adresář 29 B-5 Uživatelská příručka - příjem zprávy 29 B-6 Uživatelská příručka - inbox & archív 30 B-7 Uživatelská příručka - reset pamětí 30 C-1 Obsah přiloženého CD 31 xi

12 Seznam tabulek 2-1 J2ME konfigurace a profily Přehled balíčků MIDP Typy souborů a jejich popis Přehled tříd serveru Přehled tříd klienta Zkušební data 21 xii

13 xiii

14 1 ÚVOD Cílem této práce je podat ucelený stručný přehled o J2ME v českém jazyce. Zpracovanou teorii pak demonstrovat na příkladě. Jako ukázka byl zvolen program Messenger, pro který je třeba využít většinu možností, které Java pro mobilní telefony poskytuje. Dnes jsou na trhu dvě komplexní publikace pojednávající o J2ME. Do češtiny přeložená J2ME v kostce Pohotová referenční příručka [1] a anglicky psaná Wireless J2ME Platform Programing [2]. Z těchto publikací jsem převážně čerpal i já při zpracování teorie. Druhá kapitola se skládá ze dvou částí. První stručně pojednává o historii a Javě obecně, druhá s názvem J2ME specifika má za úkol podat stručný výtah toho nejdůležitějšího z uvedených knih doplněné o některé zajímavé informace z internetových zdrojů [4] a [5]. Tyto teoretické poznatky jsou pak využity pro samotnou implementaci aplikace. Ve třetí části je zpracována samotná ukázka aplikace. Problém je řešen standardním postupem. Nejprve je aplikace analyzována a jsou stanoveny požadavky na funkčnost. Vzhledem k tomu, že se jedná o klient/server problém, kde na straně serveru je třeba uchovávat data uživatelů, je příklad řešen ve třech samostatných liniích - klient J2ME, server a databáze. Součástí třetí části je pak i samotná realizace tzn. kód pro vytvoření databáze a popis tříd tvořící klienta a server. Na závěr této kapitoly je uveden způsob testování a dva příklady telefonů pro které byla aplikace zkoušena. Pro ukázku jsem zvolil anglický jazyk, jak pro aplikaci tak pro samotný kód aplikace. Kód je tím pro jakéhokoliv programátora přirozenější a tím i srozumitelnější, aplikace pak bude moci být zveřejněna i na zahraničních open source serverech. Ve čtvrté a poslední části je srovnání aplikace s již existujícími implementacemi a diskuze o využití tohoto programu. Součástí závěru je taktéž shrnutí, jaký měla práce na této úloze přínos pro mě osobně

15 2 J2ME 2.1 STRUČNÉ SEZNÁMENÍ S JAZYKEM JAVA Trocha historie V roce 1990 viceprezident společnosti Sun Microsystems Bill Joy vydává podnět k vytvoření nového stručného jazyka s vyšší efektivností. Vzniká Green Team vedený Jamesem Goslingem. Tato skupina si dává za úkol vyvinout jazyk pro domácí spotřebiče. Vývojáří přichází s novým jazykem Oak, pojmenovaný jednoduše po dubu, který rostl před oknem šéfa týmu. Tento jazyk musel být velice jednoduchý nenáročný na výkon a paměť koncového zařízení. Oak se však nedočkal velkého ohlasu. V letech 1993 a 1994 se začíná objevovat internet a vzniká poptávka po softwaru pro prohlížení webové sítě. Jazyk Oak je obratně přejmenován na Java (v americkém slangu znamená káva) a je vyvíjen pro tento účel. V roce 1995 se pak firma Netscape stává prvním zákazníkem Javy a kupuje licenci za USD. Netscape byl ve své době jedničkou na trhu ve svém oboru webových prohlížečů. Touto cestou se do světa začaly šířit Javovské aplety a vývojářský svět si začal uvědomovat budoucí roli Javy na trhu s internetově zaměřeným softwarem. Velkou předností Javy byla a je její přenositelnost, což zaujalo i klasické vývojáře. Pokud software běžel nezávisle na různých platformách, došlo ke snížení nákladů, ať už se jednalo o Windows nebo Unix. Firma Sun rychle reagovala na vznikající poptávku a doplnila knihovny pro propracovanější uživatelská rozhraní, než jaké měly knihovny používané k vývoji původních apletů, spolu s řadou funkcí pro distribuované výpočty a zdokonalené vylepšení. Zvyšující se nároky po té vedly k přestavbě Javy a vydání nové platformy Javy 2, ta se charakterizovala také rozdělením na J2SE a J2EE. Přestože byla Java původně koncipována pro jednoduché domácí spotřebiče, tak s vývojem a příchodem nových verzí se stala J2SE velmi náročná na výkon procesoru a paměť. V dalších letech se ale znovu začínala objevovat poptávka po Javě, která by fungovala v malých přenosných zařízeních. Reakce Sun bylo vydání J2ME, která nahrazuje původní JDK 1.1 stejnou funkčností avšak už na bázi Java 2. [4] [5]. Obr. 2-1 Schéma tří základních Java platforem Java 2 Standard Edition zajišťuje standardní funkcionalitu, kterou je možno doplnit o různé balíčky pro daná aplikační prostředí. API J2SE ještě také obsahuje knihovny pro vytváření klientských desktopových aplikací (AWT, swing). Java 2 Enterprise Edition je postavená na Java SE, je určena pro vývoj a provoz podnikových a informačních systémů. Obsahuje nástroje pro vývoj webových aplikací Java Servlets, Java Server Pages (JSP), pro vývoj sdílené business logiky Enterprise Java Beans (EJB), pro přístup k legaci systémům Java Connector Architecture (JCA), rozhraní zpráv Java Messaging Service (JMS), pro podporu technologií Web Service. Java 2 Micro Edition je malé omezené API, určené pro zařízení s omezeným výkonem a paměťovými prostředky. Tento svět malých přístrojů obsahuje širokou škálu zařízení s velmi - 2 -

16 rozdílnými možnostmi, proto není možné vytvořit unifikovaný softwarový produkt. J2ME není tedy jedinou entitou, ale je souborem specifikací pro dané podmnožiny spotřebních produktů [1]. V současnosti je Java velmi oblíbeným a rozšířeným jazykem. Java funguje na 4,5 miliardách přístrojích, počítačích, čipových kartách, telefonech, tiskárnách, kamerách, auto-navigacích, výherních automatech, zdravotnických přístrojích, parkovacích automatech atd.[12]. Firma Sun neustále pracuje na jejím vývoji a podniká mnohé kroky pro její další rozšiřování, na trhu má ovšem velmi silného protihráče a tím je firma Microsoft. Ta ovládá drtivou většinu trhu s operačními systémy a tím prakticky vylučuje rozšíření Javy mezi windows aplikace. Vývojáři Javy se tedy zaměřují na dvě části softwarového trhu, kde jsou schopni konkurence. Na malých zařízení typu mobilních telefonů nejprve Java jasně dominovala, ale s rostoucím výkonem mobilních telefonů přišly operační systémy Symbian a Windows Mobile s mutacemi programů PC Windows. Nelítostná bitva probíhá také na poli internetových aplikací, kde spolu válčí technologie JSP, servlety s firmou Sun v zádech a silné ASP od Microsoftu a třetí do party je pak populární open source PHP. Většímu rozvoji Javy ovšem brání jak sem uvedl konkurenční boj a to všemi dostupnými prostředky, jeden příklad za všechny : co se týče sporu, zda má operační systém Windows podporovat Javu, současný stav je takový, že Java na Windows běží, ovšem je nutné si stáhnout JRE, jelikož není součástí instalace Windows. Tyto tahanice jsou součástí vleklých soudních sporů. Poslední významný krok se odehrál v květnu 2007, kdy Sun zveřejnil zdrojové kódy a dnes je Java vyvíjena jako open source. Můj osobní názor je takový, že na trhu mobilních telefonů to bude mít Java ještě hodně těžké, jelikož svoje pozice posiluje i iphone od firmy Apple, který má velmi silné pozice ve světě a nyní se chystá na expanzi do Evropy. Nicméně co se týká her na mobilní telefony, zde si Java vytvořila dosti silnou pozici, kterou jen tak nepustí. Co se týká kancelářských nebo multimediálních aplikací, tam se Microsoft dostane na stejné pozice jako u PC Windows. Co se týká web aplikací, zde J2EE poskytuje velmi rozmanité a pokročilé technologie, které by se ve složitějších systémech mohly prosazovat i nadále, ovšem na jednoduchých serverech zůstane dominantní PHP a to i díky jeho mohutné podpoře ze strany providerů, kteří nabízí PHP hosting takřka zadarmo, zatímco Java hosting je podporován mnohem méně a jeho cena je také vyšší Charakteristika Charakterizovat Javu lze nejlépe výrazy šéfa Green Teamu Jamese Goslinga [12]. Jednoduchý její syntaxe je zjednodušenou verzí syntaxe jazyka C/C++. Odpadly mnohé konstrukce, které způsobovaly programátorům problémy naopak přibyla řada zajímavých rozšíření. Nezávislý na architektuře vytvořená aplikace může běžet na jakémkoliv operačním systému nebo architektuře. Jediná ale nutná podmínka je, aby na hostitelském počítači byl nainstalován JVM. Objektově orientovaný všechny datové typy jsou objektové, výjimku tvoří pouze osm primitivních typů. Přenositelný tím je myšlena nezávislost i co se týká vlastností základních datových typů v rámci jedné platformy. Přenositelnost je možná i mezi různými platformami např. J2SE a J2ME. Zde však musíme dbát omezení menší platformy J2ME, při přenosu opačným směrem zas na speciální třídy, o které je J2ME rozšířena. Distribuovaný navržen pro podporu aplikací v síti (práce se vzdálenými soubory, volání vzdálených metod) Vysoce výkonný přesto že se jedná o interpretovaný jazyk, je dnešní Java velice rychlá a to i díky tomu, že do strojového kódu se překládá pouze část kódu, která je opravdu zapotřebí

17 Vícevláknový podpora vícevláknového běhu programu Robustní vysoká spolehlivost, oproti C vypuštěny některé rizikové konstrukce (goto, správa paměti nebo předávaní ukazatelů), používá silnou typovou kontrolu. Správa paměti je pak řešena Garbage collectorem. Dynamický jazyk navržen pro vyvíjející se prostředí, knihovny mohou být rozšiřovány za chodu z vnějších zdrojů nebo vlastním programem Bezpečný Java má vlastní mechanismy, které ji chrání před nebezpečnými operacemi nebo napadení vlastního operačního systému nepřátelským kódem. Na druhou stranu má Java i své nevýhody. Jedná se o interpretovaný jazyk, proto je program před spuštěním nutný nejprve přeložit, to lze omezit mechanismy jako jsou JIT nebo HotSpot. Další zpomalení je automatická správa paměti, což dozajista běh programu také brzdí, dnes z velké části optimalizováno pomocí chytrých algoritmů na správu paměti. Při běhu programu je potřeba mít v paměti celé běhové prostředí, což je u jednoduchých aplikací zbytečné. V porovnání s C/C++ pak v Javě chybí bezznaménková čísla, příkaz goto nebo preprocesor. 2.2 J2ME SPECIFIKA CLDC a CDC Rozlišujeme dvě základní konfigurace J2ME: CLDC (Connected Limited Device Configuration) a CDC (Connected Device Configuration). Schéma vrstev a fungování aplikací na těchto konfiguracích je na obrázku 2-2, na nich pak pracují následující profily: profil MIDP (Mobile Information Device Profile), profil PDAP (PDA Profile), základový profil (Foundation Profile), osobní základ a osobní (Personal Basis, Personal), profil RMI, herní profil. Obr. 2-2 J2ME složení vrstev - 4 -

18 Název konfigurace Obsažené profily Popis CLDC MIDP, PDAP Konfigurace připojeného omezeného zařízení, typicky jejím mobilní telefon nebo PDA s pamětí kB, 16bitovým nebo 32bitovým procesorem, s nízkou spotřebou energie (většinou bateriově napájeno) a s netrvalým připojením k síti (většinou bezdrátově). CDC Osobní, osobní základ, RMI, herní profil, základový profil Tab. 2-1 Konfigurace připojeného zařízení zaměřující se na přístroje, které se svým výkonem řadí mezi CLDC a standardní PC, jako jsou dražší PDA, chytré telefony, webové telefony, rezidenční brány nebo Set-Top Boxy. CDC vyžaduje 2MB (obvykle i více), výkonnější procesory než u limitovaných zařízení. J2ME konfigurace a profily MIPD - Profil zaměřený hlavně na bezdrátová zařízení mobilní telefony, přidává síťové služby, součásti uživatelského rozhraní a místní úložný prostor. Minimální požadavky na přístroj jsou: display 96x54 pixelů, hloubka display 1bit (černo-bílý), 128kB dostupné paměti RAM, 8kB permanentní paměti pro uložení aplikačních dat, 32kB operační paměti pro javovskou haldu, obousměrné bezdrátové připojení. PDAP - Tento profil je podobný MIDP, byl vyvíjen pro PDA, klade vyšší nároky na display a paměť. PDAP byl dokončen mezi posledními a nabízí rozšíření MIDP o dva balíčky pro pohodlnější práci s daty a soubory. Základový profil - Tento profil rozšiřuje CDC o jádro Javy 2 verze 1.3 na tomto profilu pak staví ostatní profily CDC. Profily Osobní základ a Osobní - Tento profil obsahuje balíčky základového profilu a přidané AWT, Math, RMI a balíčky pro komunikaci javax.microedition.xlet a javax.microedition.xlet.ixc. Je tedy vhodný pro tvorbu Appletů a Xletů. Profil RMI - Tento profil přidává pouze balíček RMI pro vzdálené volání metod J2SE Herní profil - jak už název napovídá, měl sloužit k psaní herní softwaru, zde se ovšem vývojáři dostali do slepé uličky a vyhodnotili tento profil jako neperspektivní a tento program byl stažen z vývoje. [8] Knihovny tříd CLDC a odlišnosti od balíčků od J2SE Knihovna tříd CLDC je univerzální pro všechny zařízení na rozdíl pak od jednotlivých profilů i z tohoto důvodu je velmi omezená, obsahuje balíček javax.microedition.io (speciální funkce pro J2ME, tento balíček je velmi specifický a nemá svůj ekvivalent v J2SE, bude tedy blíže popsán v dalších částech) a výběr z tříd balíčků J2SE : java.io, java.lang, java.util. java.lang Třída Object přišla o metody finalize() a clone(). Chybějí třídy java.lang.float a java.lang.double. Není k dispozici třída java.lang.number, číselné třídy se odvozují od typu Object. Z java.lang.class odstraněny všechny metody související s reflexí. Omezení tříd System a Runtime byly odstraněny metody getproperties(), setproperty(), setproperties(), - 5 -

19 metody měnící zdroje a cíle vstupních, výstupních a chybových proudů, metody poskytující přístup ke knihovnám s nativním kódem a schopnost získat odkaz na správce SecurityManager a aktivního správce změnit. Vlákna odstraněny metody související s ThreadGroup, dále getname, setname, resume(), suspend(), stop(), destroy(), interrupt(), isinterrupted() a dumpstack(). Vyjímky a chyby ponechány pouze java.lang.error, java.lang.outofmemoryerror, java.lang.virtualmachineerror. java.util Pro práci s kolekcemi obsaženy třídy Hashtable, Stack, Vector, Enumeration. Zjednodušení tříd Date, TimeZone, Calendar java.io Oproti J2SE velmi zredukována. Obsahuje vstupní a výstupní proudy ByteArrayInputStream a ByteArrayOutputStream (nebo zabalené DataInputStream a DataOutputStream). Podpora znakového vstupu a výstupu InputStreamReader a OutputStreamWriter Přehled balíčků MIDP Jméno balíčku Popis javax.microedition.lcdui Třídy a rozhraní UI javax.microedition.rms RMS (Rekord Management systém) záznamový systém umožňující perzistenci dat javax.microedition.midlet MIDP definující typy podporovaných tříd javax.microedition.io Kolekce rozhraní definujících Generic Connection Framework (rámcový systém pro generická připojení) Java.io Standardní java IO třídy a rozhraní Java.lang VM třídy a rozhraní Java.util Standardní funkční třídy a rozhraní Tab 2-2 Přehled balíčků MIDP Aplikacím v Javě běžících na přístrojích MIDP se říká midlety. Tyto aplikace obsahují alespoň jednu třídu odvozenou od javax.microedition.midlet.midlet definované MIDP. Skupiny příbuzných midletů lze sdružovat do tzv. sad. Všechny midlety jsou zabaleny a instalovány na zařízení jako jediná entita, kterou lze odinstalovat pouze jako skupinu. Midlety v sadě sdílejí statické i běhové prostředí hostitelského prostředí. o javax.microedition.midlet.* Srdcem midletu je základní package javax.microediton.midlet.* se svojí třídou MIDlet. Tato třída umožňuje vytvořit, spustit, pozastavit a ukončit midlet. Nelze-li splnit požadavek aplikace, je vygenerována výjimka MIDletStateException. Třída má tři základní abstraktní metody, které musí být vždy definovány. Jsou to : a) public void startapp( ) je volána při každém přechodu midletu ze stavu paused state, tento přechod se děje i při samotném spuštěním programu. b) public void pauseapp( ) provede se při požadavku na přechod do paused state, např. při příchodu hovoru

20 c) public void destroyapp ( boolean uncoditional ) provádí se při ukončení projektu Tyto metody jsou určeny v konstruktoru hlavní třídy programu, která je rozšířením třídy javax.microedition.midlet.midlet. o javax.microedition.lcdui.* Dalším balíčkem nezbytným pro provoz midletu je javax.microedition.lcdui.* package se základními prvky, určujícími vzhled a základní funkčnost programu a umožňující vstup a výstup z programu. Jeho základní třídy jsou : a) Display, třída umožňující zprostředkovat informace na výstupním zařízení, každý midlet má unikátní ukazatel na tento objekt, vrací ho funkce getdisplay(). Další důležitá metoda je setcurrent (Displayable nextdisplayable), pomocí níž můžeme zobrazovat jednotlivé formuláře na display b) Displayable, třída je objektem, který může být umístěn na výstupní zařízení c) CommandListener, rozšíření určené pro příjem a zpracování požadavků uživatele, zadává je pomocí navigačních prvků, nelze zadávat textové či číselné hodnoty. Nezbytná metoda void commandaction ( Command c, Displayable d ), c udává příkaz, který je vyžadován a d nám udává ve kterém zobrazitelném prvku k požadavku došlo d) Screen, abstraktní třída, odvozena ze třídy Displayable, důležité odvozené podtřídy : Form, TextBox, List, Alert e) Ticker, třída, pomocí níž se zobrazí úzký pruh na display, který se kontinuálně po display posouvá (význam má v případě, kdy probíhající metoda zabírá delší časový úsek, můžeme uživateli např. zobrazit nápis pracuji ) f) Form, podtřída třídy Screen, jedná se o prázdnou oblast do které můžeme vkládat text nebo tzv. předměty Item, obsahuje metody pro jejich vkládání, odstranění a změnění. Každý prvek se může na formuláři vyskytovat pouze jednou, proto je pro opětovné vložení třeba prvek odebrat z formuláře předcházejícího, provádí-li se změny na aktuálním zobrazeném formuláři. Tyto změny se zobrazí automaticky, vlastní zařízení je provede samo ihned jak je to možné, pokud ale chceme zobrazit jiný formulář, musíme použít metodu setcurrent( ) třídy displayable. g) Textfield, třída reprezentující textové pole, tuto komponentu můžeme libovolně umístit do formuláře, dále editovat nebo číst její obsah. h) ChoiceGroup, pomocí této třídy můžeme realizovat výběrové menu Package javax.microedition.lcdui.* má samozřejmě mnoho jiných tříd, uvedené jsou jen ty nejpoužívanější, které sou využity pak k samotné implementaci ukázky. o javax.microedition.rms Jedná se o třídu sloužící pro uchování dat v telefonu i po ukončení aplikace nebo vypnutí telefonu. Data se ukládají ve formě záznamů pomocí objektu RecordStore, který je identifikován až 32 znakovým názvem case sensitive. Každý RecordStore může mít teoreticky nekonečně záznamů, prakticky je počet omezen pamětí telefonu. Pro snažší přístup k záznamům si lze pomoci třídami Hashtable a Enumeration. Dalšími metodami lze pak - 7 -

21 zjistit velikost jakou RecordStore zabírá, kdy byl naposledy změněn poslední záznam nebo kolik ještě zbývá volného místa pro další expanzi RecordStore Virtuální stroj VM Disponovat v CDLC standardním JVM pro J2SE, je prakticky nemožné. Už samotný běh aplikace Hello world! pod OS Windows vyžaduje alokaci přibližně 16MB paměti. V našich zařízeních se ale typicky setkáváme s prostředky 128KB paměti ROM a 32kB energeticky závislé paměti pro samotný běh programu, proto vznikl tzv. VM někdy dnes už nesprávně zvaný také KVM (Kilobyte Virtual Machine). VM vychází s původního JVM avšak ve značně redukované formě. Požadavky CLDC na hostitelský systém, kromě požadavků na paměť, jsou velice minimalizovány. CLDC předpokládá, že na hostiteli existuje nějaký operační systém, který umožňuje spuštění VM. Hostitelský přístroj může být pouze jedno-procesový, proto se žádá po VM, aby imitoval vícevláknové použití. Požadavky na display nebo prostředky pro vstup CDLC nemá. Důvodem je snaha o co největší univerzálnost, tyto požadavky pak definují konkrétní profily. Operace s plovoucí čárkou většina zařízení nepodporuje. VM tedy nemusí takové operace podporovat a odmítne je okamžitě při zavádění souborů class do paměti. To vede k těmto omezením : nelze deklarovat proměnné, konstanty ani objekty typu float nebo double, u metod pak tyto typy nesmí být argumentem ani návratovou hodnotou. Ve VM pak došlo k vynechání některých funkcí, které vychází z omezené paměti přístroje. Nejsou k dispozici balíčky java.lang.reflect, java.lang.ref. Balíček java.lang.object neobsahuje metodu finalize(). Není umožněn běh démonového vlákna. Omezeny byly také výjimky a volání nativního kódu. Z hlediska bezpečnosti není v CLDC možné, stejně jako v J2SE, víceúrovňový přístup k datům, proto zde vzniká prostředí tzv. sandbox. Aplikace běžící na VM si tedy doslova hrají na vlastním písečku a nemají práva zasahovat do nativního kódu nebo poškodit zařízení, na kterém běží Síťové možnosti J2ME Každé MIDP zařízení musí implementovat protokol http, ale to je tak vše, co je výrobce v síťové komunikaci povinen zajistit. I přesrto některé typy (např. od výrobců Siemens či Motorola) podporují sockety a některé dokonce i UDP datagramy. U standardní http komunikace mezi klientem (osobním počítačem) a serverem je PC vybaveno prohlížečem (IE, Firefox ), který odešle dotaz na adresu URL s případnými parametry. Server pak adekvátně odpovídá html dávkou, prohlížeč tuto dávku zpracuje a pak zobrazí příslušný obsah na monitor. U některých mobilních zařízení však žádný prohlížeč není k dispozici. Komunikace klient/server vypadá následovně, klient odešle na adresu URL požadavek a serverem je mu vrácena odpověď ve formě sekvence znaků, které musí aplikace sama zpracovat a vyhodnotit. Tomuto konceptu musí vyhovovat jak aplikace J2ME v mobilním zařízení tak i samotný server

22 2.2.6 Bezpečnost midletů Programátor midletů nemusí bezpečnost vůbec řešit, nemá k nim totiž žádné použitelné nástroje. J2SE disponuje mocnými prostředky pro bezpečnost (autorizovaný přístup, certifikace atd.), avšak tyto prostředky jsou velmi náročné na paměť, proto v J2ME vůbec nejsou. Jediné bezpečností opatření, které J2ME poskytuje, je, že midlety nemohou přistupovat k informacím ze zařízení, jako jsou telefonní seznam nebo kalendář. Žádný midlet také nemůže hostitelské zařízení jakkoli řídit nebo poškodit, pouze je možno ukládat a měnit data ve svém úložišti. Midlet tedy může poškodit jen sám sebe Struktura souborů a jejich význam Přehled důležitých souborů: Obr. 2-3 Schéma souborů tvořící JAR Typ souboru JAR Manifest.mf Soubory CLASS Soubory Java Zdroje RES (resources) JAD Popis Hlavní balící soubor, musí obsahovat všechny informace, které může midlet za běhu potřebovat. Balí se do něj soubor Manifest.mf, soubory typu class a zdroje (resources). Textový soubor obsahující informace, co vše je v souboru JAR uloženo. Přeložené soubory, v binární formě se komprimují do JAR. Tyto soubory tvoří programátorův kód, přístupovým bodem je soubor resp. třída dědící od javax.microedition.midlet.midlet ostatní třídy jsou pak volány z této třídy. Obsahuje-li aplikace více tříd dědící od MIDlet, pak se jedná o skupinu midletů. Za zdroje považujeme různé ikony, texty, obrázky, které midlet používá. Textový soubor obsahující informace o midletu podobné manifestu. Tento soubor se přikládá zvlášť, není součástí souboru JAR. Tab 2-3 Typy soborů a jejich popis Jak je vidět z obrázku 2-3 a tabulky 2-3, stěžejní jsou pro programátora soubory Java. Ostatní soubory Manifest.mf, JAD vytvoří překladač sám, ať už používáme KToolbar, NetBeans nebo jiné IDE. Běžně je zadáváme při tvoření nového projektu v daném IDE

23 2.2.8 Rozdíly mezi MIDP 1.0 a 2.0 Aby byl výčet vlastností kompletní je třeba ještě uvést některé rozdíly mezi profily verze 1.0 a 2.0. Novější verze byla vydána koncem roku 2002 třináct měsíců po první verzi. Všechny dnes prodávané telefony mají už buď vlastní operační systém (chytré telefony), levnější potom podporují MIDP 2.0. Avšak stále je mezi uživateli výrazně minoritní část telefonů navržených pro MIDP 1.0. Proto je na zvážení každého vývojáře na kolik využije nový profil a na jakou skupinu zákazníků se orientuje se svojí aplikací při výběru verze profilu. Já osobně jsem ukázku implementoval pro 2.0 a po té jí upravil a zjednodušil, aby fungovala i na telefonech s 1.0. Nová verze profilu byla obohacena o následující balíčky: javax.microedition.lcdui.game (třída pro vývoj her), javax.microedition.media (třída pro práci s multimedii), javax.microedition.media.control (rozhraní jež se používají k ovládání Playerů a přehrávání sekvencí tónů), javax.microedition.pki (rozhraní pro práci s certifikáty). HW požadavky byly navýšeny na paměť, 256 z 128kB trvalé paměti pro MIDP implementaci a 128 z 32kB dočasné runtime paměti. Nově musí být implementován také zvuk (schopnost přehrávat tóny) ať už softwarově či hardwarově. Pro síťovou komunikaci přibyla povinnost podpory protokolu https. Další novinkou je OTA (Over The Air), možnost instalovat, mazat nebo updatovat přes síť. V neposlední řadě též získat informaci zda bude aplikace na daném zařízení fungovat. Obr. 2-4 Schéma OTA 1. Klientské zařízení s discovery aplikací (browser či nativní aplikace) 2. Bezdrátová síť 3. Download server, poskytovatel, který má přístup do skladiště aplikací 4. Content Repositury poskytuje aplikace ke stažení a jejich popis Dále jeden RecordStore může být sdílen více midlety. Je umožněn podpis aplikace certifikátem, uživatel se pak může rozhodnout zda danou aplikaci spustí v důvěryhodné doméně, případně může omezit přístup k některým API funkcím. Tento popis jsem čerpal ze zdroje [13]. Kde je případně podrobnější popis zde uvedených změn

24 2.3 SHRNUTÍ J2ME V tomto úvodu byl popsán stručný přehled J2ME a její odlišnosti od J2SE. O J2ME by toho samozřejmě šlo napsat více, především o zavádění a překladu tříd, vývoji a běhu midletů, jejich instalaci na přístroj atd.. To však není cílem této práce, pro zájemce tedy doporučuji publikace [1], [2] a internetový zdroj [8]. Pro názornou ukázku J2ME byla zvolena aplikace messenger s vlastním serverem, která využije většinu možností J2ME od použití display, uživatelských menu, příkazů, http komunikace a RMS paměti. Prostředky pro pokročilejší grafiku využívané především v herních aplikacích nejsou v této práci použity z důvodu čitelnosti (rozsáhlosti) práce. Java hry by pak jako téma vystačily na samostatnou práci

25 3 UKÁZKOVOVÁ APLIKACE (MESSENGER) 3.1 ANALÝZA A NÁVRH ŘEŠENÍ Klient Messenger je aplikace, která slouží uživatelům pro vzájemnou komunikaci pomocí krátkých textových zpráv, obdobně jako fungují sms. Messenger bude pro komunikaci využívat GPRS technologii nebo případně jinou technologii spojující mobilní zařízení se světem internetu. Základní scénář : Uživatel se připojí k internetu se svým mobilním telefonem, zkontroluje a stáhne si nové zprávy ze serveru, poté odešle svoje zprávy na server a odpojí se od internetu (resp. vypne GPRS). Akce odeslání nebo přijetí zpráv mohou být také provedeny separátně. Zprávu pro odeslání si uživatel připraví před připojením k síti internet. Messenger je aplikace, která by měla umožnit uživatelům následující funkce : o Odeslat a přijmout zprávu ze serveru. o Kontrola, stažení nových zpráv ze serveru. o Adresář uživatelů + vkládání jmen uživatelů do zprávy o Ukládání rozepsaných, doručených či odeslaných zpráv Klient musí být schopen navázat spojení se serverem, autentizovat se pomocí uživatelského jména a hesla. Drtivá většina Java aplikací v mobilních zařízeních dnes komunikuje s internetem díky technologii GPRS pomocí http protokolu tak, že odešle sekvenci na server a čeká na odpověď. Vhodné je tedy data co nejvíce sjednocovat. Uživatelské jméno a heslo se odešle jako dvě sekvence ASCI znaků oddělené speciálním znakem, který se v uživatelském jménu ani heslu nemůže vyskytnout. Jako odpověď pak stačí jeden symbol (pro přehlednost číslo): nepřihlášen špatné uživatelské jméno nebo heslo (0), úspěšně přihlášen(1). Další přiložené číslo bude signalizovat počet nových zpráv. Dále pak je třeba dát přihlášení určitou dobu platnosti, aby se uživatel nemusel s každým požadavkem znova přihlašovat. To lze zajistit náhodně vygenerovanou sekvencí znaků (např. číslo session), která se uloží na straně klienta i serveru a bude odesílána s každým požadavkem. Server pak požadavek zpracuje a prověří sekvenci, zda je platná a prodlouží čas platnosti dané sekvence. Odeslání zprávy by mělo probíhat dle následujícího scénaře. Klient si nejprve připraví zprávu u sebe na telefonu napíše nebo vloží z adresáře jméno uživatele, kterému je zpráva určena, a vytvoří samotné tělo zprávy. To pak jako sekvenci ASCI znaků odešle na server, ze serveru pak dostane potvrzení o přijetí zprávy serverem. Při přijímání zprávy odešle klient požadavek na stažení zpráv. Zprávy mohou být stahovány ve dvou režimech a to stahovat a zobrazovat na display po jedné nebo stáhnout všechny a uložit do paměti telefonu (v tomto případě lze nastavit limit 10 zpráv, aby případně nedošlo k zahlcení telefonu). Funkci adresář využije uživatel k ukládání uživatelských jmen jiných uživatelů a jejich následnému vložení do těla zpráv. Základem adresáře je perzistentní paměť, do které se přistupuje třemi funkcemi uložení, smazání a editace uživatelských jmen odpovídající potřebám uživatele. Úložiště zpráv slouží uživateli k uchovaní přijatých zpráv, které si stáhne ze serveru ve větším počtu do paměti (druhá možnost je stahovat zprávy po jedné a zobrazovat je přímo na display). Další funkce je pak uložení jakékoliv zprávy do paměti tzn. uložení zprávy

26 z display, ať už se jedná o zprávu staženou ze serveru nebo vytvořenou uživatelem při psaní nové zprávy. Samozřejmostí by mělo být uživatelsky přátelské prostředí. Jednoduché, které nebude zbytečně plýtvat omezenými prostředky mobilního zařízení a zároveň splňovat všechny stanovené požadavky Server Server bude komunikovat s klientem resp. mobilní telefonem a adekvátně reagovat na jeho požadavky. Server by měl poskytovat následující funkce: o Autentizace, verifikace uživatele o Příjem a odeslání zpráv uživatele o Zachování zpráv na serveru do jejich stažení ze serveru Pro účely messengeru lze vybírat z různých technologií, pro server z těch nejběžnějších PHP a ASP. Tyto servery by dozajista obstojně zvládly nároky jednoduchého klienta. Ale pokud je klient psán v Javě, bude vhodné pro server zvolit také Java server. Jsou tu sice určité nevýhody např. tuto technologii provozuje méně providerů než např. zcela běžné PHP. Avšak pro budoucí případný rozvoj Java server skýtá daleko víc prostředků a možností Databáze Pro ukládání dat uživatelských jmen, hesel, zpráv a ověřovacích sekvencí je možné použít standardní databázi. Nejběžnější free (zadarmo) databáze, jednoduchá na správu, je MySQL. Co je třeba mít v databázi uloženo: o Ze strany uživatele : uživatelské jméno (username), heslo (password), počet nepřečtených zpráv (messages) o Pro autentizaci : ověřovací sekvenci (session_nr), dobu jejího vytvoření (date_created), její platnost (date_expired) a komu sekvence patří (usr_name) o Pro ukládání a rozesílání zpráv : adresát (recipient), odesilatel (sender), datum odeslání (date), tělo zprávy (text) a zda je zpráva přečtena (readed)

27 Z toho je vytvořen ER Model: Obr. 3-1 ER Model Dle tohoto modelu je vytvořena MySQL databáze, do které se připojuje pak vlastní Java server. 3.2 REALIZACE Potřebné programové vybavení Všechny programové nástroje použité v této práci jsou také obsaženy na přiloženém CD. J2ME Sun Java Wireless Toolkit -jedná se o univerzální nástroj pro překlad a testování aplikací v J2ME. Program stáhneme ze stránek výrobce : Při tvorbě této práce byla dostupná verze (DV) 2.5 pro Windows. Program je zdarma, pro stažení je třeba se zaregistrovat. K instalaci a vývoji aplikací J2ME je třeba mít na PC nainstalovaný J2SE Development Kit verze 5.0 nebo vyšší. Tento kit je dostupný na adrese : DV : Java SE Development Kit 6 Update 2 for Windows Platform. Instalace obou nástrojů je intuitivní a není třeba ji jinak komentovat. Pouze je třeba nainstalovat Java SE a po té až Wireless Toolkit. Vytváření projektů, jejich překlad a emulaci pak provádíme pomocí programu ktoolbar, dokumentace je součástí balíčku. Textový editor - pro psaní kódu a úpravu konfiguračních souborů je třeba jakýkoliv textový editor. Lze použít poznámkový blok. Vhodné je ale použít editor zvýrazňující Java syntaxi. K dispozici je např. prostředí NetBeans s Mobility Add-on pack, dostupné na adrese : Obdoba NetBeans je pak např. Eclipse nebo sunovské javovské prostředí JBuilder. Nebo samozřejmě postačí jednoduchý editor PSPad, který také zvýrazňuje syntaxi, dostupný : DV: Návody na instalaci na stránkách výrobců. Výhoda NetBeans je ve větší komplexnosti,

28 přehlednosti, nespočtu zjednodušujících funkcí pro editaci kódu a integrovaném překladači, nevýhoda je pak v jejich velikosti, nárocích na paměť oproti PSPad v kombinaci s ktoolbarem (nástroj pro překlad s emulátorem, součást Wireless Toolkitu), která má velkou výhodu v jednoduchosti a tím i menšími systémovými nároky na provoz. Osobně jsem používal nejprve PSPad s Ktoolbarem, při zvětšující se objemnosti kódu jsem pak přešel na NetBeans. Dokumentace jsou součástí instalačních souborů. Java server a databáze - volně ke stažení jsou dva nejpoužívanější servery : Sun Java System Application Server (DV: 9) a Apache Tomcat (DV: ). Sunovský server je vyspělejší a poskytuje více možností (transakce, Message Driven Bean, webovou službu, integrovaná databáze, atd.), ovšem je zase náročnější na systém. Tyto funkce bych pro klienta J2ME ani nebyl schopen využít. Pro moji ukázku jsem si vystačil s Apache Tomcat, volně ke stažení na adrese: K instalaci je samozřejmě třeba mít nainstalováno J2SE. Databázi lze použít tu nejběžnější open source MySQL. Volně ke stažení na adrese: (DV: 5). Dokumentace je součástí instalace. Pro snazší administraci databáze je dobré ještě nainstalovat PHP s phpmyadmin, podrobný návod na instalaci na CD ve složce Programove_vybaveni/phpMyAdmin. Pro psaní a překlad kódu serveru je pak optimální prostředí NetBeans (příp. JBouilder, Eclipse) zmiňované už výše Realizace databáze Databáze je vytvořena podle ER modelu z analýzy (obr. 3-1). Na realizaci použijeme následující SQL dávku : CREATE DATABASE `messenger` CREATE TABLE `login_log` ( `id` int(11) NOT NULL auto_increment, `session_nr` varchar(40) NOT NULL, `date_created` datetime NOT NULL, `date_expired` datetime NOT NULL, `usr_name` varchar(20) NOT NULL, PRIMARY KEY (`id`), UNIQUE KEY `session_nr` (`session_nr`) ) ENGINE=InnoDB AUTO_INCREMENT=61 DEFAULT CHARSET=latin1 AUTO_INCREMENT=61 ; -- CREATE TABLE `messages` ( `id` int(11) NOT NULL auto_increment, `sender` varchar(20) NOT NULL, `recipient` varchar(20) NOT NULL, `text` longtext, `date` datetime NOT NULL, `readed` binary(1) NOT NULL default '0', PRIMARY KEY (`id`) ) ENGINE=InnoDB AUTO_INCREMENT=9 DEFAULT CHARSET=latin1 AUTO_INCREMENT=9 ; CREATE TABLE `users` ( `id` int(11) NOT NULL auto_increment, `username` varchar(20) NOT NULL, `password` varchar(20) NOT NULL,

29 `messages` int(11) NOT NULL default '0', PRIMARY KEY (`id`), UNIQUE KEY `username` (`username`) ) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=latin1 AUTO_INCREMENT=4 ; Java soubory serveru Obr. 3-2 Přehled souborů serveru Server obsahuje dvě základní package data a servlets, tyto pak obsahují následující třídy. Package servlets je složena ze tří servletů je určena pro komunikaci s klientem, pro příjem parametrů a jejich zpracování. Pro komunikaci s databází pak slouží package data. Jméno MyServlet RecieveMessage SendMessage DateTime Login Význam Servlet pro logování uživatele Servlet přijímající zprávy od uživatele Servet odesílající zprávy uživateli Třída pro práci s časem Třída pracující s databázi při logování a verifikace uživatelů Message Třída pracující se zprávami uživatelů, uložení, výběr zpráv z databáze Tab 3-1 Přehled tříd serveru servlets.myservlet - uživatel se na něj dotazuje pomocí URL a předává parametry pomocí metody GET. Parametry jsou usr (jméno uživatele) a passwd (heslo). Servlet obsahuje login instanci třídy Login, pomocí které uživatele přihlásí. Při úspěšném přihlášení pomocí login je přidána session do databáze, aktuální čas pro session je získán z datetime

30 instance DateTime. Jako odpověď klientovi tento server odesílá konstanty FAILED nebo OK, pak následuje počet nových zpráv, na konec je přidáno číslo session. servlets.recievemessage - servlet sloužící pro příjem zpráv od klienta využívá třídu Login pro verifikaci uživatele resp. jeho session. Parametry jsou recipient (příjemce zprávy), sender (odesílatel), text (samotné tělo zprávy) a session (pro ověření uživatele). Datum odeslání se získá z datetime. Zprávu pak uloží do databáze, zároveň se uživateli inkrementuje hodnota počtu nových zpráv v databázi. Jako odpověď je pak konstanta : OK - zpráva úspěšně přijata do systému, BAD_RECIPIENT špatný příjemce, uživatel není v databázi, NOT_VERIFIED uživatel nebyl verifikován, je nutno se znova přihlásit. servlets.sendmessage - pomocí tohoto servletu se odesílají zprávy uživateli. Pro zvolení způsobu klient pošle parametr choice. Konstanta RECIEVE_MESSAGE_TO_INBOX je hromadné odeslání do paměti telefonu, RECIEVE_MESSAGE_DISPLAY je odeslání jedné zprávy na display telefonu, CHECK_NEW_MESSAGES je dotaz na počet nových zpráv. Další parametry jsou pak usr a session_id pro verifikaci uživatele. Dále může vrátit také konstantu NOT_VERIFIED indikující, že uživatel není přihlášen. data.datetime - Tato třída slouží pro operace s časem. Obsahuje metodu String getdate(), která vrací aktuální čas v daném formátu. Další metoda je String getmaxdate(), vrací čas o hodinu větší než je aktuální, což slouží jako hranice, kdy vyprší platnost session. Poslední metodou je boolean comparetime(string time), která vrací true, pokud čas předaný řetězcem je menší než aktuální čas. Použito pro ověřování platnosti session. data.login - Login komunikuje s databází pomocí objektů conn typu Connection, stat typu Statement pro vytvoření spojení a rs typu ResultSet pro zpracování výsledků jednotlivých dotazů. Třída Login obsahuje metodu void open() otevírající spojení a k ní opačnou void close(). Další metody slouží k ověření uživatelského jména, ověření platnosti session, přidání session do databáze a získání počtu zpráv daného uživatele. data.message - Třída sloužící k manipulaci se zprávami. Obsahuje metodu boolean savemessage (String message, String sender, String recipient, String date), která ukládá se zprávy do databáze, vrací false v případě, že příjemce zprávy není v databázi. Při uložení zprávy inkrementuje příjemci počet nepřečtených zpráv. Další metodu je int checknewmessage(string usr) zjišťující počet nových zpráv uživatele. Pro vytáhnutí zprávy z databáze se používá metoda String[] loadnewmessage (String user), tato metoda získá z databáze první nepřečtenou zprávu a označí jí jako přečtenou, hodnoty ze zprávy pak ukládá do pole řetězců. Příjemci zprávy se poté dekrementuje počet nových zpráv v databázi

31 3.2.4 Java soubory klienta Obr. 3-3 Přehled souborů klienta Projekt obsahuje jednu package myclasses, která obsahuje všechny třídy midletu : Jméno MainCl http WorkClass Inbox Archive DataStorage Význam Hlavní třída obstarávající běh midletu Třída pro spojení s internetem pomocí http Pomocná třída pro práci s řetězci Třída pro ukládání a načítání zpráv Třída pro ukládání a načítání zpráv Třída pro ukládání a načítání pomocných údajů, např. přihlašovacích nebo čísla session Tab. 3-1 Přehled tříd klienta MainCl -hlavní třída obsahující samotný běh midletu, jednotlivé formuláře, příkazy a metody na jejich obsluhu

32 Formuláře : o menuform - uvítací nápis s informací o verzi midletu a příkazy menu o loginform - textová pole pro přihlašovací údaje, příkaz submit pro přihlášení o conecting formulář s tickerem, informací o stavu midletu, který se právě připojuje o statusform pro zobrazování výsledku operací (uložení, stažení, odeslání zpráv, reset paměti atd.) o writeform textová pole pro napsání a odeslání zprávy o recieveformmenu uživatel dostane na výběr tři možnosti požadavků na zprávy, stáhnout vše do paměti, stáhnout po jedné na display zařízení, dotaz na počet nových zpráv o recieveform formulář pro zobrazení jedné přijaté zprávy o inboxform seznam přijatých zpráv pomocí prvku choicegroup o inboxmessageform pro zobrazení vybraných zpráv z inboxform o archiveform a archivemessageform obdoba inboxu pro zprávy uložené uživatelem o addressbookform seznam uživatelů s možností vložit jméno uživatele do těla zprávy k odeslání o adduserform možnost přidání nového uživatele do seznamu o settingsform možnosti nastavení paměti, resetování Základní navigace příkazů: Obr. 3-4 Navigace příkazů EXIT : řádné ukončení aplikace LOGIN : uživatel vyplní svoje přihlašovací údaje a odešle je příkazem submit vrácená odpověď je buď nepřihlášen (špatné jméno či heslo) nebo úspěšně přihlášen pak je součástí odpovědi i počet nových zpráv a číslo session, které se ukládá do paměti. Údaj o výsledku se zobrazí do formuláře statusform. WRITE MESSAGE : uživateli se zobrazí formulář pro zadání textu zprávy a příjemce, adresáta může vložit pomocí příkazu addressbook z adresáře nebo zadat ručně. Příkazem sendmessage se zpráva odešle a příkaz savemessage může být zpráva uložena do archívu. RECIEVE MESSAGE : tímto příkazem se otevře menu pro příjem zpráv recievemenuform, kde uživatel najde možnosti jak stáhnout nové zprávy ze serveru. recieveall stáhne zprávy všechny a uloží je do paměti telefonu, recieveone stáhne zprávu a zobrazí na display telefonu, check se pouze dotáže na počet nových zpráv

33 INBOX : přístup do paměti kam se stahují zprávy ze serveru, zprávy se zobrazují jako seznam CheckBoxem, tyto zprávy lze pak otevřít v novém formuláři inboxmessageform a dále s nimi manipulovat. Příkaz deletemessageinbox smaže zprávu, savetoarchivefrominbox zprávu uloží do archívu. ARCHIVE : slouží pro uložení zpráv z Inboxu nebo rozepsané z WriteForm. V archívu pak lze zprávy otevírat příkazem openmessagearchive ve formuláři archiveform nebo příkazem deletemessagearchive je mazat. SETTINGS : slouží pro reset čtyř oddělených pamětí, adresáře, inboxu, archívu a pomocných dat. Hlavní třída dědí od rozhraní Runnable, používá tedy více vláken. Metoda void run() je použita na navázání spojení ze serverem, které zabírá více času. Při tomto spojení se na display objevuje ticker s nápisem connecting, po přijetí odpovědi se pak běh vrací zpátky na jedno vlákno. V této metodě se větví program pomocí proměnné choice, aby program věděl na co odpověď ze serveru přišla jak jí má zpracovat a do jakého formuláře zobrazit. Zajímavá je také struktura této hlavní třídy. V první časti resp. konstruktoru jsou inicializovány všechny formuláře naplní se příslušnými prvky. Výjimku tvoří pouze prvky choicegroup, které se inicializují až po načtení příslušných hodnot z paměti. Do samotného běhu se pak dostáváme pomocí metody startapp(), která zobrazí uživateli uvítací menu spojené s hlavními příkazy aplikace. O další běh aplikace se pak stará listener CommandAction, který zpracovává jednotlivé příkazy, jedná-li se o příkaz nevyžadující spojení s internetem je v těle podmínky přímo zobrazen příslušný formulář, do kterého se případně načtou data z paměti. Naopak jedná-li se o příkaz vyžadující spojení s internetem, v těle podmínky se poskládá URL a je spuštěno druhé vlákno. Jedno obsluhuje display zatímco probíhá komunikace se serverem. Druhé odešle dotaz na server a čeká na odpověď. Poté co ji dostane, běh se vrací zpět na jedno vlákno. Http - tato třída slouží pro spojení s internetem. Odesílá dotaz na danou adresu serveru, ze které pak dostane odpověď. Obsahuje pouze jednu metodu connectget, kde argumentem je URL a návratová hodnota odpověď ve formě řetězce. WorkClass - jak už název napovídá jde o pracovní pomocnou třídu pro práci z řetězci a získání aktuálního času. Aktuální čas obstarává metoda String getdate(), metoda String convertspaces(sourcestring) transformuje mezery ze zdrojového řetězce na sekvenci %20, která v URL zastupuje znak mezery. Znak mezery není v URL povolen. Metoda String[] getdata() je určena na zpracování odpovědi ze serveru, ta má tvar slov oddělených znakem 10 ASCI tabulky, vrací první slovo a zbytek řetězce. Inbox a Archive - jsou to třídy pracující s perzistentní pamětí. Na začátku běhu midletu se pouští metoda void readrms(), kdy se načtou záznamy z paměti do objektu typu Hashtable, v této formě se s nimi pak dále pracuje, z toho objektu se pak i obráceně zprávy ve formách byte polí zase ukládají. O to se stará metoda void flushrms(), pouští se při každém požadavku na uložení dat z midletu. V třídách jsou ještě obsaženy metody na vytáhnutí zpráv, dle indexu v paměti String getmessage(int nr), uložení zpráv na setmessage (String from, String body, String date), seznamu zpráv String [] listofmessages(), smazání zprávy void deletemessage(int nr), nechybí ani metoda pro reset(). DataStorage - tato třída obsluhuje paměť pro pomocná data. Na tomto stupni vývoje aplikace se pomocí ní ukládá uživ. jméno, heslo a číslo session. Při dalším rozšiřování by se pak pomocí ní mohli ukládat další pomocné údaje jako jsou různá nastavení (zda si pamatovat či nepamatovat přihlašovací údaje)

34 AddressBook - třída pracující též s RMS pamětí slouží pro ukládání uživatelů do paměti. Obsahuje obdobné metody jako DataStorage, Inbox a Archive. 3.3 TESTOVÁNÍ Emulátory Pro testování byly zvoleny emulátory od dvou velkých výrobců dneška od firmy Sony Ericsson a Nokia. Z lze stáhnout Sony Ericsson SDK (DV: 2.5 Beta) obsahující MIDP 1.0 a 2.0. Z lze pak stáhnout emulátory pro jednotlivé konkrétní modely telefonů Nokia. Já jsem zvolil Series 40 5th Edition SDK Zkušební data Pro testování je databáze naplněna zkušebními daty Uživatelské Heslo Počet nepřečtených zpráv jméno test test 0 test1 test1 0 Tab. 3-3 Zkušební data Ostatní data jako jsou samotné zprávy a čísla session nebylo třeba do databáze vkládat, byla vložena při samotném testování Dva uživatelské scénáře Pro protestování aplikace byly zvoleny dva následující uživatelské scénáře. 1. Uživatel test se nejprve pokusí přihlásit se špatným uživatelským jménem a pak špatným heslem, přihlášení se nezdaří proto se přihlásí znovu už se správným uživatelským jménem a heslem test. Dostane hlášení, že nemá žádnou novou zprávu. Poté prověří funkčnost adresáře vloží do něj 5 jmen a dvě vymaže z prostřed a začátku seznamu. Pak odešle dvě zprávy uživateli test1. Třetí zprávu si rozepíše a uloží do archívu. Pak telefon vypne a ověří zda uživatelské jméno a heslo byly uloženy do paměti telefonu a zkontroluje archív jestli je v něm jeho rozepsaná zpráva a odešle ji uživateli test1. 2. Uživatel test1 se přihlásí, obdrží zprávu o 3 nových zprávách, rozhodne se nejprve jednu zprávu přijmout na display a pak přijmout 2 zbylé zprávy najednou do paměti telefonu, pak otevře inbox přečte si zprávy, jednu smaže a jednu přesune do archivu. Tyto dva uživatelské scénáře byly testovány na emulátoru modelu Sony Ericsson T610 (profil MIDP 1.0 CLDC 1.0), na modelu Sony Ericsson K750 (profil MIDP 2.0 CLDC 2.0) a na emulátoru Nokie modelové řady 40, na kterém byl simulován i příchozí hovor při běhu aplikace. Při testování byl hovor byl přijat a ukončen bez vlivu na běh aplikace

35 Testování dle zadaných kritérií proběhlo bez většího problému. Jediný problém nastal při resetování paměti na emulátoru Sony Ericsson K750, kdy paměť nebyla smazána vůbec nebo jen částečně (uživatelé nebo zprávy museli být mazáni po jednom) Tento jev se na Nokii a ani na Sunovském emulátoru nevyskytoval. Osobně to přisuzuji nedostatečnému promazání v paměti počítače při běhu tohoto emulátoru, protože tento se jev se objevoval velmi nahodile (cca. každé sedmé spuštění) a při restartu emulátoru a počítače už se nevyskytl Kompatibilita Největší odlišnosti jednotlivých modelů jsou v počtu tlačítek a velikosti display. Počet tlačítek ovlivňuje počet zobrazených příkazu na display zpravidla dva nebo tři, pokud je příkazů více než je telefon schopen zobrazit zabalují se příkazy do seznamu jmenujícího se menu nebo options. Tyto rozdíly nemají zásadní vliv na funkčnost aplikace. Nejsložitější formulář aplikace obsahuje tři objekty typu TextField. Tudíž velikost, počet barev display nepůsobí podstatné změny na vzhled aplikace. Změny by nastaly, pokud by byla použita třída Canvas pro pokročilejší grafické rozhraní. Pro tento program nemá smysl. Další rozdíl je v MIDP 1.0 a MIDP 2.0. Ericsson K750 s verzí 1.0 nepodporuje metodu void deleteall u třídy Form. Aplikace byla nejprve navrhnuta na pro MIDP 2.0, proto došlo k následujícím úpravám, aby program fungoval i na verzi 1.0. Vynechání deleteall() je oštřeno citlivějším vkládáním prvků do formulářů pomocí podmínek, které zjišťují zda daný prvek už je ve formuláři obsažen. Další nepodporovaná metoda je setpreferredsize(int x, int y) u objektu TextField, proto byla vypuštěna. Textová pole mají velikost zadanou konstruktorem. Na straně serveru existují odlišnosti. Program je psán pro Apache Tomcat, ten při výstupu metodou println (String out) dává za výstupní sekvenci znak 10 ASCI tabulky. Program byl testován i na serveru ovšem tento server používá jiné oddělující znaky, což má zásadní vliv na funkčnost systému. Proto je možné, že při použití jiného serveru než Apache Tomcat aplikace nemusí správně fungovat. Řešení by pak bylo závislé na konkrétním serveru s úpravou jeho výstupu

36 4 ZÁVĚR Tato práce zpracovává přehled problematiky J2ME jejího vývoje a odlišnosti od J2SE. Při samotném programování a překladu aplikace jsem pak objevil několik rozdílů mezi MIDP 1.0 a 2.0, na které neupozorňovala žádná literatura. Při testování jsem si všiml několika rozdílů ve vzhledu aplikace způsobených tlačítky a display různých typů telefonů. Jako možné vylepšení bych zvolil modifikaci aplikace pro konkrétní modely telefonů a vybavit ji grafickým rozhraním v závislosti na display telefonů. Dále pak program přizpůsobit na dnes používané standardní messengery jako jsou MSN, ICQ a jiné. Lepší vylepšení by pak mohlo být umožnění odesílání souborů (fotek, videa, mp3) Podobné aplikace již na trhu existují a moje aplikace se s nimi dá srovnat jen v principu fungování klienta. Příkladem je cmessenger z firmy Cleverlance. Lepší aplikace s více funkcemi a grafickým rozhraním poskytuje pak Jimm ICQ. Tyto programy poskytují daleko více možností než má moje aplikace, např. zobrazují kteří členové jsou online, away, offline a jiné. Proto se domnívám, že tato práce spíše může sloužit jako učební pomůcka v českém jazyce začínajícím J2ME programátorům, než pro další vývoj a umístění na trh. Práce na tomto projektu byla pro mne velikým přínosem, rozšířil jsem si znalosti v dalším odvětví Javy a to jak verze pro mobilní zařízení tak i práce se servlety. Další cenné zkušenosti jsem také nabral při vyhledávání a samostatné práci s různými dokumentacemi použitých nástrojů

37 5 SEZNAM LITERATURY [ 1 ] J2ME V KOSTCE Pohotová referenční příručka, Kim Topley, Grada Publishing, a.s., 2004, překlad Pavel Makovec [ 2 ] WIRELESS J2ME Platform Programming, Vartan Piroumian, Sun Microsystems, Inc., 2002 [ 3 ] UČEBNICE JAZYKA JAVA, Pavel Herout, Kopp, 2004 [ 4 ] Historie a vývoj jazyka Java, Luděk Novotný, 2003, [ 5 ] History of Oak and Java [ 6 ] Programujeme v J2ME, PC Svět, Václav Hodek [ 7 ] Vývoj J2ME aplikací, interval.cz, [ 8 ] Dokumentace SUN k J2ME, MIDP, [ 9 ] Web společnosti Nokia s fórem a nástroji pro developery [ 10 ] Web firmy Sony Ericsson s nástroji pro developery [ 11 ] Programujte - seriál Java, [ 12 ] Oficiální web jazyka Java, [ 13 ]

38 A. SEZNAM POUŽITÝCH ZKRATEK : API Aplication Programing Interface CDC Connection Device Configuration CLDC Connection Limit Device Configuration DV Dostupná verze při tvorbě této práce HW Hardware IDE Integrated Development Enviroment IE Internet Explorer IO Input/Output vstup/výstup J2EE Java 2 Enterprise Edition J2ME Java 2 Micro Edition J2SE Java 2 Standard Edition JAD Java Application Descriptor JAR Java Archive File JDK Java Development Kit JVM Java Virtual Machine MIDP Mobile Information Device Profile OTA Over The Air PC Personal Computer PDA Personal Digital Assistant PDAP PDA Profile RAM Random Access Memory RMI Remote Method Invocation RMS Record Management System SE Special Edition UI User Interface URL Unique Resource Locator WEB World Wide Web

39 - 26 -

40 B. UŽIVATELSKÁ PŘÍRUČKA INSTALACE Návod na instalaci Apache Tomcat serveru, MySQL databáze a emulátorů jsou na přiloženém CD. Klient je nastaven na URL při změně adresy nebo portu serveru je třeba změnit i tuto adresu přímo v nepřeloženém kódu ve třídě MainCl. Dále před spuštěním aplikace je třeba vytvořit a naplnit databázi, SQL dávka je součástí práce i CD. Samotný program lze spouštět jak na emulátorech tak i přímo na telefonu. Pro přenos aplikace do telefonu je nutno použít patřičný program v závislosti na výrobci telefonu např. Nokia PC Suite nebo některý z komerčních produktů jako je MobilEdit, tyto už nejsou součástí CD. SAMOTNÉ POUŽÍVÁNÍ APLIKACE Po spuštění aplikace se na telefonu zobrazí uvítací zpráva s informací o verzi aplikace s volbou Menu nebo Options, záleží na konkrétním modelu telefonu. Obr. B-1 Uživatelská příručka - spuštění aplikace

41 LOGIN Přihlášení se do systému provedeme volbou login, zobrazí se dvě okna, do kterých vložte svá přihlašovací data, pokračujte příkazem SUBMIT. Na display se pak zobrazí formulář s výsledkem pokusu o přihlášení, dále je možno pokračovat volbou libovolného příkazu z menu. Obr. B-2 Uživatelská příručka - přihlášení uživatele ODESLÁNÍ ZPRÁVY Pro odeslání zprávy je třeba být přihlášen a to kratší dobu než jednu hodinu. Nejprve je třeba zprávu napsat volbou WRITE MESSAGE, vyplňte textové pole příslušnými hodnotami a pak pokračujte volbou SEND MESSAGE. Obr. B-3 Uživatelská příručka - vytvoření/odeslání zprávy Obsah těla zprávy lze vymazat příkazem CLEAR FORM, recipient nelze vymazat, lze jen nahradit uživatelem z adresáře nebo ručně smazat

42 ADRESÁŘ Do adresáře se lze dostat příkazem ADDRES BOOK z formuláře pro psaní zpráv, příkazem ADD USER, přidáme uživatele do adresáře, DELETE USER označeného uživatele smaže a příkaz INSERT USER označené uživatele vloží do zprávy. Obr. B-4 Uživatelská příručka - adresář PŘÍJEM ZPRÁVY Přijmutí zprávy je možné po přihlášení a to pokud uživatel není po přihlášení více jak hodinu neaktivní. Do menu pro příjem zpráv slouží volba RECIEVE MESSAGES, zde jsou tři možnosti : stáhnout všechny zprávy ze serveru do paměti RECIEVE ALL, při úspěšném stáhnutí se zobrazí hláška Messages were saved, dále stáhnout pouze jednu na display nebo odeslat dotaz na počet zpráv na serveru. Obr. B-5 Uživatelská příručka - příjem zprávy

43 INBOX & ARCHÍV Přijaté zprávy po příkazu RECIEVE ALL se ukládají do paměti inbox. Příkazem SAVE MESSAGE nebo SAVE TO ARCHIVE se ukládají zprávy do archívu. Zprávu lze uložit z inboxu nebo rozepsanou zprávu z write formuláře. Z archívu příkazem SEND MESSAGE lze zprávu otevřít ve formuláři write a dál jí editovat případně odeslat. Obr. B-6 Uživatelská příručka - inbox & archív SETTINGS Vymazání pamětí telefonu se provádí příkazy RESET MEMORY, ADDRESS BOOK, INBOX, OUTBOX. Obr. B-1 Uživatelská příručka - reset pamětí