kliensalkalmazás fejlesztése Android platformon

Átírás

1 Erdőökológiai terepi adatgyűjtő kliensalkalmazás fejlesztése Android platformon szakdolgozat Készítette: Kozák Csaba Mérnök informatikus BSc hallgató Konzulensek: Tornai Kálmán, Dr. Oláh András Pázmány Péter Katolikus Egyetem Információs Technológiai és Bionikai Kar 2013

2

3 Alulírott Kozák Csaba, a Pázmány Péter Katolikus Egyetem Információs Technológiai és Bionikai Karának hallgatója kijelentem, hogy ezt a szakdolgozatot meg nem engedett segítség nélkül, saját magam készítettem, és a szakdolgozatban csak a megadott forrásokat használtam fel. Minden olyan részt, melyet szó szer, vagy azonos értelemben, de átfogalmazva más forrásból átvettem, egyértelműen a forrás megadásával megjelöltem. Ezt a Szakdolgozatot más szakon még nem nyújtottam be.... Kozák Csaba

4

5 Tartalomjegyzék Absztrakt 3 Abstract 4 1 Bevezetés és motiváció 5 2 Helymeghatározó rendszerek és helyfüggő alkalmazások Helymeghatározó rendszerek A helymeghatározó technológiák osztályozása Global Positioning System A Google helymeghatározó szolgáltatása Mobil platformok Az Android mobilplatform Az ios mobilplatform Létező, elérhető megoldások Keretrendszer POI-alapú térinformatikai alkalmazásokhoz Specifikáció Általános leírás Forgatókönyv Használati esetek Architektúra Megvalósítás A megvalósult szoftverarchitektúra rövid bemutatása Képernyőképek Terepi mobil kliensalkalmazás biodiverzitás felméréséhez Funkcionális specifikáció A főképernyőről elérhető funkciók Közvetlenül a felméréshez kapcsolódó képernyők Az űrlapon szereplő lehetséges kérdéstípusok Architektúra terv Autentikáció Hálózati kommunikáció

6 4.2.3 Adatbázis-kezelés Űrlap Megvalósítás A megvalósult szoftverarchitektúra Képernyőképek Tesztelés A JUnit A Robolectric A Mockito A Crittercism Összefoglalás, a dolgozat eredményei 43 6 Köszönetnyilvánítás 44 Irodalomjegyzék 45 Függelék 48 A Adatbázisszerkezet 48 B Űrlap XML leírás 49 C Hálózati XML napló 50 D CD melléklet tartalma 51 2

7 Absztrakt Napjainkban egyre nagyobb teret hódítanak az okostelefonok, amelyek lassan minden ember számára hozzáférhetővé válnak. Ezen készülékek terjedésével párhuzamosan beindult az úgynevezett kontextusfüggő, illetve helyfüggő alkalmazások egyre szélesebb körű használata is, melyek megkönnyítik, meggyorsítják a mindennapos feladatok elvégzését. Elérhetőek már olyan mobilalkalmazások, amelyek figyelembe veszik a felhasználó aktuális pozícióját és annak függvényében végeznek meghatározott feladatokat. Ezeket viszont általában egy adott speciális célra fejlesztették, funkcionalitásuk nem bővíthető, nem rugalmasak, az újonnan jelentkező felhasználói igényekre nem adnak választ. A szakdolgozat első fele egy olyan keretrendszer fejlesztését mutatja be, amely bármilyen Po of Interest (POI) alapú alkalmazás készítését lehetővé teszi úgy, hogy a rendszer fölé gyorsan, az igényeknek megfelelően lehessen fejleszteni az adott programot. Ezen kívül a keretrendszernek olyan szerkezetűnek kell lennie, hogy az specializáció nélkül is alapvető, általános célokra használható legyen. A dolgozat második részében egy, a keretrendszerre épült konkrét alkalmazás kerül bemutatásra. A program egy komplex erdőökológiai projekt keretén belül készül el, melynek célja adatotokat gyűjteni a hazai erdőkben azok biológiai sokféleségének megtartása érdekében. Az alkalmazás külső igények alapján, a biológiai felmérési szempontok figyelembevételével készül el és vesz részt a felmérésben. Az adatokat pontokhoz és területekhez rendeli, biztonságosan tárolja és továbbítja a központi szerver felé. Ezeket az adatokat szakértői csoport értékeli ki és készít belőle olyan adatbázist, mely segítségével megvalósítható az erdők biodiverzitásának megőrzése és a fajok minél teljeskörűbb védelme. A dolgozat bemutatja az alkalmazás teljes fejlesztési ciklusát a program részletes specifikációjától kezdve a tervezésen át a végső implementációig és tesztelésig, így átfogó képet ad egy komoly, kontextusfüggő mobilalkalmazás fejlesztésének lépéseiről. 3

8 Abstract Nowadays smartphones ensely gather ground and slowly will be available for all people. In parallel with the spread of these devices the wider use of so-called context- and location-based applications has been started, which facilitate and expedite the completion of everyday tasks. Now applications are already available which take o account the user s current position and carry out pre-defined tasks according to the context, but these are usually developed for a specific purpose, the functionality of them can not be expanded and these are not flexible enough to fulfill emerging user needs. The first part of the thesis describes the development of a framework that allows the creation of any Po of Interest (POI) based application quickly over the system for the given needs. In addition, the framework must be constructed so that the core can be used for general purposes without any specialization. In the second part of the thesis a specific application is presented which is built on the top of the framework. The program is made within a complex ecological forest project to collect data of national forests in order to maain their biological diversity. The application is based on external demand, respects the needs of the biological assessment and participates in the survey. The program assigns the data to pos and areas, stores them safely and transmits them to the central server. These data will be evaulated by an expert group, who puts it o a database. This datastore helps the preservation of species and the protection of forest biodiversity. This paper presents the complete application development cycle from the detailed specification through the program design to the final implementation and testing, hence it provides a comprehensive picture of the development steps of a serious, context-aware mobile application. 4

9 1. Bevezetés és motiváció Az elmúlt években az okostelefonok robbanásszerű fejlődésen mentek keresztül, és széleskörűen elterjedtek a hétköznapi felhasználók között is. Ezen készülékek már magukba egrálva tartalmazzák a különböző helymeghatározó hardvereket, technológiákat. Mivel egy egységen belül adott az okostelefon platform rugalmassága, továbbá a helymeghatározás lehetősége is, így a helyfüggő alkalmazások készítése lehetővé vált a mobiltelefonokra. Ezek az alkalmazások megkönnyítik, automatizálják azokat a folyamatokat, amiket a felhasználónak manuálisan kéne elvégeznie, amennyiben az adott helyszín közelébe ér, továbbá egy teljesen új koncepcióba helyezik a mobilprogramozást. A klasszikus térkép és navigációs alkalmazásokon kívül ma már sze minden komolyabb program rendelkezik kontextusfüggő almodullal, továbbá egészen újfajta alkalmazások készülnek, melyek a helymeghatározó technológiákat kihasználják. Bár a helyfüggő mobilalkalmazások széles rétege érhető el, azok még sem tudják teljességgel lefedni a piaci igényeket. Az ilyen alkalmazások általában az adott célra készülnek el, fix funkciókkal rendelkeznek, további lehetőségek beépítését nem teszik lehetővé. Ezért van létjogosultsága egy olyan keretrendszernek, amely helymeghatározó technológiákat használ, és úgy van kialakítva, hogy az adott igény alapján egy új, specializált alkalmazást lehessen elkészíteni a segítségével a lehető legrövidebb időn belül. A dolgozat első fele egy ilyen keretalkalmazás fejlesztésének menetét írja le, amely azon kívül, hogy platformot szolgáltat a specializált megoldások felé, önmagában is elegendő funkcionalitással bír a hétköznapi felhasználáshoz. A dolgozat második fele egy, a keretrendszerre épült specializációt mutat be. Ez a program egy nagyobb projekt keretén belül készül el, melyet egy svájci alap támogat, és célja a magyarországi erdők biodiverzitásának felmérése. Az alkalmazást a felmérést végző ökológiai kutatócsoport specifikálta, és feladata az adott pontok mentén rögzíteni előre meghatározott változók értékeit, ezeket összegyűjteni, tárolni és egy központi szervernek elküldeni egy adott felmérési időszak végén. Az adatok összegyűjtése után egy szakmai csoport értékeli azokat, statisztikákat készít azokból, majd egy olyan adatbázisba szervezi, amely nagy segítséget ad a magyarországi erdők és azok fajainak minél tartósabb megőrzéséhez. Mivel Magyarországon még nem készült ilyen program, a fejlesztés nagy kihívást jelent és a keretrendszert is próbára teszi, amely alapjain megépül. A dolgozat második része az adatgyűjtő alkalmazás fejlesztésének teljes ívét leírja, a specifikációtól kezdve az implementációig és tesztelésig, majd értékeli az elkészült programot és a 5

10 fejlesztés során előjött tapasztalatokat levonja. A dolgozat felépítése a következő: - az 1. fejezet leírja, hogy milyen előzmények alapján vetődött fel a keretrendszer alkalmazás és az arra épülő adatgyűjtő program fejlesztése, és ezek milyen motivációk mentén készülnek el; - a 2. fejezet általánosságban tárgyalja a helymeghatározó technológiákat és az azokat felhasználó helyfüggő alkalmazásokat. Milyen módszerekkel történik a helymeghatározás, milyen paramétereket kell figyelembe venni ilyen szolgáltatás egrálása során, hogyan lehet csoportosítani ezeket. Rövid piackutatással sorra veszi a már létező, elérhető megoldásokat a POI alapú alkalmazások között. Továbbá röviden bevezeti a mobilplatformokat, ezek közül két piacvezetőt részletesebben is tárgyalja; - a 3. fejezet leírja a keretrendszer alkalmazás specifikációját mind funkcionális, mind felhasználói felület szempontjából, továbbá tárgyalja a szoftver teljes tervezési folyamatát és a tervezet alapján történő implementációját Android mobilplatformon; - a 4. fejezet részletezi az ökológiai adatgyűjtő alkalmazás specifikációját, bemutatja a felhasználói felület, az üzleti logika, az adatbázis, továbbá a teljes rendszer tervét. Bemutatja az alkalmazás megvalósítását, az elkészült modulokat, és sorra veszi a felhasznált programkönyvtárakat. A fejezet utolsó részében tárgyalja a teszteléshez használt módszereket és technológiákat; - az 5. fejezet értékeli az elvégzett munkát mind a keretrendszer, mind az adatgyűjtő alkalmazás teketében, továbbá levonja azokat a következtetéseket, amelyekre a fejlesztés különböző lépései során jutni lehet. 6

11 2. Helymeghatározó rendszerek és helyfüggő alkalmazások Az elmúlt években a technológia fejlődése és a szükséges hardverelemek árának drasztikus csökkenése lehetővé tette, hogy már a belépőszű telefonok is rendelkeznek olyan eszközökkel, amelyekkel a felhasználó pozícióját meg lehet valós időben határozni. Ezeknek az eszközöknek a segítségével már elérhetőek különböző alkalmazások, melyek megkönnyítik a feladatokat az aktuális pozíció igénybevételével. Ez a fejezet a helymeghatározó technológiákat és az ezeket felhasználó mobilalkalmazásokat mutatja be Helymeghatározó rendszerek Napjainkban az okostelefonok mindegyikén elérhető valamely eszköz, amely a készülék földrajzi helyét képes meghatározni valamely pontossággal. A következő fejezetek a helymeghatározáshoz használható technológiákat tárgyalják az elsőként megjelent rendszerektől kezdve a legfrissebb megoldásokig A helymeghatározó technológiák osztályozása Az 1. tábla a fontosabb tulajdonságok alapján veszi sorra a különböző technológiákat [2]. LBS típusa Pontosság Költség TTFF Lefedettség Cell ID hálózat-alapú 300m-20km alacsony gyors közepes Cell ID + jelerősség hálózat-alapú 250m-12km közepes gyors magas AOA hálózat-alapú m közepes közepes jó TOA U-TDOA hálózat-alapú és készülék asszisztált hálózat-alapú és készülék asszisztált m alacsony közepes jó m magas közepes jó GPS készülék alapú 30-80m alacsony lassú változó AGPS hálózat-alapú és készülék asszisztált 5-50m közepes közepes változó WLAN/RF hálózat-alapú 10m közepes közepes közepes 1. táblázat. Helymeghatározó rendszerek összehasonlítása A helymeghatározási technológiák osztályozási szempontjai a következők: 7

12 - Pontosság: Az egyik legfontosabb tulajdonság, a mért pozíció megbízhatósága a legjobban ettől függ. Legérthetőbb mérőszáma a valós pozíció és a mért pozíció közötti távolság, amely a mérés hibáját jelenti. A pontosság nem csak az eszköz karakterisztikájából adódhat, nagyban az adott körülmények határozzák meg. - Lefedettség: Nagyon fontos tényező, hogy a helymeghatározó szolgáltatásnak milyen elérhetősége van az adott környezetben. Lényeges különbség van általában az épületen belüli, és azon kívüli lefedettség között. Illetve azt is figyelembe kell venni, hogy az adott szolgáltatás globálisan, vagy az adott országban, esetleg ennél is csak szűkebb környezetben érhető el. - Felállási idő: megmutatja azt, hogy mennyi idő kell ahhoz, hogy a rendszer működése elinduljon és megadja az első koordinátákat. Az indítás és a földrajzi helyzet első vétele közti idő a felállási idő (time to first fix, TTFF). - Energiahasználat: A fogyasztást is figyelembe kell venni. Különösen megkerülhetetlen olyan esetekben, amikor az energiaforrás erősen limitált (akkumulátor), ahogy az a mobilplatformokra is jellemző. - CPU és sávszélesség szükséglet: Egyrészt kérdés az, hogy a megkapott adatokból mennyire nehéz feladat kiszámolni a pozíciót. Bizonyos esetekben ez közel sem triviális kalkulációt jelent, amely komolyabb CPU-időt eredményez, különösen nagyobb pontosságú és sűrű mérési időpontok esetén. A sávszélességet is figyelembe kell venni: milyen frekvenciasávban és mekkora energiával kell adni a jelet, illetve milyen erősségű antenna kell a kapott jelek elfogadható minőségű vételéhez. - Infrastruktúra: Új technológia bevetése szükséges, vagy már meglévő elemeket lehet újrafelhasználni. - Költség: Mennyi pénzbe kerül a technológia egrálása és licencelése, illetve használata. Kimondható, hogy jelenleg nincs olyan módszer, amelyik mindegyik kritérium alapján egyértelműen legjobbnak tekhető. Mivel ez a dolgozat a mobilplatformokra koncentrál, ezért a következőkben az átlagos, kommerciális, hétköznapi embereknek elérhető okostelefon-készülékeken alkalmazott helymeghatározó rendszerek bemutatása következik. 8

13 Global Positioning System A GPS a legismertebb helymeghatározó rendszer, alapjai mérési referenciapontok: műholdak, melyek közül jelenleg 24 van szolgálatban. A műholdak nagyjából km/h sebességgel, körülbelül km magasan helyezkednek el és 12 óra alatt tesznek meg egy kört a Föld körül. Keringési pályájuk valóban közel kör alakú, a szatellitek úgy vannak elhelyezve, hogy a bolygó egész felszínét lefedjék, így a Földről legrosszabb esetben is legalább négy látható közülük. A műholdak atomóra pontossággal mérik az időt, ezáltal a GPS készülék a saját órája segítségével a szatellit és önmaga távolságát kiszámíthatja. Ezt az úgynevezett trilaterációs számolási módszerrel határozza meg: adott 3 változó (3 dimenziós koordináta), melyeket a kapott 4 műhold pozíció alapján 4 egyenletből lehet kiszámolni: p 1 = (x A x 1 ) 2 + (y A y 1 ) 2 + (z A z 1 ) 2 + cδt p 2 = (x A x 2 ) 2 + (y A y 2 ) 2 + (z A z 2 ) 2 + cδt p 3 = (x A x 3 ) 2 + (y A y 3 ) 2 + (z A z 3 ) 2 + cδt p 4 = (x A x 4 ) 2 + (y A y 4 ) 2 + (z A z 4 ) 2 + cδt p i = pszeudotávolságok; cδt = órahiba hatása A GPS rendszert az Egyesült Államok hozta létre és üzemelteti, eredetileg katonai célokra tervezték, később a polgári használatot is elérhetővé tették. Polgári alkalmazás esetén a pontosságot direkt rontják, a katonai eszközök jóval nagyobb pontosságot képesek elérni. A GPS rendszer USA-tól való függősége igen nagy kockázatot jelent az egyéb országok számára, ezért többen már elkezdtek saját műhold alapú helymeghatározó rendszert kiépíteni. Ilyen az Európai Unió által fejlesztett Galileo, Oroszország által fejlesztett GLONASS és a Kínai Népköztársaság által készített Compass. Ezek közül jelenleg csak a GLONASS használható ténylegesen a GPS-en kívül [5]. 1. ábra. GPS műholdak és a vevő [24] 2. ábra. Pályák a Föld körül [23] 9

14 A Google helymeghatározó szolgáltatása A Google pozicionáló rendszere jóval kisebb pontosságot képes elérni, m a GPS, viszont a helymeghatározáshoz szükséges energiaigénye alacsonyabb. A Google szolgáltatása alapvetően két, térerősség alapú technológiát használ: a GSM cella ID alapú, illetve a WiFi Access Po ID alapú helymeghatározást. A helyzet lekérése során nem megadható, hogy melyikkel dolgozzon, a rendszer a körülményeknek megfelelően az általa vélt legjobb módszert választja ki [4]. A cellainformációkon alapuló pozicionálás azt használja ki, hogy a felszín a mobilszolgáltatás szempontjából cellákra van osztva. Minden egyes cellának van egy egyedi azonosítója, amely időben nem változik (elvileg). A cellák mérete nem egységes, az adott területen a forgalom sűrűségétől függ. Jellemzően vidéki környezetben akár 30 km-es sugarú, külvárosban pár kilométeres, belvárosban 100 méteres lehet. A femtocellák még ennél is kisebbek, egy-egy épületet szolgálnak ki. A mobiltelefon működése során mindig egyetlen egy cellához van kötve, azon keresztül kommunikál a hálózattal. Amennyiben ismert a kurrens cella azonosítója, illetve a cella pozíciója, ez a pozíció a telefonkészülékhez köthető. Lényegében így működik a Google rendszere is: a mobiltelefon pozíciója így a cella által lefedett terület lesz, ami az előbb leírt módon a cella nagyságától függően pár száz métertől pár km-ig terjedhet. A legnagyobb feladatot itt a cellák pozíciójának feltérképezése jelenti. A Google-nek óriási adatbázisa van, amely több m 200 országot, illetve több m 200 szolgáltatót fed le. A WiFi térerősség alapú helymeghatározás a Google szolgáltatásánál hasonló módon működik, m a cella ID alapú. Publikus WiFi hálózatok azonosítóját és helyzetét gyűjtötték össze egy nagy adatbázisba, és ez alapján is történik a pozicionálás. Azonban ez a módszer egy komoly adatvédelmi aggályt vetett fel, ugyanis egy privát WiFi hálózat adatainak ilyenformán történő használata jogsértő lehet. Az erre vonatkozó vádakra reagálva a Google felkínál egy módszert, amivel eltávolítható az adott WiFi hálózat az adatbázisából [21]. A Google szolgáltatása jól működik, azonban zárt, nem lehet abból saját célra adatokat kinyerni. Ugyanakkor léteznek olyan hasonló adatbázisok, amelyek nyíltak, bárki számára elérhetőek. Egy példa ilyen adatbázisra az opencellid [13], amely egy egyszerű webes Application Programming Interface-el (API) érhető el. Bárki lekérheti a pontok listáját, illetve maga is szerkesztheti az adatbázist, tehát tölthet fel cellákat pozícióval. A projekt célja nem csak az adatbázis létrehozása, frissítése és karbantartása, hanem olyan eszközök közzététele is, amelyekkel az adatbázisból pozíció információ kinyerhető, továbbá az 10

15 adatbázist szerkeszteni lehet. 3. ábra. GSM cellák elhelyezkedése [3] 4. ábra. Pozíció becslés bizonytalansága Egy ennél professzionálisabb adatbázis a Location API [14], amelynek cellákról és WiFi hálózatokról vannak adatai több m 200 országban, és átlagosan globálisan a helymeghatározó kérések 96% -át tudja sikeresen teljesíteni. Magyarországon például celláról és WiFi access poról van pozícióinformációjuk. Ilyen mennyiségű információt azonban nem adnak ingyen: az első 100 lekérés tesztjelleggel ingyenes, viszont ezen túl már fizetős a lekérések mennyiségének függvényében. Szén webes API-juk van, amellyel a jelenlegi cella ID-t megadva a válaszban közlik a hozzávetőleges pozíciót. Látható, hogy bár ez a megoldás sokkal kevesebb energiát fogyaszt, m a GPS, viszont ernet elérés szükséges hozzá, amelynek árát a felhasználónak kell megfizetnie. 11

16 2.2. Mobil platformok Az elmúlt évtizedben nagyon sokféle mobil platform, operációs rendszer került kifejlesztésre, közülük néhány ma is használatban van, sok pedig már elvesztette felhasználói bázisát, ahogy az a 5. ábrán is látható. A ma már nem használatos operációs rendszerekre néhány példa: Maemo (fejlesztő: Nokia), MeeGo (fejlesztő: Linux Foundation), Palm OS/Garnet OS (fejlesztő: Access Co.), Windows Mobile (fejlesztő: Microsoft). A napjainkban legjobban elterjedt rendszerek a következőek: Android (fejlesztő: Google), ios (fejlesztő: Apple), BlackBerry (fejlesztő: RIM) és Windows Phone (fejlesztő: Microsoft). Érdemes még megemlíteni két új, még tesztelési fázisban lévő operációs rendszert: a Firefox OS a Mozilla alapítványtól, illetve a Ubuntu Touch OS a Canonical-tól. 5. ábra. Mobil operációs rendszerek piaci részesedésének változása időben, 2013 harmadik negyedévéig [17] Az Android mobilplatform Az Android egy Linux-alapú, nyílt-forráskódú mobil operációs rendszer, amelyet elsősorban érőképernyős eszközökre terveztek, m például a okostelefonok és táblaszámítógépek. A rendszert az Android Inc. kezdte el fejleszteni, ezt 2005-ben a Google felvásárolta és folytatta a fejlesztést. A rendszert a szűk szakmai közönség számára 2007-ben mutatták be, az első kommerciális, ilyen rendszerrel működő telefont pedig 2008-ban kezdték el forgalmazni. Az Android alapja Linux kernel, azonban ez nem azonos az asztali, illetve szervergépekben használatos Linux kernellel, de a fejlesztése abból ágazott ki. Törekvések vannak arra, hogy az Android egy az egyben ugyanazt a kernelt használja, de ezek 12

17 egyelőre nem értek el eredményt. A kernel fölött C nyelven írt API-k vannak, amelyek a legalapvetőbb szolgáltatásokat adják, továbbá a struktúra egyik legfontosabb eleme a Dalvik VM virtuális gép. Ez a regiszter-alapú VM futtatja az androidos alkalmazásokat, melyek Java nyelven vannak megírva. Minden egyes processzhez a virtuális gép egy futó példánya tartozik, így biztosítva a reszponzivitást és a biztonságot. A VM rendelkezik automatikus memóriaszemét gyűjtő alrendszerrel és támogatja a többszálú programozást. A rendszer részei továbbá a Java könyvtárak, amelyeket közvetlenül az alkalmazások fejlesztői elérhetnek. Lehetőség van natív kóddal rendelkező programok fejlesztésére is, de ez lényegesen nehezebb feladat, mha Java nyelven történne a fejlesztés. Az Android fő hardverplatformja az ARM, de ezen kívül más platformokra is történik portolás napjainkban is. 6. ábra. Az Android rendszer architektúrája [15] Az első széles körben elérhető Android verzió az 1.0 volt, amely 2008-ban került kiadásra. Ez stabil volt ugyan, de nem volt népszerű, és nem igazán nyerte el a felhasználók tetszését. Az első kiadás óta az Android rengeteget fejlődött, jelenleg a stabil változata a 4.4 -es verziószámnál tart. Az újabb és újabb verziók általában mindig új funkciókat hoznak magukkal, illetve a meglévőket javítják, sebességet növelik, a sebezhetőségeket foltozzák be. Azonban a különböző verziókkal az API is sokszor megváltozik, ami megnehezíti a fejlesztés folyamatát. Sokszor előfordul az, hogy a régi, jól bevált megoldások helyet egy újfajta felületet használatára kényszeríti a programozókat a Google. Ez különösen fellép akkor, amikor az eddig meglévő funkciókat elavult jelzővel látja el (deprecated). Ez azt jelenti, hogy az adott funkció még bennmarad a programozási könyvtárban, de már nem fejlesztik tovább, és bármikor kivehetik, tehát nem érdemes használni. Az Android állandó változása miatt nehéz frissen tartani a szoftvereket. A másik probléma 13

18 az, hogy nehéz olyan alkalmazást fejleszteni, amely mindegyik Android verziót teljességgel támogatja, az előbb felsorolt problémák miatt. Az Android fejlesztés nagy hátránya még, hogy például az ios-el szemben rengeteg fajta hardver érhető el, és sokszor ezek egyazon API hívást különböző módon hajtanak végre, tehát nem csak a verziókkal, hanem a telefonokon lévő különböző implementációkkal is meggyűlik a programozók baja. 7. ábra. A használt Android verziók eloszlása harmadik negyedévéig [16] Az Android mobilplatformon rengeteg elérhető szolgáltatás van a programozók részére. A dolgozat témáját tekve a legfontosabb a helymeghatározás: mind a GPS alapú, mind a Google-féle kevert cella és WiFi hálózat alapú szolgáltatás elérhető. A rendszer támogatja továbbá különböző szenzorok használatát, úgy m a giroszkóp, távolságérzékelő, fényérzékelő, gyorsulásmérő, hőmérő, légnyomásmérő, mágneses iránytű, páratartalom mérő. Támogatja a kép és videofelvételt, akár fullhd minőségben is. Mind a GSM, mind a Code Division Multiple Access (CDMA) hálózaton használható a telefonálás, SMS, MMS és a mobilernet szolgáltatás. Támogatja a WiFi, a Bluetooth és a Near Field Communication (NFC) többféle verzióit [7] Az ios mobilplatform Az ios operációs rendszert az Apple fejlesztette ki. Zárt forráskódú, és kizárólag iphone, ipod Touch és ipad készülékeken futtatható, ARM processzoron, Power VR grafikus gyorsítókártyával. Az ios az OSX-ből származik, így osztozik a Darwin alapon, ez utóbbi az Apple 2000-es évek elején kifejlesztett, UNIX-alapú operációs rendszere. Az első publikusan elérhető verzió június 29-én jelent meg, a legfrissebb, pedig november 14-én [18]. 14

19 A rendszer négy absztrakciós rétegre bontható fel [20], amelyeket a 8. A legalsó szen helyezkedik el a Core OS réteg, amely lényegében a kernelt tartalmazza, illetve a hardverközeli, alacsony-szű szolgáltatásokat. A Core Services réteg adja az alkalmazások számára az alapvető rendszerszolgáltatásokat, ilyenek például az automatikus referencia számlálás, blokk objektumok, adatvédelem, aszinkron végrehajtási sorok. A Media réteg tartalmazza azokat a grafikai, audió és videó technológiákat, amelyek a multimédia alkalmazások fejlesztését lehetővé teszik, a teljesség igénye nélkül: hardveresen gyorsított rajzolás, 2D és kép alapú renderelés, médialejátszó modul, kódekek, stb. A legfelső szen a Cocoa Touch áll, amely az alkalmazások építőelemeit tartalmazza, m például gombok, panelek, szövegmezők. Fontos megjegyezni, hogy a Cocoa Touch a Model-View-Controller architektúrát követi. Az ios programok készítéséhez fejlesztőeszközök széles skálája áll rendelkezésre, azonban ezek nagy része sze kizárólag OSX operációs rendszeren fut. Az alkalmazások implementációs nyelve az Objective-C, illetve az alacsonyabb szű API-k esetén a C. A rendszer zártsága miatt a verzióproblémák nem lépnek fel, m Android esetében. Gyakorlatilag csak egy hardverre kell fejleszteni, mivel csak Apple készüléken fog futni az alkalmazás. Továbbá az eddig megjelent készülékek különböző verziói sem térnek el nagyban egymástól, olyannyira, hogy az utolsó kettőt eltekve a képernyők mérete is egy az egyben megegyezik. 8. ábra. Az ios rendszer architektúrája [19] 15

20 2.3. Létező, elérhető megoldások Természetesen már vannak hasonló mobilalkalmazások, amelyek a dolgozatban tárgyalt keretrendszer funkcionalitásait részben megvalósítják. Az Android alkalmazásboltjában, a Google Play-ben található pár ilyen program, a 2. táblázat ezeket hasonlítja össze. Név Előnyök Hátrányok Ár Letöltések Értékelés Meghatározható au- Nincs térkép, nehe- Proximity Alert (Patrick J. Doran) tomatikus műveletek a pont körzetébe érkezéskor zen átlátható, csak kézzel lehet felvenni pontokat Ingyenes Proximity Alerts (4real.gr) Nagyfokú testreszabhatóság, informatív térképes reprezentáció Elavult GUI, csak kézzel lehet felvenni pontokat Ingyenes Pont közelébe érve Modern felhasználói egy automatikus Proximity Alert (AndroidRaj) felület, a felvett pontok exportálhatóak, illetve akciót tud csak végrehajtani: SMS küldést. A felvett Ingyenes importálhatóak pontok listája nem kezelhető. Nagyon uitív Location Alert (Jarvisware) UI, kedvenc pontok kezelése, figyelmeztetések kötése időervallumhoz, áttekhető lista megjelenítése dátum Nincs automatikus akció végrehajtás, a készített POI lista nem elmenthető, nem is importálható Ingyenes szer Locus Pro (Assam Software) Rendkívül testreszabható, sok funkcionalitással, többféle offline térkép, POI lista importálása/exportálása több formátumban Hétköznapi felhasználóknak bonyolult felület, a demó időszak után viszonylag drágának tekhető 1861 Ft táblázat. Elérhető megoldások összehasonlítása A 2. táblából kiolvasható, hogy bár több létező program is elérhető már, ezek közül egyik sem ad teljes funkcionalitást a felhasználók számára, továbbá nem is bővíthető tetszőleges módon, így van igény olyan keretrendszerre, amely fölé az adott igények szeri helyfüggő mobilalkalmazást lehet építeni. 16

21 3. Keretrendszer POI-alapú térinformatikai alkalmazásokhoz Ez a fejezet egy olyan keretrendszer specifikálását, tervezését és megvalósítását mutatja be, amelyből bármilyen igénynek megfelelő specializált Po of Interest (POI) alapú helyfüggő mobilalkalmazást lehet fejleszteni Specifikáció A következő alfejezetek a keretrendszer részletes specifikációját tárgyalják, bemutatják a felhasználói erfészt, továbbá részletesen leírják az alkalmazás funkcióit is Általános leírás A keretrendszer olyan alkalmazások fejlesztését teszi lehetővé, amelyek megkönnyítik a felhasználó térképpel történő tájékozódását. Az alkalmazás fő képernyőjén egy térképnézet jelenik meg, ezen POI-k helyezhetőek el, amikre kattva a felhasználó információkat szerezhet az adott helyről. Az alkalmazásból lekérhető az aktuális pozíció is, melyet a telefon beépített GPS modulja és/vagy a Google cella alapú szolgáltatás ad meg. A felhasználó kijelölhet egy, vagy több meghatározott POI-t, és ha ez egy megadott távolságon belül kerül, akkor az alkalmazás figyelmezteti őt, vagy egyéb előre meghatározott akciókat hajt végre. A keretrendszert úgy kell elkészíteni, hogy egy olyan alapot adjon a fejlesztők számára, amiből többféle POI alkalmazás alakítható ki, azonnal specializálható legyen a különböző igényekre, például: - tömegközlekedésben az állomáshelyre való beérkezés jelzésére, - túrázóknak, kirándulóknak Geocaching célokra, - városnézőknek, nem ismert érdekes pontok megtalálására, - autóvezetőknek kritikus hely, például benzinkút közelségének figyelmeztetésére, - sportolóknak figyelmeztetésre, ha szakaszhatárhoz értek, - és ezekhez hasonló bármilyen helyhez kötött rutin elvégzésére. 17

22 Forgatókönyv A 9. ábra az alkalmazás képernyőinek elrendezését, funkcionalitását és a képernyők közötti relevanciákat szemlélteti. 9. ábra. Az úgynevezett GUI storyboard A forgatókönyvben szereplő képernyő állapotok a következőek: 1. képernyő: A program általános főképernyője, a térképen megjelenő POI-kkal és az egyik adatait tartalmazó buborékkal. 2. képernyő: A készülék hardveres menügombjáról nyíló menüje. 3. képernyő: A térképnézet felett megjelenő, Load KML menüpontból hívható dialógus, amellyel az online POI-kat lehet letölteni. 4. képernyő: Ezen a felületen a felhasználó beállíthatja azt a távolságot, amelyen belülre érve az alkalmazás figyelmezteti őt a POI közelségéről. 5. képernyő: Azt a listát demonstrálja, amelyen a felhasználó kiválaszthatja azt a POI-t, amelyikre távolsági figyelmeztetést szeretne kapni. 18

23 6. képernyő: Itt a beállítások láthatóak, ezeknek teljes listáját a specifikáció nem határozza meg, a terven csak két példát láthatunk. A forgatókönyvön jól látszik, hogy az egyes funkciók a térképnézet felett megjelenő menüből érhetőek el. Azok a funkciók, amelyek nagyobb mennyiségű új információt adnak a felhasználónak, új ablakban nyílnak meg, az egyéb funkciók pedig modális dialógusablakokon keresztül érhetőek el Használati esetek A 10. ábra az alkalmazás használati eseteit mutatja be, azt, hogy kik és mire használják a rendszert, továbbá milyen egyéb feltételeknek kell teljesülniük a specifikációnak megfelelően. MobilWPOIWAdatbázis <uses> 5 POIWKiválaszóWmodul GPS WifiWlokalizáció 6 Beállítások <uses> POIWExportálás <uses> Térkép POIWmegjelenítés <extends> <uses> <uses> Lokalizáció <uses> GSMWCellaWinfo <uses> POIWAdatbázis <uses> POIWImportálás TérképWNézet 5 Riasztás <uses> 3 User 10. ábra. Az alkalmazás UML use-case diagramja 3.2. Architektúra Az alkalmazás több alrendszerből épül fel, amelyek különállóan is képesek funkciót betölteni. Ezek kapcsolatban vannak egymással, és közösen valósítják meg a specifikációban leírt funkciókat: - Mobil POI adatbázis: SQLite adatbázisban tárolja a POI-kat. Ez az alrendszer központi szerepet tölt be. Kapcsolódik hozzá a POI kezelő, megjelenítő és a riasztásért felelős alrendszer is. 19

24 - Térkép és POI megjelenítés: Ez az alrendszer jeleníti meg a térképet és az aktuális nézeten látható érdekes pontokat is. Közvetlenül a POI adatbázistól kéri le a megjelenítendő adatokat. Két rétege van: a térkép, amelyet egy meglévő komponens felhasználásával rajzol ki, illetve a POI pontok rétege. - POI kezelés: Érdekes pontok importálását, szerkesztését és exportálását magában foglaló alrendszer. Az importáláshoz kapcsolatban áll külső POI adatbázisokkal, valam a felhasználó által összeállított POI fájlt is tudja importálni. Ezeket az adatokat a POI adatbázis alrendszer menti el. - Helymeghatározó modul: Helymeghatározásért felelős modul, mely magában foglalja a GPS, WiFi és GSM cella adatok alapján történő lokalizációt is. Ezeket a hardveres szolgáltatásokat az Android SDK által biztosított, magasabb szű absztrakciós rétegen keresztül éri el. A Riasztás modul ennek segítségével tudja meghatározni, hogy történt-e kiválasztott POI-khoz kötött esemény. A térképnézet ezen alrendszer alapján határozza meg, és rajzolja ki a felhasználó aktuális pozícióját. - Riasztás modul: Ez a modul felel az érdekes pontok hatáskörébe érkezéskor történő riasztásért. Adatait a POI adatbázistól kapja és riasztáshoz a lokalizációs modultól kapott információkat is felhasználja. Amennyiben a felhasználó kezeli a riasztást, akkor a térkép megjelenítő modul szolgáltatását hívja meg. TérképQnézet POIQszerkesztésQésQkiválasztás ImportálásQésQExportálás Riasztás POIQAdatbázis MédiaQésQfájlQkezelés HálózatiQkommunikáció SQLite Lokalizáció AndroidQDalvikQVM LinuxQkernel 11. ábra. Az alkalmazás rétegzett architektúra diagramja 20

25 3.3. Megvalósítás A keretrendszer alkalmazás elkészült implementációját tárgyalja ez a fejezet, bemutatva az architektúra megvalósítását, továbbá a kész felhasználói felületet képernyőképeken keresztül A megvalósult szoftverarchitektúra rövid bemutatása cd UMLClassDiagram1 A következő szakasz a programkódot alkotó osztályok működését, és azok kapcsolatát tárgyalja, melyek a 12. ábrán jól megfigyelhetőek. SettingsActivity Attributes # cellcheckbox : CheckBox # gspcheckbox : CheckBox # saveselectedcheckbox : CheckBox # savesettingcheckbox : CheckBox # servicebutton : Button # servicecheckbox : CheckBox # settings : SharedPreferences Operations ProximityServiceConnection Attributes Operations + getservice() : ProximityAlertService + onserviceconnected(component, IBinder) : void + onservicedisconnected(componentname) : void + ProximityServiceConnection() + setservice(proximityalertservice) : void ProximityServiceConnection N ProximityServiceConnection 1 ProximityAlertService 1 ProximityAlertService Attributes # locationmanager : LocationManager # proximityposition : # proximityvalues : Integer[] # selected : ArrayList<Integer> Operations + getserviceconnection() : ServiceConnection + ProximityAlertService() - addproximityalert(double, double, ) : void - addproximityalerts() : void - removeproximityalerts() MainActivity 1 GeoLocatorTask MainActivity Attributes # currentlocation : Location Operations - GeoLocatorTask() # doinbackground(object[]) : Object # onpostexecute(object[]) : void Attributes # LocationManager : locationmanager # mapoverlays : List<Overlay> # placemarks : ArrayList<PlaceMark> # poioverlay : PlaceMarkOverlay # proximityvalues : Integer[] # selected : ArrayList<Integer> Operations ProximityIntentReceiver Attributes Operations + onreceive(context, Intent) : void + ProximityIntentReceiver() - createnotification(pendingintent) : Notification - addlocationoverlay() : void - bindservice() : void - handeproximity() : void - handleabout() : void - handlelocation() : void PlaceMarkOverlay DoubleTapMapView Attributes # geturedetector : GestureDetector Operations + DoubleTapMapView(Context, AttributeSet) + DoubleTapMapView(Context, AttributeSet, ) + DoubleTapMapView(Context, String) + onsaveinstancestate(bundle) : void + ontouchevent(motionevent) : boolean DoubleTapMapView 1 MainActivity 1 - handlepoiloading() : void - handlepoiselect() : void - handlesettings() : void - populatepoioverlay() : void - readlists() : void - unbindservice() : void MainActivity 1 MainActivity 1 PlaceMarkOverlay N Attributes # dialogicon : Drawable # overlays : ArrayList<OverlayItem> Operations + addoverlay(overlayitem) : void + draw(canvas, MapView, boolean) : void + ontap() : boolean + PlaceMarkOverlay(Drawable) + PlaceMarkOverlay(Drawable, Context, Drawable) + populateoverlay() : void + size() : # createitem() : void CoordinateUtils Attributes Operations + coordinatetogeopo1(double, double) : GeoPo SelectPoiActivity PlaceMarkSaxHandler + CoordinateUtils() + getsimplestringfromaddress(address) : String + locationtogeopo(location) : GeoPo + placemarktooverlayitem(placemark) : OverlayItem Attributes # adapter : PlaceMarkAdapter # filtered : HashMap<PlaceMark, Integer> # filtertext : EditText Attributes # coordinates : boolean # current : boolean # description : boolean # name : boolean # placemark : boolean ParcelableGeoPo # filtertextwatcher : TextWatcher # list : ListView # selected : ArrayList<Integer> # selectionchanged : boolean Operations # po : boolean Operations Attributes + characters(char[],, ) : void + endelemenet(string, String, String) : void + getplacemarks() : ArrayList<PlaceMark> + PlaceMarkSaxHandler() + startdocument() : void + startelement(string, String, String, Attributes PlaceMarkSaxHandler N Operations + ParcelableGeoPo() + ParcelableGeoPo(, ) + ParcelableGeoPo(GeoPo) - ParcelableGeoPo(Parcel) - writetoparcel(parcel) : void ParcelableGeoPo 1 PlaceMark 1 PlaceMark N PlaceMark Attributes - coordinates : ParcelableGeoPo - description : String - title : String Operations + PlaceMark(String, String, String) PlaceMark + PlaceMark(String, String, double, double) + PlaceMark(String, String,,, boolean) 1 + writetoparcel(parcel, ) : void - readobject(objectinputstream) : void - writeobject(objectoutputstream) : void 12. ábra. Az alkalmazás UML osztálydiagramja PlaceMark: Egy POI-t reprezentáló osztály, tartalmazza a POI rövid címét és egy hosszabb leírást róla, továbbá magába foglalja a POI koordinátáit, ami a ParcelableGeoPo osztály egy példányaként jelenik meg. A PlaceMark osztály megvalósítja az Android Parcelable erfészét, illetve a Java Serializable erfészét, így 21

26 könnyen küldhető képernyők között Intent-eken át és szerializációval fájlba menthető. ParcelableGeoPo: A Google APIs-ban megtalálható GeoPo osztály leszármazottja. A nevéből is adódóan megvalósítja a Parcelable erfészt, így könnyen elküldhető képernyők között. Erre azért is szükség van, mert a PlaceMark, amely szén Parcelable, az osztály egy példányát tartalmazza. DoubleTapMapView: Szén egy Google APIs-ban elhelyezkedő osztály, a MapView leszármazottja. Az ősosztályhoz képest annyi plusz funkcionalitást ad, hogy dupla érés esetén ránagyít a térképfelületre, ahogy azt a legtöbb ilyen alkalmazás teszi. A dupla érés detektálását egy GestureDetector objektummal teszi meg. PlaceMarkOverlay: Az ItemizedOverlay osztály leszármazottja. A Google APIs-ban ez az osztály valósítja meg a térképfelületre egy jelölő halmaz rajzolását. Az osztály PlaceMark objektumokat képes megjeleníteni a térképfelületen, mindegyiket egy-egy jelölő formájában. Amennyiben erre katt a felhasználó, az ontap() metódus meghívása során egy felugró ablakban megjeleníti az adott érdekes pont részletes adatait. PlaceMarkSaxHandler: Az XML-alapú POI formátumok értelmezését, feldolgozását megvalósító osztály. A Simple API for XML (SAX) a Document Object Model-el (DOM) ellentétben nem egy fát építi fel a dokumentum alapján, melynek elemeit tetszőleges részletességű lekérdezésekkel lehet elérni, hanem egy menetben végigolvassa a fájlt, és azonnal értelmezi is. Az olvasás közben eseményeket észlel, m például egy XML elem kezdete, vagy vége. Ilyen esetben hívódnak meg az osztály függvényei. Az osztály logikai változókkal tartja számon, hogy melyik XML elemnél tart éppen az olvasás, és ezeket feltételként felhasználva elágazásokkal dolgozza fel a fájlt. Fontos megjegyezni, hogy a SAX -nak az a nagy előnye a DOM -al szemben, hogy jóval kevesebb memóriát fogyaszt, illetve a CPU-igénye is alacsonyabb, így ideális mobilkészülékeken való használatra. ProximityAlertService: Ez az osztály az alkalmazás lelke, ugyanis ez valósítja meg a POI-k helyzetének figyelését és a riasztást. Ez az osztály a Service leszármazottja, és nevéből is látszik, hogy egy háttérbeli szolgáltatást végez. A Service-t a felhasználó bármikor leállíthatja a beállítások képernyőről. Ez a szolgáltatás elindulásakor az Android rendszerben regisztrálja, hogy mely koordináták közelségére kell figyelni, illetve leállásakor ezeket a figyeléseket távolítja el. Ezt mindenképpen meg kell tenni, különben azok a végtelenségi működnek, feleslegesen fogyasztva a készülék erőforrásait. 22

27 ProximityIntentReceiver: A felhasználó figyelmeztetését ez az osztály végzi. Amennyiben egy kijelölt érdekes ponthoz érünk, meghívódik az onreceive() metódusa, amely egy Notification objektumot készít el. Ez utóbbi a figyelmeztetést mind a képernyő tetején található értesítési területen, mind a villogó LED-en jelzi a felhasználó felé. MainActivity: Az alkalmazás központi osztálya. Ez jeleníti meg a térképnézetet, és innen érhető el a többi Activity is a menün keresztül. Az osztály hosszan tartó műveleteket is elvégez, ilyen például a POI-k fájlba mentése, avagy a felhasználó aktuális pozíciójának lekérése. Ezeket egy külön szálon futtatja, így a GUI továbbra is reszponzív marad. SelectPoiActivity: A POI-k kezelését valósítja meg. Fő eleme egy ListView, amellyel listában jeleníti meg a letöltött érdekes pontokat és azok lehetséges beállításait. Az egyszerűbb kezelhetőséget elősegítve egy szűrőmezőt tartalmaz, ami gépelés közben azonnal szűrt találatokat jelenít meg a listában. Ezt a funkciót a TextWatcher osztály egy példányával éri el, amely minden szövegváltoztatás esetén egy eseményt küld, illetve egy Filter leszármazottal, amely a konkrét szűrést végzi. A szűrt adatokat hasító táblában tárolja, így rendkívül gyorsan, konstans idő alatt képes lekérni a szűrt elemek indexeit. 23

28 Képernyőképek A 13. ábrán a megvalósított androidos alkalmazás képernyőmentései láthatóak, HTC Sensation készüléken, Android operációs rendszeren futtatva. A három képen az elkészült alkalmazás három állapota látható. Az Android natív GUI elemeit használva belesimul az operációs rendszer és a többi alkalmazás felhasználói felületébe, ezáltal egy konzisztens felhasználói élményt nyújt. A felhasználónak nem kell újra felfedezni az alkalmazást: a már megszokott mákat használva tudja elérni a bizonyos funkciókat. Látható, hogy a menü nem teljesen egyezik meg a tervekkel: az implementáció a klasszikus menü helyett az úgynevezett Action Bar-t használja, amely az alkalmazás címével egy vonalban helyezkedik el, a legfelső sorba helyezi a menügombokat, ezzel is több helyet hagyva a lényegi tartalomnak. Azok a menüelemek, amelyek már nem férnek ilyen módon ki a képernyőre, a 3 ponttal jelzett gombbal előhívhatóak. Érdemes megjegyezni, hogy a régebbi Android verziókon ez a fajta menüelrendezés alapértelmezésben nem érhető el. Így az alkalmazást régebbi készülékeken futtatva a klasszikus, a GUI terveken is megtalálható menü jelenik meg. 13. ábra. Képernyőképek az alkalmazásról 24

29 4. Terepi mobil kliensalkalmazás biodiverzitás felméréséhez Az alkalmazás egy - a svájci alap által támogatott projekt keretében készül el, melynek célja a magyarországi erdők biodiverzitásának minél alaposabb megismerése [22]. Az erdők változatosságának megőrzése kritikus Magyarország számára, de az országban eddig nem volt ilyen teljes körű felmérés, az egyes mérések izoláltak voltak, továbbá nem adtak kielégítő részletességű képet a hazai erdők állapotáról. A felmérés kezdetben az Északi-középhegység erdőiben fog zajlani, és az előzetes eredmények kiértékelése után az ország többi erdőjére is kiterjedhet majd. A projekt biológiai szakmai feladatait az ELTE Növényrendszertani, Ökológiai és Elméleti Biológiai Tanszék, továbbá a Duna-Ipoly Nemzeti Park végzi el, a felmérésben ember fog részt venni. A mavételi pontok egy pontháló mentén lesznek kijelölve. A szisztematikus mavétel során minden változóra külön-külön készíthető egy ponttérkép, amely rapoláció segítségével teljes lefedésű térképek előállítását teszi lehetővé. A projekt keretén belül sor kerül néhány faj élőhely-megfelelőségi vizsgálatára, amely során kiderül, hogy milyen élőhelyi elemekre és abból mennyire van szüksége az adott fajnak. Ennek köszönhetően elérőjelzéseket is lehet majd adni az adott faj előfordulására. A térképek birtokában javaslatok tehetőek a beavatkozások helyének megadására, hogy azok a lehető legkisebb változást okozzák az erdők biológiai sokféleségében Funkcionális specifikáció A program a terepi felmérésben vesz részt, egyfajta felületet ad az adatok bevitelére. Az alkalmazás egy kliens, melyhez egy szerveroldal is tartozik, ez utóbbi szolgáltatja a felmérési feladatokat, változókat, amelyeket a felmérő a program segítségével kitölt, és az adatokat visszatölti a szerverre. 25

30 Az alkalmazás platformja Android 4+ mobil operációs rendszer, feladatai a következőek: - a felhasználókat autentikálni; - FTP-n keresztül a felhasználó mérési feladatait (csomagjait) le-, illetve feltölteni; - felkínálni szerkesztésre az adatgyűjtőn lévő csomagokat, illetve azok mavételi pontokhoz tartozó rekordjait; - a mavételi pont rekord kiválasztásának segítése (név, készenléti állapot alapján, sok rekord közül); - menedzselni az egy mavételi ponton történő adatgyűjtés folyamatát; - követni a csomagok feltöltöttségi, készenléti állapotát, metaadatait; - kezelni a rekord metaadatait; - regisztrálni és a feltöltés során a csomaggal együtt mozgatni a rögzítésre került média anyagot (kép, hang), metaadatokat. A 14. ábra a felmérési rutin szokásos menetét mutatja be, jelezve, hogy melyik művelet melyik képernyőhöz tartozik. Felmérés Init Első init? Nem Napi letöltés Csomag kiválasztás Pont kiválasztás Napi feltöltés Igen Bejelentkezés Mozgás pontra Űrlap kitöltése 14. ábra. A felmérés egyszerűsített folyamatábrája Az alkalmazás indításakor a bejelentkező képernyő jelenik meg, amely két szövegmezőt tartalmaz a felhasználónév és jelszó beírásához, valam egy Belépés gombot, amelyre kattva a program a főképernyőre ugrik, amennyiben a beírt adatok helyesek A főképernyőről elérhető funkciók A főképernyő a következő továbblépési lehetőségeket tartalmazza: Felmérés, Letöltés, Feltöltés, Beállítások, Kilépés. Mindegyik gomb értelemszerűen az adott funkciót megvalósító képernyőre ugrik, a Kilépés gombra kattva az alkalmazás leáll. 26

31 Felmérés: A képernyő listázza a letöltött csomagokat, egy csomagra kattva az adott csomag pontjait listázó képernyőre vált. Az egyes csomagok listaelemekként vannak megjelenítve, ezen elemek tartalmazzák a csomag nevét, illetve azt, hogy a csomag milyen készültségi szen áll (elkészült pontok száma/összes pont száma). 15. ábra. Bejelentkezés 16. ábra. Főképernyő 17. ábra. Csomaglista Letöltés: Internet kapcsolat esetén az adott felhasználónak kiadott csomagokat lehet letölteni a szerverről. Egy listában megjeleníti az elérhető csomagokat, melyekből a felhasználó kiválaszthatja, melyeket szeretne letölteni. Letöltés esetén a csomagok tárolódnak a készülék SD kártyáján. Feltöltés: Internet kapcsolat esetén a felhasználó az elkészült felmérési csomagokat feltöltheti a szerverre. Csak a valóban elkészült csomagokat ajánlja fel listában a program, ezek közül a felhasználó kiválaszthatja és feltöltheti az adott csomagokat. Amennyiben teljességgel sikeres egy csomag feltöltése, az törlődik a készülék háttértárjáról. Beállítások: A beállítható funkciókat listázza a program ezen képernyőn. Egyelőre két ilyen beállítási lehetőség van: a csomagokat kezelő szerver címe, illetve a fajnevekben történő keresés módszere. Az alkalmazás nyelvét automatikusan nem lehet beállítani, viszont az Android rendszerben éppen aktuálisan kiválasztott nyelvet a program figyelembe veszi Közvetlenül a felméréshez kapcsolódó képernyők Az alkalmazás legfontosabb feladata egy adott terület mérési pontjainak felmérése. Ez az alfejezet azt írja le, hogy a felméréshez kapcsolódó képernyők pontosan milyen funkcionalitással rendelkeznek. 27

32 Pontok listázása: A felmérési pontokat a program egy rácsszerkezetben jeleníti meg. A GUI-n megfelelő pozíció a rácsban közelítést ad a felhasználónak a pont valós fizikai helyzetére. A pontok háttérszíne jelzi az adott pont készültségi állapotát. Fekete szín jelzi a nem felmérendő pontot, a piros a felmérendő de még el nem kezdett pontot, sárga a folyamatban lévő pontot, kék a befejezett pontot. A legközelebbi pontot a program egy kör fölé rajzolásával különbözteti meg. Kérdéscsoportok listázása: Az adott ponton a navigáció befejezése után az adott pontra vonatkozó űrlapot töltheti ki a felhasználó. Az űrlap kérdéscsoportokba van rendezve, ez a képernyő ezeket listázza ki. Adott kérdéscsoport csak akkor nyitható meg, ha az előző már be van fejezve. A befejezés azt jelenti egy kérdéscsoport esetében, hogy a tartalmazott összes kötelező kérdés már kitöltésre került. Egy kérdéscsoportra kattva az adott kérdéscsoport első kérdésével kezdve jelenik meg az űrlap megfelelő része. Űrlap: Adott kérdéscsoportban található kérdéseket jeleníti meg és teszi kitölthetővé. Egyszerre alapesetben egy kérdést jelenít meg, kivételes esetben rövid kérdések esetén többet. A kérdések között (következő, előző) úgynevezett swipe gesztussal lehet váltani. Amennyiben a kérdés kötelezően kitöltendő és még nincs kitöltve, akkor a következő kérdésre nem enged ugrani, továbbá ha egy kérdésre helytelen választ ad a felhasználó, szén letiltásra kerül a továbbugrás. Minden kérdés esetén lehetőség van bármikor a kérdéscsoportokat listázó képernyőre visszalépni. 18. ábra. Pontok listázása 19. ábra. Kérdéscsoportok 20. ábra. Űrlap Az űrlapon szereplő lehetséges kérdéstípusok Általánosan: Minden egyes kérdésnél a képernyő tetején a kérdés címe jelenik meg. Egy kérdésnek lehetnek megszorításai, mely azt jelenti, hogy szűkíti a válaszok halmazát 28

33 az adott vagy más kérdések már meglévő válaszai alapján. Amennyiben a felhasználó nem ebből a halmazból ad választ, akkor az nem kerül rögzítésre és a program figyelmeztet a helytelen válaszról. A kérdések relevanciával is rendelkezhetnek, ez azt jelenti, hogy nem a következő kérdésre, hanem egy másik megadott kérdésre ugorhatnak. Egyszeres választás: A választási lehetőségeket listában, rádiógombokként jeleníti meg. Minden lehetőség esetén a választott érték fel van tüntetve. A válasz kiválasztása után a következő kérdésre navigál az alkalmazás. Többszörös választás: A választási lehetőségeket listában jeleníti meg, minden listaelem áll egy jelölőnégyzetből, amely a kiválasztást reprezentálja, továbbá az értékből, szövegesen megjelenítve. Ezekben a listákban előfordulhat az egyik sem pont, amely választása esetén ellentmondás fordulhat elő (más lehetőségek is kiválasztva lehetnek). Ha ez az ellentmondás felmerül, akkor a program szövegesen figyelmezteti a felhasználót annak feloldására. Szöveges bevitel: Ilyen kérdés esetén egy szerkeszthető szövegmezőbe lehet bevinni a választ. Alapvetően kétféle ilyen kérdés lehetséges: szöveges vagy egész szám érték. Amennyiben egész szám típusú az adott kérdés, akkor a billentyűzeten csak a számok billentyűi jelennek meg. Egyszeres választás legördülő listával: Rövid választási listával rendelkező egyszeres választást úgynevezett Spinner -rel jelenít meg. Ez az aktuálisan kiválasztott értéket mutatja egy dobozban, amire kattva egy legördülő lista jelenik meg. A lista egy elemére kattva az újonnan választott érték az adott listaelemben szereplő lesz. Képek választása: Lehetőség van többszörös és egyszeres választás esetén képeket felajánlani választási lehetőségként. Ekkor a képek egy rácson kerülnek megjelenítésre, egy adott képre kattva annak kerete megváltozik, jelezve ezzel a választás állapotát. Fotó: Az ilyen típusú kérdés megjelenít egy képmezőt, melyen a kamera képe jelenik meg, továbbá egy gombot, amelyre kattva rögzítésre kerül a fotó a kamerán keresztül. Az ilyen típusú kérdés mindig fekvő módban jelenik meg. Táblázatos kérdés: Több válasz adását teszi lehetővé, továbbá a már betáplált válaszok teljes törlését. A válaszokat egy listában jeleníti meg, új válasz adását a jobb 29

34 felső sarokban található + gombra kattva lehet elvégezni. Ekkor a lista végére beszúrásra kerül egy üres válasz és a képernyő ehhez görgetődik. Amennyiben a válasznak egy fő értéke van, először ez kerül betáplálásra egy másik képernyőn keresztül. A válasz alértékei alapesetben összefoglaló módon az adott lista eleme jobb szélén jelennek meg. Ezeket szerkeszteni nem lehet ilyen állapotban. A szerkesztés megkezdéséhez a lista elemre kell kattani, amely lenyílik és második megjelent sorában mutatja a szerkeszthető mezőket. A válasz első sorára kattva összecsukódik az adott sor. Az adott válasz során hosszú kattással az úgynevezett Contextual Action Bar jelenik meg. Ekkor a képernyő felső során, az úgynevezett Action Bar-on, eltűnik az adott menü ikonja, helyére törlés gomb kerül. Az egyes listaelemekre (válaszokra) kattva több válasz is kijelölhető, a törlés gombra kattva a válaszok eltávolításra kerülnek. A bal felső sarokban a Kész gombra kattva a törlés és kijelölés művelete befejezhető és meg a szokásos menü jelenik meg. 21. ábra. Táblázatos kérdés Válasz adása kereshető listával: Ha ilyen kérdésre kattunk, akkor egy új képernyő jelenik meg, amelyben egy lista van megjelenítve a lehetséges válaszokkal. A felső sorban egy keresőmező található, ebben szövegesen írva miden egyes gépeléskor a lista szűkül, csak azokat az elemeket jeleníti meg, amelyekben a keresőszó megtalálható. Lehetséges, hogy összetett választási lehetőségek vannak. Ekkor csak a kitüntetett (fő) érték jelenik meg a listában, de keresve az adott válasz alternatív részeiben is keres az alkalmazás. Lehetséges, hogy egy kérdésre több lista is rendelkezésre áll. Ezek között váltani a jobb felső sarokban lévő gombbal lehet. Amennyiben listát váltunk, az új lista jelenik meg, és a keresőszó törlődik. A listában egy elemre kattva kiválasztjuk az adott lehetőséget, a program visszaugrik az előző (a kérdés) képernyőjére, és abban megjeleníti a választott lehetőséget. 30

35 22. ábra. Egyszeres választás 23. ábra. Többszörös v. 24. ábra. Kereshető lista Időváltozó: Egyes kérdéseknél szükség van arra, hogy a kérdésnél mennyi időt töltött el a felhasználó. Ezért ez mérésre kerül. Amennyiben a felhasználó visszatér a kérdéshez, az idő hozzáadódik a már meglévőhöz, nem felülíródik Architektúra terv Ez a fejezet az alkalmazás szerkezetét tárgyalja és mutatja be az egyes modulok felépítésének tervét. Az alkalmazás rétegzett architektúra modellje, mely a szerkezetet írja le, a 25. ábrán látható. Pontok,XcsomagokXnézete ŰrlapXnézet Pontok,XcsomagokXkezelése ŰrlapXlogika AdatbázisXkezelő XMLXfeldolgozó MédiaXésXfájlXkezelés HálózatiXkommunikáció SQLite AndroidXDalvikXVM LinuxXkernel 25. ábra. Az alkalmazás rétegzett architektúra modellje 31

36 Autentikáció A felhasználó belépési azonosítóját és jelszavát a központi szerver adminisztrátorától kapja meg, az alkalmazásba történő belépéskor ezeket kell begépelnie. Amennyiben az adatok helyesek, az alkalmazás elindít egy munkafolyamatot, megjegyzi a felhasználó belépett állapotát és nem kéri újbóli megnyitáskor meg azokat. Ezen adatok tárolása az alkalmazás saját belső, más alkalmazások számára nem elérhető tárhelyén történik. A jelszó tárolásánál nem önmagát, hanem a jelszó MD5 hash leképzését tárolja a program. Az FTP szerverrel való kommunikáció során ezt az MD5 kulcsot küldi jelszóként, így a felhasználó tényleges jelszava nem kompromittálódhat. Az FTP szerver felé történő autentikáció az FTP szabvány [25] szer hajtódik végre Hálózati kommunikáció Az adott kérdések le- és feltöltése a szerverre WiFi-n történik. A csomagokat a program egy erre a célra fejlesztett FTP szerverről tölti le. A feltöltés két úton zajlik: egyrészt az előbb említett szerverre, másrészt egyfajta biztonsági tartalékként megadott Dropbox [39] tárhelyre. Dropbox esetén az elkészült csomagokat egy dedikált szinkronizálási mappába helyezi a program. A Dropbox-al történő szinkronizáció nem ezen alkalmazás feladata, azt egy külső program végzi el. A hálózati rendszert egyszerűsítve a 26. ábra mutatja be. Minden egyes felhasználónak saját mappát kap az FTP-szerveren és kizárólag csak ezt éri el. Mivel az FTP szerverrel nem lehet eraktívan kommunikálni, parancsokat végrehajtani az egyszerű fájlműveleteken kívül, ezért a hálózati kommunikáció protokollja egy XML log fájlban kerül bevezetésre, amelyre példa a C függelékben található. A szerver felelőssége, hogy az XML log fájlt egyidejűleg ne tudja a kliens is írni: amennyiben a szerver ír, ideiglenesen eltávolítja a kliens írási jogát a fájlról. A hálózati kommunikáció és a naplózási protokoll lépései a következőek: - a szerver által csomag kihelyezésére FTP mappába, bejegyzés az XML-be, - a kliens letölti az üres csomagot, siker esetén erről bejegyzést tesz, - a kliens egy csomag véglegesítése után azt feltöltődik a szerverre, siker esetén erről bejegyzést tesz, - a szerver mindeközben periodikus ellenőrzéseket végez, a sikeresen letöltött üres csomagokat törli, a sikeresen feltöltött véglegesített csomagokat áthelyezi a PostgreSQL adatbázisába, 32

37 - a kliens a csomagok listázásakor ellenőrzi, hogy a feltöltött véglegesített csomagot a szerver feldolgozta-e már, ez esetben törli a csomagot a mobil tárhelyéről. Felhasználó 1 Kiértékelés Felhasználó 2 Szerver FTP szerver SQLite Csomag1 SQLite Csomag2 PostgreSQL SQLite Csomag1 SQLite Csomag2 26. ábra. A rendszer hálózati áttekése Adatbázis-kezelés Egy csomag egy SQLite adatbázis fájlt jelent. Ezen fájlok tárolása az SD kártyán történik. Amennyiben egy adott csomaggal szeretne a felhasználó foglalkozni, a program lezárja az előzőleg megnyitott.db fájlt, és az újat megnyitja. A letöltéskor a.db fájl tartalmazza a csomag adatait, a pontok listáját és a pontok adatait, továbbá a válaszok tábláit kitöltetlenül. Ezekbe a táblákba a program beszúrja az adatokat. Minden egyes csomagnál egy mappában tárolódik a.db fájl, valam a létrehozott egyéb médiafájlok. Egy csomag véglegesítése után a program kimásolja azt egy dedikált könyvtárba, ahonnan majd a hálózattal történő szinkronizáció történik. Az űrlap flexibilis kezelése érdekében pár szabály került lefektetésre, melyek alapján a kérdések a táblákba lettek sorolva. Ennek köszönhetően a programba nem kell rögzíteni, 33

38 hogy pontosan melyik adatot hova kell beszúrnia, a pont azonosítója, a kérdés azonosítója, a kérdés típusa illetve választható típus esetén a válasz azonosítója szükséges csak az adatbázis-kezelő modulnak a megfelelő mentési hely megtalálásához. Amennyiben egyszeres választás, vagy szöveges bevitel típusú kérdés az aktuális, egyszerűen egy oszlop szükséges csak, ahova a válasz beírható. Többszörös választás esetén a helyzet bonyolultabb: amennyiben kevés válaszlehetőség adott, mindegyiknek egy oszlop van fenntartva, melyek Boolean értékeket tárolnak a kiválasztás függvényében. Amennyiben sok válaszlehetőség van megadva, akkor egy külön táblában tárolja a program a válaszokat. Az adatbázis rövid áttekését az A függelék mutatja be. A csomag tábla szerkezete statikus, egy kiadott feladatcsomagot reprezentál. A ppont tábla szerkezete szén nem változik, egy elméleti felmérési pontot jelent. Minden egyes ppont egyedhez tartozik egy mpont és egy szakasz, ez utóbbiak a tényleges felmért pontadatokat tartalmazzák. Az előbb bemutatott szabályrendszer a példa-adatbázisdiagramon a következőképp valósul meg: a favane oszlop egy egyszeres választást, az n2k prefixű oszlopok a többszörös választás tárolásának első verzióját realizálják, míg a faallomany tábla a többszörös választás tárolási szabályának második verzióját Űrlap Az űrlap leírása a készülék SD kártyáján, a program saját mappájában tárolódik, XML fájl formájában. Az XML fájl felsorolja az összes kérdéscsoportot, az összes kérdést. A kérdéseknek kötelező egy egyedi azonosítóval rendelkezniük, továbbá ajánlott egy leírást adni hozzájuk. Az XML fájl tartalmazza a kérdések közötti relevanciákat is, azaz, hogy különböző válaszok esetén melyik kérdés a következő, ugrásnál melyikre váltson a program. A kérdések megszorításait is tárolja, amely a válaszok lehetőségét szűkíti le megadható szabályok szer. Amennyiben egyszeres vagy többszörös választás típusú kérdésről van szó, a válaszlehetőségeket is ezen XML fájl tárolja. Lehetőség van arra, hogy inline, a kérdés definíciójában történjen ez, illetve arra is, hogy egy másik XML fájlban. Ez akkor hasznos, ha a válaszok listája meglehetősen hosszú, és átláthatatlanná tennék az XML szerkezetét. Mivel egy teljesen flexibilis, dinamikus űrlap fájlban tárolódik a kérdések felépítése, logikája, ezért szükség esetén könnyen lehet módosítani a kérdésfolyamot a program megváltoztatása nélkül. Az alkalmazás a többnyelvűséget is támogatja: amennyiben talál olyan XML fájlt, amely a rendszer jelenlegi nyelvi beállításaihoz illik, akkor az adott nyelven tölti be az űrlapot és az adott nyelven jeleníti meg a kérdéssort a felhasználó felé. Az XML fájl szerkezetét egy rövid példán keresztül a B függelék mutatja be. 34

39 4.3. Megvalósítás Ez a fejezet az alkalmazás implementációját mutatja be. Mivel a program meglehetősen bonyolult, összetett, ezért csak a lényeges részeket emeli ki. A fejezet bemutatja továbbá az elkészült szoftver képernyőképeit is. Answer Interface Answer Questions Question Class Choice Class FTPManager Class AbstractListActivity Class Question FTPManager SelectQuestions QuestionGroup TextInputQuestion SelectQuestion PackageListActivity PoListActivity Class Class Class Class Class Question Question Question AbstractListActivity AbstractListActivity SelectQuestion SingleSelectQuestion Class SelectQuestion MultiSelectQuestion Class QuestionParser Class FormParser Q Class FormParser AbstractActivity Class TextInputQuestionParser Class QuestionParser LoginActivity FormActivity MainActivity Class Class Class AbstractActivity AbstractActivity AbstractActivity FormController Class FormController QuestionFragment Class QuestionFragments DatabaseManager DatabaseManager Class DatabaseManager FormNavigator FormNavigator Class Package Package Class QuestionGroupFragment Class QuestionFragment Po Form Po Class Form Class 27. ábra. Az egyszerűsített osztálydiagram A megvalósult szoftverarchitektúra A 27. ábrán a program elkészült lényeges moduljai és azok kapcsolódásai láthatóak. Az alábbi fejezet az mutatja be, hogy az egyes modulok hogyan vannak implementálva 35

40 és milyen külső komponenseket használnak fel, mind az Android SDK-ből, mind egyéb forrásból. Mivel az alkalmazás Android 4 platformra készül, igénybe tudja venni az Android 3 (API 11) [26] és az Android 4 (API 14) SDK [27] újdonságait. GUI elemek Az űrlap megjelenítése nagyrészt az Android 3-ban bevezetett Fragment-eken alapul [8]. Az űrlapban a kérdéscsoportokon belüli kérdések között jobbra és balra történő ú.n. swipe gesztussal lehet navigálni. Mivel a kérdések nem alkotnak önálló képernyőegységet, nem nyitnak új képernyőt, ezért nem az Activity osztály leszármazottai, hanem a Fragment-é. A Fragment egy önálló egység, rendelkezik eseménykezeléssel, GUI-val, vezérlési logikával. Rendkívül flexibilisen használható: egy képernyőn (Activity-n) belül akár több is elhelyezhető, ezáltal úgymond alképernyőket létrehozva. Ezt a funkciót ki is használja a program. Amennyiben több kérdést kell egyszerre megjeleníteni, például a GPS X és Y koordinátáját bevinni, 3 Fragment-et jelenít meg egyszerre a képernyőn: magát a kérdéscsoportét, továbbá a két kérdését a kérdéscsoporton belül. Nagyon fontos, hogy a lapozás után a kérdés állapotát vissza kell tudni az alkalmazásnak állítani, mivel a Fragment illetve a hozzá tartozó widget-ek nagy memóriaigényűek, nem lehetséges, hogy egyszerre az összes kérdéshez tartozó a memóriában legyen [10]. A program a különböző menük megjelenítésére az Action Bar-t használja. Ez egy új GUI elem, mely a program képernyőjének felső sávjában foglal helyet. Ezen alapvetően jobb oldalt lehet elhelyezni a menüpontokat. A szokásos menühöz képest itt nem címkéket, hanem ikonokat használnak - kevesebb helyet foglalnak el, továbbá gondosan tervezett kép esetén a program kezelője gyakori használattal gyorsan megtanulja, melyik menüpont mire való [9]. A bal oldali alkalmazás logó szerepe is megváltozott: beállítható, hogy rákattva az előző képernyőre térjen vissza az alkalmazás, ez az opció szén bele van építve a programba. Az Action Bar-nak van egy speciális lehetősége is: kontextus menüként is képes működni. A táblázatos kérdéseknél a lista elemek kijelölésének vizualizációját valósítja meg a Contextual Action Bar. Listák esetén nagyban segíti a felhasználót az, hogyha a műveleteket valamilyen animáció követi, amely reprezentálja a logikában végrehajtott tényleges változásokat. Ilyen például egy elem törlése, beszúrása, áthelyezése stb. Ebből a célból a program a List- ViewAnimations[28] Android programkönyvtárat használja. Ezzel a library-vel könnyen hozzá lehet adni animációkat a lista műveletekhez, továbbá olyan bevált UI mákat is meg lehet valósítani, m a swipe-to-dismiss, ami vízszes eldobás gesztussal kitöröl egy adott elemet a listából. 36

41 AndroidAnnotations Az elmúlt időszakban kezdtek el elterjedni a különböző Dependency injection programkönyvtárak, amelyekkel egy modul függőségeit dinamikusan és kényelmesen lehet kezelni, csatolni. Egy ilyen library az AndroidAnnotations[29] is, amely az alapvető függőségkezelésen kívül Android specifikus opciókat is felkínál. A könyvtár Java 5 annotációkat használ a függőségek jelölésére. Ezeket az annotációkat fordítási időben elemzi, majd kódot generál. Ennek lényege az, hogy a repetitív, plusz funkcionalitást nem adó, csak technikai kódrészleteket elrejtei a generált kódban, így a programozó valóban csak a hasznos részekre koncentrálhat. Ezt a könyvtárat használó programok nem lassulnak semmit sem, hiszen a generálás fordítási időben történik. Egyetlen apró hátránya akad csak: a programozónak a generált neveket kell használnia, amelyek egy karakterben térnek el a tényleges osztálynevektől. Űrlapkezelés A kérdések sorozata egy XML fájlban van tárolva, értelemszerűen ezt fel kell dolgozni, hogy a program a memóriában felépített modellel tudjon dolgozni. Az XML feldolgozására alapvetően két módszer kínálkozik: a Simple API for XML (SAX), ami egymenetben iterál végig a fájlon, kevés memóriát fogyaszt és gyors feldolgozásra képes; illetve a Document Object Model (DOM), amely egy fát épít fel a memóriában, emiatt lassabb és nagyobb memóriaigényű, de bonyolultabb struktúrákat képes kezelni. A mobilos programok esetén általában a SAX -ot illetve annak válfajait szokták alkalmazni kis költsége miatt, de ebben esetben a DOM -ra esett a választás. A kérdéseket tartalmazó XML meglehetősen részletes, szerteágazó, nehéz lenne egymenetben feldolgozni. Továbbá a feldolgozás csak a program indulásakor történik meg, egyszer, így nem vesz el sok időt a felhasználótól. A program nem a beépített W3C DOM implementációt használja, hanem egy külső könyvtárat, a JDOM -ot [31]. Ez sokkal kényelmesebben és gyorsabban használható API-t biztosít, továbbá a teljesítménye is jobb. Magát a könyvtárat a Java specifikációba is be akarták építeni a Java Community Process keretén belül JSR 102 [30] kódnév alatt, de ezt azóta elvetették. Ettől függetlenül a könyvtár azóta is rendszeresen kap frissítéseket. A kérdések úgynevezett relevanciákat és megszorításakot is specifikálhatnak, ahogy az az előző szekciókban már tárgyalva volt. Ezeknek a leírására egy szkript felületet biztosít a program az XML-en belül, melyekre a B függelékben mutat egy példát. A program a szkriptek értelmezésére és végrehajtására az Apache Commons Jexl programkönyvtárat [32] használja. Ahogyan az a nevében is van, ez Java Expression Language (Jexl) 37

42 szaxisú szkripteket képes kezelni. A Jexl a 6-os verzió óta a Java Enterprise Edition szabvány része, de a Java Standard Edition-ben, és ezáltal az Androidban, nincs benne. A Jexl lényegében a Java szaxisát biztosítja, a programkönyvtár pedig lehetőséget ad a szkriptek végrehajtására, aktuális változók behelyettesítésére, egyéni függvények hívására, így teljes mértékben megfelel a program céljainak. Adatbáziskezelés Objektum-orientált programok esetén mindig is nehézkes volt az adatbázisok kezelése, ugyanis az adatbázis táblák részben hasonlítanak az osztályokra, a rekordok a példányokra, de mégis más elvek mentén kell kezelni őket. Ezen kívül nehézkes az, hogy SQL parancsokon keresztül kell vezérelni az adatbázis lekérdező és módosító műveleteket, holott a objektum-orientált eszközökkel sokkal egyszerűbb lenne. Ezt a dilemmát próbálja feloldani az objektum-relációs leképezés, mely egy hidat biztosít az adatbázisok és az objektum-orientált világ között. Az adatbázis rekordjait objektumokba tölti be, melyeken így a programozó kényelmesen dolgozhat, és egyszerűen mentheti el állapotukat vissza az adatbázisba, így létrehozva a perzisztens objektumokat, avagy aktív rekordokat. Rengeteg objektum-relációs leképezést implementáló library készült, de ezek nagy része igen nagy futásidejű többletköltséggel rendelkezik, és vállalati alkalmazásokhoz készült. Az ebben a programban használt OrmLite[33] viszont minimális műveletigényt ad, így mobil eszközökön is hatékonyan használható. Az Android-specifikus java SQLite API-t is támogatja, így könnyen beépíthető bármely androidos alkalmazásba. Hálózati kommunikáció A hálózati kommunikáció FTP-n keresztül valósul meg, illetve egy XML naplófájl kezelésével. Az FTP üzenetek küldéséhez és fogadásához az Apache Commons Net[34] programkönyvtár lett beépítve az alkalmazásba. Ez a library az FTP-n kívül számos ismert és bevált hálózati protokollt implementál (pl. SMTP, POP3, Telnet, stb). Használatával egyszerűen lehet kommunikálni az FTP szerverrel, mivel egy absztrakciós réteget helyez a protokoll fölé: a tényleges hálózati üzenetekkel a programozónak nem kell foglalkoznia, elég a megadott műveletek végrehajtására fókuszálnia Képernyőképek A 28., a 29. és 30. ábrákon az elkészült alkalmazás screenshotjai láthatóak, a programot Android 4.2-es emulátoron futtatva. 38

43 28. ábra. Képernyőképek 29. ábra. Különböző kérdéstípusok 4.4. Tesztelés Az alkalmazás eléggé bonyolult, összetett, sok modul együttes helyes működését követeli meg. Ezért nagyon fontos a megfelelő tesztek elvégzése, és rendszeres futtatása. A tesztek biztosítják azt, hogy a program az előírt specifikációk szer működik, az elvárt működést biztosítja és a program módosítása esetén azonnal kiugrik az esetlegesen okozott hiba. Viszont mindenképpen figyelembe kell venni azt, hogy a tesztek csak a bennük előírt szabályokra működnek, a le nem fedett hibalehetőségeket nem fogják semmi esetben sem feltárni. Az alkalmazás három tesztelést segítő keretrendszert, illetve egy távoli hibákat jelentő rendszert használ. A következőkben ezek fognak röviden bemutatásra kerülni. 39

44 30. ábra. Táblázatos kérdés A JUnit A JUnit[35] egy egységtesztelő keretrendszer, Java nyelven írva. Egységeket tesztel, tehát az egyes modulok önállóan elvárt viselkedését, a többitől függetlenül. Elősegíti az automatizált tesztelést: egy kattással végrehajtható az alkalmazáshoz írt összes teszt. Sőt, akár a fordítási folyamat részévé is lehet tenni, így az programkódot nem engedi addig lefordítani, amíg az összes teszt nem fut le hibátlanul. A JUnit nagyban elősegíti a tesztvezérelt programozást, azaz a programkód és a tesztek együttes írását. Általában egy JUnit tesztesetet egy junit.framework.testcase-ból örökölt osztály valósítja meg, és általában egy Java osztály működését szokták vele vizsgálni. A tesztelő metódusait Java 5 annotációkkal kell megjelölni, így kifejezve, hogy melyik pontosan milyen tesztfeladatot hajt végre A Robolectric A Robolectric[38], a JUnit-hoz hasonlóan szén egy egységtesztelő környezet, de ez Android-spefikus teszteket képes végrehajtani. Általában a JUnit-tal együtt szokás használni, így a tesztesetek végrehajtását a JUnit, az Android rendszerrel való együttműködést pedig a Robolectric adja. Általában Activity-ket, View-kat, Adapter-eket tesztelnek vele, de szokás API -k, callback-eket és hálózati kommunikácó egységtesztelésére is használni. A keretrendszer rengeteg osztályt, metódust és segédletet ad, egy androidos alkalmazás teljes tesztelésére felületet biztosít. 40