Univerzális adatgyűjtő Androidra

Átírás

1 DIPLOMATERV-FELADAT Dézsi Krisztián (R48QXQ) szigorló villamosmérnök hallgató részére Univerzális adatgyűjtő Androidra A modern mobiltelefonok (okostelefonok) és tabletszámítógépek számos szenzort tartalmaznak. Ezek részben a telefon fizikai tulajdonságait, helyét, mozgását, orientációját, környezeti paraméterit (telep töltöttség, telep hőmérséklet, mágneses térerő, hőmérséklet, páratartalom) mérik, részben a telefon működésével kapcsolatos informatikai jellemzőket (CPU használat, szabad memória, kommunikációs paraméterek, stb.) tesznek elérhetővé az alkalmazások számára. Számos specializált alkalmazás áll rendelkezésre ezen szenzorok lekérdezésére, az adatok felhasználására, ugyanakkor nincs egy olyan univerzális, konfigurálható adatgyűjtő szoftver környezet, amely lehetővé teszi kiválasztott jellemzők mérését és hosszú távú gyűjtését akár lokálisan (eszközön lévő szabad flash memória) a felhasználó által üzemeltetett szerverre. Ennek megfelelően felvethető egy ilyen alkalmazás elkészítése Android operációs rendszerre. Az elkészült alkalmazásnak konfigurálhatónak kell lennie, hogy az adatgyűjtési feladatnak megfelelően be lehessen állítani a gyűjtött adatok körét, az adatgyűjtés és a tárolás gyakoriságát, valamint a tárolás (lokális flash és/vagy szerver) és a kommunikáció módját (pl. milyen típusú Internet elérésen történjen az adatgyűjtés, pl. csak WI-FI elérés esetén a költségek csökkentésére). Szintén fontos, hogy az alkalmazás minimálisan befolyásolja a készülék üzemidejét, ennek megfelelően a fogyasztási szempontokat a fejlesztés során figyelembe kell venni, valamint ebben a tekintetben is tesztelni kell az alkalmazást. A diplomatervezés során az alábbi feladatok merülnek fel: Ismerkedjen meg az Android-ban elérhető fizikai szenzorok és egyéb jellemzők lekérdezésére alkalmas interfészekkel, készítsen példaalkalmazásokat azok elérésére. Készítse el az univerzális adatgyűjtő rendszertervét, és valósítsa meg a szoftvert Android-ra, a szerverkomponensek Linux alatt legyen futtathatóak. Vizsgálja ez elkészült alkalmazás Android-on futó komponensét az energiafogyasztás (üzemidő) szempontjából, optimalizálja a szoftvert, és írja, hogyan függ a fogyasztás a konfigurációs paraméterektől (szenzorok típusa és száma, adatgyűjtés gyakorisága, használt tárolási és kommunikációs megoldások). Példaalkalmazással igazolja a megoldás működőképességét. Tanszéki konzulens: Dr. Kovácsházy Tamás, docens Budapest, 2014.március 10. Dr. Jobbágy Ákos tanszékvezető, egyetemi tanár

2 Budapesti Műszaki és Gazdaságtudományi Egyetem Villamosmérnöki és Informatikai Kar Méréstechnikai és Információs Rendszerek Tanszék Univerzális adatgyűjtő Androidra Készítette Dézsi Krisztián Konzulens Dr. Kovácsházy Tamás 2014

3 TARTALOMJEGYZÉK Összefoglaló... 7 Abstract Bevezetés Hasonló alkalmazások a piacon AndroSensor Az alkalmazásról képekben Előny Hátrány Sensor Box for Android Az alkalmazás képekben Előny Hátrány Phone Tester Az alkalmazásról képekben Előny Hátrány Alkalmazások összegzése Tervezés Szenzorok és mérőeszközök áttekintése Szenzorok általános ismertetése Gyorsulásmérő Orientáció Mágneses mező Hőmérséklet, Fény, Légnyomás GPS

4 Processzor sebességének mérése Android rendszer alatt Memória Adatforgalom Akkumulátor Rendszer megtervezése Alkalmazás Szerver komponens Megvalósítás Alkalmazás Szerver Energia fogyasztás minimalizálása Adatok küldésnél felmerülő problémák Adattárolás a készüléken Grafikus megjelenítés Google beépített szolgáltatásai Google Térkép API rövid ismertetése Térkép használata Mobil környezetben Szerver védelme Hiba logolás és log küldés Sebesség optimalizálás Tesztelés Felhasználói felület analizálása Stressz teszt Szerver sebessége Szerver sebezhetősége Felhasználói teszt

5 6. Összegzés Előnyök Továbbfejlesztési lehetőségek Összefoglalás Ábrajegyzék Irodalomjegyzék Függelék

6 HALLGATÓI NYILATKOZAT Alulírott Dézsi Krisztián, szigorló hallgató kijelentem, hogy ezt a diplomatervet meg nem engedett segítség nélkül, saját magam készítettem, csak a megadott forrásokat használtam fel. Minden olyan részt, melyet szó szerint, vagy azonos értelemben, de átfogalmazva más forrásból átvettem, egyértelműen, a forrás megadásával megjelöltem. Hozzájárulok, hogy a jelen munkám alapadatait, cím, angol és magyar nyelvű tartalmi kivonat, készítés éve, konzulens neve a BME VIK nyilvánosan hozzáférhető elektronikus formában, a munka teljes szövegét pedig az egyetem belső hálózatán keresztül (vagy hitelesített felhasználók számára) közzétegye. Kijelentem, hogy a benyújtott munka és annak elektronikus verziója megegyezik. Kelt: Budapest, Dézsi Krisztián 6

7 Összefoglaló Az okostelefonok, tabletek száma napról napra nő, úgy ahogy az ezekre készített alkalmazások száma is. Ezek az alkalmazások megkönnyítik a felhasználók számára a mindennapi életet, információt adnak szokásaikról. Az eszköz paramétereinek megfigyelésére sok alkalmazás létezik, ám még nem található egy olyan alkalmazás sem a piacon, amely ezeket egészében összefogná. Az együttes megtekintés nem csak a felhasználók számára lehet előnyös, hanem a fejlesztők körében is. Ennek oka, hogy egyszerűbb összegészében látni a fogyasztást, processzor és memória használatot, vagy éppen mikor mennyi adatot forgalmaztunk mobilinterneten, illetve wifin keresztül. További érdekesség, hogy a mindennapi életben mennyire tesszük ki magunkat erős mágneses térerősségnek. Fontos továbbá a telefon elhasználódása, mert az idő múlásával az akkumulátorunk is egyre gyorsabban merül, amelyet a felhasználó nem lát, ám összegészében szembetűnő a változás. A leírtak alapján egy olyan alkalmazást, illetve szervert valósítok meg, ahol láthatóak lesznek a paraméterek változásai. 7

8 Abstract The number of the smartphones and tablet devices grows day by day, so as the number of the made applications as well. These application make life easier for everyday life, proving information about their habitat. There are several application for monitoring the device parameters, but yet there are not any application in the market, which would bring them all together. The combined views not only beneficial for the users, but also among the developers as well. The reason is that it is easier to see the whole consumption, CPU and memory usage, or even how much data did we use via mobile internet, or via Wifi. Another interesting thing is how much do we put out ourselves in daily life for magnetic field strength. The device wear out is also important, because the battery will discharge faster by passage of time, which the user cannot see, but in the total it is an obvious change. From the fund of the description I develop an application, and a server, where the parameter changes will be visible. 8

9 1. Bevezetés Az okostelefonok, tabletek száma napról napra nő, úgy ahogy az ezekre készített alkalmazások száma is. Ezek az alkalmazások megkönnyítik a felhasználók számára a mindennapi életet, információt adnak szokásaikról. Az eszköz paramétereinek megfigyelésére sok alkalmazás létezik, ám még nem található egy olyan alkalmazás a piacon, amely ezeket egészében összefogná. Az együttes megtekintés nem csak a felhasználók számára lehet előnyös, hanem a fejlesztők körében is. Ennek oka, hogy egyszerűbb összegészében látni a fogyasztást, processzor és memória használatot, vagy éppen mikor mennyi internetet használtunk mobilinterneten, illetve wifin keresztül. További érdekesség, hogy a mindennapi életben mennyire tesszük ki magunkat erős mágneses térerősségnek. Fontos továbbá a telefon elhasználódása, mert az idő múlásával az akkumulátorunk is egyre gyorsabban merül, amelyet a felhasználó nem lát, ám összegészében szembetűnő a változás. A dolgozatban elsőként áttekintem a jelenleg piacon használt olyan Androidos alkalmazásokat, amelyek hasonló feladatokat látnak el, kitérek előnyeikre, hátrányaikra. A leírás végén rátérek arra, hogy mennyiben lesz más a saját alkalmazásom, mint ez előzőek, és ez mennyiben jelent előnyt a felhasználóknak. Következő lépésében, amely a tervezési rész, megvizsgálom a használt technológiákat, illetve Android készülék által leggyakrabban használt szenzorokat, ezekre épül majd a mérés. A tervezési fázisban külön kitérek a fogyasztásra, amelynek optimalizálása rendkívül fontos egy alkalmazásnál. Tervezés során a másik fontos kérdése, a szerver komponens megvalósítása (nyelv, kommunikáció, adattárolás, egyéb kényelmi szolgáltatások). A megvalósítás fázisban ismertetem az alkalmazás és a szerver képernyőit. Következő lépésben rámutatok arra, hogy milyen főbb nehézségek merültek fel a fejlesztés során, mint az energiafogyasztás minimalizálása, adattárolás a készüléken, nagyobb mennyiségű adat küldésnél felmerülő problémák, mentési intervallumok meghatározása, grafikus megjelenítési lehetőségek, Google beépített szolgáltatásai, kinézet, hiba logolás 9

10 és log küldés, sebesség optimalizálás, valós idejű szolgáltatás, kiegészítő lehetőségek beépítése. Tesztelés szekcióban kitérek arra, hogy hogyan viselkedik az alkalmazás különböző készülékeken, melyeket ismerőseim napi szinten használnak. A teszt során kiértékeléseket készítek, illetve felhasználói élmény gyűjtök. Fontos hozzátenni, hogy a tesztelők között kevés mérnök, illetve informatikus szerepel, mivel későbbiekben is nagyobb valószínűséggel fogja az alkalmazást ezen szakmától távolabb álló személy használni. Az élményekből és tanácsokból okulva megvizsgálom az alkalmazást, illetve szerverkomponenst, összegzem az eddigi megvalósított komponenseket. Kitérek a továbbfejlesztési lehetőségekre, amelyeket a közeljövőben valósítok meg annak érdekében, hogy az alkalmazás piacképes legyen. 10

11 2. Hasonló alkalmazások a piacon Ebben a fejezetben mutatom meg piacon legnépszerűbb és témámhoz legközelebb álló alkalmazásokat AndroSensor Az alkalmazásról képekben Előny 1. ábra, AndroSensor alkalmazás Az alkalmazás rendkívül egyszerűen átlátható, nem kell hozzá semmilyen hozzáértő ismeret, ennek ellenére az készülékben található összes szenzor méréseit tökéletesen 11

12 leolvashatjuk róla. A feldolgozott adatok késleltetés nélkül jelennek meg a kijelzőn, azokat ábrázolja, GPS esetén elhelyez minket a térképen. További előnyös tulajdonság, hogy minden szenzorról tartalmaz egy rövid leírást, amely tájékozat minket a szenzor működéséről, illetve használatáról. Az alkalmazást úgy tervezték, hogy minden paraméter konfigurálható legyen, lehetőség van az adatok rögzítésére is, valamint az adatok exportálására SD kártyára, vagy adat küldésre -en keresztül CSV formátumban Hátrány Mintavételi idő nem egyértelműen beállítható, mint ahogy az adattárolás sem egyértelműsített, mivel nem tudjuk, hogy mekkora tartományban menti az adatokat az alkalmazás. A készüléken nem visszakövethetőek az adatok, csupán rövid ideig, ábrázolása folytonos, így nincs lehetőség az adatokat pillanatszerűen megtekinteni. Forrás: Sensor Box for Android Az alkalmazás képekben 12

13 2. ábra, Sensor Box for Android alkalmazás Előny Első és legfontosabb előny a kinézet és a grafika, amely szemet gyönyörködtető látvány. Egy átlagos felhasználónak talán a leghasznosabb alkalmazás, mivel jól vizualizálja a méréseket. Az egyes mérések közben információt ad arról, hogy milyen szenzor található készülékükben Hátrány Ez az alkalmazás átlagos felhasználóknak készült, így nincsen semmilyen beállítási lehetőség, ami elég zavaró lehet. Mérések mentését nem tették lehetővé, így az adatok nem visszakövethetőek sem a készüléken, sem egyéb helyen. A szenzorokról és azok működéséről nem tartalmaz semmiféle leírást. Forrás: 13

14 2.3. Phone Tester Az alkalmazásról képekben 3. ábra, Phone Tester alkalmazás Előny Az alkalmazás, mint a neve is mutatja a telefonon lévő szenzorokat, illetve fogadó vevő egységeket tárja elénk széles körben. Kiválóan tesztelhető vele a készülék minden tekintetben, információt ad arról is, hogy milyen szenzorok nem találhatók meg benne. 14

15 Hátrány Kizárólag a készülék teszteléshez alkalmazható az applikáció. Nem lehet visszakövetni semmilyen módon az adatokat, nincsen a mért értékekről grafikon, nem lehet tárolni, sem pedig exportálni. A megértéshez hiányzik a megfelelő leírás, a multi-touch kizárólagosan két ujjra működik, ha többel próbáljuk meg használni, abban az esetben nem érzékel egyet sem. Forrás: Alkalmazások összegzése A felsorolt alkalmazások főként az átlagembereknek készültek, mivel csak pillanatértékek láthatóak, nem alkalmasak adatok mentésére, tárolására, valamint arra, hogy egy központi rendszerben elemzést készítsünk azokról. Az adatok grafikus megjelenítésére láthatunk jó megvalósításokat, ám hiányzik a hosszú távú megtekintés, mivel az adatok folyton frissülnek. Az alkalmazások összehasonlítása után a következő tulajdonságok kell rendelkeznie saját alkalmazásomnak: Egyszerű és jól kezelhető Adatok tárolására alkalmas Az adatok mentése beállítható Központi rendszerben elérhető az összes adat Központi rendszerrel történő kommunikáció legyen periodikus, annak periodicitása beállítható Az adatok grafikus megjelenítése lehet folytonos vagy pillanatszerű A grafikus megjelenítés legyen konfigurálható Az egyes szenzorokhoz és mérésekhez legyen segítő leírás 15

16 3. Tervezés 3.1. Szenzorok és mérőeszközök áttekintése Szenzorok általános ismertetése A szenzorok olyan elemek, melyek a környezet jellemzőit mérik, illetve egyes fizikai, kémiai, biológia változásra reagálnak. Két típusát különböztetjük meg a szenzoroknak: Passzív: Csakis a környezet fizikai jellemzőinek megváltozására épít. Pl.: hő-, fény-, nyomásszenzor Aktív: A méréshez valamilyen segédjelet bocsájt ki. (fény, rádióhullám, stb.) Pl.: közelségérzékelő, kapacitív érintőképernyő Fontos az egyes paraméterek jellegzetességeit ismerni, mint: Érzékenység Méréstartomány Jel/zaj viszony Adaptációs képesség Karakterisztika Gyorsulásmérő Minden eszköz rendelkezik gyorsulásmérővel, amely megadja az x, y, z koordinátára eső gyorsulás nagyságát. A gyorsulást SI mértékegységekben tudjuk lekérdezni, m amely jelen esetben: 2 s 16

17 4. ábra, Gyorsulásmerő koordináta tengelyei [3] Mivel minden esetben a készülékre ható gyorsulást vizsgáljuk, ezért az alábbi képlettel számolhatunk: a d Fs m Ahol ad a készülék gyorsulása, Fs a rá ható erő, illetve m a tömeg. Előfordulnak olyan esetek, melyeknél a gravitációs erőt figyelmen kívül kell hagynunk, ilyen esetben az alábbi képletet alkalmazhatjuk: a d g F s m Ebben az esetben g értéke ismert, amely földön 9.81 m 2 s átlagértéken számoltunk. A gravitáció értékét tudjuk, ám ez irányát nem, ezért az befolyásolja a mérést, így annak érdekében, hogy eltűnjön a nem kívánt gyorsulás, végezzünk koordinátánkénti szűrést [3][4]. 17

18 Orientáció Az irányszenzor, avagy orientációs szenzor nem egy külön fizikai egységből nyeri adatait, hanem a mágneses tér és a gyorsulásmérőből. A szenzorból kinyerhető, hogy milyen szöget zárunk be a mágneses északkal. A szenzor az adatokat egy három dimenziós tömbben adja vissza, melyek elemei: irányszög (z tengely körüli forgás szöge): a vizsgált értéktartomány a lehet (0 Észak, 90 Kelet, 180 Dél, 270 Nyugat) hosszdőlés (x tengely irányában vett dőlés): pozitív az érték abban az esetben, ha z tengely pozitív forgási iránya az y tengely pozitív iránya felé mutat. Negatív, hogyha a z tengely pozitív forgási iránya az y tengely negatív irányába mutat. Értéktartománya dőlés, vagy gördülés (y tengellyel bezárt dőlés): pozitív az érték abban az esetben, ha z tengely pozitív forgási iránya az x tengely pozitív iránya felé mutat. Negatív, hogyha a z tengely pozitív forgási iránya az x tengely negatív irányába mutat. Értéktartománya Érdemes figyelni a számítások során a pontosságra, mivel a szenzor az adatokat a nyers mágneses és gyorsulásmérő adataiból számítja, ennek következtében az érzékelő pontossága csökken (pontossága csak akkor elfogadható, ha a dőlés értéke 0) [3][4] Mágneses mező A mágneses mező erősségét mérjük vele, amely SI mértékegységben µt-t ad viszsza. Mágneses térerősség mindenhol jelen van, normál értéke 49µT, ám fémek közelében ennek többszöröse is lehet. Az érzékelő visszaadja a tér mindhárom irányának megfelelő nagyságú mágneses terét, általánosan nem használjuk közvetlenül mérésre. Lehetőségünk van kalibrált és nem kalibrált értékeket lekérni az eszközről. Kettő közötti különbség, hogy előbbi esetben ke- 18

19 mény vassal kalibrálják a mágneses mezőt. Gyári kalibrációt és hőmérséklet kompenzációt mindkét esetben alkalmaznak, így a kalibrálatlan szenzor arra az esetre hasznos, hogy a kemény vasra durva becsléseket tegyünk. Nem kalibrált szenzor nyersebb adatokat szolgáltat, így kevesebb a korrekció általi eltérés, ezt az előnyt használja ki néhány alkalmazás. Ilyen példa lehet, ha több szenzor által szolgáltatott adatból készítünk számítást [3][4] Hőmérséklet, Fény, Légnyomás Az Android platform négy különböző szenzort szolgáltat számunkra, amelyek által ellenőrizhetjük környezetünket, ezek a páratartalom, hőmérséklet, fény és légnyomásmérők. A négy szenzor közül nem feltétlen található meg minden készülékben, mivel ezek fizikailag is különálló egységek, így azok beépítését a készülékbe kizárólag a gyártón múlik. A felsorolt mérőegységek kizárólag egyetlen értéket adnak vissza, ellenben az eddig felsoroltakkal. További különbség, hogy ezekben az eszközben nincsen szükség szűrésre, mint a mozgás vagy pozíció mérése esetén, mivel ott rendszeresen alkalmaznak alul vagy felül áteresztőket. Annak következtében, hogy nem szükséges kalibráció, vagy egyéb szűrés, nagyon egyszerűvé teszi használatát más mérőegységekkel szemben. A következőkben csak a hőmérséklet, fény, illetve a légnyomás szenzorokról írok, mivel ezek méréseit valósítom meg Hőmérséklet Általánosságban az akkumulátor hőmérsékletét adja vissza, egyes eszközökben azonban található külön még külső hőmérséklet mérésére alkalmas egység is. A szenzor által visszaadott érték C-ban értendő [3][4]. 19

20 Fény Minden készülékben rendelkezésre áll fényszenzor. Ez azért szükséges, hogy a kijelző fényerejét változtatni tudjuk, így sok energiát spórolhatunk, melynek hatására tovább üzemel készülékünk [3][4] Légnyomás A Légnyomás adott területre ható nyomás, amelyet a levegő tömege okoz, mértékegysége Pascal [3][4]. A földfelszíni nyomás h magasságban leírható másképpen az alábbi képlettel [5]: p p 0 1 L h T 0 gm RL, vagy közelítőleg: h e, ahol p0 - a tengerszinten lévő légköri nyomás, normál értéke: Pa K L átlagos légköri hőmérséklet csökkenés, normál értéke m T0 tengerszinti átlagos hőmérséklet, normál értéke: K m g nehézségi gyorsulás, normál értéke: s M száraz levegő moláris tömege, normál értéke: mol kg R egyetemes gázállandó, normál értéke: J mol K 20

21 5. ábra, Nyomás a magasság függvényében [5] GPS Általános ismertetés Felhasználó pozíciójának meghatározása nem triviális feladat, mivel a hely meghatározása során sokféle pontatlansági hiba fordul elő, így fontos tudni, hogy éppen mi a cél [6]. Néhány hiba eshetőség a helymeghatározásban [7]: Több helyszíni forrásból: GPS, Cellainformáció, és Wifi alapján információt kapunk a helyzetről. Ezek közül választhatunk, annak alapján, hogy pontos, gyors, vagy energiatakarékos megoldást szeretnénk. Felhasználó mozgása: Mozgás esetén változik a helyzet, így becsülni kell a mozgás sebességét, valamint újra meg kell határozni a pozíciót. Változó pontosság: A becslések, amelyeket végzünk minden pozícióban nem feltétlen konzisztensek, így lehet, hogy egy korábbi becslés pontosabb volt, mint a jelenlegi becslésünk. 21

22 6. ábra, Helymeghatározás elve [8] Helymeghatározás energiaigénye Csupán a pozíció pontos meghatározása Androidos készülékeken nem nehéz feladat, ha nem tekintjük azok energiaigényét. Ahhoz, hogy olyan szoftvert írjunk, amelynek energiaigénye alacsonynak mondható a többi fogyasztáshoz képest, kövessük az Android által használt modellt. Egy tipikus eljárás a felhasználó pozíciójának meghatározására: 1. Alkalmazás indítása 2. Az alkalmazás indítását követően elkezdjük hallgatni a hely szolgáltató által biztosított frissítéseket 3. Legjobb becslést teszünk a pozícióra, hogy kiszűrjük az új kevésbé pontos javításokat 4. Pozícióra figyelés befejezése 5. Az utolsó legjobb becslés használata 7. ábra, Felhasználó pozíciójának meghatározása [3] 22

23 A pozíció hallgatását általában az alkalmazás indításakor kezdjük, ám ekkor figyelni kell arra, hogy mennyi ideig határozzuk meg a pozíciót, mivel ez nagymértékben megnöveli az alkalmazás energiaigényét. Alkalmazás indítása után akár nagyobb idő elteltével sem feltétlen meghatározható a készülék pozíciója, ekkor érdemes kiindulni az utoljára elérhető adatból, majd azt addig használni, ameddig nincsen újabb frissítés. Hallgatás befejezésének meghatározása nem triviális feladat, mivel kis rés van pontos pozíció meghatározása és felhasználása között. Nem feltétlen előnyös bizonyos értéken túli pontosság, mert ez az eszköz rendkívül energiaigényes. A legtökéletesebb becslésnél a következő alapelveket érdemes betartani: számottevően pontosabb e, mint az új pozíció az előzőnél pontosabb-e vagy pontatlanabb-e az új becslés, mint az előző ellenőrizzük, hogy melyik szolgáltató által nyújtott pozíció a legpontosabb Az előzőekben említettek alapján akkor készíthető alacsony energiaigényű alkalmazás, ha a hallgatás hosszát minimálisra vesszük, vegyük figyelembe, hogy milyen pontosságra van szükségünk, ezek alapján határozzuk meg a frissítés gyorsaságát. Csökkentést jelenthet még, hogyha az egyes szolgáltatókat csak külön használjuk [3] Processzor sebességének mérése Android rendszer alatt A processzor sebességét leginkább átlagolással tudjuk meghatározni, mivel adott időpontra nézve vagy használatban van, vagy éppenséggel nem, így a mérésre csak ilyen módszert alkalmazhatunk. Elsőként vizsgáljuk meg, hogy milyen információkkal rendelkezünk. A linux kernelről könnyedén kinyerhetünk információkat a processzorról, amelyek a /proc/stat fájlban találhatóak. 23

24 Fájl tartalma általánosan a következőképpen néz ki [9]: > cat /proc/stat cpu cpu cpu intr ctxt btime processes 2915 procs_running 1 procs_blocked 0 Az első sora tartalmaz számomra minden információt, amit a processzorról tudni szeretnénk, ezt felhasználom a mérés során. A processzor sorában az oszlopok a következőt jelentik: Felhasználói: Felhasználó módban végrehajtott normál folyamatok (jel: F) Nice: Priorizált folyamatok, amelyek felhasználó módban futnak, legnagyobb prioritás a 0 (jele: N) Rendszer: Azok a folyamatok, amelyek kernel módban futnak (jele: R) Tétlen (jele: T) iowait: ki vagy bemenet befejezésére vár (jele: IO) irq: megszakítások kiszolgálása (jele: I) softirq: szoftveres megszakítások kiszolgálása (jele: S) Átlagolásra a következő képletet alkalmazom: CPU N F N N N R N IO N I N S N CPU speed CPU CPU T N N N CPU CPU N 1 N 1 T N Memória A memória használat szintén kulcsfontosságú, mivel hiány esetén fel kell szabadítani, ám túl sok használaton kívüli memória szintén előnytelen, mert nem vesszük igénybe a hardver adta lehetőségeket. Érdemes tehát átgondolni, hogy mely paraméter lényeges 24

25 számunkra, hiszen az eszköz kihasználtságára vagyunk kíváncsiak. Ennek tudatában a szabad memóriát mérem, mert a felhasznált memória hasznos, ahogy a cache-elt memória is nagy valószínűséggel használtra kerül [10][11] Adatforgalom Minden okos készüléket alapvetően internettel együtt használunk, mivel csak így tudjuk őket teljes egészében kihasználni, ám lényeges kérdés, hogy az internetet hogyan érjük el, wifin vagy mobilinterneten keresztül. Az Android rendszer külön kezeli a wifi-t, illetve a mobilinternettel generált forgalmat, de ezekhez hozzáférhetünk. Monitorozhatjuk a fel és letöltést wifi, és mobilinternet esetére, ami fontos feladat, mert a szolgáltatásba belefoglalt adatmennyiség túllépése esetén nagy költségeket von maga után. A rendszerben nincsen lehetőség arra, hogy figyelembe vegyük azt az időpontot amikortól kezdjük az adatforgalom mérését, ami hatalmas hátrány. A felhasználó ezek alapján egy valótlan képet kap, ami csak közelíti a valós állást, így ennek pontosítására egy effektív megoldás kell. A program telepítésének első hónapjában sajnos ezt nem tudjuk nagy pontossággal megtenni, mivel nem mérhető, hogy mikor mennyi adatforgalmat generáltunk precíz kezdőpont nélkül. A mérést ezért úgy dolgoztam ki, hogy a hónap első napjától kezdje a számlálást, ami pontatlan, ez nagy hátrány, ám minden további hónapban pontosan fog működni Akkumulátor Akkumulátor szempontjából két dolgot kell figyelembe vennünk, egyrészt az feszültséget, másrészt a hőmérsékletet. Ezen paraméterek megfigyelése hosszútávon betekintést adhat az akkumulátor állapotába, mivel az az idő folyamán egyre jobban öregszik, így kevésé képes a töltések megtartására. 25

26 8. ábra, Akkumulátor cella öregedés [12] Az ábra jól vizualizálja az öregedés jellegét, ám gyári hiba, vagy egyéb meghibásodás esetén a felhasználó gyorsan értesülhet erről, így lecserélheti az akkumulátort, ezzel elkerülve az okostelefon, tablet többi részének károsodását. 26

27 3.2. Rendszer megtervezése A rendszer két fő egységre bontható, melyek az Androidos alkalmazás, illetve a webes komponens. A megvalósítandó architektúrát az alábbi ábra szemlélteti: 9. ábra, Megvalósítandó architektúra Az ábrából jól látható, hogy a mobil készülék közvetlen kapcsolatban van az üzleti logikai réteggel, azon keresztül küld adatok az adatbázisba. Az adatok megtekintéséhez a felhasználónak be kell jelentkeznie, ezt követően a web szerver kiszolgálja kéréseit. 27

28 Alkalmazás Általánosan az alkalmazás az alábbi diagram szerint működik: 10. ábra, Alkalmazás MVC diagramja A szerkezeti minta alapján jól szétválasztható a vezérlő, nézet, modell és adatbázis réteg. Az alkalmazás nézet rétege jeleníti meg a modellt, mely kétféle formátumot jelent, egyrészt az adatok felsorolását, másrészt grafikus ábrázolást. A kimenet biztosításán kívül olyan felületi elemeket tartalmaz, amelyek alkalmasak arra, hogy kövessék a felhasználó interakcióit, ezáltal biztosítva a bemenetet. A bemenetet a vezérlő réteg kezeli, feldolgozza a felhasználó által generált eseményeket, válaszol rájuk, vagy megváltozatja a modellt. A modell réteg kezeli az információkat, tárolt eljárásokon keresztül kommunikál az adatbázissal, kérés esetén menti, vagy betölti az adatokat. Az általános megtervezés után különbontom a főbb feladatokat, amelyeket meg kell valósítani, ezek: Bejelentkezés 28

29 Adatfeldolgozás, megjelenítés, küldés Grafikus adatfeldolgozás Bejelentkezés Annak érdekében, hogy a felhasználó csak saját adatait láthassa majd a szerveren, ahhoz szükséges egy bejelentkező képernyő az alkalmazásban is. Bejelentkezni csak egyszer szükséges, ahol egy felhasználónevet és jelszót kell megadnunk, amelyet a szerver ellenőriz, mert nem lehet névbeli egyezés. Sikeres regisztrálás esetén a visszakapott userid-t tárolja az applikáció, ennek alapján azonosítja a készüléket a szerver a későbbiekben. A szerverrel történő kommunikáció aszinkron lesz, így a felhasználó adat küldése közben is zavartalanul kezelheti az alkalmazást. A sikeres, vagy sikertelen adat küldése esetén a szerver információt küld vissza az alkalmazásának, melyek a következők: Not Ok a felhasználó már létezik OK sikeres regisztráció, elmentjük a visszaküldött azonosítót egyéb hiba történt a feldolgozás során Adatfeldolgozás, megjelenítés, küldés A jelenleg mért adatokat a főképernyőn jelenítem meg, ezzel párhuzamosan folyamatosan történik a mentés. A kijelző frissítése, és adatok mentésének periodicitása beállítható. Megjelenítéshez a következő képernyőtervet készítettem: 29

30 11. ábra, Adatmegjelenítés képernyőterve Adatküldés során, a készüléken tárolt adatokat továbbítom a szerver felé. A szenzor és egyéb adatok XML formátumban küldöm. Fontos megemlíteni, hogy mivel a készülékek nem feltétlen tartalmaznak mindenféle szenzort, ezért lehetnek üres értékek, így az adatokat attribútumként nem továbbíthatjuk! A küldésre alkalmas XML struktúra: 12. ábra, XML struktúrája 30

31 Sikeres küldés esetén a szervertől OK érkezik, egyéb esetben pedig hibaüzenet. Itt megemlítem, hogy a telefon, illetve tablet készülékek nem alkalmasak nagymennyiségű adat tárolására, illetve azok feldolgozására, ennek okán az alkalmazás törli az egynaposnál öregebb adatokat. Az egy nap azért optimális, mert az ez alatt összegyűjtött adatmennyiséget könnyű kezelni, megjeleníteni Grafikus adatfeldolgozás A tárolt adatokat grafikusan jelenítem meg egy erre szánt képernyőn. Az adatok, illetve ábrák megjelenítését konfigurálni lehet, valamint a megjelenítendő adatok menynyiségét is. A megjelenítéshez elvárás: valós idejű ábrázolás automatikus skálázottság közelítés a grafikus ábrába adatmegjelenítés időben o különböző mintavételi idők megkülönböztetése adatmegjelenítés megadott pontszámban Szerver komponens Az összes adat tárolására, megjelenítésére nem alkalmas a készüléken futó alkalmazás, ezért szükségszerű egy szerver, ahol elérhetővé válik az összes adat, melyekből akár statisztika készíthető Modulok megtervezése A szerveren minimálisan három modult kell megvalósítani, hogy lefedjék a készülék által is nyújtott szolgáltatásokat, melyek a bejelentkezés, adatok folytonos megjelenítése, adatok grafikus ábrázolása. A bejelentkező modulon keresztül lépünk be az alkalmazásba, amihez a már használt felhasználó jelszó párosra lesz szükség, mivel mindenkinek csak saját adatállománya elérhető. 31

32 Az adatmegjelenítő modul az adatok számszerű megjelenítésére szolgál. Az adatok pontos vizsgálatához szükséges, hogy a felhasználó olyan szűrőfeltételeket adhasson meg, amely kevesebb adat megjelenítését biztosítja. Az adatok számszerű megjelenítésén kívül szükséges egy grafikus modulra is, ahol az adatmegjelenítő modulhoz hasonlóan lehetőség van szűrőfeltételeket megadni. 13. ábra, Főoldal képernyőterve Technológia megválasztása Szerver oldal megvalósítása nem egyértelmű, mivel több különböző jól bevált technológia létezik, szám szerint három, ezek: Java, JSP és MySQL ASP.NET és MSSQL PHP és MySQL A Java nyelv nyílt forráskódú, robusztus és biztonságos, melyhez rendkívül sok keretrendszer létezik, jól dokumentált használata egyszerű, Android is használja [14]. 32

33 ASP vagy Active Server Pages a htmlt és a szerver oldali kódot kombinálja, mivel a feldolgozás szerver oldalon történik, megjelenítés pedig html-ben [15]. A PHP az előzőektől eltérően csak szerver oldali programozáshoz készítették, megvan az az előnye, hogy összekapcsolódjon a html-el. Minden mai tárhely képes futtatni, így nincs szükség lokális szerverre [16]. A választásnál szempont volt, hogy a kommunikációt egyszerűen meg lehessen valósítani, ne kelljen külön szervert futtatni működtetéséhez, valamint a tapasztalat. A választásom ezek alapján a PHP és MySQL lett, mivel nincsen lehetőségem külön egy szervert üzemeltetni Szerver megválasztása A szervert a 000.webhost.com alá regisztráltam, ennek okai a következők [17]: ingyenes megfelelő nagyságú tárhely és adatforgalom (1500 MB, 100GB/hónap) rendelkezik MySQL adatbázissal rendelkezésre állás megfelelően magas (99%) támogatja a PHP-t automatikus mentés lehetséges saját domain név kreálható (dezsikrisz.net78.net) FTP támogatás 33

34 4. Megvalósítás Első lépéseként megmutatom az alkalmazás és szerver UML diagramjait, képernyőit, amely által képet kapunk a megvalósított feladatokról, majd ezeket átlátva ismertetem a felmerült nehézségeket, illetve azok megoldását Alkalmazás 14. ábra, Az alkalmazás UML diagramja 34

35 Alkalmazás első indításával a bejelentkező képernyő fogad bennünket, ami egy felhasználó nevet és jelszót kér, ezt megadva léphetünk be az alkalmazásba. 15. ábra, Alkalmazás bejelentkező képernyője A bejelentkezési adatok elküldése előtt az alkalmazás vizsgálja, hogy a beírt karakterszám minimum négy, de maximum tizenhat hosszú legyen, mivel ez a szerver bejelentkezéshez extra ellenőrzési lehetőséget ad, ami növeli a biztonságot. Bejelentkezés után az alkalmazás főképernyője fogad. 35

36 16. ábra, Alkalmazás főképernyője A főképernyőn tekinthetjük meg a mért adatokat, valamint az egyes szenzorokról, egyéb egységekről találunk hasznos információkat. Az információk azért kerültek az alkalmazásba, mert egy átlagember nem ismeri ezeket az eszközöket, ám ezeknek a segédinformációknak hála képet kap arról, hogy mire jó, mit és hogyan mér az egység. A főképernyőn kijelzett adatok frissítési, az adatok mentési, illetve azok küldési periodicitását a beállítási képernyőn adjuk meg. A képernyőn beállítható még a mobil adatforgalom nullázásának időpontja, helyinformációt GPS vagy hálózat alapján kérje le a készülék, valamint megadhatjuk, hogy csak wifin keresztül kommunikáljunk a szerverrel. 36

37 17. ábra, Főképernyő beállításai A készüléken tárolt helyinformációkat megjeleníthetjük egy térképen, melyre a Google támogatást nyújt, ehhez az alkalmazáshoz igényelni kell egy kulcsot, így használható a térkép. A térképen megjelenik, hogy mikor hol jártunk az elmúlt egy napban. 18. ábra, Pozíció megjelenítése térképen 37

38 A főképernyőről a grafikonokat tartalmazó képernyőjére navigálhatunk, itt megtekinthetjük az adatokból ábrázolt grafikonokat. 19. ábra, Alkalmazás grafikonjai Az ábrákon látható, hogy a grafikon kirajzolásának három módja van, ezeket a pont szerinti, időbeli, időben folytonos kirajzolás. A pont szerinti kirajzolásnál csak a beállított mennyiségű pont kerül megjelenítésre. Időbeli kirajzolásból két típust implementáltam. Első típus, melynél nem számít a folytonosság, itt az elmúlt időszaktól visszamenőleg történik a megjelenítés adott periodicitással, második típus esetén számít a folytonosság, így ahol a két pont közötti idő nagyobb, mint a beállított periodicitás mértéke, ott szint vált az ábra, ezáltal is pontos képet kapva a mérés pontosságáról. Beállítható még a valós idejű megjelenítés, mely esetén az ábrák a beállított idő elteltével frissülnek. A felhasználónak lehetősége van belenagyítani az ábrába. Az grafikonok beállításai képernyőn adjuk meg, hogy melyik grafikonok jelenjenek meg, valamint választhatunk a három ábrázolási forma között. Az ábrázolási formát megadva be kell állítanunk, hogy hány pontot, vagy mennyi időre visszamenőleg, illetve milyen periodicitással ábrázolunk. 38

39 20. ábra, Grafikonok beállításai Csak olyan szenzoradatokról készíthető ábra, amilyen szenzor van a készülékben, mivel feleslegesen nem használunk erőforrást arra, hogy olyan adatokat jelenítsünk meg, amit nem tudunk mérni. Ennek azért van jelentősége, mert azokat az adatokat, amelyekhez nem tarozik érték (rendszerint a légnyomásmérő), ott nullát ment az alkalmazás null helyett, ennek optimalizációs indokai vannak, melyre később kitérek. 39

40 4.2. Szerver 21. ábra, A szerver UML Diagramja A szerver oldalra lépve az első oldal a bejelentkező oldal. A felhasználóhoz társított készülék adatai csak bejelentkezés után tekinthető meg, ennek hiányában egy oldal sem elérhető, mivel minden esetben a kezdőoldalra fog visszairányítani a szerver. Belépéshez szükséges az Androidos alkalmazásban regisztrált felhasználónév és jelszó páros, melyek biztonsági ellenőrzésen esnek át. 40

41 22. ábra, Bejelentkező képernyő Következő oldal a főképernyő, ahol megtekinthetőek a készülékből származó összes adat. A képernyőképből jól látszik, hogy az adatok jól elkülönülnek egymástól, valamint lehetőség van dátum alapján szűkíteni a lekért adatokat. 23. ábra, Főképernyő A készüléken is lehetőség van grafikonokon megtekinteni az adatok, így a szerver oldalra is került olyan oldal, ahol ezt meg lehet tenni, annyi különbséggel, hogy a webes felületen az összes eddigi adat a rendelkezésünkre áll. Az oldalon szintén lehetőség van az adatok szűrésére, valamint az ábra görgetésére. Az ábra vertikális görgetésére azért volt szükség, 41

42 mert nagyszámú adat esetén, az ábrán található pontok annyira zsúfoltak lesznek, hogy azokat képtelenség lenne megkülönböztetni. A grafikonon található piros vonal jelzi a megjelenített adatok átlagát. 24. ábra, Grafikonok A negyedik oldal a Térkép oldal, itt a felhasználó megtekintheti, hogy adott időpillanatban merre tartózkodott. A pozíciókból sok információ derül ki a készülék tulajdonosáról, mint például a napi közlekedési rutinja. 25. ábra, Térkép 42

43 4.3. Energia fogyasztás minimalizálása Minimális energiafelhasználás eléréséhez fontos, hogy kizárólag azokat a tevékenységeket futtassuk, amelyre szükség van. A futtatandó tevékenységek körét két fő részre különítem el, egyrészt ha az alkalmazás előtérben van, illetve ha nincs előtérben, akkor lényegesen csökkenthető a frissítendő paraméterek száma. Az alkalmazást aktívan használva a készülék kijelzője fogyasztja a legnagyobb energiát, ezen csökkenteni csak sötét színek alkalmazása esetén lehet. A kijelzőkben megtalálható minden egyes dióda fényt bocsájt ki, tehát a sötétebb színek esetén kevesebb diódát használunk színképzéshez, így kevésbe terheljük az akkumulátort [18]. Következő nagyobb energiafogyasztó a képernyő adatok frissítése, ám ennek optimalizálása nehézkes, mivel olyan periódusidőt kell találni, amely a felhasználónak is megfelel. Megoldásképpen olyan stratégiát dolgoztam ki, melynél a képernyő frissítési periódusát a felhasználó választja ki, de néhány paraméter, mint a GPS, telep töltöttsége, hőmérséklete csak mentés előtt frissül. Ezt a stratégiát azért választottam, mert ezek a paraméterek lassan változnak, így nem okoznak nagy pontatlanságot a mérés során, ha ezeket nagyobb időközönként frissítem. Grafikon kirajzolása közben is aktív a kijelző állapota, így lényeges azok kirajzolásának ideje. A kirajzolásra három módszert biztosítottam, ezekhez a módszerekhez a felhasználó választja meg, hogy hány darab vagy mennyi időre visszamenőleg ábrázoljuk az adatot, tehát itt további optimalizáció nincs, de van lehetőség valós idejű ábrázolásra. Valós idejű ábrázolásnál fontos, hogy már az eddigi adatok rendelkezésre állnak, azok újbóli lekérése felesleges, tehát minden módszerhez készítettem egy külön lekérést, ami a friss adatokkal bővíti az ábrát, ezzel időt és energiát megtakarítva. Következő eset, ha az alkalmazás nincsen előtérben, ahol már jelentősen kevesebb energiát fogyaszt kijelző híján, ám mégis ajánlatos áttekinteni az optimalizációs lehetőségeket. Adatok mentése során minden paramétert frissíteni kell, így itt fontos kérdés a periódus. A frissítési ciklus rendkívül lényeges a felhasználó számára, mivel múlhat rajta a mérés pontossága, tehát ennek megválasztása az ő feladata lesz, mint ahogy a szerverhez fordulás megválasztása is. 43

44 4.4. Adatok küldésnél felmerülő problémák Adatok küldése során meglehetősen sok probléma merülhet fel, ezek lehetnek az aktív internetkapcsolat, nagyméretű adatmennyiség továbbítása, illetve előzőleg megszakadt kommunikációval kapcsolatos problémák. Az alkalmazás a felhasználó által beállított periódusonként küld adatokat a szerver felé, és mivel ez a periódus nem függ össze az internetkapcsolattal, ezért elég gyakran előfordul, hogy az adattovábbítás nem valósul meg. A megoldáshoz két dolgot kell egyszerre megfigyelni, hogy az előző kommunikáció időpontja és a jelen időpont különbsége nagyobb egyenlő-e, mint a periódusidő, ha igen, akkor abban az esetben ellenőrizzük az hálózati kapcsolatot. A kapcsolat megléte nem elégséges feltétel, csak gyorsabban tesztelhető, tehát következő lépésben a szerver webcímét kell ellenőrizni. A webcím elérésének kísérlete előnyös, mert nem csupán internetkapcsolatot ellenőrizhetjük vele, hanem azt is, hogy a szerver aktív állapotban van e. A feltételek teljesülésekor módosítani kell az előző küldés időpontját jelen időpontra, és nullázni kell a számlálót. Küldés közben is adódhatnak problémák, melyek akkor jelentkeznek, ha megfelelően sok ideig nem továbbítottunk adatot a szerver felé, ennek oka a heap memória fogyása. A heap minden folyamatot korlátoz egyetlen virtuális memória tartományban, mérete folyamatosan nő használat közben, ám vannak korlátai. A korlát készülékenként változó, nincs összefüggésben a fizikai memóriával, de általánosságban 16 és 128 MB közé becsülhető [19]. Az alkalmazás küldésénél figyelembe kell venni a heap - et, és mivel ennek az értéke eléggé váltózó, ezért olyan értéket kell megtalálni, amely minden készülékre megfelelő. Tesztelések során arra az eredményre jutottam, hogy 1000 sor lesz az optimális választás, mivel ezen érték körülbelül 8 MB os heap - et eredményez. A megfelelő méreten kívül az is a megoldás mellett szól, hogy nem kell sokszor ismételni a küldést (Naponta maximálisan 3600 sornyi adatot ment az alkalmazás), ezzel minimalizálva egyéb hibaforrásokat. A folyamatos adatküldés sem veszélytelen, előfordulhat, hogy a fogadó komponens nem képes időben feldolgozni az előző adatot, de már érkezik az új csomag, ekkor adatvesztés történik. A feldolgozás gyorsaságát növelni nem lehet, de az alkalmazás küldését várakoztathatom. A várakozási időt teszteléssel határoztam meg, erre a 10 másodperc tűnt optimális időnek, így az előző adatok biztosan rögzülnek az adatbázisban. 44

45 A szerverrel történő kapcsolat bármikor megszakadhat, ennek több oka lehet, mint az internet kapcsolat megszűnése, szerveren egyéb hiba történt, vagy egyéb okból megszakadt a kapcsolat. Az ilyen hibákat előre jelezni nem lehet, tehát küldés közben fel kell készülni rájuk. A felkészülés nem jelent mást, mint vizsgálni a küldések sikerességét, amely esetén menteni kell az utolsó elküldött sor ID ját, ezzel biztosítom azt, hogy ne kerüljön a szerverre duplikált elem Adattárolás a készüléken Adattárolásra sok különböző lehetőséget kínál az Android platform, mint a Shared Preferences, belső, külső tárhelyre mentés, SQLite adatbázis, vagy webes tárhelyre mentés [20]. A lehetőségek közül kettőt kell használnom, melyek a Shared Preferences, illetve a SQLite. SQLite használata ideális nagyszámú és/vagy strukturált adatoknál, további előnyei, hogy egyszerű SQL lekérdezéseket alkalmazunk benne [21]. Androidos eszközökön ennek ellenére nem érdemes nagyszámú adatot tárolni, mivel azok kezelése nehézkes, ezáltal a lekérdezés sebessége lassulhat. A gyors sebesség megtartása érdekében törekedtem arra, hogy készüléken csak minimálisan szükséges adatokat tároljam. A készüléken lévő adatokat grafikus ábrán akkor látszanak jól, ha az elmúlt egy napot jelenítem meg, ezért minden sikeres küldés befejeztével az ennél régebbi adatok törlésre kerülnek, ami által nem duzzad meg túlzottan az adatbázis mérete. A tárolt adatokon kívül szükség van olyan kitűntetett információkra, amik befolyásolják az alkalmazás működését, mint a frissítési, mentési, küldési periódusidő, mobil adatforgalom nullázásnak dátuma, küldés csak wifin valósuljon e meg, a felhasználóhoz társított azonosító, valamint az összes grafikon beállítás. A célra legalkalmasabb a Shared Preferences használata, mivel kulcshoz társított primitív típusú értékeket menthetünk vele, amelyhez a session ön belül mindenki hozzáfér, valamint tartalma nem vész el az alkalmazás bezárásakor [22][33]. 45

46 4.6. Grafikus megjelenítés A grafikonok megrajzolásához a GraphView nevű library-t használtam kisebb módosítással. Elsőként a library-ről [23]: Kétféle diagramtípus (oszlop és vonal) Egy diagramra egyszerre több grafikon is rajzolható, ezekhez különböző színt és leírást társíthatok Megadható jelmagyarázat a grafikonhoz Saját felírat is megadható a tengelyekhez Diagram nézetének nagysága megadható, így külön részlet megjelenítésére is alkalmas Görgethető Közelíteni lehet a diagramon belül Háttér változtatható Saját dizájn is használható A képernyőképekből látható, hogy grafikonokat három féle módon lehet megjeleníteni, ezek közül csak egyre volt alkalmas a library, ennek oka, hogy az idő skálázott megjelenítése nem triviális feladat. Az eredetileg használt ábrázolás az y tengelyre két féle érték tehető, egyrészt a módosítatlan tömb indexe, ez lett az első típusú megjelenítés, másrészt egy string tömb, amelynek minden eleme megjelent. Az összes elem megjelenítése semmiképpen sem jó megoldás, mivel a diagramnak mozgathatónak, és közelíthetőnek is kell lennie egyben, de ezt egy fix elemsor nem engedi meg. Saját megvalósításomhoz elsőként az eredeti kódot módosítottam, mivel ezt nyílt forráskódja miatt megtehetem, amely által megvalósítható a tervezett megjelenítés. Harmadik megjelenítési módszerhez ötvöztem az új felirati skálát, illetve a több grafikon rajzolási lehetőséget. A folytonosság vizsgálatához a megjelenítendő adat feldolgozására is szükség van, mivel a grafikon akkor folytonos, hogyha két elem közti távolság megegyezik a skálázási idővel. Az időtől való eltérés esetén, ha ennél kisebb, akkor nem jelenik meg a pont, ha pedig nagyobb, akkor külön színnel kell jelölni, mivel ott szakadás van. Természetesen a készüléknek is lehet hibája, mikor menti az adatok, ezért hibahatárt 46

47 is adtam meg a szűréshez, ami a skálaidő egy százaléka, így elég pontos ábrázolás készíthető minden esetben Google beépített szolgáltatásai Google Térkép API rövid ismertetése A Google Térkép API több API gyűjteménye, melyek segítségével saját adatait használva személyre szabott Google Térképet jeleníthetünk meg. A Google erőteljes térképplatformjával stílusos és könnyen használható weboldalakat és mobilalkalmazásokat hozhatunk létre. A platform tartalmaz műholdképeket, utcaképet, szintprofilokat, autós útvonalterveket, stílusformázott térképeket, demográfiai adatokat, elemzéseket és egy rengeteg helyet tároló adatbázist. A világ legpontosabb globális lefedettségének és a napi frissítéseket végző, aktív térképészeti közösségnek köszönhetően a felhasználók egy folyamatosan fejlődő szolgáltatás előnyeit élvezhetik [24] Térkép használata Mobil környezetben A GPS koordináták megfigyelése a mérés része, így ésszerű döntés a felhasználónak egy külön felület biztosítani mind Androidos, mind webes környezetben. A felület több szempontból hasznos, mivel növeli a felhasználói kényelmét, grafikus megjelenítést biztosít (A GPS koordinátákból egy átlagos felhasználó nem feltétlenül tudja megállapítani elsőre, hogy éppen hol van), lehetőséget biztosít a visszakövetésre. A térkép használathoz szükséges az alkalmazáshoz és szerverhez külön azonosítót kell igényelni a Google-től. Az igényléshez engedélyeznünk kell a szolgáltatások fülön a Google Maps Android API v2-t, majd az API Access fülön az alkalmazás SHA1 ujjlenyomatával, illetve a csomagunk nevével kapunk külön kulcsot. Szerveren hasonló az eljárás, csak ott a kulcsot a weblap címével kell igényelni. A kapott kulcsokat be kell ágyazni a weboldalba, másrészt az alkalmazás manifest.xml-jébe, majd adni egy saját felhasználói jogot a használathoz [25] [26]. 47

48 Androidos fejlesztéshez külön biztosít szolgáltatásokat a Google biztosít külön, ami megkönnyíti a kivitelezést, mivel ebben létezik saját térkép osztály. Az osztályban implementálva van az összes szükséges funkcionalitás, mint a jelző pont hozzáadása, kamera mozgatása, valamint a helyet meg lehet adni GPS koordinátákkal is [24]. A webes megvalósítás hasonlóan egyszerű, mint az Androidos, mivel minden előzően felsorolt funkciót használhatunk [33] Szerver védelme A megfelelő biztonsághoz a felhasználót is kényszeríteni kell, hogy megfelelő erősségű jelszót használjon. A jelszónak elegendően hosszúnak kell lenni, mivel ez extra validációra ad lehetőséget. Hosszra optimálisnak tűnt a minimum 4 illetve maximum 16 karakter. Az erősséget tovább növeli, ha kis és nagybetű, szám illetve speciális karakter is szerepel a jelszóban. Fontos még a felhasználó védelme érdekében, hogy a jelszó megfelelően legyen titkosítva, hogy feltörés esetén se tudják azt visszaállítani. A titkosítást SHA1 algoritmussal végeztem, mivel ez nem visszafejthető, továbbá minden jelszóhoz hozzáillesztettem egy véletlen Stringet, amely tartalmazza az összes karakterosztály egy elemét. A webszerver biztosítása hasonlóan fontos feladat, ám feltörhetetlen rendszer nincsen, de a cél minden esetben a betörök feladatának megnehezítése. Megvalósítás közben ügyeltem arra, hogy a lehető legtöbb hibaforrást kiküszöböljem, melyek között a legáltalánosabb az SQL injection. A módszer lényege, hogy formázott adatokkal próbálja meg a támadó elérni, hogy a webes alkalmazás módosított SQL lekérdezéseket hajtson végre. Kivédésére a php rendelkezik saját függvénnyel, amely elégséges védelem szempontjából. Egy másik gyakori támadási forma a Cross Site Scripting avagy XSS. Az XSS támadás lényege, hogy a támadó egy scriptet próbál meg lefutatni a felületen, ezáltal bármit megjeleníthet, vagy akár átnavigálhat vele egy másik oldalra. Egy ilyen támadásra elhárítása komolyabb feladat, ezért ehhez saját osztályt hoztam létre, amely a következőket hajtja vége: felesleges szóközök és sortörések eltávolítása HTML és PHP tagek eltávolítása 48

49 speciális karaktereket átkonvertálása HTML entitássá backslashek levágása Ez az eljárás szavatolja, hogy ne tudjon egy támadó scriptet futtatni a weboldalon Hiba logolás és log küldés Akármelyik éles rendszerben előfordulhat nem várt hiba, melynek felderítése igen nehézkes abban az esetben, ha csak a felhasználó által közölt információ áll rendelkezésünkre. A felhasználó szinte sosem tudja teljes körrel leírni a hibát, sem annak körülményét, így előnyös, ha bevezetünk loggolást külön a webes, külön az Androidos környezethez. A webes környezetnél adott a helyzet, mivel helyben van a tárhely, illetve rendszer is, ezáltal mindent egy gépen tudunk futtatni. Annak érdekében, hogy a hiba jól meghatározható legyen saját loggert készítettem, melyben kétféle szint létezik, egyrészt az információs szint, mely bizonyos alkalmakkor mindig ment, másrészt a hiba szint, ami csak hiba esetén tárolja el az információt. A logger osztályt úgy valósítottam meg, hogy azonítható legyen benne a log hívásának helye, időpontja, szintje, illetve hiba esetén a hiba jellege is. Az egyszerű hibakeresés érdekében hasznosnak tartottam, hogy a log fájt naponta újragenerálom, így minden információ megmarad, de mégsem kell egy nagyméretű objektumban keresni. A log fájl kinézete: 26. ábra, Log webes környezetben 49

50 Androidos rendszerben a hiba loggolásra adott minden, ám azt alapesetben csak a fejlesztőkörnyezet segítségével vizsgálhatjuk, így szükséges, hogy a meglévő állományt mentsük a készüléken. A készüléken feleslegesen sok adatot nem érdemes tárolni, mivel az nem arra való, továbbá a lokálisan tárolt információ nem segíti elő a fejlesztést, mert a hibák nem jutának el a megfelelő helyre. A probléma kiküszöböléséhez csak annyit kell tenni, hogy az adatokat a szerverre kell továbbítani, ami az eddig megvalósítottak után egyszerű feladat. Adatot eddig is küldött az eszköz a szerver felé, így egészen egyszerűen a küldés befejeztével a logot is elküldöm, ezzel növelve a felmerülő hibák kijavításának esélyét [27] Sebesség optimalizálás Minden alkalmazásnál fontos, hogy a felhasználó akciója a lehető leggyorsabban reagáljon, így a fejlesztésben sarkalatos pont a sebesség optimalizáció. A legegyszerűbb eljárás ezekhez, ha követjük az Android rendszer által kiajánlott lehetőségeket. A rengetek optimalizációs lehetőség közül csak az alkalmazottakat említem meg. Az alkalmazásokban általánosságban rendkívül sok változót használunk, ám ezeknek egy jó részét soha nem módosítjuk. Az ilyen esetekben feleslegesen hívjuk az osztály inicializáló metódusát, így ez kerülendő megvalósítás, helyette a változót final al kell deklarálni. A final kulcsszó használata azért előnyös, mert direkt hívja a változót, ellenben nem hívja meg az osztály inicializáló metódust, ezáltal gyorsabb. Minden fejlesztőnél napi szinten előfordul, hogy különböző ciklusokat kell létrehozni melyek használata időnként igen költséges lehet. Vegyünk alapul egy egyszerű iterációt egy entitáson listán, erre különböző beépített és saját megoldások léteznek, ezért lényeges őket áttekinteni. Általánosságban véve egy for ciklus felparaméterezve átlagosan háromszor lassabb, mint egy foreach, így ezeket alkalmaztam. A változók típusa is rendkívül fontos, mivel egy egész számot sokkal gyorsabban tudunk feldolgozni, mint egy lebegőpontos számot, így lényeges, hogy csak ott használjuk ahol feltétlen szükséges. Jó példa erre a fényszenzor, mivel a készülékek legjobb esetben egészszám nagyságrendben adják vissza a fényerősség mértékét. Hasonlóan fontos 50

51 az is, hogy a lehető legtöbb változónak legyen primitív típusa, mivel egy komplex objektummal akár 6-7-szer gyorsabb, így érthető használatának oka [28]. Valós idejű megjelenítésnél is az optimális lekérésre kell törekedni, mivel minden egyes frissítés során nem megfelelő megoldás, ha az összes adatot újra kiolvasassuk az adatbázisból, mert ez sok extra időt venne igénybe. A gyors megjelenítés érdekében a felhasználó által kiválasztott időintervallumonként új lekérést valósítok meg, de csak az utolsó ötven adattal. Az ötven adatot azért választottam, mert kellően gyorsan lehet lekérni, illetve ennél a mennyiségnél több friss adat nem lehet semmilyen mérési beállítás esetén sem. 51

52 5. Tesztelés Tesztelés során különböző tesztelő programokat vettem igénybe, illetve közeli ismerősök segítségét kértem, hogy valósághűbb eredményt kapjak Felhasználói felület analizálása Az sdk tartalmaz több teszt eszközt, ezek egyike az uiautomatorviewer. Ezzel az eszközzel könnyen megvizsgálhatjuk az alkalmazás felhasználói felületét. A 25. ábrán jól látható, hogy az összes komponenst külön meg lehet vizsgálni, így egyszerűsítve a felhasználói felület fejlesztését [29]. 27. ábra, uiautomatorviewer 52

53 5.2. Stressz teszt A rendszert a tervezett értéknél jobban terheljük, akkor gyakran fed fel hibákat számunkra. Egy ilyen tesztelésre kiválóan alkalmas az Excerciser Monkey nevű alkalmazás. Az emulátoron és készüléken is futtatható program olyan pszeudo véletlen folyamatokat generál, mint a felhasználó eseményei, kattintásai, így megismételhető módon tesztelhetjük az alkalmazást. A program négy fő beállítási lehetőséggel rendelkezik, ezek: Alapszintű beállítás (események számának beállítása) Csomagra történő korlátozás Események típusa és frekvenciája Fejlesztői beállítás Használata parancssorból történik, meg kell adni hozzá a csomag nevét, illetve, hogy mennyi ideig teszteljen az alkalmazás. Egy egyszerű példa: adb shell monkey -p com.android.kdezsi.mobiletracker -v 1000 Jelen esetben ezer pszeudo véletlen eseményt küld az alkalmazás az eszközre, ahol fizikailag is láthatjuk, hogy éppen mi történik a készüléken [30]. Tesztek során egy apróbb hibát találtam, amit normál esetben nem tud egy felhasználó sem reprodukálni. Ez a hiba akkor kerül elő, ha a főképernyőn a súgó gombra klikkel a felhasználó, ekkor normál esetben a felhasználó csak bezárás után tud egy következő ablakot megnyitni, mert fizikailag számára elérhetetlen, ám az Excerciser Monkey képes erre. A megoldás triviális, hiszen csak be kell zárni a megnyitott ablakot, ha előtérben van, de ilyen hibára nem nagyon kellett volna egyébként számítani Szerver sebessége Első lépésben a webszerver sebességét teszteltem, ehhez nem volt más teendőm, mint egy ilyen tesztre alkalmas weboldalt keressek. A teszthez tökéletesnek tűnt az alábbi 53

54 oldal: Az eredményekben láthatjuk, hogy a válaszidőket komponensekre bontva látjuk, ami jól reprezentálja az idők eloszlását. 28. ábra, Szerver elérésének sebessége vízesés diagramon A következő ábra pedig az értékelést mutatja, ahol látszik a statikus tartalmak betöltése Cookie mentes doménban, helytelen kérések elkerülése, kérések minimalizálása, statikus erőforrások karaktersorozat lekérdezéseinek eltávolítása, és cache validáció [31]. 29. ábra, Szerver teljesítményének értékelés 54