TARTALOMJEGYZÉK 1 BEVEZETÉS MIÉRT ÉPPEN JAVA MIDP 2.0? A JAVA NYELV LEGFŐBB TULAJDONSÁGAI MIT ÍGÉR A MIDP 2.0?...

Átírás

1 TARTALOMJEGYZÉK 1 BEVEZETÉS MIÉRT ÉPPEN JAVA MIDP 2.0? A JAVA NYELV LEGFŐBB TULAJDONSÁGAI MIT ÍGÉR A MIDP 2.0? ALKALMAZOTT TECHNOLÓGIÁK A JAVA 2 MICRO EDITION (J2ME) A Connection Limited Device Configuration (CLDC) ismeretetése A K virtuális gép (KVM) A MIDP MID alkalmazás típusok: MIDP könyvtárak ALKALMAZÁSOK, MIDLETEK Az alap MIDlet: A Midlet Suit MIDlet életciklusa Perzisztens tárolás Felhasználói felület Fejlesztőkörnyezetek TERVEZÉS A FELADAT ISMERTETÉSE TERVEZÉSI MINTÁK A Model-View-Controller (MVC) A Smart Ticket Sample Application (STSA) A STSA funkcionalitásai A STSA alkalmazásról röviden: TERVEZÉSI SZEMPONTOK ÉS ELVEK A kliens és a szerver kapcsolata Üzenetküldés Az üzenetküldés formájának tervezése Bináris üzenetek: XML üzenetek: Kommunikáció biztonsága Műveletvégzés szálakkal SZÁMÍTÁSTECHNIKAI ONLINE SHOP ALKALMAZÁS (SPECIFIKÁCIÓ) Az alkalmazással szemben támasztott követelmények A kívánt funkcionalitás ismertetése A kliens képernyőtervei

2 TARTALOMJEGYZÉK Adatkezelés a kliensen A szerver A Kliens és a szerver AZ ALKALMAZÁS NÉHÁNY EGYSÉGÉNEK MEGVALÓSÍTÁSA KATEGÓRIÁK KÉPERNYŐ A VIEW-BAN A VIEWCONTROLLER ADATTÁROLÁS A MODEL-BEN A SZERVER EREDMÉNYEK ÖSSZEFOGLALÁS, ÉRTÉKELÉS TOVÁBBFEJLESZTÉSI LEHETŐSÉGEK IRODALOMJEGYZÉK

3 BEVEZETÉS 1 Bevezetés Mint azt a tartalmi összefoglalóban említettem, diplomamunkám célja egy Java MIDP 2.0 alkalmazás, azon belül egy online shop kliens és szerver megtervezése és implementálása a technológia megismerése után, majd annak tesztelése. A dokumentumban igyekszem megismertetni munkámat az olvasóval lépésről lépésre, a technológiák, módszerek megismerésétől a tervezésen át egészen a kliens teszteléséig. 1.1 Miért éppen Java MIDP 2.0? A Sun Microsystems honlapján közzétette a Java környezet kifejezetten mobil eszközök számára kialakított változatának legújabb verzióját. Az új Java Mobile Information Device Profile (MIDP) 2.0 átdolgozott felhasználói felülettámogatással, fejlesztett hanggenerátor képességekkel és újabb biztonsági funkciókkal büszkélkedhet. A MIDP 2.0 támogatja a push-technikát is, amelynek segítségével az ún. MIDlet-alkalmazások automatikusan átvihetők a megfelelő végberendezésekre, például mobiltelefonokra SMS-en vagy WAP-on keresztül is. Az új MIDP a biztonság terén is jelentős fejlődést hoz, hiszen már beépített támogatást tartalmaz az SSL, az azon alapuló HTTPS és a vezetéknélküli eszközökben alkalmazott WTLS protokollhoz is. 1.2 A Java nyelv legfőbb tulajdonságai Könnyen elsajátítható. Ez a megállapítás akkor helytálló, ha valaki jártas a C++ programozási nyelvben. A Java nyelv szintaxisa ugyanis nagyban támaszkodik a C és a C++-ban már megszokott szintaxisra. Objektum orientált. A Java lényegében a C++ objektumorientált tulajdonságait tartalmazza. Létrehozhatunk objektumokat, azaz egyes osztályokba tartozó egyedeket. Osztályok definiálásánál felhasználhatunk már meglévő osztályokat, az új osztály (a leszármazott) örökli a szülő adatait, eljárásait. Az eljárások hívásánál a meghívott módszer futási időben, objektum aktuális típusának megfelelően kerül kiválasztásra (virtuális módszerek, polimorfizmus). Az egyes osztályokban definiált változók és eljárások láthatóságát a C++-ban megismert módon - private, protected és public - lehet megadni. Eltérést jelent a 3

4 BEVEZETÉS C++-hoz képest, hogy a Jávában a beépített, egyszerű adattípusú - numerikus, logikai és karakter típus - változók kivételével minden objektum; az egyetlen összetett adattípus, a tömb (array) teljes értékű osztályként viselkedik. A program nem tartalmaz globális változókat és globális eljárásokat, minden adat és eljárás valamilyen objektumhoz, eljáráshoz kötődik. Architektúra-független és hordozható. Ezen cél elérése végett a Java nyelv nem tartalmaz architektúra- vagy implementációfüggő elemeket. A C nyelvvel ellentétben a beépített adattípusok (pl. int) mérete - tárolásához szükséges memória mérete, a típus értelmezési tartománya - nyelvi szinten meghatározott. Ahhoz, hogy a lefordított program változtatás nélkül futtatható legyen különböző hardver architektúrákon, a fordítóprogram a programot nem egy konkrét processzor gépi kódjára, hanem egy képzeletbeli hardver - virtuális gép (Virtual Machine) - utasításrendszerére fordítja le. Az így létrejött közbülső, ún. Byte kódot töltjük le a célarchitektúrára, ahol a virtuális gépet megvalósító program értelmezi és hajtja végre. Egy új architektúrán akkor futtathatók a Java programok, ha már implementálták rá a virtuális gépet, beleértve a rendszerkönyvtárakat is. Többszálú. A programok jelentős része párhuzamosan végrehajtható részletekre - vezérlési szálakra - bontható. Így jobban kihasználható a számítógép központi egysége, a programok a külső - például felhasználói - eseményekre gyorsabban reagálhatnak. A többszálú programozáshoz a Java nyelvi szinten biztosítja az automatikus kölcsönös kizárást: szinkronizált (synchronized) módszerek vagy utasítások, valamint a szálak létrehozásához, szinkronizációjának megvalósításához a rendszerkönyvtár tartalmaz egy ún. Thread osztályt. Hozzáférhető. Nem elhanyagolható tulajdonság, hiszen a Java nyelv elterjedéséhez nagymértékben hozzájárult ez is. Számos specifikáció, forráskód, ingyenesen elérhető. A Sun Microsystems ugyanakkor számos példaprogramot, tervezési mintákat, egyéb dokumentumokat, és nem utolsó sorban fejlesztő környezetet is biztosít számunkra. 4

5 BEVEZETÉS 1.3 Mit ígér a MIDP 2.0? A Java támogatói azt remélik, jelenlegi pozíciójukat az új, elődjénél sokkal robosztusabb MIDP 2.0 megjelenésével tovább erősíthetik, és a közeljövőben minél több MIDP 2.0-alapú mobiltelefon, illetve alkalmazás jelenik meg a piacon. Bár a MIDP új változata sokkal erőteljesebb hardvert igényel, az új megoldással olyan alkalmazások fejleszthetők, amelyek jelentősen megnövelik a készülékek értékét. Ahogy a mobiltelefonok ára ráadásul tovább esik, a többletköltségek lecsökkennek, a készülékek fejlett képességeiknek köszönhetően pedig várhatóan igen népszerűek lesznek. A SUN a MIDP 2.0 gyors elterjedésére számít a vezető mobilgyártók, mint a Nokia, Motorola, Siemens, Sony-Ericsson, és Samsung termékeinek körében. Várakozásaik szerint egyre több gyártó fog MIDP 2.0 alapú készüléket kiadni a közeljövőben. Az első MIDP 2.0 támogatású eszközök 2003 nyarán jelentek meg a piacon, és azóta népszerűségük folyamatosan növekszik. Az új felhasználói felület még nagyobb portabilitást, interaktivitást, és bővíthetőséget nyújt. Ezzel egy időben maximálisan kihasználhatóvá váltak a mobiltelefon készülékek grafikai- és audio képességei, valamint jelentősen növekedett az alkalmazások biztonsága. A szoftverfejlesztők az új mobil Java verzióval hatékonyabban, és olcsóbban fejleszthetnek rendkívül ütőképes mobiltelefon alkalmazásokat. A "sprite" objektumok támogatása lehetővé teszi, hogy a fejlesztőknek ne kelljen minden egyes képpontot külön kezelniük, hanem a karaktereket és egyéb grafikai elemeket egyszerűen mozgathassák a kijelzőn. A MIDP 2.0 felhasználói felülete lehetővé teszi a fejlesztők számára, hogy teljes mértékben elképzeléseiknek megfelelően alakítsák alkalmazásaik kinézetét és kezelését. A megoldás szintén fontos eleme, hogy szabványos módszert kínál a programok mobilhálózaton keresztüli letöltéséhez, mivel a mobilszolgáltatók elsősorban fizetős szolgáltatásként, bizonyos díj ellenében letölthető alkalmazásként tervezik biztosítani a különféle Java-alapú programokat, amelyet a felhasználó egyenlegének rovására, igénye szerint tölthet le készülékére. Jelentős előrelépés tapasztalható az internetes szolgáltatások terén is, a web elérése egyre hatékonyabb. Az új, fejlett, nagyméretű kijelzővel ellátott készülékek már élvezetessé tehetik a PC-kre szánt oldalak megjelenítését. 5

6 BEVEZETÉS Mint minden technológiának, a MIDP-nek is vannak előnyei, illetve hátrányai is. Legnagyobb előnye, hogy egységes, szabványos szoftver platformot kínál a mobiltelefon piac számára, ahol az idáig uralkodó egyedi készülékek lehetetlenné tették a többféle eszközön is működőképes, ütőképes alkalmazások készítését, és az alkalmazásokra épülő, széles körben elérhető szolgáltatások megjelenését. A szoftverfejlesztők számára az egységes megoldások hatékonyabb munkát, nagyobb piacot, és biztosabb bevételt jelentenek, amelyek az ütőképes alkalmazások készítésének alapfeltételei. A mobiltelefon gyártók számára a platform egyszerűbb és gyorsabb fejlesztést, alacsonyabb költségeket, ugyanakkor sokkal tökéletesebb végeredményt ígér. Hátránya, hogy az olyan készülékek esetében, amelyek több megabyte memóriával rendelkeznek, a 100 KByte többletmemória igény nem jelent különösebb problémát. A társaságok célja azonban az, hogy a Java az olcsóbb, általánosabb mobiltelefon készülékekben is elterjedjen. Ezen modellekben általában azonban csak éppen annyi memória van, amennyi feltétlenül szükséges, és már a 100 KByte plusz is problémát okozhat, vagy a készülék árát növelő módosítást tesz szükségessé. A 100 KByte pluszmemória igény számos olyan készülék MIDP 2.0-ra való frissítését is lehetetlenné teszi, amely a platform korábbi, 1.0-ás változatára épül, azonban a mobiltelefonok tárkapacitása a PC-kkel ellenben általában nem bővíthető. Figyelembe véve a piacon lévő mobil eszközök rendszer-architektúráinak változatosságát, számunkra legfontosabb tulajdonság ezek közül a Java alkalmazás hordozhatósága és architektúra-függetlensége. Most lássuk, hogy milyen lehetőségeket biztosít a mobil eszközök szoftvereinek fejlesztésére a Java 2 Platform Micro Edition (J2ME). 6

7 ALKALMAZOTT TECHNOLÓGIÁK 2 Alkalmazott technológiák 2.1 A Java 2 Micro Edition (J2ME) A J2ME platformot alapvetően olyan beágyazott eszközökre való fejlesztésre találták ki, mint a mobil telefonok, PDA-k, illetve az autóba szerelhető telematikus eszközök. A J2SE és J2EE-hez hasonlóan a J2ME is a Java Community Process által szabványosított API-val rendelkezik A J2ME platform biztosítja a Java technológia előnyeit e fenti eszközökön (rugalmas felhasználói interfész, robosztus biztonsági modell, hálózati protokollok széles skálája, illetve hálózati és off-line alkalmazások támogatása). Szerverek és vállalati gépek Optional Packages Szerverek és PC-k Optional Packages Felső kategóriás PDA-k, beágyazott eszközök Mobil telefonok, egyszerűbb PDA-k Smart-kártyák Optional Packages Java 2 Platform Enterprise Edition (J2EE) Java 2 Platform Standard Edition (J2SE) Personal Profile Personal Basis Profile Optional Packages Foundation Profile MIDP CDC CLDC Java Card JVM JVM JVM KVM Card VM Java 2 Platform Micro Edition 1. ábra. A J2ME architektúra A J2ME platform nem egyszerűen szoftverspecifikáció. A J2ME a kisméretű eszközök számára kifejlesztett technológiák és specifikációk gyűjteménye. Az alapját egy konfiguráció jelenti, amelyre épül az adott eszköz működését meghatározó profil. Ez a profil egy adott konfigurációra épül, de jóval specifikusabb API-kal is bír, azért hogy teljes környezetet biztosítson az alkalmazások fejlesztéséhez. 7

8 ALKALMAZOTT TECHNOLÓGIÁK Ugyan a konfiguráció írja le a virtuális gépet és az alapfunkciókat ellátó csomagokat, nem önállóan teszi lehetővé azt, hogy komplett alkalmazásokat tudjunk írni az adott eszköz osztályra. A profilokban általában olyan csomagokat definiálnak, amelyek az alkalmazás életciklusára, a felhasználói felület készítésére, és a helyi megmaradó adattárolásra biztosítanak objektumokat. Egy opcionális csomag olyan funkcionalitásokat nyújt, amelyek nem illenek bele egy adott konfigurációba vagy profilba. Egy példa az opcionális csomagra a Bluetooth API, ami a Bluetooth hálózati kommunikáció használatát valósítja meg. A J2ME alapplatformja két különböző konfigurációból áll össze, a CDC-ből (Connected Device Configuration - kapcsolódott eszköz konfigurációja) és a CLDC-ből (Connected Limited Device Configuration - kapcsolódott korlátozott eszköz konfigurációja). A konfiguráció meghatározza a Java technológia központi függvénytárait és a virtuális futtatókörnyezet képességeit. A CLDC-t általában a hordozható készülékek használják, mint például a mobiltelefonok, míg a CDC-t a fejlettebb mobilkészülékek, mint például a kommunikátorok, PDA-k. A Mobile Information Device Profile (MIDP) - ami a CLDC-re épül - volt az első elkészült profil, ami belekerült a J2ME-be. A MIDP-t futtatni képes eszközök széles választékban elérhetőek. Mivel az általam megvalósítani kívánt alkalmazás futtató eszközei elsősorban mobiltelefonok, ennek megfelelően ismerkedjünk meg bővebben a CLDC-vel és a MIDP-vel, mint technológiával A Connection Limited Device Configuration (CLDC) ismeretetése A CLDC egy jól csatlakoztatható, minimális méretre törekvő, Java alkalmazásfuttató platformot valósít meg, korlátozott erőforrásokkal rendelkező hálózatban lévő készülékekhez. 8

9 ALKALMAZOTT TECHNOLÓGIÁK Profilok Konfiguráció Könyvtárak JVM Operációs rendszer 2. ábra: Magas szintű architektúra A CLDC konfigurációra épülő eszközökre általában igazak a következők: elemmel működnek korlátozott memória kapacitással rendelkeznek korlátozott feldolgozási teljesítménnyel rendelkeznek alacsony sávszélesség Az egész CLDC implementációnak (a virtuális gép + osztály könyvtárak) kisebbnek kell lenni, mint 128 Kbyte. A CLDC specifikáció feltételezi, hogy egy alkalmazás 32 Kbyte Java heap területen is el tud futni. Egy CLDC-t támogató Java virtuális gép a következőkben nem kompatibilis a Java virtuális gép specifikációval: Nem támogatja a lebegőpontos adattípusokat. Nem támogatja a JNI-t (Java Native Interface). Nem létezik finalize() metódus. Nem támogatja a szálcsoportokat és a démon szálakat. Nincs felhasználó-definiált Java-szintű osztálybetöltő. Korlátozott a hibakezelés. A java.lang.error legtöbb leszármazottja nem támogatott. A CLDC igényli azt, hogy a virtuális gép felismerje a hibás class fájlokat. Egy hibás class állomány interpretálása ugyanis összedöntheti a virtuális gépet. Mivel az J2SE kiadásban használt algoritmus memóriaigényes, ezért a CLDC egy másik módszert használ. A CLDC a következő Java osztályokat tartalmazza (egy osztály az eredei osztály részhalmaza) : 9

10 ALKALMAZOTT TECHNOLÓGIÁK java.lang java.util java.io A hálózatkezelésre a CLDC az úgynevezett GenericConnection keretrendszert alkalmazza. Kapcsolat létrehozása a javax.microedition.connector osztály segítségével történhet : A konfiguráció csak azokat a legfontosabb könyvtárakat és a virtuális gép legalapvetőbb tulajdonságait szolgáltatja, melyeknek kötelezőképpen szerepelnie kell a J2ME környezet implementációjában. A CLDC tervezésekor a következő célokat tűzték ki: Lecsökkenteni a méretét olyan szintre, hogy a mobilpiacon lévő eszközök minél szélesebb rétegének igényeihez és lehetőségeihez illeszkedjen. Az alkalmazás portolhatóságának elősegítése a helyi rendszer műveletinek általánosításával egy standardnak tekinthető API-ba való csomagolásával. Az eszköz funkcionalitásainak kiegészítése olyan API-val, ami az alkalmazások dinamikus letölthetőségét valósítja meg. A céleszközök tulajdonságai meghatározottak, bizonyos hardver igényeknek meg kell felelniük: 16 vagy 32 bites processzor (minimum 16 MHz-es órajellel) Legalább 160 KB memória a CLDC és a VM részére Legalább 192 KB memória a JAVA platform számára Hálózati kapcsolat Energiatakarékosság A K virtuális gép (KVM) A CLDC szíve a Sun K virtuális gép (KVM). A KVM neve arra utal, hogy a mérete néhány 10 Kbájt-ra van korlátozva. A KVM olyan 16/32-bites RISC/CISC mikroprocesszorokkal/vezérlőkkel rendelkező eszközökhöz alkalmazható, melyek legalább 160 Kbyte memóriával rendelkeznek. Ebből 128 Kbájt tárolja az aktuális virtuális gépet és a könyvtárakat. A Sun mérnökei optimalizálták a J2ME API-t úgy, hogy eltávolították a lehetséges osztály- 10

11 ALKALMAZOTT TECHNOLÓGIÁK függőségeket, és csökkentették az osztály-könyvtárak méretét. További szempontok voltak a következők: Hordozhatóság. C-ben írt kódok az alacsony-szint hatékonysági előnyei végett. Mivel a KVM C-ben íródott, ezért könnyen átvihető oda, ahol van C fordító. Az írásánál ANSI-C kompatibilis C fájlokat használtak. Egy teljesen új szemétgyűjtögetési mechanizmus. wrapperek és natív függvények használata a host rendszerfüggvények meghívásához a Java natív interfészek helyett. Nem támogatja a JNI-t. Helyette minden olyan natív kódot, melyet a virtuális gép hív meg fordítási időben be kell linkelni közvetlenül a virtuális gépbe. Nem támogatja az AWT-t és a Swing-et. Jini alkalmazások támogatása. Azokon az eszközökön, amelyek nem rendelkeznek megfelelő felhasználói interfésszel, a KVM egy Java Application Managert (JAM) szolgáltat. A JAM feltételezi, hogy az alkalmazások JAR fájlként érhetők el a letöltéshez. A KVM támogatja a JavaCodeCompact (JCC) utilityt. Ez lehetővé teszi a Java osztályok belinkelését a virtuális gépbe, ezáltal lecsökkentve a KVM indulási idejét. Ahhoz, hogy egy KVM-en futó alkalmazást készítsünk, a rendelkezésünkre álló hagyományos Java eszközök segítségével kell fejlesztenünk, majd lefordítani a kódot. A fordítás előtt azonban a következőket figyelembe kell venni: Nem használhatunk minden JDK osztályt egy KVM alkalmazásban. A - bootclasspath opcióval (JDK 1.2 óta) kényszeríthetjük a fordítót a KVM könyvtár alkalmazására. Az eredményezett.class fájlok nem alkalmasak a futásra. Ezeket az osztályokat elő-ellenőrizni kell a preverify.exe program segítségével. Ez létrehoz egy.\output könyvtárat, ahova az előellenőrzött osztályt be fogja pakolni. 11

12 ALKALMAZOTT TECHNOLÓGIÁK A KVM kifejlesztésének három technikai indoka volt. Ezek közül talán a legfontosabb, hogy a virtuális gép és a könyvtárak méretét jelentősen csökkenteni kellett. Egy másik elvárás, hogy a végrehajtás közben felmerülő memóriaigényt csökkentse, valamint megengedje, hogy a virtuális gép egyes részei az egyéni eszközöknek megfelelően legyenek konfigurálva. A fejlesztés eredményeképpen a következő változtatásokat figyelhetjük meg: Jelentős méretcsökkentés, a KVM alap konfigurációja mindössze KB között van, ez függ a cél platformtól és a fordítási beállításoktól. Csökkentett memória használat: A K virtuális gépnek mindössze néhány tíz kilobyte dinamikus memóriára van szüksége a hatékony futáshoz. (A csökkentett méret és memória használat miatt a K virtuális gép lehetővé teszi Java technológia alapú alkalmazások problémamentes futtatását egy eszközön, még akkor is, ha csak 128 KB teljes elérhető memóriával rendelkezik.) Hatékonyabb teljesítmény: A K virtuális gép képes hatékonyan futni 16 és 32 bites processzorokon és 25 MHz-es órajelen. Minimális rendszerfüggőség: A K virtuális gép architektúrája nagymértékben hordozható A MIDP Ezt a specifikációt a MIDPEG (Mobile Information Device Profile Expert Group) készítette. Ebben számos cég benne van, a fejlesztés szempontjából a legfontosabbak a következők: Motorola (az egész specifikáció vezetője) Nokia (felhasználói API) Sun (hálózat, perzisztens tárolás, rendszer, nemzetköziesítés, időkezelés) Az MIDPEG definiálta, hogy egy MID egy olyan eszköz, amelynek a következő minimális tulajdonságokkal kell rendelkeznie: Képernyő. méret: 96*54, színmélység: 1 bit, torzítási arány: 1:1. Input. Vagy egykezes billentyűzettel (ITU-T), vagy kétkezes billentyűzettel (QWERTY), vagy érintő képernyővel rendelkeznie kell. Memória. 128 Kbájt non-volatile memótia a MIDP komponenseknek. 8 Kbájt non-volatile memória az alkalmazás által létrehozott perzisztens adatoknak

13 ALKALMAZOTT TECHNOLÓGIÁK Kbájt volatile memória a Java futtatásnak. A non-volatile memória megőrzi a tartalmát a készülék. Hálózat. Két utas, rádiós, esetleg időszakos, korlátolt sávszélességgel. A MID eszközök operációs rendszere nagyon eltérő lehet : multiprocessing hierarchikus fájlrendszerrel, vagy szálalapú fájlrendszer nélkül. Éppen ezért a MIDP minimális feltételezéseket tesz a MID rendszer szoftverére vonatkozólag. Ezek a következők: Egy minimális kernel, amely kezeli az alatta lévő hardvert (megszakítás és kivételkezelés, minimális scheduling). A kernelnek legalább egy ütemezett egyedet (entity) tartalmaznia kell a JVM futtatására. Nem kell támogatnia különböző névterületeket vagy processzeket. Nem garantálja a valós idejű ütemezést. A non-volatile memóriákból történő olvasás vagy írás. Az eszköz rádiós hálózatához való írási és olvasási hozzáférés. Időkezelés, időzítés. Egy minimális képesség a bittérképes grafikus kijelzőre történő írásra Felhasználói input beolvasása. Egy alkalmazás életciklusának kezelése. 13

14 ALKALMAZOTT TECHNOLÓGIÁK MID alkalmazás típusok: 3. ábra: MID architektúra MIDP alkalmazás (MIDlet) az, amely csak a MIDP és a CLDC specifikációkban definiált API-kat használja. OEM-specifikus alkalmazás, amely OEM-specifikus osztályokat használ. Ezek az alkalmazások nem hordozhatóak. Natív alkalmazások, amelyek nem Java-ban íródtak MIDP könyvtárak Rendszer (System Functions) CLDC-n alapul System properties: microedition.locale a jelenlegi beállítás nyelvkód-országkód (en-us, fr-fr, hu-hu) microedition.profiles (a MIDP verzió) Erőforrások: java.lang.class getresourceasstream(string name) 14

15 ALKALMAZOTT TECHNOLÓGIÁK Időzítők (Timers) Osztályai: java.util.timer java.util.timertask segítségével egy párhuzamos szálat indíthatunk mely adott időközönként lefuttatja a run metódust az alosztályt a TimerTask osztályból kell származtatnunk A Timer objektumokat egy háttér szál menedzseli metódusok: public void schedule (TimerTask task, Date firsttime, long period) nem veszi figyelembe a csúszást (animáció) public void scheduleatfixedrate (TimerTask task, Date firsttime, long period) megpróbálja kiküszöbölni a csúszást (hálózati időzítések) Hálózatkezelés (Networking) HTTP protokoll egy része használható Transzparens szolgáltatást kell nyújtania (nem kell tudnunk arról, hogy esetleg nem IP hálózatot is használunk) Osztályok : javax.microedition.io Interfészek : public interface HttpConnection extends javax.microedition.io.contentconnection setrequestmethod setrequestproperty Tartós Tárolás (Persistent Storage) Osztályok : javax.microedition.rms Record Management Store (RMS): Max 8kbyte A MIDletek futtatása között is megőrzik az értéküket 15

16 ALKALMAZOTT TECHNOLÓGIÁK Minden MIDlet-nek saját RMS A neve max. 32 unicode karakter (egyedinek kell lennie) Egymás RMS-ét elérhetik (nincs zárolás, a programozónak kell gondoskodnia erről) Felhasználói interfész (User Interface) Osztályok : javax.microedition.lcdui Felső szintű (high level) Készülék független Nincs sok beleszólás a kinézetbe Alsó szintű (low level) Jobban kihasználja a készülékek képességeit Teljes hozzáférés a képernyőhöz Egyszerű események is használhatóak Elérhetjük a az egyes beviteli elemeket Alkalmazások (Applications) 2.2 Alkalmazások, MIDletek A MIDP definiál egy alkalmazás modellt, amely lehetővé teszi az eszköz korlátozott erőforrásainak megosztását több MIDP alkalmazás között. Az alkalmazást vezérlő szoftver egy környezetet nyújt, melybe a MIDletek installálódnak, elindulnak, leállnak és uninstallálódnak. Ez a felelős a műveletek közben bekövetkezett hibák kezeléséért, és a felhasználóval való kommunikációért, ha szükséges. Egy vagy több MIDletet bele lehet pakolni egy egyszerű JAR fájlba. Minden MIDlet tartalmaz egy osztályt, amely a javax.microedition.midlet.midlet osztály leszármazottja, és olyan további osztályokat, amelyek szükségesek a MIDlet számára. Egy MIDlet nem rendelkezhet public static void main() 16

17 ALKALMAZOTT TECHNOLÓGIÁK metódussal. A MIDlet az az egyed, amelyet az alkalmazásvezérlő szoftver elindít, azaz létrehozza egy példányát. A MIDP definiál egy futási környezetet a MIDletek számára, ezáltal a következők lesznek elérhetők: A CLDC-t és a virtuális gépet implementáló osztályok és natív kód A MIDP-t implementáló osztályok és natív kód. A végrehajtandó egyszerű JAR fájl minden osztálya. A leíró fájl tartalma Az alap MIDlet: import javax.microedition.midlet.* public class SimpleMidlet extends MIDlet { public SimpleMidlet() { // Constructor } public void startapp() { // Entering active state } public void pauseapp() { // Entering paused state } public void destroyapp(boolean unconditional) { // Entering destroyed state } A Midlet Suit Ha alkalmazás töltünk le a webről, akkor nem a MIDletet töltjük le és indítjuk, hanem egy ún. MIDlet suit-ot, ami egy vagy több MIDlet-et tartalmaz összecsomagolva. A MIDlet suite többnyire több, hasonló funkciót ellátó vagy együttműködő MIDlet összessége. Az egy suite-ban lévő MIDletek osztozhatnak az erőforrásokon (adat, grafika) ugyanabban a suite-ban lévő MIDletek hozzáférhetnek egy suite-beli MIDlet információihoz, míg más suite-ban lévő MIDletek erőforrásaihoz nem. A suit-nak tartalmaznia kell a MIDletek class fájljait és egyéb, a MIDletek által megosztott osztályok class fájljait, valamint a MIDletek erőforrás fájljait és azokat az attribútumokat is, melyeket az alkalmazás vezérlő software használ a MIDlet készlet azonosítására és installálására. A MIDlet Suit a fordítás során a jar (Java Archive) kiterjesztésű fájlba mentődik. A jar fájlokban fellelhető elemekről a jad (Java Application Descriptor) leíró fájl szolgáltat információt a készülék számára. Ezt a fájlt telepítéskor az adott eszköz AMS (Application Management 17

18 ALKALMAZOTT TECHNOLÓGIÁK Softwer) rendszere ellenőrzi. A Leíró fájlnak kétféle tartalma van, a kötelező tartalmak és az opcionális tartalmak. A kötelező tartalmak előredefiniált attribútumok, az opcionális tartalmak nem minden esetben kerülnek bejegyzésre. Attribútum MIDlet-Name MIDlet-Version MIDlet-Vendor MIDlet-Jar-URL MIDlet-Jar-Size MicroEdition-profil MicroEdition- Cofniguration Leírás A MIDlet készlet neve A MIDlet készlet verziója (major.minor.micro) A MIDlet készletet szolgáltató szervezet Az URL, ahonnan a JAR fájl le lett töltve A Jar file mérete bájtokban A MIDP verziója, amin fut CLDC verziója 4. táblázat: Kötelező bejegyzések a MIDlet suit-ban Attribútum MIDlet-Description MIDlet-Icon MIDlet Info-URL MIDlet Data-Size Leírás A MIDlet készlet leírása A MIDlet készletethez rendelhető png neve Egy URL amely információt tartalmaz a MIDlet készletről A MIDlet által igényelt minimális perzisztens adat bájtokban, alapértelmezetten 0 5. táblázat: Opcionális bejegyzések a MIDlet suit-ban A leíró fájlt az alkalmazás vezérlő szoftver használja a MIDlet irányítására és ez szolgáltat konfiguráció-specifikus attribútumokat a MIDlet számára. Minden JAR fájl tartalmazhat egy ilyen leírót. Lehetővé teszi az alkalmazás vezérlő számára, hogy az egész JAR fájl letöltése előtt eldöntse, hogy a MIDletek alkalmasak-e az eszközre. A leíró fájl kiterjesztésének jad-nak kell lennie MIDlet életciklusa A MIDlet életciklusának három állapota van. Az AMS a MIDlet osztály metódusainak hívásaival értesíti a MIDletet az életciklus-változásokról. 18

19 ALKALMAZOTT TECHNOLÓGIÁK MIDlet pédányosítása Paused Active Destroyed Garbage Colector 6. ábra: MIDlet életciklusa A MIDlet normálisan Destroyed állapotban van. Ez azt jelenti, hogy a MIDlet installálódott, de a JVM-be nem töltődött be. A MIDlet aktiválásakor Paused állapotba kerül. Ez azt jelenti, hogy a MIDlet osztály és a belőle hivatkozott osztályok betöltődtek a JVM-be a JAR-ból. A MIDlet még nem foglal erőforrásokat. A MIDletet ezek után aktiválja az AMS. Ezt a MIDlet startapp() metódusának meghívásával teszi. A startapp() metódusban a MIDlet létrehozza a felhasználói felületét és egyéb módokon is kapcsolódik a környezetéhez (pl. értesítéseket kér a kommunikációs könyvtártól). A startapp() sikeres lefutása után a MIDlet Active állapotba kerül. Bizonyos körülmények teljesülése esetén a MIDlet futását szüneteltetni lehet, ez a Paused állapot. Ilyenkor az AMS meghívja a MIDlet pauseapp() metódusát. Jól viselkedő MIDlet ilyenkor minimumra csökkenti erőforráshasználatát és várja az újabb startapp() hívást. Ennek az állapotnak pontos definíciója vitatott. A Nokia MIDlet implementációja pl. magától soha nem szünetelteti a MIDlet futását, csak akkor, ha a MIDlet azt maga kéri. A Motorola ezzel szemben úgy implementálta ezt az állapotot, hogy 19

20 ALKALMAZOTT TECHNOLÓGIÁK valahányszor a MIDlet eltűnik a képernyőről (pl. hívás érkezett és a dialógusablak eltakarja) a MIDlet Paused állapotba kerül. Robusztus MIDlet tehát lekezeli a pauseapp() hívást, de nem okoz neki gondot az se, ha a pauseapp()-ot sose hívják meg. Végül a MIDlet befejezi pályafutását és az AMS törli. Mielőtt ez megtörténik, az AMS meghívja a MIDlet destroyapp( boolean unconditional ) metódusát. Ha a destroyapp() paramétere false, a MIDlet megakadályozhatja az állapotátmenetet, ha a destroyapp metódusban MIDletStateChangeExceptiont dob. A paraméter true értéke esetén a MIDletet mindenképpen elpusztítja az AMS Perzisztens tárolás Minthogy a MIDleteket installálják a telefonra és hálózati kapcsolat nélkül is működőképeseknek kell maradniuk, igen jól jön egy perzisztens (=a MIDlet lelövése, sőt a telefon kikapcsolása után is megőrződő) tárolóhely. A MIDlet API egy rendkívül egyszerű rendszert kínál, ez a Record Management System (RMS) API. Az RMS funkciói a következők: Névvel azonosított, a MIDlet sorozathoz tartozó tároló (RecordStore) létrehozása. Ha egy MIDlet sorozat létrehozott egy RecordStore-t, az végigköveti a MIDlet sorozatot az életén át (a MIDlet sorozat törlése során törlődik a RecordStore is), más MIDlet sorozat nem tud hozzáférni. A RecordStore nevének a MIDlet sorozat számára kell egyedinek lennie, egy MIDlet sorozat több RecordStore-t is létrehozhat, de azok neve különböző kell legyen. Rekordok hozzáadása a RecordStore-hoz ill. rekordok kiolvasása a RecordStore-ból. Egy rekord egy egyszerű bájtsorozat. A rekordokat a számuk azonosítja, a rekordazonosító 1-ről indul és minden rekord hozzáadásánál eggyel növekszik. Ezen felül az RMS még néhány egyszerű szolgáltatást nyújt, pl. változásfigyelő eseménykezelőt lehet a RecordStore-hoz kötni, a rekordok utolsó változtatási idejét le lehet kérdezni, stb. 20

21 ALKALMAZOTT TECHNOLÓGIÁK A RecordStore mérete nem túl nagy, pl. a Nokia 6310-ben csupán 20Kbájt az összes MIDlet sorozat számára. A méret azonban jelentősen nőtt az utóbbi időben, a Nokia legújabb nem Symbian telefonjaiban a teljes méret eléri az 1 MBájtot, Symbian-os telefonokban ennél nagyobb is lehet Felhasználói felület A Jáva létező felhasználói felület csomagjai (pl. AWT) nem alkalmasak mobiltelefonos használatra. Egyrészt túl nagyok, másrészt általában átlapolódó ablakokkal modellezik a rendszert, ami a mobiltelefonos felhasználói felületekre nem igaz. A MIDP-t kis méretű, tömegesen használt mobiltelefonokra tervezték, amelyeknek tipikus felhasználói felület-eleme a lista. Ilyen felületekre a MIDP megalkotásának idején nem volt alkalmas Jáva könyvtár, ezért hozták létre a MIDP LCDUI könyvtárát. Az LCDUI tervezésekor a fő követelmények a következők voltak: Támogatni kell olyan alkalmazásokat, amelyek teljes ellenőrzést szeretnének a kijelző felett, pontosan meg akarják mondani, mi hova kerüljön. Tipikusan ilyen alkalmazás egy játék, ami a MIDP egyik legfontosabb alkalmazástípusa. Támogatni kell, hogy a lehető legegyszerűbb módon lehessen írni egyszerű, űrlap-alapú alkalmazásokat, amelyek üzleti rendszerek kliensoldali részeként működhetnek. A telefon felhasználói felületére a lehető legkevesebb megkötés vonatkozzon, minthogy a telefongyártók ezen a területen versenyeznek. Az LCDUI központi fogalma a képernyő (screen). A képernyő egy objektum, ami a valóságos kijelzőn megjelenítendő tartalmat jelképez. Az alkalmazás élete során a felhasználó képernyőről képernyőre halad. A képernyők három fő fajtája a következő: A telefon által meghatározott szerkezetű képernyők összetett funkciókkal, pl. List vagy TextBox. Ezeknek a képernyőknek a szerkezetét a program nem változtathatja meg és nem adhat hozzá újabb elemeket. A telefon által meghatározott kinézetű képernyők, melyeket a program tölt fel tartalommal (pl. Form). Ezekre a képernyőkre szövegmezők, szövegbeviteli 21

22 ALKALMAZOTT TECHNOLÓGIÁK mezők, képek, stb. helyezhetők, a telefon azonban maga dönti el, hogyan nézzen ki a tényleges kijelzőkép. Képernyők, melyeknek tartalmát teljesen a program határozza meg (Canvas és leszármazottjai). A képernyő pontosan úgy jelenik meg, ahogy a program megrajzolta. A képernyők megjelenítését a Display osztályon keresztül vezérelhetjük. Ennek setcurrent metódusa beállítja az aktuális képernyőt, ami ezután meg is jelenik a mobiltelefon képernyőjén. A képernyőket alapvetően két stílus szerint kell létrehozni, ezek: Canvas és Screen (ezek egyben az ősosztályai a stílust megvalósító objektumoknak). A Canvas-nak nagyjából egy tucat eseménykezelő metódusa van, a keypressed csak egy közülük. A legérdekesebb a shownotify-hidenotify páros. A MIDlet nem egyedül fut a telefonban és általában még csak nem is a legfontosabb folyamat. Beérkezhet egy hívás, amit azonnal jelezni kell a felhasználóknak. Ilyenkor a felhasználói felület olyan lehet, hogy a MIDlet képernyőjét eltakarja egy üzenet, hogy hívás érkezett. Ekkor a MIDlet hidenotify üzenetet kap, majd ha a képernyő újra szabad, shownotify-t. A MIDletek hívás közbeni viselkedése a MIDlet specifikáció legzűrösebb pontja, amelyet a Nokia és Motorola másként implementált. Nokia telefonokon a MIDletet semmi nem akadályozza a futásban, még akkor sem, ha a telefon hívást fogad. A MIDlet háttérbe kerülhet a hívás során (pl. üzenetablak miatt), de ettől még fut. A háttérbe-előtérbe kerülési események hidenotify-shownotify események formájában jutnak el hozzá. Motorola telefonokon a hívás ideje alatt a MIDlet nem fut, hanem Paused állapotba kerül. A másik fontos stílus a Screen. A Screen alapelve, hogy a MIDlet komplex felhasználói felület-elemek megjelenítését kéri a telefontól, melyet az kedve szerinti stílusban jelenít meg. A Screen-típusú képernyők tehát különbözőképpen jelennek meg különböző telefonokon, cserébe viszont a képernyő részletes rajzolásával nem kell bajlódnunk. A Screen ősosztálya két specializált leszármazotti ágnak. A List és TextBox egész képernyőt foglalnak el, megjelenésük semmilyen módon nem módosítható. 22

23 ALKALMAZOTT TECHNOLÓGIÁK A Form képernyőkre egy sor egyszerű képernyőelem (statikus kép, szöveg, szövegbeviteli mező, kiválasztó lista, vonalkijelző (gauge)) helyezhető el. A telefon így is szabadon megválaszthatja, hogyan jeleníti meg a Form-ot. Az egyszerűség kedvéért Screen-t a Canvas-tól teljesen különböző programozói stílusban kell létrehozni. A Form konstruktorában a Form-hoz kell adni a képernyő elemeit, majd eseménykezelőket kell installálni a Listener pattern szerint. Másik fontos Listener típus a CommandListener, ami Command egyedekhez kapcsolódó eseményekről küld értesítést (itt nem részletezzük, a Command osztály egyedeivel saját opciómenü vagy funkcióbillentyű-kezelést valósíthatunk meg) Fejlesztőkörnyezetek A Sun Microsystems által fejlesztett Wireless Tool Kit (WTK) sok lehetőséget kínál a mobil alkalmazások fejlesztői számára. A fejlesztőkörnyezetektől elvárható módon tudunk projektekben dolgozni. Az elkészült kódot egy beépített mobiltelefon emulátoron futtatja, képet adva a fejlesztőnek arról, hogy a megkonstruált képernyők hogyan mutatnak majd a valóságban. Az emulátor természetesen nem csak külsőségeiben olyan, mint egy mobil készülék, hanem annak minden megszorítását pl. memóriakorlát- is színleli. Találhatunk MIDP 1.0 vagy MIDP 2.0-t is futtatni képes emulátort a WTK emulátorcsomagjában. Nagy hátránya a WTK-nak azonban az, hogy nem rendelkezik a fejlesztőt munkájában segítő funkciókkal. Nem rendelkezik beépített szerkesztővel, hanem azt javasolja, hogy egyszerű szövegszerkesztőt mint például a notepad használjunk. Másik Sun termék, a Sun Java Studio Mobility viszont biztosítja az IDE (Integrated Developmet Environment)-nél megszokott kényelmet, ami manapság elvárható egy efféle terméktől. Jómagam is ezt használtam az implementáció során. 23

24 TERVEZÉS 3 Tervezés 3.1 A feladat ismertetése A kitűzött cél egy olyan mobil alkalmazás mérnöki tervezése és implementálása volt, amely a Java 2 Platform J2ME, és azon belül is a Mobile Information Device Profile (MIDP) technológia tanulmányozása során szerzett ismereteket mutatja be. A konkrét feladat egy számítástechnikai online shop alkalmazás létrehozása, ami egy olyan MIDP alkalmazás (MIDlet), mely lehetővé teszi azt, hogy egy szerveren tárolt adatbázisból az aktuális termékek és árak között böngészhessen a felhasználó, majd a kiválasztott illetve kosárba rakott termékeket online megrendelheti. A mobil klienssel szemben támasztott követelmények egyike az volt, hogy ne csak a szerverhez csatlakozva érjük el a szolgáltatásokat, hanem maradjon működőképes akkor is, ha a hálózat vagy a kiszolgáló nem áll rendelkezésre valamilyen váratlan esemény következtében. 3.2 Tervezési minták Az alkalmazás megtervezése előtt olyan mintát illetve mintákat kerestem, amelyek segítségemre lehetnek munkámban. A feladathoz legközelebb álló alkalmazást a SUN MIDP technológiával foglalkozó web szerverén találtam, egy online mozijegy-rendelő programot (Smart Ticket Sample Application). Azért választottam ezt az alkalmazást mintának, mert a fejlesztőkörnyezet, a nyelv, a struktúra mind megegyezik az általam létrehozni kívánt alkalmazáséval. A kliens egy MIDlet, ami JAVA Bean technológiával kapcsolódik egy J2EE szerverhez, ez a struktúra egy hagyományos kliens-szerver minta. A mobil eszközök teljesítőképessége jelentős korlátokat szab, amelyeket a tervezésnél figyelembe kell venni. Ilyen korlát a processzor teljesítőképessége, a memória kapacitása (elsősorban a kód méretét és a tárolt adatok mennyiségét kell minimalizálnunk), valamint a képernyő mérete (ami a megjeleníthető információ mennyiségének szab határt). Az erőforrásokkal való takarékoskodás következtében figyelnünk kell arra is, hogy csak akkor csatlakozzunk a szerverhez, ha elengedhetetlen. Ha például letöltöttük a minket érdeklő termékekre vonatkozó adatokat, akkor azok között utána offline módban is 24

25 TERVEZÉS böngészhessünk. Fontos megemlíteni, hogy csak a legszükségesebb adatokat célszerű letölteni, hiszen ha minket csupán az alaplapok érdekelnek, akkor ne kelljen letölteni az egész adatbázist, mert ez a kis sávszélesség és az előbb említett korlátok miatt igen időigényes, nagyobb adatbázis esetén lehetetlen lenne. Így ha a kapcsolatunk megszakad, akkor is használható a program. A kliens oldal tervezése a Model-View-Controller tervezési minta alapján történik A Model-View-Controller (MVC) Néhányan azt állítják, hogy a MVC egy felépítési struktúra, míg mások úgy gondolják, hogy ez egy tervezési módszer, minta. Jómagam tervezési mintának tekintem, és ez alapján kívánom megtervezni, majd megvalósítani az alkalmazásomat. Ez a tervezési minta három részből áll mint ahogy a nevében is benne van-, a Model-ből, a View-ból és a Controller-ből. Ez a három részre bontás teszi a struktúrát átláthatóvá és kezelhetővé egy fejlesztő számára. A felhasználói felület (UI) és a modell a controller segítségével kapcsolódnak egymáshoz. 7. ábra: A Model-View-Controller minta 25

26 TERVEZÉS View: Ez a felhasználói felület, ami láthatóvá teszi a megjeleníteni kívánt információkat. A felhasználó csak ezt látja, a számára nem fontos részeket elrejtjük előle a Model Facade segítségével. Controller: Logikai folyamatokat jelöl, kezeli a felhasználó kéréseit a modelhez, majd a model válaszait a felhasználói felülethez. Model: Ez a program magja, magába foglalja az adatokat és az alapvető funkcionalitásokat. 8. ábra: A MVC és a felhasználó kapcsolata A Controller osztály teljesen izolált, ezért ha valamit meg szeretnénk változtatni a felhasználói felületen (pl. a képernyők egymás utáni sorrendjét), akkor csak ezt kell átalakítanunk. Ezáltal átláthatóbbá, könnyen javíthatóvá válik a kód. Ez azért előnyös, mert a külalakot egyszerűen megváltoztathatjuk anélkül, hogy a modelbe belenyúlnánk, nem kell foglalkoznunk az adatstruktúrával. Nem áll kapcsolatban az adatmodell felépítése (és annak forrása) a megjelenéssel. Mint már említettem, feladatomat egy már meglévő alkalmazás mintájára próbálom megvalósítani. Ez az alkalmazás ajava Smart Ticket Sample Aplication, amit a SUN fejlesztői valósítottak meg A Smart Ticket Sample Application (STSA) A SUN Microsystems fejlesztői ezt az alkalmazást az előbb felvázolt MVC minta alapján tervezték. Az alkalmazás nagy mértékben hasonlít az általam megvalósítani kívánthoz, ezért választottam mintának, példának. 26

27 TERVEZÉS A STSA funkcionalitásai Első használatkor regisztrációs űrlap kitöltése Profil beállítása (érdeklődési kör, tartózkodási hely stb.) Belépés után online böngészési lehetőség Offline böngészés (műsorok letöltése a készülékre) Letöltések frissítése, törlése az offline böngészéshez Előadás kiválasztása után kapcsolódás a szerverhez, szabad helyek grafikai ábrázolása Szabad helyek közül a nekünk megfelelő kiválasztása, majd foglalása egy visszajelzéssel, hogy a foglalás sikeres volt-e. Előadások online értékelése Nézzünk néhány példát az alkalmazás használatára, először nézzük meg egy felhasználó beállításainak kezelését. 9. ábra: Felhasználó beállításainak kezelése Első indításnál a kliens a felhasználótól információkat kér, annak érdekében, hogy használatkor csak az őt érdeklő adatok jelenjenek meg a képernyőn. Majd kér egy login nevet és néhány olyan adatot, amely a felhasználó azonosítására szolgál. Amikor megtörtént a beállítások mentése, a szerver létrehoz egy hozzáférést a felhasználónak, a kliensen pedig tárolódnak a belépéshez szükséges adatok. Belépés után használhatjuk csak a STSA legfontosabb funkcionalitását, az előadások közötti böngészést és a jegy rendelését. 27

28 TERVEZÉS 10. ábra: előadás keresése és jegyrendelés Miután a felhasználó kiválasztja a konkrét mozit, ahova szeretne ellátogatni, a következő képernyőn megjelennek az aktuális programok a konkrét időpontokkal. Ezután ha jegyet szeretne rendelni, megtekintheti hogy mely ülőhelyek foglaltak és melyek szabadok. Kiválaszthat egy számára megfelelő ülőhelyet, majd egy utolsó adatellenőrzés után megrendelheti azt. A rendelés után kap egy visszaigazolást, hogy az akció sikeres volt-e, avagy sem. További fontos funkció még az előadások osztályozása illetve az offline böngészési lehetőség. Utóbbi előnye hogy nem szükséges folyamatosan kapcsolatban lenni a szerverrel, le lehet tölteni a különböző mozik programjait a kliensre, és offline lehet közöttük böngészni. A filmek osztályozására nézzünk 28

29 TERVEZÉS egy példát, ahol a felhasználó az Invasion of the Dots című előadásra adott egy közepes osztályzatot. 11. ábra: Előadások osztályozása A STSA alkalmazásról röviden: Ez az alkalmazás egyelőre csak prezentáció, nem használják éles környezetben. Véleményem szerint napjainkban népszerű lenne egy ilyen vagy akár hasonló alkalmazás hasznosítása, hiszen egyre több embernek fontos a kényelem, hogy otthonról tudjuk intézni dolgainkat. Ez az oka annak, hogy én egy hasonló alkalmazás készítését választottam, ami egy számítástechnikai online shop megvalósítása, aminek részletei az alábbiakban ismertetném. 29

30 TERVEZÉS 3.3 Tervezési szempontok és elvek A kliens és a szerver kapcsolata 12. ábra: J2Me kliens és szerver általános blokkvázlata A fenti ábrán egy általános kliens-szerver kapcsolatot látunk. A MIDP eszköz http-n keresztül kommunikál a JAVA szervlettel, majd a szervlet továbbítja a kérést a megfelelő EJB komponensnek. Amikor ez a kérés teljesül, akkor generál egy választ a kliensnek. Az EJB konténer tranzakciós, biztonsági és erőforrás kezelési szolgáltatásokat nyújt a szervernek. A szervlet és az EJB-k további Enterprise szolgáltatásokat vehetnek igénybe, mint pl. a JDBC API, amelyen keresztül adatbázis elérés válik lehetővé Üzenetküldés A MIDP nem tartalmaz előre definiált üzenetküldési módokat, ezért nekünk kell létrehozni ilyen protokollokat. Ezeket célszerű HTTP alapra helyezni, mivel ezt a protokollt minden MIDP eszköz támogatja, ellentétben a socket illetve a datagram alapú protokollokkal. Ha mégis az imént említett két típus közül választanánk, könnyen problémákba ütközhetnénk programunk hordozhatóságát illetően, nem biztos, hogy az alkalmazások egymáshoz kapcsolhatók. Ha a hálózat nem támogatja közvetlenül a HTTP-t, akkor az eszköznek egy átjárón át kell közvetítenie kérését. 30

31 TERVEZÉS Ha egy MIDP eszközzel kommunikálni akarunk, akkor a GCF (General Connection Framework) keretrendszert kell használnunk. Ez igaz minden más CLDC profilra is. Ez a szerkezet nem más, mint olyan osztályok és interfészek halmaza, amelyet a CLDC definiál, és ez az a halmaz, amely elemei helyettesítik azokat a java.net és java.io osztályokat, amelyeket a J2SE határoz meg. Azért van szükségünk arra, hogy a GCF-et használjuk, mert a J2SE-ben használható java.net és java.io csomagok sokkal több memóriát igényelnek, mint amivel a vezeték nélküli eszközök rendelkeznek. 13. A GCF hierarchia A GCF-ben a kapcsolatot a Connector osztály open metódusával lehet felépíteni, és ha ez sikeres, akkor ez a metódus egy olyan objektummal tér vissza, amely implementálja a GCF interfészek egyikét. A fenti ábrán láthatjuk ezen interfészek örökösödési hierarchiáját. A sárgával jelölt interfészek a CLDC 1.0 részei, a HttpConnection interfész egészíti ki MIDP 1.0-ra, majd a kékkel jelölt interfészek MIDP 2.0-ra. A HTTP mellett szól az is, hogy tűzfal barát, ez az egyik olyan protokoll, amelyet a legtöbb tűzfal átenged. A HTTP 1.1-et is támogatja a MIDP, emellett olyan API-kat tartalmaz, amelyek segítségével lehetővé válik a stream alapú fogadás és a header manipulációk, és nem utolsó sorban generálható a GET és a POST valamint a HEAD kérés. 31

32 TERVEZÉS A servlet és a MIDP kliens kommunikációja alatt a következő eseményekre lehet számítani: A kliens kódolja az alkalmazáskérést, és HTTP kérésbe csomagolja úgy, hogy a Content-type headert beállítja azért, hogy biztosítsa azt, hogy a közbülső átjárók helyesen kezeljék a kérést. Például a text/plain jelenti a szöveges kérést, az application/occet-stream pedig a bináris kérés jelölésére szolgál. A szervlet megkapja a HTTP kérést és dekódolja az applikáció kérést. A szervlet és/vagy egy EJB végrehajtja a feladatot, amire az alkalmazás kérte. A szervlet egy alkalmazás választ kódol be, majd becsomagolja HTTP válasz csomagba úgy, hogy a content-type header-t beállítja a tartalomnak megfelelően: Szöveg - text/plain Bináris adat - application/occtet-stream Kép - image/png. A kliens megkapja, dekódolja. És 1 vagy több objektumot példányosítva ezeken a helyi objektumokon hajtja végre a műveleteket Az üzenetküldés formájának tervezése Az üzenetküldés formájának két szélsőséges esete az egyszerű bináris formátum és az egészen komplex XML üzenet formátum. A méret, ugyanakkor a leírtság az XML esetében a legnagyobb. Figyelembe kell azonban venni, hogy az XML használatával az erőforrás igény, a hálózati lefoglaltsággal együtt nő, amit kétszer is érdemes meggondolni Bináris üzenetek: A bináris üzenetek a legegyszerűbbek. Használatuk a java.io csomagban implementált DataInputStream és a DataOutputStream osztályok segítségével történik. Ebben a csomagban megannyi író és olvasó függvény-párt lehet találni, a különböző típusú adatok írására és olvasására. Például: DataInputStream.readInt, DataOuputStream.writeInt egészekhez, vagy a DataInputStream.readUTF, DataOuputStream.writeUTF sztringekhez, UTF-8 kódolású írás és olvasáshoz. A bináris üzenet esetében az üzenet pontos formátumáról előre kell tudnia a 32

33 TERVEZÉS szervernek és kliensnek egyaránt, ugyanis nem pontos leíró. Ez azt jelenti, hogy a kliens és a szerver szorosan csatolt XML üzenetek: XML üzenetek pontosan definiáltak, bonyolultak és nagyok. A MIDP fejlesztői úgy vélték, hogy nincs szükség XML támogatásra, de adtak lehetőséget a használatára további könyvtárak felhasználásával. Az XML parzolására és általános műveletkezelésre használatos programok közül a két legnépszerűbb modell, amire ezek ráépülnek a következők: - DOM (Documentum Object Model) - Simple API for XML(SAX) A SAX és a hasonló esemény alapú parzolók sokkal használhatóbbak a mobil eszközökön a sávszélesség és a memóriakorlátozások miatt. Végezetül a fejlesztők két kódolási stratégia közül választhatnak. Meg kell győződni arról, hogy a kérés és a visszatért értékek, - amik kicserélődtek a kliens és a szerver között - szerializációja és deszerializációja kompatibilis egymással. Hasznos lehet, ha az osztályok támogatják a saját szerializációjukat és ezek az osztályok meg vannak osztva a kliens és a szerver között is. Ekkor azonban különös figyelemmel kell lenni arra, hogy ezek a megosztott osztályok kompatibilisek legyenek a J2ME MIDP-vel és a J2SE/J2EE API-kal is. A másik lehetőség, hogy az üzenetküldésre használt objektumok a kliensen tárolódnak perzisztensen. Az online shop applikáció bináris adatformátumot használ, és a modellobjektumok képesek magukat adatfolyamba szerializálni illetve adatfolyamból felépíteni egy azonos típusú objektumot. Ezt a szerializácós - deszerializációs mechanizmust használom a helyi kliens oldali perzisztens adattárolásra és a kliens szerver kommunikációjára is Kommunikáció biztonsága Egy újabb oka annak, hogy a MIDP platform tökéletes a mobil eszközök számára, hogy biztonság terén is megbízhatunk benne. Ennek részét a JAVA programozási modelltől örökölte: A MIDlet kódok a virtuális gép korlátain belül 33

34 TERVEZÉS futnak, ami azt jelenti, hogy immunis azokra a tipikus hibákra, amelyeket a bináris kódok okozhatnak. Ha bármilyen kapcsolatot szeretnénk nyitni, akkor a MIDlet-nek kell kapnia egy engedélyt a szerver oldalról. Például ha a MIDlet ami HTTP- t használ, nem tudja addig megnyitni a HTTP kapcsolatot, amíg erre engedélyt nem kap. Ezek a MIDP 2.0-ban definiált jóváhagyások megegyeznek az általános hálózati protokollok jóváhagyásaival, de az API-k lehetővé teszik, hogy magunk definiáljunk ilyeneket. Minden jóváhagyásnak, kérésnek egységes neve van, a MIDP 2.0-ban ezek a következők: javax.microedition.io.connector.http javax.microedition.io.connector.socket javax.microedition.io.connector.https javax.microedition.io.connector.ssl javax.microedition.io.connector.datagram javax.microedition.io.connector.serversocket javax.microedition.io.connector.datagramreceiver javax.microedition.io.connector.comm javax.microedition.io.pushregistry Ha kommunikálni akarunk, akkor egyszerűen meghívjuk a Connector.Open függvényt, ahol az url paraméter értéket shttp-vel kell kezdeni. Elképzelhető, hogy nem lehetséges az shttp-vel való kommunikáció. Ilyenkor egy ConnectionNotFoundException típusú kivétel generálódik, amit egy catch blokkban kell lekezelni Műveletvégzés szálakkal Szálakra azért van szükségünk, hogy több műveletet is tudjunk egyszerre végezni. Mivel a rendszer a különböző szálakat külön hajtja végre, minden egyes szálra külön számítódik a ráeső processzor-idő (végrehajtási időszelet), sőt a szálaknak külön - külön prioritást (fontossági szintet) is adhatunk. Ennek is megvan az előnye, hisz egyes részfeladatokat, amik nagyon lelassítanák programunkat külön szál(ak)ba, a program másodlagos vagy további szálaiba tehetőek. Például ha egyszerre akar az alkalmazás hálózaton keresztül 34