Szakdolgozat
OROSZ TIVADAR Műszaki informatikai szak, gazdasági informatikai szakirány, nappali tagozat
Kecskeméti Főiskola Gépipari és Automatizálási Műszaki Főiskolai Kar KECSKEMÉT 2005
Kecskeméti Főiskola Gépipari és Automatizálási Műszaki Főiskolai Kar KECSKEMÉT 2005
BIZTOSÍTÁSI ÜGYNÖKVÁLASZTÓ ALKALMAZÁS SYMBIAN ÉS JAVA KÖRNYEZETBEN
Készítette:
Orosz Tivadar 2005
Konzulensek: Ercsényi András Nagy Gusztáv
2
Tartalomjegyzék 1. Feladatértelmezés......................................................................................................................4 1.1 Célkitűzések..........................................................................................................................4 1.2 A feladatkiírás elemzése.......................................................................................................5 2. Bevezetés a Symbian operációs rendszerbe........................................................................6 2.1 Az operációs rendszer múltja................................................................................................6 2.2 Az okos telefonok képességei...............................................................................................7 2.3 A Symbian felépítése............................................................................................................9 2.4 A Nokia Series 60 Platform................................................................................................12 2.5 Egy Symbian Nokia mobiltelefon hadver felépítése...........................................................14 3. Bevezetés a szerver oldali Java programozásba...............................................................15 3.1 Java szervletek....................................................................................................................15 4. Programozás Series 60 Platform-ra..................................................................................16 4.1 Fejlesztő környezet.............................................................................................................16 4.2 Fjlesztési folyamat..............................................................................................................17 4.3 WINS emulátor...................................................................................................................19 4.4 Elnevezési konvenciók........................................................................................................20 4.5 Kivétel- és memóriakezelés a Symbian 5.6 rendszerben....................................................21 4.6 Alapítpusok.........................................................................................................................23 4.7 Sztringek használata a Symbian operációs rendszer alatt...................................................24 4.8 Fájlkiterjesztések – hogyan épül fel egy Symbian alkalmazás...........................................26 4.9 Az MVC minta alkalmazása...............................................................................................28 4.10 Az erőforrás leíró állomány..............................................................................................28 4.11 Kliens felhasználói felület.................................................................................................30 4.12 Symbian telepítő alkalmazás készítése.............................................................................32 5. A tervezés részletes leírása.................................................................................................32 5.1 Használati eset diagramm...................................................................................................33 5.2 Fogalomszótár.....................................................................................................................33 5.3 Forgatókönyvek..................................................................................................................33 5.4 Funkciók..............................................................................................................................34 5.5 Osztályterv..........................................................................................................................35 5.6 Adatbázis tervek..................................................................................................................38 6. Értékelés...............................................................................................................................38 6.1 Továbbfejlesztési lehetőségek.............................................................................................39 7. Irodalomjegyzék.................................................................................................................39
3
1. Feladatértelmezés Napjainkban, ahogy egyre kisebb méretben készülnek a hagyományos telefonkészülékekből kinőtt
mobil
telefonok,
másrészt
az
asztali
számítógépek
kisméretű
utódai,
a
kéziszámítógépek is kezdenek egyre népszerűbbé válni. Egyre nagyobb teret hódítanak a kettő ötvözéséből születő okos telefonok. Ezen készülékek ereje abban rejlik, hogy bár sokkal kisebb tudásúak, mint egy asztali PC vagy laptop, mégis mindig kéznél vannak valamint képesek egyszerűbb számítások és munkák elvégzésére és szinte bárhonnan alkalmasak adatkapcsolat felvételére más gépekkel. Ezen tulajdonságokat használja ki az úgynevezett „mostly disconnected” vagyis főként kapcsolat nélkül működő alkalmazásmodell is. Az ilyen alkalmazások képesek egyszerűbb önálló feladatok elvégzésére külső erőforrás folyamatos segítsége nélkül is. A bonyolultabb feladatok megoldására pedig időről időre felkapcsolódnak egy központi szerver gépre, amely ezen feladatokat elvégzi helyettük. A szakdolgozat egy főként kapcsolat nélkül működő alkalmazás elkészítését mutatja be Symbian operációs rendszer alatt, megoldást keresve az Allianz Hungária Biztosító Rt. úgynevezett UKR azaz ügynökkiválasztó rendszerének hatékonyabbá tételével kapcsolatban. Az alkalmazás egy egyszerű ügynökkérő szoftvert valósít meg, melyben a kliens munkaköre a felhasználó adatainak adatbázisba gyűjtése, valamint a felhasználó kívánalmainak elemzése, majd ezen adatokat egy szinkronizációs protokoll segítségével a szerverrel egyezteti. A leírás kiterjed mind a mobil kliens mind a szerver oldali szoftver felépítésére, valamint a kettő közti kommunikáció részletes leírására.
1.1 Célkitűzések A feladat egy mobil kliens és egy szerver oldali alkalmazás készítése, különös tekintettel a köztük lezajló kommunikáció és adatcsere megvalósítására. Tekintve, hogy az alkalmazás egy biztosító társaság problémájára keres választ, nem lehet elmenni a probléma üzleti jellegének tárgyalása mellett sem. Fel kell építeni egy leegyszerűsített biztosítási ügynökkiválasztó alkalmazást, mely lehetőséget kell, hogy teremtsen arra, hogy a felhasználó helytől függetlenül egyszerűen választhasson a felkínált biztosítási szolgáltatások közül. Az alkalmazás a következőképpen működik: a felhasználó az okos telefonján telepíti az alkalmazást. Mivel minden okos telefon saját, fizikai azonosítóval rendelkezik, melyet UIDnak (Unique Identification Number) hívnak, ezért alkalmassá tehetők arra, hogy a biztosító kizárólag az arra alkalmas ügyfeleinek terjeszthesse a programot. Ezáltal elkerülhető az illetéktelen felhasználás. A telepített kliens alkalmazás segítségével a felhasználó egy 4
adatbázisba mentheti a profilját. Ez hasznos, hiszen a mobiltelefonokon alkalmazott adatbeviteli lehetőségek korlátozottak, nehézkesek, így azonban elég egyszer elmenteni a személyes adatokat, a későbbiekben az alkalmazás ezt fogja felhasználni minden egyes kéréssel kapcsolatban. A felhasználónak lehetőséget kell biztosítani ahhoz, hogy mindazokat a biztosító által nyújtott szolgáltatásokat elérhesse, amelyeket az Interneten keresztül is megtehet. Elsősorban olyan biztosítási szolgáltatásokról beszélünk, melynek ügyintézéséhez egy biztosítási ügynökre, úgynevezett alkuszra van szükség. A kliens alkalmazás tehát csak összegyűjti a felhasználó igényeit, majd adatkapcsolatot tart fenn a szerver alkalmazással, frissíti annak adatbázisát és visszajelzésre vár. A visszajelzés történhet HTTP kapcsolaton keresztül is (mint jelen dolgozatban), ám a mobiltelefonok esetében célravezető lehet a saját üzenet típus alkalmazása a TCP/IP protokoll megkerülésével. A feladat terjedelme természetesen túlmutat ezen kliens alkalmazás elkészítésén, ám a cél egy modell készítése, mely lehetőséget teremt arra, hogy egy okos telefon is képes sokoldalú alkalmazások futtatására. Szerver oldalon a tervezés célja megismerkedni valamelyik jelenleg elterjedt alkalmazásszerver technológiával, továbbá jártasságot kell szerezni a manapság - mobil eszközök körében – rohamosan teret hódító Symbian operációs rendszer felépítésével, működésével. Nem utolsó sorban ki kell alakítani köztük valamilyen összeköttetést és szinkronizációs protokollt. A példa nem törekszik arra, hogy az Allianz Hungária Biztosító Rt. számára egy teljes funkcionalitással rendelkező kész alkalmazást mutasson be. A lényeg abban áll, hogy egy olyan alkalmazás készüljön el, mely jól demonstrálja a szerverrel kommunikáló mobil eszközök erejét, bemutatva hogyan kell egy ilyen alkalmazást felépíteni, milyen veszélyekre kell ügyelni, valamint vázat szolgáltat amelyre bármilyen hasonló alkalmazás is felépíthető.
1.2 A feladatkiírás elemzése A feladat konkrét megoldása előtt szemügyre kell venni egy sor ma használatos technológiát, amelyekkel a feladatot meg lehet valósítani. Meg kell ismerkedni a szerver oldalon alkalmazott legnépszerűbb szervertechnológiákkal, különös tekintettel a J2EE-re, amelyben majd az alkalmazás el fog készülni. Ezen kívűl meg kell vizsgálni a Symbian operációs rendszert, amely a mai okos telefonok nagy részének lelke. Ebben az operációs rendszerben fog ugyanis elkészülni a kliens alkalmazás. A cél elsődlegesen a kliens oldali Symbian programozás bemutatása. Sajátosságainak köszönhetően azonban a konkrét példa alkalmazás bemutatása előtt célravezető lehet az elméleti különbségek részletes taglalása is.
5
A feladat tehát egy kliens és egy szerver oldali alkalmazás elkészítése, különös tekintettel a köztük lezajló adatkapcsolat megvalósítására.
2. Bevezetés a Symbian operációs rendszerbe Napjainkban a mobilkommunikáció szerepe és piaca átalakulóban van. A pusztán távközlésre kialakított eszközökből a technológiai fejlődés, a felhasználói igények és a piaci verseny nyomására egy új eszközcsalád, az okos telefonok családja fejlődött ki. Ezek a készülékek sokrétű multimédiás képességgel, adatküldési lehetőséggel rendelkeznek, valamint különféle irodai eszközök is megtalálhatók bennük. A készülékgyártók egy igen nagy csoportja felismerte, hogy az új kihívásokra egy naprakész, közösen
fejlesztett
operációs
rendszer
jelentheti
a
leggazdaságosabb
választ.
A
készülékgyártók megállapodtak abban is, hogy az új operációs rendszernek testre szabhatónak kell lennie, hiszen a készülékek nem csak gyártónként, de termékenként is eltérhetnek egymástól, tükrözniük kell a cég egyéni arculatát. Így született meg a Symbian operációs rendszer, azon belül is anak egy testre szabott változata, a Nokia Series 60 Platform.
2.1 Az operációs rendszer múltja A Symbian operációs rendszer gyökerei az 1980-as évek végéig nyúlnak vissza. Ekkor kezdte kifejleszteni a Psion Computers a kéziszámítógépeihez a SIBO, majd az EPOC operációs rendszert. Az EPOC figyelemre méltó tulajdonságokkal rendelkezett, a kéziszámítógépek komplett irodai szoftverkészletet tartalmaztak és a beépített akkumulátoraik segítségével meglehetősen hosszú üzemidőt értek el. Az EPOC operációs rendszer fejlesztése 1998-ban állt meg az ötös verziónál. Ekkor vette át a fejlesztését a Symbian és maga az operációs rendszer is új nevet kapott : Symbian OS lett belőle. A Symbian OS jelenleg a 8.0-ás verziónál tart de már bejelentésre került a 9.0-ás változat is, melyet hamarosan kiadnak. A szakdolgozatban használt mobilkészülék egy Nokia 7610-es típusú telefon, melyben a Symbian OS 7.0s operációs rendszer került implementálásra. Magát a Symbian céget 1998 júniusában alapította a Nokia, a Motorola, a Psion valamint az Ericcson, de az azóta tartó üzleti háborúk folyamatosan változatják a részesedéseket. 1999ben csatlakozott hozzájuk a Matsushita, majd 2002-ben a SonyEriccson és a Siemens. A Symbian operációs rendszerben abszolút többséget szerzett Nokia jelenleg uralja a Symbian piacot és megoldást szállít több már – már felsorolt – Symbian tulajdonos cégnek is.
6
A Symbian számára az áttörést a 2000-ben megjelentett 6.0-ás verzió jelentette. Megjegyzendő, hogy Magyarországon a legtöbb eladott okostelefon a Symbian OS 6.0-ás verziót használja. Az első erre épülő eszköz a Nokia 9210 kommunikátor volt. A 2001. januárjában elkészült Symbian OS 6.1, majd a valamivel több mint egy évvel későbbi 7.0-s verzió már számos okos telefon alapját képezi.
2.2 Az okos telefonok képességei Az okos telefonok, mint azt a nevük is mutatja, rendkívűl fejlett tulajdonságokkal rendelkeznek. Erős processzoruk (legtöbbször ARM), nagyméretű, színes kijelzőjük, viszonylag nagy memóriájuk lehetővé teszi személyes információkezelő (PIM – Personal Information Manager) és egyéb komplexebb alkalmazások használatát. Fontos ugyanakkor szem előtt tartani, hogy az okos telefonok felhasználói a régi mobiltelefonoknál már megszokott egyszerű kezelhetőséget és megbízhatóságot várják el. Az erőforrások pazarló használata, a mobiltelefon újraindítása vagy éppen egy hibás szoftver javítócsomagokkal történő foltozása nem megengedhető az okos telefonok esetében. A fenti problémákra mind-mind figyelni kell valamint tekintettel kell lenni arra, hogy a felhasználók nem szívesen várakoznak hosszú másodperceket például egy hívás kezdeményezésére csak azért, mert az operációs rendszer éppen valamilyen belső működést végez. Ebből következően a Symbian operációs rendszer árnyaltabb és speciálisabb, mint azt első ránézésre gondolni lehetne. A Symbian filozófiája szerint a mobiltelefonok piacát öt jellemző teszi egyedivé, majd mindezek az alapelvek együttesen határozzák meg az operációs rendszerrel szemben támasztott követelményeket: 1.) A mobiltelefon kicsi és hordozható legyen.A hardver méretének kezelhetőnek és elég kompaktnak kell lennie. A miniatürizálás nem mehet a végtelenségig, a használhatóságot is figyelembe kell venni. A telefonra minél nagyobb kijelzőt és kényelmes beviteli eszközt kell felszerelni. A kis méret nyilvánvalóan felveti az energiafogyasztás problémáját is. Minél bonyolultabb képességű egy okos telefon, minél nagyobb a kijelzője, stb, annál nagyobb lesz az enrgiafogyasztása is. A helyzetet csak nehezíti, amennyiben a készülék mérete apró, így az akkumulátor kapacitása is hagy kívánni valót maga után. A mobiltelefonok gyakran napokig, vagy akár hetekig is be vannak kapcsolva. Eközben azonban nem szabad újraindulniuk vagy összeomlaniuk. Elinduláskor szintén nem várakoztathatják hosszasan a felhasználót.
7
2.) A minél szélesebb felvevőpiac megcélzása a cél. A tömegpiacra szánt mobiltelefonoknak megbízhatónak kell lenniük, hisz ez minden készülékgyártó józan üzleti érdeke is egyben. Semmilyen körülmények között nem megengedett, hogy adatvesztés lépjen fel, hiszen a készülék nélkülözhetetlen és pótolhatatlan információkat is tárolhat tulajdonosa számára. Az operációs rendszernek még szélsőséges körülmények között sem szabad összeomlania. Fontos, hogy minden memória szivárgást (memory leaking) elkerüljön a programozó, ezáltal az erőforrásokat gazdaságosan lehet felhasználni. A Symbian operációs rendszerben egy elég bonyolult, moduláris felépítésű, jól használható hibakezelő keretrendszer található. 3.) Fontos szempont a nem állandó kapcsolatok kezelése. Egy mobiltelefonnal folyamatosan kapcsolatot tartunk a külvilággal, hiszen ha mást nem is, de legalább egy adótoronyhoz mindenképpen – vezeték nélkül – csatlakozni kell. A felmerülő hibákra azonban fel kell készülni, hiszen elmehet a térerő és egyéb nem várt események is bekövetkezhetnek. A vezeték nélküli kommunikáció tehát nem folyamatos, a készüléknek azonban ekkor is működőképesnek kell lennie, vagyis nem működhet vékony kliensként. Kezelnie kell az adatátvitelből eredő hibákat valamint tájékoztatnia kell a felhasználót. 4.) Az
eszközök
sokfélesége
mérvadó.
Az
eszközök
sokfélesége
látszólag
ellentmondásos helyzet elé állítja a fejlesztői közösséget. Amint az a bevezetőben is említve lett, a készülékgyártók szeretnék, ha a a fejlesztések a saját egyedi arculatukat tükröznék. Az ellentmondás feloldását az operációs rendszer alapjának és felhasználói felületének (Usre Interface) különválasztása jelenti. Ez a gyakorlatban annyit jelent, hogy készülékgyártótól függetlenül, az a programozó, aki Symbian alá képes alkalmazásokat írni, képes minden Symbian okos telefonra ezt megtenni. A különbség a fejlesztés során csak annyi, hogy adaptálnia kell a felhasználói felületet az adott telefon készülékre is. A Nokia esetében ez a felhasználói felület a Series 60 nevet kapta. A 60-as szám a kijelző méretére és a hardver felépítésére utal, melyről a későbbiekben még részletesen is szót ejtünk. A Series 60 Platform a Nokia által kifejlesztett Uim amelyet azonban már más gyártóknak is továbblicencelt, például a Siemens-nek. 5.) A mobiltelefon nyitottsága alapkövetelmény. Egy okos telefon esetében alapvetően elvárható, hogy nyitott legyen a külső fejlesztések irányába. Az operációs rendszer elfogadottságát és népszerűségét növeli, ha számos alkalmazás megtalálható hozzá. A 8
programozás elterjedt nyelveken (C++, Java), objektumorientált megközelítésben folyik és az interneten a http://www.forum.nokia.com oldalról bárki által letölthető fejlesztőkészletek illetve eszközemulátorok állnak rendelkezésre.
2.3 A Symbian felépítése Ahhoz hogy megértsük egy fentebb említett Symbian kliens működését, nagyon fontos megértenünk a Symbian operációs rendszer felépítésének vázlatát:
2.3.1. ábra A Symbian operációs rendszer felépítése
A legalsó, integrációs rétegre alacsonyszintű szolgáltatások épülnek, majd ezt egy middleware szint követi (grafikai, kommunikációs és egyéb szolgáltatásokkal), majd az alkalmazásszintű szolgáltatások jönnek, végül legfelül a felhasználói interfész – igény szerint testre szabhatóan – elemei találhatóak. Az architektúra ugyancsak tartalmaz egy fejlett, mobil környezetre optimalizált Java futtatókörnyezetet is. A legalsó réteg nem más, mint egy kernel- és hardverintegrációs szint, amely a különböző eszközök felépítésbeli eltéréseit fedi el. Így lehetővé válik, hogy az operációs rendszer új hardvereszközökre való telepítésekor ne kelljen a felsőbb szintekben módosítani. Ez a fajta integráció éppen megfelelő teljesítményt biztosít. A mikrokernel közvetlenül a processzorban fut, melynek natív környezete a 32 bites ARM processzor.
A
mikrokernel
privilegizált
üzemmódban
fut.
A
kernel
többszálú
programvégrehajtást biztosít, ahol a legnagyobb prioritást éppen a kernelszálnak tartja fenn, amely a kliensek kéréseit szolgálja ki. Felhasználói kód csak a User könyvtáron keresztűl
9
kerülhet kernel módba, aminek – mint a példaprogramban látni fogjuk – nagy jelentősége lesz a hibák megfelelő kezelésében. Az eszközmeghajtók szerepe a hardver-szoftver együttműködés megteremtése, így például a kijelző, a billentyűzet vagy akár a kommunikációs csatornák elérésének biztosítása, a konkrét hardverfüggő részek implementálásával. A meghajtók általában két részre bonthatók: fizikai meghajtókra (Physical Device Drivers, PDD), illetve logikai meghajtókra (Logical Device Drivers, LDD). Ez utóbbiak egy adott eszköztípusra vonatkozó hasonló tulajdonságok kezelésére tartalmaznak magasabb szintű funkcionalitást. Az alapszolgáltatásokat nyújtó szint leginkább az operációs rendszer többi komponensének az alapját adja. Egyik legfontosabb eleme a fájlszerver, amely a fájlrendszerhez biztosít megosztott hozzáférést. Beépített moduljai mellé újaindítás nélkül, dinamikusan adhatunk újabb elemeket. Az alacsonyszintű szolgáltatások közé tartoznak többek között a különböző biztonsági szolgáltatások, a beépített adatbázis-kezelés, az energia-gazdálkodás, a karakterkódolási eljárások, az XML-feldolgozás, valamint az alkalmazások beállításának kezelése. Az operációs rendszer legfontosabb elemét jelentő szolgáltatásokat egy middleware rétegbe gyűjtötték össze. A biztonsági szolgáltatások két alapvető része a kriptográfiai modul, valamint a tanúsítványkezelő modul. Az operációs rendszer biztosítja az összes fontos és elterjedt kriptográfiai algoritmust, mint a szimmetrikus (DES, 3DES, RC2, RC4, RC5) és asszimmetrikus
(RS,
DSA,
DH)
rejtjelező
algoritmusokat
vagy
a
különböző
hashfüggvényeket (MD5, SHA1, HMAC). A multimédia terén nyújtott funkcionalitást keretrendszerekbe és programozói könyvtárakba szervezték. A multimédia-szerver az audio- és videoanyagok felvételét és lejátszását támogatja, valamint különböző képmegjelenítési és feldolgozási képességekkel rendelkezik. A támogatott formátumok egyébként is széles skálája természetesen bővíthető. A Window szerver egy hatékony ablakkezelő rendszer, amelynek alapvető feladata, hogy megossza a képernyőt és a beviteli eszközöket az alkalmazások között. Ugyancsak fontos megemlíteni a kommunikációt támogató szolgáltatások gyűjteményét, hiszen egy mobiltelefon eszköz estében, ezek egyike a legfontosabb lehetőségeknek. A kommunikációs réteg három alapvető részre oszlik: 1.) Telefónia alrendszer A telefónia alrendszert a gyártók valósítják meg. Ennek integrálása teszi lehetővé az operációs rendszer egyéb részei számára a komplex adatkommunikáció biztosítását.
10
2.) Rövid hatótávolságú kommunikáció A rövid hatótávú vezeték nélküli kommunikáció (Personal Area Network, PAN) illetve a soros kommunikáció szerteágazó lehetőségeket kínál. A pont-pont kapcsolat történhet USB porton, infrán vagy Bluetooth kapcsolaton keresztűl. 3.) Hálózati szolgáltatások Az operációs rendszerben megtalálható TCP/IP stcak, HTTP, valamint WAP stack megvalósítás és természetesen minden fontos protokoll implementálva van hozzájuk. A fent említett middleware rétegben található meg továbbá az alapvető grafikai szolgáltatásokat nyújtó könyvtár, amely a képernyő és a billentyűzet kezelésést biztosítja. A GDI-t (Graphical Device Interface) használhatjuk a képernyőre, nyomtató eszközre vagy memóriába történő rajzolás esetén is. Ugyancsak az operációs rendszer szolgáltatásai közé tartozik a mobil eszköz számítógéppel való összekapcsolását biztosító eszközkészlet. Az operációs rendszer következő rétege alkalmazásszintű szolgáltatásokat biztosít. Ebben olyan alkalmazásmotorokat találunk, amelyek a mobiltelefonokban szokásos, a felhasználó adatait tároló és kezelő programok (Personal Information Management, PIM) készítését könnyítik meg és teszik egységessé. A személyes információkezelő modul különböző naptárés határidő funkciókhoz, személyes kapcsolatok kezeléséhe, teendőlisták kialakításához ad támogatást. Az üzenetkezelő keretrendszer az elterjedt üzenettípusok (SMS, EMS, MMS, email, fax, BIO) küldését és fogadását végző alkalmazások készítését könnyíti meg. A böngészést segító alrendszer általános szolgáltatásokat biztosít mind a beépített, mind a külön telepített tartalommegjelenítőknek. A Symbian operációs rendszer tartalmaz még egy OMA (Open Mobile Alliance) SyncML motort is adatszinkronizáció céljára, amely például gázóra leolvasó programok készítésére alkalmas. A rendszer tartalmaz egy Java virtuális gépet is (Java Virtual Machine, JVM) amely a mobileszközökre írt, hordozható alkalmazások futtatását teszi lehetővé, bár a dolgozatnak nem feladata a kliens oldali Java alkalmazás elkészítése. A felhasználói interfész szintje nagyfokú rugalmasságot biztosít a gyártóknak a megjelenítéssel kapcsolatos különböző elképzelések megvalósításában, miközben az operációs rendszer szolgáltatásai a közös programozói interfész (API) miatt ugyanúgy érhetőek el.
11
2.4 A Nokia Series 60 Platform A Series 60 Platform a Symbian operációs rendszerre épülő felhasználói felület néhány kiegészítéssel, mely tükrözi a Nokia vállalat egyedi arculatát a menürendszer felépítésében és szerkezetében valamint igazodik a Nokia készülékek speciális hardver felépítéséhez is. Jelenleg A Nokia Series 60 Platformját tekinthetjük a Symbian operációs rendszer legelterjedtebb felhasználói kiterjesztésének.
2.4.1. ábra Nokia Series 60 Platform felhasználói felület
Ebből következik, hogy a Series 60 Platform elsősorban egy jól konfigurálható grafikus felhasználói interfész könyvtárral bővűlt, amely lehetővé teszi a piacon nem véletlenül sikeres Nokia felhasználói felület kialakítását és testre szabását. A 2. ábrán jól látható egy Symbian alkalmazás felhasználói felülete, amint azt a Series 60 Platformra optimalizálták. A hardver felépítésből következően is, a bevitelre és vezérlésre a már megszokott nyomógombokon kívűl két bal és jobb oldali gomb szolgál, melyeket Soft Key-nek neveztek el, s melyeknek nem honosodott meg magyar megfelelője eddig. Az ikonok elrendezése az egyik legkedveltebb formát, az úgynevezett rácsos elrendezést követi. A két Soft Key címkéje szabadon megváltoztatható. A nyelv mindig az adott készülék nyelvbeállításától függ. A két Soft Key között található nyíl az öt állapotú navigációs gomb státuszát jellemzi. A navigációs gomb tulajdonképpen egy joystick-re hasonlít, melyet a négy irányba lehet mozgatni, valamint lenyomva egy ötödik állapot érhető el.
12
A Series 60 felület különböző részekre osztahó és mindegyik külön-külön programozható:
2.4.2. ábra A Series 60 Platform felhasználói felületének részei
Amint az a 3. ábrán jól látható, egy Series 60 alkalmazás jól elkülöníthető három részre tagolható. A legfelső státusz panel (status pane) az alkalmazás és a készülék állapotáról tájékoztatja a felhasználót, de a megjelenítése szabadon programozható C++ nyelven. Általában az alkalmazás ikonja, neve, valamint a készülék energia-ellátását biztosító akkumulátor töltöttségi állapota és a térerő tekinthető meg. A státusz panel további részekre bontható:
2.4.3. ábra A státusz panel részei
A felirat panel (title pane) alkalmas az alkalmazás nevének vagy egyéb tartalomtól függő állapotának kijelzésére. Általában az éppen aktuális ablak nevét lehet leolvasni róla. A környezet panel (context pane) leginkább az alkalmazást reprezentáló ikont jeleníti meg, mely dinamikusan változtatható. Fontos megjegyezni, hogy maga az ikon is tartalmazhat beépített, programozható dinamikus elemet. Ilyen például egy óra mutatója. A navigációs panel (navi pane) lesődleges célja, hogy információval lássa el a felhasználót az éppen aktuális nézetben, valamint, hogy tanácsokkal lássa el a program használatával kapcsolatban. A normál PC-n futó Windows alkalmazásokhoz hasonlóan itt is beszélhetünk egy nézeten belül több fülről, melynek kijelzése szintén ennek a panelnek a feladata:
2.4.4. ábra A navigációs panel nézeteinek fülekre felosztása
13
A térerő panel legfőképpen csak a GSM jelerősség kijelzésére szolgál, valamint az esetlegesen aktív kommunikációs műveletekről (pl.: GPRS) szolgáltat információt. A felhasználói felület következő, középső és egyben legnagyobb teret kapott felülete a fő panel (main pane) amely a tulajdonképpeni alkalmazás megjelenítési eszköze. Ebben a panelben lehet tájékoztatni a felhasználót a program által szolgáltatott adatokról, itt lehetne elhelyezni a különféle vezérlőket, amelyet tetszés szerint testre szabhatunk és itt kerülhet sor a felhasználói adatbevitelre is. Kétféle fő panelt különböztetünk meg. Az egyik lehetséges mód, ha dialógus ablakokat használunk (hasonlóan egy Visual Basic alkalmazás Form-jához) és ezen keresztűl férünk hozzá a vezérlő elemekhez, valamint ezen keresztűl alakítjuk ki a megjelenítést. A dolgozat ezt a fajta megvalósítási módot fogja bemutatni. A második lehetőség a közvetlen hozzáférés lenne a hardver grafikai függvényei által, de a művelet leginkább csak bonyolult multimédiás és egyéb grafikai műveleteket tartalmazó alkalmazások esetében lehet hasznos. Ebben az esetben nézetekről és nem dialógus ablakokról beszélünk. Természetesen több nézetet is létrehozhatunk, de egy nézetet is alakíthatunk dinamikusan a program életének egésze során. A vezérlő panel (control pane) a két vezérlő billentyű (soft key) címkéjét szabályozza valamint az ötállású navigációs gomb pillanatnyi állapotát mutatja a felhasználó felé. A vezérlő panel felépítését a 6. ábra mutatja.
2.4.5. ábra A vezérlő panel felépítése
Az opciók felirat természetesen a bal oldali vezérlő gomb megnyomásakor aktivizálódik (és általában egy opció menürendszert jelenít meg), míg a jobb oldali vezérlő gomb megnyomása a vissza feliratú címkéhez tartozó parancsokat hajtja végre. A két címke között elhelyezkedő nyilak az ötállású navigációs gomb pillanatnyi helyzetét szimbolizálják, amely jelen esetben azt jelenti, hogy a dialógus ablakban megjelenített tartalmat görgetni lehet mind lefele, mind felfele, de miáltal a lefelé mutató nyíl vastagabb, mint a felfele mutaté, ezért lefelé több nem látható tartalom van, mint felfelé.
2.5 Egy Symbian Nokia mobiltelefon hadver felépítése A Nokia egy specifikációt tett közzé a különböző készülékgyártókat segítve, melyek minimum követelményeknek tekinthetők mindazon cégek számára, akik licencelni szeretnék a platformot. Elsősorban a kijelző méretét szabályozták le, melynek pontosan 176 × 208 pixel felbontást
kell
prezentálnia,
valamint
minimálisan
14
4096
féle
színt
kell
tudni
megkülönböztetnie. Ettől sem lefele, sem felfele jelenleg nem térhet el egyik készülék sem. Mindössze egyetlen fő processzor található meg mindegyik készülékben, mely egy 32 bites ARM processzorra épül. Az ARM processzorok nagyfokú megbízhatóságukról híresek, eddig elsősorban hadászati célokra használták főként beépített eszközökben. A 32 bites ARM processzor csak ajánlásnak tekinthető, némely készülékek THUMB processzort használnak, de ez ma már igen ritka. Valamennyi Nokia Series 60 Platform-ot futtatni kívánó mobiltelefonnak minimálisan 16 MB ROM memóriával kell rendelkeznie és beépített RAM memóriájának kapaítása 8 MB kell, hogy legyen. A memória természetesen bővíthető különböző MMC kártya segítségével.
3. Bevezetés a szerver oldali Java programozásba A Java eredetileg egy erős kliens oldali alkalmazás megközelítés volt a 90-es évek közepén. Hamarosan azonban elfogadottá, napjainkban pedig szinte szabvány technológiává vált a szerver oldali programozást területén. A Java szervletek valamint az adatbázis kezelési réteg hathatós eszközt nyújt a programozó kezébe, ha logikusan felépített szerver oldali programozásban gondolkodik.
3.1 Java szervletek A Symbian kliens által küldött adatok kiszolgálását és feldolgozását, valamint az adatok egy MySQL adatbázisba történő elhelyezésének legkézenfekvőbb módja egy Java szervlet alkalmazása. Egy szervlet nem más, mint az alkalmazás kiszolgáló bővítése, tulajdonképpen egy Java osztály, amely dinamikusan betölthető és így bővíti a kiszolgáló funkcióit. A szervletek kizárólag a kiszolgálón belül futnak és képesek kezelni ugyanazon processzen belül a különböző szálakat. A szervlet technológia hatákony és méretezhető választás a szerver oldali alkalmazás megvalósítására. A példában található Java szervlet egyetlen feladata a Symbian kliens kéréseire való válaszadás. Fogadja a Symbian rendszer által küldött felhasználói profilban található személyes adatokat, valamint gondoskodik azok adatbázisban való elhelyezéséről. Az adatokat kielemzi és siker esetén üzenetet küld a biztosító társaság megfelelő fiókjába, melyben értesítést küld egy új igénylésről.
15
4. Programozás Series 60 Platform-ra Mielőtt nekilátnánk a szakdologzat programjának elemzéséhez nem árt tudni, hogy a megírt forráskódból milyen lépésekkel állíthatunk elő futtatható állományt, valamint, hogy egyáltalán hogyan hozhatunk létre egy Symbian keret alkalmazást. Tudni kell, mire van szükség az egyes lépések megtételéhez. Tekintve, hogy bár a Symbian operációs rendszer a C++ nyelvre épül, jelentős különbségek lehetnek a nyelv eredeti változata és annak Symbian megfelelője között, így ezek a különbségek is bemutatásra kerülnek, különös tekintettel a forráskód áttekinthetőségére, az osztályok jelölési rendszerére, valamint a forrás állományok kiterjesztésére is, mely nagymértékben segíti az alkalmazás pontos megértését.
4.1 Fejlesztői környezet A fejlesztéshez először is szükség van egy fejlesztői környezetre (Software Development kit, SDK). A dolgozatban ismertetésre kerülő biztosítási ügynök igénylő alkalmazás (továbbiakban: ügynökkérő rendszer, UKR) egy Symbian OS 7.0s operációs rendszert futtató Nokia 7610-es mobiltelefonon került tesztelésre. Ehhez az operációs rendszerhez kétféle SDK-t lehet választani. Az egyik a Microsoft .NET fejlesztőkörnyezet alatt teszi lehetővé a fejlesztést, a másik változat a Microsoft Visual C++ 6.0 fejlesztői környezet alatt vézi el a szükséges hibakeresési és fordítási műveleteket. A példában az utóbbi fejlesztői környezet került kiválasztásra, azaz a Nokia Series 60 SDK 2.0-ás verziója. Az SDK tartalmaz egy emulátort, amelyen Windows környezetben próbálhatjuk ki programunkat. A 7. ábrán jól látható, hogy az emulátor egy komplett okos telefont szimbolizál, amelyen megtalálható maga a felhasználói felület, valamint az összes olyan gomb, ami egy valódi készüléken is megtalálható lenne.
16
4.1.1. ábra A Series 60 emulátor
Természetesen az emulátoron futtatott alkalmazás pontosan úgy reagál a felhasználó által kiváltott eseményekre, mintha az egy igazi Symbian képes okos telefonon futna. Az SDK továbbá tartalmaz egy GNU C++ fordítót, amellyel akár az emulátorhoz, akár az igazi készülékhez fordíthatók programok. Az SDK szintén tartalmaz minden szükséges fájlt, amely a fordítási folyamathoz szükséges (pl.: fejlécfájlok, könyvtárak, fordítási segédprogramok). Az SDK igen fontos részét képezi a dokumentáció, mely elengedhetetlenül szükséges néhány ismert függvény pontos paraméterlistájának és a paraméterek jelentéseinek megtekintéséhez. Az SDK-ban található Perl interpreter a fordítási segédprogramokhoz szükséges, mivel azok egy jelentős része Perl nyelven íródott. Létezik fejlesztőeszközzel egybecsomagolt SDK is. Az
ilyen
fejlesztői
fejlesztőkészletét
készletek
támogatják,
elsősorban de
elvétve
a
Metrowerks
található
a
cég
Borland
CodeWarrior cég
C++
nevű
Builder
fejlesztőkészletéhez is megfelelő verzió. A Microsoft VisualStudio-t azért érdemes használni, mert tartalmaz egy alkalmazás varázslót, ami egy üres Symbian keretrendszert generál a programozónak. Az eljárás igen hasznos még abban az esetben is, ha a fejlesztő tisztában van a fejlesztési folyamat minden egyes lépcsőfokával.
4.2 Fejlesztési folyamat Elsősorban azért érdemes már a konkrét alkalmazás elemzése előtt bezsélni a Symbian fejlesztési folyamatról és azon belül is a Symbian fordítási láncról, mert megértésével
17
közelebb jutunk a Symbian logikájához, felépítéséhez, gondolkodásmódjához. Első lépésként azt kell tudni, milyen lépéseken keresztül kell az SDK-ban található egyszerű segédprogramok használatával az elkészült forrásfájlokat lefordítani. Egy Symbian program egy vagy több projektfájlból áll. Ezeket az állományokat egy bld.inf nevű állományban kell felsorolnunk: PRJ_MMPFILES \PROJECT\UKRCustomer\group\UKRCustomer.mmp
Amint látható, a bld.inf fájl az UKR program esetében mindössze egyetlen projektfájlból áll, mely egy mmp kiterjesztésű fájlt tartalmaz, ez a projektfájl. A projektfájlban fel kell sorolni a fordításban résztvevő forrásfájlokat, a fejlécfájlok keresési útvonalát, a használt könyvtárakat és egyéb beállításokat, s majd csak ezután történhet a tényleges fordítás. A felhasznált mmp állomány a következő: TARGET UKRCustomer.app TARGETTYPE app UID 0x100039CE 0x0FCE35BD TARGETPATH \system\apps\UKRCustomer SOURCEPATH ..\src SOURCE UKRCustomerApp.cpp SOURCE UKRCustomerAppUi.cpp SOURCE UKRCustomerDocument.cpp SOURCE UKRCustomerDialog.cpp RESOURCE ..\data\UKRCustomer.rss RESOURCE ..\data\UKRCustomer_caption.rss LANG SC USERINCLUDE . USERINCLUDE ..\inc SYSTEMINCLUDE . \epoc32\include LIBRARY euser.lib apparc.lib cone.lib eikcore.lib LIBRARY eikcoctl.lib avkon.lib LIBRARY eikdlg.lib LIBRARY bitgdi.lib fbscli.lib ws32.lib gdi.lib LIBRARY efsrv.lib estor.lib edbms.lib bafl.lib commdb.lib LIBRARY CommonEngine.lib esock.lib insock.lib START BITMAP allgraph.mbm HEADER SOURCE c24 bckgrnd.bmp END AIF UKRCustomer.aif ..\aif UKRCustomeraif.rss c8 context_pane_icon_mask.bmp list_icon.bmp list_icon_mask.bmp
context_pane_icon.bmp
A projektfájl szerkezete összetettnek tűnhet, de a belőle automatikusan generált makefile fájlhoz képest egyértelműek az előnyei. A TARGET direktíva a készítendő állomány nevét adja meg. A TARGETTYPE azért szükséges, mert egy állomány neve nem azonosít konkrét
18
fájltípust, így ezt külön specifikálni kell. A UID (Unique Identification Number) a Symbian programok egyik nagyon fontos összetevője. Ha valaki kereskedelmi alkalmazást kíván készíteni, kötelezően igényelnie kell egy ilyen egyedi program azonosító számot a Nokia-tól annak érdekében, hogy az egyes globális alkalmazások között ne léphessen fel összeakadás. Az UID tehát egy 3 részből álló állományazonosító. A TARGETPATH a Symbian operációs rendszer fájlrendszerén belüli célkönyvtárat tartalmazza. A Symbian esetében egy valódi készüléken az összes alkalmazás a \System\Apps könyvtárba kerül. A Symbian operációs rendszer kétféle módot ismer a különböző vezérlő elemek dialógus ablakokon való elhelyezésére. Az egyik módszer, melyet a példa is támogat, amikor egy erőforrásállományon belül (egy úgynevezett RSS állomány) van definiálva a vezérlő, vagy közvetlenül dinamikus úton kerül előállításra. Természetesen erőforrásállományból is van lehetőség a vezérlő későbbi dinamikus változtatására. Az erőforrásállomány mindazonáltal kötelező még akkor is, ha mindent dinamikusan kíván a fejlesztő előállítani. Pontosan ezen okból van szükség a projektfájlban a SOURCEPATH direktívára, amely a szükséges erőforrás állományt sorolja fel. Miután minden szükséges forrásfájl és projektfájl a helyén van, megkezdődhet a tulajdonképpeni fordítási folyamat. A fordítás történhet a VisualStudio-ból közvetlenül, de az átláthatóság kedvéért inkább a konzolról futtatható fordítási folyamat kerül bemutatásra. Első lépésként
a bldmake nevű eszközzel létre kell hozni egy abld.bat fájlt. Ezutóbbi
meghívásával történik ugyanis a későbbiekben a célplatfrom kiválasztása. Amennyiben a készülék processzorára szeretnénk lefordítani az alkalmazást, akkor célszerű speciális Symbian telepítőállományt készíteni. Ez egy egységes formátumú fájl (Symbian Installation System, SIS). Az elkészült SIS fájl a készülékre való áthelyezés után (adatkábelen, infrán vagy Bluetooth kapcsolaton) közvetlenül telepíthető.
4.3 WINS emulátor Az SDK nagyon fontos részét képezi az emulátor, mellyel kipróbálhatjuk és tesztelhetjük a programot a készülékre telepítés nélkül is, sok időt és energiát megtakarítva. Fontos azonban felhívni a figyelmet a Windows alatt futó Symbian emulátor néhány lényeges különbségére egy valódi Symbian-t futtató okos telefonnal összehasonlítva. Az emulátor által használt alkalmazások x86 processzorra vannak lefordítva, vagyis az emulátor nem emulálja a készülék processzorának utasításkészletét, azaz nem bináris szintű a kompatibilitás, hanem forráskódszintű. Ez annyit jelent, hogy a C++ nyelven írt alkalmazásunkat fordíthatjuk többféle platform alá, melyek közül az egyik az x86 processzoron futó emulátor. A
19
különbségek persze lényegesek, hiszen az emulátor segítségével megfelelő alkalmazások segítségével lehet csak SMS üzenetet küldeni SIM kártya nélkül, de ilyen SDK specifikus különbség lehet a TCP/IP kommunikáció kezelése is. Az említett eltérések nem minden SDK esetében jelentkeznek, egy közös eltérés azonban mindig van: A WINS emulátor egy Windows processzben fut, míg a valódi készüléken több processz fut, melyek közül az általunk írt program csak az egyik. Különbség tapasztalható továbbá
az erőforrások
tekintetében is. Egyes számítások a mai PC-ken nagy valószínűséggel gyorsabban futnak le, mint az igazi készülékeken. Az emulátor alatt rendszerint nem fogyunk ki a memóriából sem, míg egy okos telefono ez könnyen megtörténhet. A merevlemez tároló kapacitásától függően áll rendelkezésre megfelelő tároló hely, mivel az egyes készülékmeghajtókat egy-egy könyvtár képviseli a merevlemezen. Összességében a Symbian C++ programozói interfészét sikerült nagyon jól lefednie a Windows emulátornak, a különbségek a legtöbb esetben nem fetünőek. Ennek ellenére a programot érdemes igazi készüléken tesztelni, hogy a lényeges eltérések időben kezelhetők legyenek.
4.4 Elnevezési konvenciók Az elnevezési konvenciók fontosak abból a szempontból, hogy a mások által írt kódot el tudjuk olvasni, azonban a Symbian esetében különös jelentősége van, tekintve, hogy az elnevezések jelentős eltérést mutatnak a hagyományos C++ konvenciók között. A Symbian rendszer megfelelő elnevezési konvencióinak alkalmazásával ugyanis a programozó sokkal jobban oda tud figyelni a különböző memória- és hibakezelési problémákra. Az egyik leglényegesebb eltérést az osztályok nevei mutatják. A Symbian platformon az egyes osztályok nevei az esetek nagy részében a T (type), C (class), M (mixin), R (resource) betűkkel kezdődnek, melyek komoly információt hordoznak a fejlesztő számára. A T osztályok egyszerű típusokat jelentenek. Az ilyen egyszerű, valamilyen értéket reprezentáló osztályok nem rendelkeznek semmilyen külső objektummal, erőforrással, és ezért destruktorra sincs szükségük. A legtöbb esetben az ilyen egyszerű osztályok konstruktor nélküliek. Megjegyzendő, hogy az összes C++ alaptípusnak van T-vel kezdődő, Symbian megfelelője is, például: Tint, az int típus helyett). Memóriakezelés szempontjából azt mondhatjuk, hogy az ilyen típusú objektumok általában a stack-en foglalnak helyet, mint lokális változók.
20
A másik leggyakrabban használt osztálytípus a T osztályok mellett a C osztályok. Ezek valamilyen osztályhierarchia részei. Mindegyik C osztály a CBase osztályból származik. Memóriakezelés szempontjából különös figyelmet kell rájuk fordítani, mert rendszerint más objektumokat is birtokolnak. Az ilyen objektumok példányosítása két fázisból áll, hiszen a Symbian rendszerben fontos szerep jut a kétlépcsős konstruktor alkalmazásának. A destruktor meghívásának elmaradása nem megengedhető, így ezen osztályok példányainak nem a stacken kell helyet foglalni, hanem a heap-en. Az R osztályok erőforrásokat reprezentálnak, vagyis valamilyen szerver szerepű program által birtokolt erőforrásra tartalmaznak egy azonosítót. Ha az adott erőforrásra szükségünk van, akkor egy R osztállyal tudjuk jelezni a tulajdonos felé. Az R osztályok ténylegesen nem tartalmazzák az erőforrást, csak annak valamilyen azonosítására szolgálnak, ezért helyet foglalhatnak a stack-en is. Az R osztályoknak a C osztályokkal ellentétben nincs közös ősosztálya. Memóriakezelés szempontjából a legegyszerűbbek az M osztályok. Ezek az objektumorientált szemléletben az interfészként megjelenő kategóriát képviselnek. Egy ilyen osztály nem azért készül, hogy objektumpéldányokat lehessen belőle létrehozni, hanem, hogy az interfészt megvalósító osztályok mindegyike egységesen örökölhessen belőle. Fontos tudni, hogy a Symbian-beli öröklődés a C++-ban megszokottnál szigorúbb.
4.5 Kivétel- és memóriakezelés a Symbian rendszerben A memóriakezelés a mobiltelefonok világában kényes téma tekintettel a korlátozott erőforrásokra. A Symbian operációs rendszert az okos telefonok számára fejlesztették ki. Ezekben az eszközökben kevesebb memória és kisebb számítókapacitás áll rendelkezésre, míg az alkalmazásoknak sokkal tovább kell újraindítás nélkül futniuk. Érthető, hogy a memóriaszivárgás kiküszöbölésére különös gondot kell fordítani. A Symbian rendszerben a C++-ban megszokott kivételkezelés nem használatos, melynek nagyon fontos oka van. A Symbian elődjének, az EPOC rendszernek a fejlesztésekor a C++ fordítók még nem ismerték a kivételeket, valamint a C++ kivételek túl általánosak voltak és nagy többletmunkát kívántak meg, míg a Symbian igényeinek megfelelő kivételkezelés egykét konvenció bevezetésével és használatával sokkal kisebb erőforrást emészt fel. Annak a programozónak, aki okos telefonra szeretne fejlett programot írni, beható ismeretekkel kell rendelkeznie a memóriaszivárgások elkerülése érdekében.
21
A Symbianban a hiba jelzésérea User könyvtár Leave metódusa szolgál. Ez annyit jelent, hogy a User::Leave hívás logikailag megfelel a C++-ban megszokott throw-nak (vagy a Javaban megszokott throws-nak), mely egy adott típusú kivételt dob. Jelen esetben a kivétel típusa egy számot jelent. Minden függvény, amely fel van készítve a kivételkezelésre, L betűre végződik. Az egyik legismertebb kivételkezelő metódus a Symbian rendszerben a dinamikus memóriafoglalás a new operátor használata. Az operátornak, a többi szokványos C++ operátorhoz hasonlóan létezik egy felüldefiniált változata, a new (ELeave), amelyik akkor dob kivételt, ha elfogy a memória. Míg a C++-ban lévő throw esetében a deklarációt a fordító ellenőrzi, addig a függvények záró L betűjének helyes használatára maguknak az alkalmazás fejlesztőknek kell figyelniük. Tekintve, hogy egy okos telefon esetében kritikus jelentőségű a memória és a kivételek megfelelő kezelése, ezért a Symbian alkotói kitaláltak egy olyan mechanizmust – hasonlóan a Java nyelv szemétgyűjtő (garbage collector) mechanizmusához – amely automatikusan összegyűjti mindazokat az objektumokat, program részeket, amelyekre a program futásának szempontjából nincs szükség, majd felszabadítja azokat. Másrészről sajnálatos módon a heap-en a new operátorral lefoglalt objektumoknak nem feltétlenül hívódik meg a destruktora, ha kivételt dob a metódus, ez pedig akaratlanul is megengedhetetlen mmóriaszivárgáshoz vezet. Ezért a heap-en lefoglalt objektumok mutatóit el kell tárolni valamilyen erre alkalmas helyen, így ha hiba történik, akkor a hibakezelő rutin az összes ilyen objektumot szabályosan fel tudja szabadítani. Ez a hely pedig az úgynevezett CleanupStack. A dolgozat korábbi fejezetében említve lett a Symbian egyik sajátossága, a kétfázisú konstrukció. Ennek alkalmazása a CleanupStack, azon belül is, a helyes memóriafelszabadítással kapcsolatos. A CleanupStack segítségével sikerült felkészülni egy esetleges kivétel dobás utáni takarításra, mégis ütközhetünk problémába. Előfordulhat ugyanis, hogy már az objektum lefoglalása után, de még a mutató CleanupStack-re történő helyezése előtt történik a Leave hívás. Ezt nem szabad megengedni, ezért a megoldás egy olyan kétlépéses konstruktor, amelyet a Symbian fejlesztők előszeretettel alkalmaznak. A kétfázisú konsatruktor azt jelenti, hogy az egyszerű tagváltozók inicializálásának feladatát az igazi, elsődleges konstruktor végzi, míg a C osztálybeli tagváltozók helyfoglalását és az egyéb feladatokat egy másik metódus, a második konstruktor végzi el.
22
4.6 Alaptípusok Nem lehet kikerülni az alaptípusok kérdéskörének tárgyalását, hiszen a Symbian-ban a C++ alaptípusok helyett azok symbianos megfelelői használatosak. Ezek az elnevezési szokásokhoz illeszkedően T betűvel kezdődnek. Egy részük csak egy új típus definíció az eredeti C++ típusra, más részük azonban valódi T osztály. Új típusok létrehozására azért is volt szükség, mert a C++ nem határozza meg, hogy egy adott típus (például int) fizikailag hogyan, hány bit hosszan tárolódik. A Symbian rendszerben azonban szükséges az alapítpusoknak olyan változata is, amely konkrét bithosszúságú. A Symbian operációs rendszer a következő alapítpusokat tartalmazza: TInt, TInt8, TInt16, TInt32, TUint, TUint8, TUint16, TUint32, TText, TText8, TText16, TChar, TBool, TReal, TReal32, TReal64, TRefByValue
, Min(), Max(), Abs() és Rng() Lássuk a fent leírt alaptípusokat részletesebben is: ● TInt Egy gép szó hosszúságú előjeles egész, aritmetikai műveletekben használatos. ● TInt8, TInt16, TInt32 Adott hosszúságú előjeles egész szám. Akkor használjuk, ha a konkrét fizikai méret is fontos. ● TUint Egy gépi szó hosszúságú előjel nélküli egész. Használata azonban nem olyan aritmetikai műveletek során javasolt, ahol az adott változó csak pozitív értéket vehet fel, hanem olyanokhoz, ahol az előjel hatása zavaró, mint például a különféle bitműveleteknél. ● TUint8, TUint16, TUint32 Előjel nélküli, adott bithosszúságú egész. ● TText Egy karaktert jelképező típus, melynek hossza Unicode-ot használó programok esetén 16 bit, egyéb esetben csak 8 bit. ● TText8, TText16 Fordítási paraméterektől független, adott bithosszúságú karaktertípus. ● TChar Ez az osztály karakterek manipulálására (például nagybetűvé alakítás) és vizsgálataira készült segítő osztály.
23
● TBool Ez a C++ bool típusának felel meg, értéke ETrue (igaz) vag EFalse (hamis) lehet, az érték egy gépi szó hosszúságon van tárolva. ● TReal 64 bites dupla pontosságú valós szám. Általában matematikai műveleteknél használatos. Mivel a Symbian operációs rendszer a legtöbb esetben olyan RISC processzorokon fut (például ARM vagy THUMB), amelyek nem támogatnak lebegőpontos számításokat. Használatukkal erős teljesítménycsökkenést vehetünk észre. ● TReal32, TReal64 Megadott pontosságú lebegőpontos szám. ● TRefByValue A változó paraméterű függvények egyéb paramétereinek referencia szerinti átadását hivatott megoldani.
4.7 Sztringek használata a Symbian operációs rendszer alatt A programozók többségének előbb vagy utóbb feltűnik, hogy a C nyelvből hiányzik egy intelligens sztringtípus. A Java nyelvben és a C++-ban már található ilyen osztály, amely megkönnyíti a sztringek kezelésével kapcsolatos feladatokat, ám a Symbian esetében a memóriakezelés sajátosságai miatt sajátos sztringkezelési módszereket dolgoztak ki. Legelőször is tisztázni kell, hogy milyen fajta sztringekkel találkozhatunk egy-egy program során. Sztringek három fő helyen helyezkedhetnek el. Először is, a programkódba belefordított sztring konstansok, melyek értéke nem változhat és a ROM-ban vagy a RAMban helyezkednek el. Egyébiránt sztringeket létre lehet hozni a stack-en is, ám a stack meglehetősen korlátos mérete miatt érdemes csak kis sztringeket tárolni ezen a helyen. A Symbian-ban a sztringek ősosztálya a TDes vagy konstans értelemben a TDesC. A különböző egyéb sztring osztályok ezekből az absztrakt osztályokból öröklődnek. A TDesC deszkriptorosztály és ezzel el is jutottunk oda, hogy módosítsuk a sztring elnevezést. Symbian rendszer alatt ugyanis deszkriptorokról beszélünk, amelyek egy címet és egy hosszt tárolnak a sztring leírására. Az ilyen sztring előnye, hogy rajta mindenféle művelet elvégezhető, ami nem módosítja a sztring hosszát. A TDes osztály még egy maximális hosszt is tárol ami által olyan módosítások is végezhetők a sztringen, amelyekkel a sztring nem nyúlik túl ezen a hosszon.
24
A deszkriptorosztályok hierarchiáját a következő ábra mutatja:
TDesC TBufCBase
TDes
TBufBase
TBufC
HBufC
TPtrC
TBuf
TPtr
4.7.1. ábra A deszkriptorosztályok hierarchiája
A deszkriptorosztályok megértése és használata olyan jelentőségű a Symbian programozás szempontjából, hogy nem lehet elmenni részletes ismertetésük mellett. A Ptr függvény használandó a tárolt adat címének eléréséhez. Természetesen rengeteg segédfüggvény szolgál a sztringel kapcsolatos műveletek elvégzésére, úgy mint MaxLength(), Length(), Compare(), UpperCase(), stb. A Symbianban az alábbi sztringosztályok használatosak: ● _LIT(KFoiskola, „GAMF”); Konstans. Programba belefordított sztringek a _LIT azaz literál makróval hozhatók létre. A Symbian egyik leggyakrabban használt makrója ez. ● TPtrC ptrSztring(KFoiskola); Az előző konstanra kaphatunk segítségével egy mutatót, azonban természetesen maga a konstans sztring nem lesz megváltoztatható. ● const TDesC& elavultSztring = _L(„GAMF”); A literálok régi formája. Tulajdonképpen csak a kompatibilitás miatt maradt még fenn az új Symbian rendszerekben. A hossz nem kerül eltárolásra ebben az esetben. ● TBufC<4> stackSztring(KFoiskola); A stackSztring nevű változó a stack-en jön létre és belemásolódik az eredeti KFoiskola konstans sztring értéke ● HBufC* heapSztring = KFoiskola().AllocLC();
25
A heapSztring nevű változó a heap-en jön létre. Az AllocLC() metódus helyet foglal a heapen, belemásolja az új változóba a konstans sztring tartalmát és a CleanupStack-en hagyjuk az objektumot ami a későbbi takarítás végett fontos. Erre utal egyébként az LC végződés (CleanupStack). A feladat végeztével később a sztringet a CleanupStack::PopAndDestroy hívással semmisíthetjük meg. ● TDesC8, TDes8, TBuf8, TPtr8, HBuf8 Ha bináris adatokkal dolgozunk, akkor is kényelmesen használhatjuk a deszkriptorokat az adatok tárolásához.
4.8 Fájlkiterjesztések – hogyan épül fel egy Symbian alkalmazás Gyanítható, hogy az a programozó, aki bár gyakorlott, mégis először lát egy Symbian programot, aggódva tekint a rengeteg féle kiterjesztésre, amelyek csak látszólag tűnnek kuszának.
Az
UKR
program
megértéséhez
feltétlenül
szükség
van
a
Symbian
fájlkiterjesztések ismertetésére, ezért azok rövid magyarázatára ebben a fejezetben kerül sor. Egy egyszerű Symbian program könyvtár struktúrája az alábbi módon néz ki:
UKRCustomer
aif
data
group
inc
install
src
4.8.1. ábra Egy egyszerű Symbian alkalmazás könyvtár felépítése
Az AIF könyvtár az alkalmazás megjelenítendő ikonjait tárolja, valamint a hozzájuk tartozó erőforrás leíró fájlt tartalmazza. A DATA könyvtár főként a program fő erőforrás leíró állományát tartalmazza, mely meghatározza a program indulásakor létrejövő megjelenítendő felületet valamint a felületen lévő vezérlők tulajdonságait. A GROUP könyvtár kiemelt jelentőséggel bír, hiszen itt zajlik a tényleges fordítás a projektállomány és egyéb segítő állományok segítségével. Az INC mappa az erőforrásokkal kapcsolatos konstansok, és legfőképpen a saját include állományok otthona. Az INSTALL könyvtár mindössze egy fájlt tartalmaz, méghozzá a csomag fájlt, amelynek közreműködésével készíthető el a makesis segédprogrammal a ténylegesen célhardveren futtatható installációs fájl. Az SRC az angol source szó után természetesen az alkalmazás saját forrásfájlait tartalmazza.
26
Az egyes fájltípusokhoz tartozó fájlkiterjesztések magyarázata: ● bld.inf A projektfájlokat felsoroló állomány, melyet a bldmake segédprogram igényel. ● .mmp A projekt leírására szolgáló projektfájl. ● .armi, .wins, .winc A névhez kapcsolódó platformhoz tartozó make file. ● .h, .cpp Hagyományos C++ fejléc- és forrásfájl. ● .pkg A makesis (SIS készítő) segédprogram bemenetem, melyben a telepítéshez szükséges leírás található. ● .sis Symbian telepítőfájl, a makesis kimenete. ● .aif Applikációs leíró fájl (Application Information File). ● .mbm Több képet is tartalmazó, speciálisan a Symbian rendszer alatt használatos Multi-Bitmap fájl. ● .mbg Az mbm fájlokban található képek programból történő használatához szükséges konstansokat tartalmazó fejlécfájl. ● .rss Az alkalmazás erőforrásait leíró fájl. ● .rh Erőforrásokban használt struktúrákat definiáló fejlécfájl. ● .hrh Az erőforrásokkal kapcsolatos konstansok gyűjteménye.
27
4.9 Az MVC minta alkalmazása Symbian-fejlesztés
során
gyakran
találkozunk
tervezési
minták
használatával,
az
alkalmazások szerkezete például az MVC (Model-View-Controller) mintát követi:
Controller (vezérlő)
View (nézet)
Model (modell) 4.9.1. ábra Az MVC minta szerkezete
Az MVC minta annyit jelent, hogy az alkalmazás állapotát egy modell tartalmazza, ezt a modellt egy nézeten keresztül látja a felhasználó és mindkettőt a vezérlő segítségével tudja befolyásolni. Sajnos a gyakorlatban nehéz átültetni az MVC minta felépítését egy Symbian programban.A vezérlő (AppUi) és nézet (Dialog) osztályok természetesen biztosan léteznek, valamint ezen kívűl még két további osztály is: egy applikáció és egy dokumentum. Az applikáció osztály mindössze az alkalmazás elindításáért felelős, ezen felül szolgáltatnia kell az alkalmazás UID-ját. A dokumentum osztály az alkalmazás állapotának elmentését és visszaállítását végzi.
4.10 Az erőforrás leíró állomány Az erőforrás leíró állomány tartalmazza mindazokat a vezérlőket, amelyekkel dolgozni szeretnénk egy program elkészítése kapcsán. Az erőforrás leíró állomány kiterjesztése .rss. Az UKR program egy olyan menürendszert tartalmaz, amelynek elemeit a későbbiekben dinamikus módon kívánjuk manipulálni, valamint szükségünk lesz több dialógus ablakra. Az első dialógus ablak csupán egy üdvözlő képet tartalmaz, amely jelen esetben a biztosító társaság egyéni arculatát tükrözi. Egy másik dialógus ablak a segítség ablak, mely a program használatához nyújt segítséget a felhasználónak. Szükség van továbbá speciális dialógus ablakokra is, úgy mint egy űrlapra, amely segíti a felhasználót profilja elkészítésében. Ekkor adhatja meg ugyanis személyes adatait a felhasználó, mely a Symbian kliensen egy adatbázisban tárolódik el. Az adatbázisban eltárolt adatokat természetesen vissza is kell tudni nyerni ahhoz, hogy törlést vagy módosítást lehessen rajta végrehajtani. Ezt egy lista vezérlővel fogjuk megtenni, ami egy sima dialógus ablak, rajta egy lista vezérlővel. 28
A menürendszer erőforrás leírásának kódja a következő: 1.) A fő menürendszer leírására szolgál az alábbi kódsor, melynek segítségével létrejön egy R_UKRCUSTOMER_MENU nevű menü objektum. RESOURCE MENU_BAR r_ukrcustomer_menubar { titles= { MENU_TITLE { menu_pane=r_ukrcustomer_menu; txt="File";} }; }
2.) Ezt követően létrehozunk minden menüt a főmenüben: RESOURCE MENU_PANE r_ukrcustomer_menu { items= { MENU_ITEM { cascade=r_ukr_services_menu; txt = qtn_appl_services; }, MENU_ITEM { cascade=r_ukr_customer_menu; txt = qtn_appl_customer; flags=EEikMenuItemSeparatorAfter; }, MENU_ITEM { command=EUKRCustomerCmdAppHelp; txt = qtn_appl_help; flags=EEikMenuItemSeparatorAfter; }, MENU_ITEM { command=EAknCmdExit; txt = qtn_options_exit; } }; }
A főmenü tehát pontosan négy darab menüpontot fog tartalmazni, úgy mint Szolgáltatások, Személyes adatok, Segítség valamint Kilépés menüt, amint az a 11. ábrán is jól látszik:
4.10.1. ábra Az UKR fő menüje
29
4.11 Kliens felhasználói felület A felhasználó első feladata, hogy a személyes adatait egy lokális kliens oldali adatbázisba mentse el. Erre azért is szükség van, mert a telefonok billentyűzete nem alkalmas, vagy legalábbis nehézkes alkalmat
kínál
viszonylag
szövegek
bevitelére.
hosszabb
Azzal,
hogy
a
személyes adatok adatbázisba kerülnek elérhető,
hogy
felhasználónak
a
későbbiekben
ezzel
már
ne
a
kelljen
törődnie mindaddig, amíg nem módosítja vagy törli saját profilját. A felhasználó az „új ügyfél” menüpontra kattintva lehetőséget kap arra, hogy a felbukkanó
űrlapon
adatait
begépelve
elmentse saját profilját.
Miután a felhasználói profil elmentésre került a kliens oldali adatbázisban, a menü dinamikusan változik meg, lehetőséget biztosítva az adatok megtekintésére, az adatok módosítására, valamint a teljes profil törlésére. Az alkalmazás nem ad lehetőséget
több
felhasználó
egyidejű
kezelésére, melyre szükség van, tekintve, hogy a biztosító társaság célkitűzése kifejezetten az, hogy a telefont egyénhez kösse.
30
Amennyiben
a
felhasználónak
információra van szüksége a program működésével
kapcsolatban,
úgy
segítségére lehet egy speciális dialógus, amely eligazítást nyújthat a lépések között.
Miután a felhasználói profil elmentésre került,
a
következő
lépés,
hogy
–
amennyiben igény jelentkezik rá – a felhasználó
kiválassza
legmegfelelőbb
a
számára
szolgáltatást
a
szolgáltatások listájából. Ezt követően az adatbázisban tárolt profil a személyes adatokkal együtt elküldésre kerül az alkalmazás szerver számára, amely egy szerver oldali adatbázisban tárolja innentől kezdve a kérést.
Az adatok elküldését követően, mint ahogy fentebb már említve lett, az adatok valamint a szolgáltatás típusa egy központi szerver
adatbázisába
kerül.
Ezután
történhetne, hogy az alkalmazás szerver kijelöli
az
legmegfelelőbb
irányítószám szabad
alapján
a
kapacitással
rendelkező ügynököt és értesítést küldjön számára egy új ügyfél igénylésről.
31
4.11 Symbian telepítő alkalmazás készítése A példaprogram sikeres telepítéséhez a következő lépések szükségesek. Hardver szempontból bármilyen személyi számítógép megfelelő lehet, amely Bluetooth hapcsolattal, vagy Nokia adatátviteli kábellel rendelkezik. Amennyiben nem áll rendelkezésre egy Nokia típusú okos telefon, úgy lehetőség van a PC-n a már említett emulátor segítségével kipróbálni az alkalmazást. 1.) Telepíteni kell a Microsoft Visual Studio 6.0 fejlesztői környezetet 2.) Telepíteni kell a Java Virtual Machine rendszer 1.3-as verziónál újabb kiadását 3.) Telepíteni kell a Perl értelmezőt 4.) Telepíteni kell a JBoss alkalmazás szervert valamint a MySQL adatbáziskezelő rendszert A telepítés parancsait a konzolon keresztűl kell begépelni, fontos, hogy az alkalmazás GROUP nevű könyvtárában tartózkodjunk. A parancsok a következők: 1.) bldmake bldfiles 2.) abld build wins udeb Ezután az epoc parancsal el lehet indítani az emulátort, a programlistában pedig meg fog jelenni az elkészült alkalmazás. Abban az esetben, amennyiben közvetlenül valódi készüléken szeretné valaki megtekinteni a programot a parancsok a következőképpen alakulnak: 1.) bldmake bldfiles 2.) abld build armi urel 3.) abld build thumb urel Ezután az az INSTALL könyvtárból a következő parancsal készül el a telepítő állomány: Makesis UKRCustomer.pkg Az INSTALL könyvtárban keletkező SIS állományt ezekután csak el kell küldeni Bluetooth kapcsolaton kersztűl közvetlenül a telefon készülékre, az alkalmazás magától fel fog települni.
5. A tervezés részletes leírása Az ügynökkiválasztó program esetében egy telefonon kizárólag egy ügyfél léphet kapcsolatba az alkalmazással. Az ügyfelet felhasználónak tekintjük, aki az alkalmazást kezeli. Az alábbi diagram felvázolja a felhasználó lehetőségeit:
32
FELHASZNÁLÓ
Új ügyfél felvétele
Szolgáltatások listázása
Ügyfél törlése
Új szolgáltatás kiválasztása Ügyfél adatainak módosítása
5.1. ábra Használati eset diagramm
5.1 Fogalomszótár Új ügyfél felvétele: a felhasználó itt adhatja meg adatait, ami bekerül az ügyfél adatbázisba. Ügyfél törlése: az ügyfél adatbázisból törlése kerül az ügyfél összes személyes adata Ügyfél adatainak módosítása: az ügyfél adatbázisból az adataok visszakeresése, majd módosítás esetén azok felülírása Szolgáltatások listázása: a felhasználó számára rendelkezésre álló biztosítási szolgáltatások Új szolgáltatás kiválasztása: a rendelkezésre álló szolgáltatások közül egyszerre mindig csak egyet választhat a felhasználó. Csak ezután kerül elküldésre az ügyfél profilja valamint a kiválasztott szolgáltatás kódja.
5.2 Forgatókönyvek A felhasználó elkészíti személyes profilját - a felhasználó kitölti az ügyfél dialógusablak alapján a személyes adatait - elmenti a bevitt adatokat az ügyfél adatbázisba, mely lokálisan, a készülékben található meg A felhasználó megtekintheti adatait és módosíthatja azokat - a felhasználó a meglévő ügyfél adatbázisból megtekintheti személyes adatait, majd ha kívánja, módosíthatja azokat - végül elmenti a változtatásokat
33
A felhasználó törölheti profilját, majd teljesen új felhasználót vehet fel - a felhasználó teljesen törölheti profilját minden személyes adatával együtt. - az ügyfél adatbázis alaphelyzetbe kerül és lehetőséget nyújt új ügyfél adatainak felvételére A felhasználó megtekinti majd kiválasztja a számára megfelelő szolgáltatást - a felhasználó egy legördülő listán megtekinthető a jelenleg elérhető szolgáltatások listáját - választ egyet azok közül, mely érdekli és amelyhez ügynöki személyes segítségre van szüksége
5.3 Funkciók A különböző funkciócsportok meghatározásával az alkalmazás egyértelműen elkülöníthető részekre bontható. Ennek segítségével lehet egységbe foglalni a teljes alkalmazást. A rendszert három jól elkülöníthető részre lehet felosztani, ezek a megjelenítés, a modell és a különféle adatbáziskezeléssel kapcsolatos funkciók. Megjelenítés: a grafikus felület megjelenítéséért és a különböző dialógusok grafikájáért felelős osztályok gyűjteménye Modell: az események kezeléséért felelős osztályok gyűjteménye valamint különböző kisegítő osztályokat foglal magába Adatbázis: az adatbázis hozzáféréshez szükséges funkciókat valósítja meg. A rendszer struktúráját ábrázoló csomagdiagramot a következő ábrán láthatjuk.
MEGJELENÍTÉS
MODELL
ADATBÁZIS
CUKRCustomerAppUi
CUKRCustomerDialog
DataBase
CUKRCustomerForm
CUKRCustomerHelpDialog
5.3.1. ábra Az UKR Program csomagdiagramja
34
Az ábrán jól látható, hogy az adatbázis réteg az adatbázishoz való hozzáférést nyújtja a modell osztály objektumaihoz, míg a modell osztályok szolgáltatásokat nyújtanak a megjelenítési réteg számára.
5.4 Osztályterv Az osztálydiagram áttekinthető formában ábrázolja az alkalmazásban lévő objektumokat és a köztük lévő kapcsolatokat.
CUKRCustomerAppUi osztály public
private
void ConstructL()
void DynInitMenuPaneL(TInt aResourceId,CEikMenuPane* aMenuPane)
~CUKRCustomerAppUi()
void HandleCommandL(TInt aCommand) virtual TKeyResponse HandleKeyEventL(const TKeyEvent& aKeyEvent,TEventCode aType);
private adattagok CUKRCustomerDialog* iAppDialog CUKRCustomerForm* customer_form
CUKRCustomerDialog osztály public
protected
CUKRCustomerDialog() ~CUKRCustomerDialog()
void PreLayoutDynInitL() TBool OkToExitL( TInt aButtonId )
CUKRCustomerForm osztály private adattagok
protected
TBuf<20> uName TBuf<50> uAddress TBuf<4> uZipCode TBuf<9> uPhoneNumber TBuf<20> uEmail TBuf<200> uComment RFs iFileServerSession CPermanentFileStore *iFileStore RDbStoreDatabase iDatabase
void ProcessCommandL(TInt aCommandId) TBool SaveFormDataL()
CUKRCustomerHelpDialog osztály private adattag
protected void PreLayoutDynInitL()
CFont *myFont . 5.4.1. ábra Osztály diagram
35
CUKRCustomerAppUi osztály Feladatai: -
az MVC modell kontroll összetevőjét valósítja meg
-
a felhasználó cselekedeteinek kezelésére szolgál
-
felügyeli a különböző nézeteket és betölti a dialógos ablakokat
Attribútumok: - CUKRCustomerDialog* iAppDialog A fő dialógus ablakra mutató objektum - CUKRCustomerForm* customer_form Űrlap objektum Metódusok: - Public void ConstructL() Felépíti a fő dialógus ablakot a felhasználó számára - Public ~CUKRCustomerAppUi() Memória takarítást végez miután a fő dialógus ablakra már nincs szükség - Private void DynInitMenuPaneL(TInt aResourceId,CEikMenuPane* aMenuPane) Feladata a dinamikus menürendszer előállítása a főmenüben - Private void HandleCommandL(TInt aCommand) A menüpontokhoz rendelt parancsok kezelése a feladata - Private virtual TKeyResponse HandleKeyEventL(const TKeyEvent& aKeyEvent,TEventCode aType) A telefon billentyűzetéhez rendelt parancsok kezelése a feladata
CUKRCustomerDialog osztály Feladatai: -
elsősorban a dokumentum megjelenítésére szolgál
-
billentyűzet események kezelése
-
adatbázis kapcsolatok megjelenítése
-
tárolja az alkalmazás perzisztens adatait
Metódusok: - Public CUKRCustomerDialog()
36
A fő dialógus ablak megjelenítési elemeinek felépítése a feladata - Public ~CUKRCustomerDialog() A fő dialógus ablak helyes megszüntetése a feladata - Protected void PreLayoutDynInitL() A dialógus ablak megjelenítéséért felel még a memóriába betöltés előtt - Protected TBool OkToExitL( TInt aButtonId ) A dialógus ablak menüpont eseményeinek kezelésére szolgál
CUKRCustomerForm osztály Feladatai: -
az űrlapok megjelenítéséért felelős metódusok gyűjteménye
-
az űrlapok eseménykezelésének feladatát látja el
Attribútumok: - TBuf<20> uName A felhasználó nevét tároló deszkriptor 20 karakter hosszan - TBuf<50> uAddress A felhasználó postázási címét tároló deszkriptor 50 karakter hosszan - TBuf<4>
uZipCode
A felhasználó irányítószámát tároló deszkriptor 4 karakter hosszan - TBuf<9>
uPhoneNumber
A felhasználó mobiltelefon számát tároló deszkriptor, körzetszámmal, 9 karakteren - TBuf<20> uEmail A felhasználó elektronikus levelezési címét tároló deszkriptor 20 karakter hosszan - TBuf<200> uComment A felhasználó bármilyen megjegyzését tároló deszkriptor 200 karakter hosszan - RFs iFileServerSession Fájl-Szerver kapcsolat felépítéséhez szükséges objektum - CPermanentFileStore *iFileStore Fájl-Szerver kapcsolat felépítéséhez nélkülözhetetlen úgynevezett Store objektum - RDbStoreDatabase iDatabase Az adatbázis objektum, melyre az adatbázis eléréséhez van szükség Metódusok: - Protected void ProcessCommandL(TInt aCommandId)
37
Az űrlap sikeres mentését ellenőrzi, valamint üzenetmegjelenítés a feladata - Protected TBool SaveFormDataL() A tényleges adatbázisba mentést végzi el, miután a felhasználó kitöltötte az űrlapot
CUKRCustomerHelpDialog osztály Feladatai: -
az alkalmazás használatát megkönnyítő segéd dialógus megjelenítése
-
a dialógus méretének meghatározása
-
tartalmának dinamikus feltöltése
Attribútumok: - CFont *myFont Az aktuális betűtípust tároló mutató Metódusok: - Protected void PreLayoutDynInitL() A segítség dialógus ablak megjelenítéséért felel még a memóriába betöltés előtt
5.5 Adatbázis tervek
6. Értékelés A feladat alapvetően a különböző technológiákkal való megismerkedést szolgálta, különös figyelmet fordítva a Symbian operációs rendszer lehetőségeihez. A dolgozat célja az volt, hogy bemutassa a kliens oldali Symbian rendszerek valamint a szerver oldali java szervletek közötti együttműködés hatékonyságát, a két világ közötti kapcsolódási lehetőségeket. Nem volt cél tehát a biztosító társaság számára egy teljes funkcionalitású, működő rendszert szolgáltatni. Az elkészült rendszer egy jól működő vázat nyújt hasonló alkalmazások számára, amelyek ugyanezen technológiák bevonásával kívánnak valamilyen funkcionalitást megvalósítani. Mivel a dolgozat főként a kliens oldali Symbian alkalmazási rendszer bemutatására helyezi a legfőbb hangsúlyt, érthető okokból a Java szervlet és az adatbázis felépítése igen egyszerű.
6.1 Továbbfejlesztési lehetőségek 38
A feladat továbbfejlesztését több oldalról is meg lehet közelíteni: Természetesen nagyobb fejlesztésekre van szükség abban az esetben, ha a valóságot kívánjuk modellezni, valamint egyéb biztonsággal kapcsolatos kérdésekkel is foglalkozni lehetne, tekintve, hogy a mai okos telefonok fejlett hardveres védelmi megoldássok rendelkeznek. Valójában nagyságrendekkel bonyolultabb modellt kellene alkotni ahhoz, hogy egy valós rendszer minden részletét le tudja fedni. A fejlesztés természetesen eltolódhat a szerver oldal irányába is és megannyi lehetőség adódik az adatbeviteli technikák fejlesztésében. Másik oldalról nézve lehetne magát a technológiát is fejleszteni. Legkézenfekvőbb terület a szinkronizációs modell tovább fejlesztése például SyncML alapokra vagy olyan üzenetkezelő rendszer kifejlesztése, amely a manapság nagyon elegáns, de bonyolultsága miatt kevésbé használatos BIO Messaging üzenetkézbesítő rendszert használja az adatok továbbítására, megkerülve ezzel a teljes TCP/IP protokollt. Természetesen egy valódi rendszerben az adatokat bizalmasan kellene kezelni. Ez vonatkozik mind a szinkronizáció és az adatátvitel lépéseire, mind pedig a beérkezett adatok szerveren való elhelyezésére. Jelenleg a titkosítás és az adatok bizalmas tárolása nem volt cél, főleg azt figyelembe véve, hogy a szerver oldali Java technológiára csak a dolgozat bemutatása miatt volt szükség.
7. Irodalomjegyzék [1]
Charaf Hassan, Csúcs Gergely, Forstner Bertalan, Marossy Kálmán: SYMBIAN alapú szoftverfejlesztés Szak Kiadó, 2004
[2]
Leigh Edwards, Richard Barker: Developing Series 60 Applications Addison-Wesley, 2004
[3]
Digia: Programming for the Series 60 Platform and Symbian OS Symbian Press, 2002
[4]
Jason Hunter: Java szervletek programozása Kossuth Kiadó, 2002
[5]
Nyékyné Gaizler Judit: J2EE – Útikalauz Java programozóknak ELTE TTK Hallgatói Alapítvány, 2002
[6]
Forum Nokia () http://www.forum.nokia.com
[7]
JavaSite BME http://javasite.bme.hu 39
40
