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
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
Konzulens
Dézsi Krisztián
Dr. Kovácsházy Tamás
2014
TARTALOMJEGYZÉK Összefoglaló...................................................................................................................... 7 Abstract ............................................................................................................................. 8 1.
Bevezetés .................................................................................................................. 9
2.
Hasonló alkalmazások a piacon .............................................................................. 11 2.1.
2.1.1.
Az alkalmazásról képekben ...................................................................... 11
2.1.2.
Előny ......................................................................................................... 11
2.1.3.
Hátrány...................................................................................................... 12
2.2.
Sensor Box for Android .................................................................................. 12
2.2.1.
Az alkalmazás képekben ........................................................................... 12
2.2.2.
Előny ......................................................................................................... 13
2.2.3.
Hátrány...................................................................................................... 13
2.3.
Phone Tester ................................................................................................... 14
2.3.1.
Az alkalmazásról képekben ...................................................................... 14
2.3.2.
Előny ......................................................................................................... 14
2.3.3.
Hátrány...................................................................................................... 15
2.4. 3.
AndroSensor ................................................................................................... 11
Alkalmazások összegzése ............................................................................... 15
Tervezés .................................................................................................................. 16 3.1.
Szenzorok és mérőeszközök áttekintése ......................................................... 16
3.1.1.
Szenzorok általános ismertetése ............................................................... 16
3.1.2.
Gyorsulásmérő .......................................................................................... 16
3.1.3.
Orientáció.................................................................................................. 18
3.1.4.
Mágneses mező ......................................................................................... 18
3.1.5.
Hőmérséklet, Fény, Légnyomás ............................................................... 19
3.1.6.
GPS ........................................................................................................... 21 3
3.1.7.
Processzor sebességének mérése Android rendszer alatt ......................... 23
3.1.8.
Memória .................................................................................................... 24
3.1.9.
Adatforgalom ............................................................................................ 25
3.1.10. 3.2.
4.
5.
Akkumulátor ......................................................................................... 25
Rendszer megtervezése ................................................................................... 27
3.2.1.
Alkalmazás................................................................................................ 28
3.2.2.
Szerver komponens ................................................................................... 31
Megvalósítás ........................................................................................................... 34 4.1.
Alkalmazás...................................................................................................... 34
4.2.
Szerver ............................................................................................................ 40
4.3.
Energia fogyasztás minimalizálása ................................................................. 43
4.4.
Adatok küldésnél felmerülő problémák .......................................................... 44
4.5.
Adattárolás a készüléken ................................................................................ 45
4.6.
Grafikus megjelenítés ..................................................................................... 46
4.7.
Google beépített szolgáltatásai ....................................................................... 47
4.7.1.
Google Térkép API rövid ismertetése ...................................................... 47
4.7.2.
Térkép használata Mobil környezetben .................................................... 47
4.8.
Szerver védelme .............................................................................................. 48
4.9.
Hiba logolás és log küldés .............................................................................. 49
4.10.
Sebesség optimalizálás ................................................................................... 50
Tesztelés.................................................................................................................. 52 5.1.
Felhasználói felület analizálása ...................................................................... 52
5.2.
Stressz teszt ..................................................................................................... 53
5.3.
Szerver sebessége ........................................................................................... 53
5.4.
Szerver sebezhetősége .................................................................................... 55
5.5.
Felhasználói teszt ............................................................................................ 55 4
6.
Összegzés ................................................................................................................ 57 6.1.
Előnyök ........................................................................................................... 57
6.2.
Továbbfejlesztési lehetőségek ........................................................................ 57
7.
Összefoglalás .......................................................................................................... 58
8.
Ábrajegyzék ............................................................................................................ 59
9.
Irodalomjegyzék ..................................................................................................... 61
Függelék.......................................................................................................................... 65
5
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, 2014. 12. 19.
………………………………… Dézsi Krisztián
6
Ö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
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
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
é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
2. Hasonló alkalmazások a piacon Ebben a fejezetben mutatom meg piacon legnépszerűbb és témámhoz legközelebb álló alkalmazásokat.
2.1. AndroSensor 2.1.1. Az alkalmazásról képekben
1. ábra, AndroSensor alkalmazás
2.1.2. Előny
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
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 email-en keresztül CSV formátumban.
2.1.3. 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: https://play.google.com/store/apps/details?id=com.fivasim.androsensor
2.2. Sensor Box for Android
2.2.1. Az alkalmazás képekben
12
2. ábra, Sensor Box for Android alkalmazás
2.2.2. 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.
2.2.3. 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: https://play.google.com/store/apps/details?id=imoblife.androidsensorbox
13
2.3. Phone Tester 2.3.1. Az alkalmazásról képekben
3. ábra, Phone Tester alkalmazás
2.3.2. 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
2.3.3. 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: https://play.google.com/store/apps/details?id=com.mtorres.phonetester&hl=hu
2.4. 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
3. Tervezés 3.1. Szenzorok és mérőeszközök áttekintése
3.1.1. 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
3.1.2. 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: s 2
16
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: ad g
Fs m
m Ebben az esetben g értéke ismert, amely földön 9.81 s 2 á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
3.1.3. 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 0° → 359° 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 -180° → 180°
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 -90° → 90°
É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].
3.1.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
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].
3.1.5. 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.
3.1.5.1. 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
3.1.5.2. 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].
3.1.5.3. 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]: g M
5 L h R L , vagy közelítőleg: e 15500 , ahol p p0 1 T0 h
p0 - a tengerszinten lévő légköri nyomás, normál értéke: 101325 Pa
L – átlagos légköri hőmérséklet csökkenés, normál értéke 0.0065
T0 – tengerszinti átlagos hőmérséklet, normál értéke: 288.15 °K
m g – nehézségi gyorsulás, normál értéke: 9.80665 s 2
kg M – száraz levegő moláris tömege, normál értéke: 0.0289644 mol
J R – egyetemes gázállandó, normál értéke: 8.31447 mol K
20
K m
5. ábra, Nyomás a magasság függvényében [5]
3.1.6. GPS 3.1.6.1. Á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
6. ábra, Helymeghatározás elve [8] 3.1.6.2. 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
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].
3.1.7. 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
Fájl tartalma általánosan a következőképpen néz ki [9]: > cat /proc/stat cpu 2255 34 2290 22625563 6290 127 456 cpu0 1132 34 1441 11311718 3675 127 438 cpu1 1123 0 849 11313845 2614 0 18 intr 114930548 113199788 3 0 5 263 0 4 ... ctxt 1990473 btime 1062191376 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 FN N N R N IO N I N S N
CPU speed
CPU N CPU N 1 100 CPU N TN CPU N 1 TN 1
3.1.8. 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
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].
3.1.9. 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.
3.1.10.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
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
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
3.2.1. 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
Adatfeldolgozás, megjelenítés, küldés
Grafikus adatfeldolgozás
3.2.1.1. 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
3.2.1.2. 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
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
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.
3.2.1.3. 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
3.2.2. 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ő.
3.2.2.1. 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
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
3.2.2.2. 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
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.
3.2.2.3. 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
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.
4.1. Alkalmazás
14. ábra, Az alkalmazás UML diagramja
34
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
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
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
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
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
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
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
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
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
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
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.
4.5. 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
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
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.
4.7. Google beépített szolgáltatásai 4.7.1. 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].
4.7.2. 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
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].
4.8. 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
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.
4.9. 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
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].
4.10. 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
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
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.
5.1. 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
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.
5.3. 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
oldal: http://tools.pingdom.com/fpt/. 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
5.4. Szerver sebezhetősége
A sebezhetőségre kitértem megvalósítás során, mivel lényeges, hogy az oldalt, illetve adatokat illetéktelenek ne változtathassák. Az ilyen feltérképezésre léteznek online szolgáltatások. Egy ilyen szolgáltatást biztosít a https://www.scanmyserver.com/ is. Az értékeléshez meg kell adnunk egy email címet, illetve weboldal láblécébe beilleszteni egy linket, amit az oldal számunkra generál. Beillesztés után a teszt 2 órán belül végrehajtódik. Emailben a következő riportot kaptam:
30. ábra, Webszerver sebezhetőségi riportja
A teszt során a weboldal különböző biztonsági réseit próbálja felderíteni, mint a SQL injection, Cross Site Scripting, malware [32]. Az eredmény jól látható a képernyőkép alapján, miszerint az oldal ezektől mentes, így biztonsággal használható.
5.5. Felhasználói teszt
Az alkalmazás kipróbálásra legalkalmasabb minden esetben, ha több felhasználó tesztel, mert a későbbiekben ők fogják használni az alkalmazást, nekik kell megfelelni. A több felhasználós teszt hibák felderítésére is kiváló, mivel minden tesztalany különböző készülékkel rendelkezik, valamint más böngészőket használnak. A tesztelésre egy hónapot hagytam mindenki számára, illetve feltelepítettem az alkalmazás, valamint megadtam a webszer elérési útját. Az időszak végeztével összegyűjtettem a tapasztatokat és kiértékeltem azokat. A kiértékelésnél figyelembe vettem az elégedettséget, az alkalmazás használatának könnyűségét/nehézségét, valamint az esetleges
55
hibákat. Összegészében az mondható el, hogy mindenki pozitív véleménnyel volt az alkalmazásról, hibát senki nem tapasztalt, inkább dizájn elemekre történt egy-egy megjegyzés. Egy felhasználó által írt vélemény: „A
Mobile Tracker egy univerzális adatgyűjtő és megjelenítő alkalma-
zás, a manapság a készülékekbe kerülő szenzorok és érzékelők széles skáláját lefedi. Az applikációban elénk táruló képernyők informatívak, tömören jelennek meg a grafikonokon a mért értékek. A felhasználói felület kialakítása ergonomikus használta kényelmes és könnyen elsajátítható. Mindemellett számos beállítás áll a rendelkezésünk az adatok gyűjtésével, tárolásával és megjelenítésével kapcsolatban, így válik kimagaslóan testre szabható eszközzé.”
A visszajelzések azt mutatták, hogy szívesen tanulnak a felhasználók a készülékeikben lévő szenzorokról, mivel erről nem rendelkeznek szinte semmilyen információval. Energiatakarékosság szempontjából is megfelelőek a vélemények, mivel senki nem tapasztalta, hogy az alkalmazás feltelepítése óta csökkent volna a készüléke üzemideje, tehát az energiaigény minimalizálása sikeres volt. A webes alkalmazást mindenki egyszerűen és kényelmesen tudta használni, az oldalak betöltődése során nem voltak fennakadások, az ábrákat egyértelműnek találták. Többen külön kiemelték tetszésüket a térképes felületnél telefonon, illetve weboldalon is, melyhez annyit tettek hozzá, hogy érdemes lehet akár egy külön oldalon az útvonalakat is megjeleníteni, ám ez jelen alkalmazásban nem volt cél.
56
6. Összegzés Ebben a fejezetben a megvalósított munkát hasonlítom össze a piacon meglévő alkalmazásokkal.
6.1. Előnyök
Saját alkalmazásom megvalósítása során ügyeltem arra, hogy egyedi legyen a meglévőekkel szemben, tartalmazzon olyan plusz lehetőséget, amit az eddigiek nem. Az eddig leírtak alapján látható, hogy ezt sikerrel valósítottam meg, az extra lehetőségek:
Webszerveren visszamenőleg az összes adat lekérhető
Külön térképes megvalósítás Androidos és webes környezetben
Esztétikus és konfigurálható grafikonok
Grafikonok bármilyen mélységben vizsgálhatóak
Valós idejű grafikus megjelenítés
Konfigurálható mérési paraméterek
Informatív tájékoztatás az eszköz szenzorjairól
6.2. Továbbfejlesztési lehetőségek
Az alkalmazás rendkívül sokrétű, így még rengeteg kihasználása lehetséges, ezek közül csak párat sorolok fel, melyet a közeljövőben meg is valósítok. Elsőként továbbfejlesztés excel export lenne, ami azért előnyös, mert így saját adatainkat bárhová kimenthetjük, vagy egyéb számításokat végezhetünk vele. Fejlesztés és tesztelés kevés készüléken történt, így optimális lenne többet bevonni és azokra tervezni. Továbbá több dizájn elem alkalmazása, esetlegesen különböző témák létrehozása, hogy még több felhasználó gondolja vonzóbbnak az alkalmazását hasznossága mellett.
57
7. Összefoglalás Az első félév során irodalomkutatással, valamint a mobil eszközökben található szenzorok vizsgálatával foglalkoztam. Kutatás során feljegyeztem az egyes szenzorok működését, amely alapján később elkészítettem a méréseikhez használt mini alkalmazásokat. Az adatokat struktúrába állítottam össze, mely az adatbázis alapja lett. Következő lépésben a mini alkalmazásokból megvalósítottam az alkalmazás vázát, ami képes kommunikálni a szerverrel. A fogadáshoz és megjelenítéshez létrehoztam egy egyszerű webes alkalmazást, ezáltal előállt a prototípus. A második félév a meglévő folyamatok kiegészítéséről, optimalizálásról szólt. A webes alkalmazást módosítottam úgy, hogy biztonságos legyen, valamint létrehoztam dizájnelemeket hozzá. Következő lépésben az Androidos alkalmazáshoz készítettem egy grafikus modult, amit beépítettem webes környezetbe is. A legideigényesebb lépés az energia és a sebesség optimalizációja volt, ahol sikerült jelentős eredményeket elérnem. Az alkalmazás könnyebb használatához kreáltam külön súgó gombokat, illetve dizájn elemeket illesztettem bele. A megvalósítás utolsó fázisában külön térképet implementáltam mind a webes mind az Androidos alkalmazásba. A két félévet felölelő diplomamunka során egy olyan alkalmazást tudtam elkészíteni, amely megállja a helyét a piacon is, mivel nem létezik hasonló komplett megoldás. Viszszajelzésekből is hasonlót tapasztaltam, mindenki elégedetten használja továbbra is az alkalmazást.
58
8. Ábrajegyzék 1.
ábra, AndroSensor alkalmazás ................................................................................ 11
2.
ábra, Sensor Box for Android alkalmazás .............................................................. 13
3.
ábra, Phone Tester alkalmazás ................................................................................ 14
4.
ábra, Gyorsulásmerő koordináta tengelyei [3] ........................................................ 17
5.
ábra, Nyomás a magasság függvényében [5].......................................................... 21
6.
ábra, Helymeghatározás elve [8] ............................................................................ 22
7.
ábra, Felhasználó pozíciójának meghatározása [3]................................................. 22
8.
ábra, Akkumulátor cella öregedés [12] ................................................................... 26
9.
ábra, Megvalósítandó architektúra .......................................................................... 27
10.
ábra, Alkalmazás MVC diagramja...................................................................... 28
11.
ábra, Adatmegjelenítés képernyőterve ................................................................ 30
12.
ábra, XML struktúrája......................................................................................... 30
13.
ábra, Főoldal képernyőterve ............................................................................... 32
14.
ábra, Az alkalmazás UML diagramja ................................................................. 34
15.
ábra, Alkalmazás bejelentkező képernyője ......................................................... 35
16.
ábra, Alkalmazás főképernyője........................................................................... 36
17.
ábra, Főképernyő beállításai ............................................................................... 37
18.
ábra, Pozíció megjelenítése térképen .................................................................. 37
19.
ábra, Alkalmazás grafikonjai .............................................................................. 38
20.
ábra, Grafikonok beállításai ................................................................................ 39
21.
ábra, A szerver UML Diagramja ........................................................................ 40
22.
ábra, Bejelentkező képernyő ............................................................................... 41
23.
ábra, Főképernyő ................................................................................................ 41
24.
ábra, Grafikonok ................................................................................................. 42
59
25.
ábra, Térkép ........................................................................................................ 42
26.
ábra, Log webes környezetben............................................................................ 49
27.
ábra, uiautomatorviewer ..................................................................................... 52
28.
ábra, Szerver elérésének sebessége vízesés diagramon ...................................... 54
29.
ábra, Szerver teljesítményének értékelés ............................................................ 54
30.
ábra, Webszerver sebezhetőségi riportja ............................................................ 55
60
9. Irodalomjegyzék [1] Fiv Asim: AndroSensor alkalmazás 2014. https://play.google.com/store/apps/details?id=com.fivasim.androsensor (Hivatkozva: 2014. augusztus) [2] IMOBLIFE INC. : Sensor Box for Android alkalmazás 2014. https://play.google.com/store/apps/details?id=imoblife.androidsensorbox (Hivatkozva: 2014. augusztus) [3] Android Developer: Sensor Overview 2014. http://developer.android.com/guide/topics/sensors/sensors_overview.html (Hivatkozva: 2014. augusztus) [4] Android Developer: SensorEvent 2014. http://developer.android.com/reference/android/hardware/SensorEvent.html (Hivatkozva: 2014. augusztus) [5] Wikimédia Commons: Légnyomás 2014. http://hu.wikipedia.org/wiki/L%C3%A9gnyom%C3%A1s (Hivatkozva: 2014. augusztus) [6] Android Developer: Location Strategies 2014. http://developer.android.com/guide/topics/location/strategies.html (Hivatkozva: 2014. augusztus) [7] Chris Veness: Calculate distance, bearing and more between Latitude/Longitude points 2014. http://www.movable-type.co.uk/scripts/latlong.html (Hivatkozva: 2014. augusztus) [8] Pierluigi Paganini: GPS vulnerability exploitable to control the route of a vessel 2014.http://securityaffairs.co/wordpress/wp-content/uploads/2013/07/gpsvulnerability-vessel.jpg (Hivatkozva: 2014. augusztus)
61
[9] Sascha Nitsch: /proc/stat explained 2014.http://www.linuxhowtos.org/System/procstat.htm (Hivatkozva: 2014. augusztus) [10] Android Developer: Systrace 2014. http://developer.android.com/tools/help/systrace.html (Hivatkozva: 2014. szeptember) [11] Patrick Dubroy: Memory Analysis for Android Applications 2014. http://android-developers.blogspot.hu/2011/03/memory-analysis-forandroid.html (Hivatkozva: 2014. szeptember) [12] Woodbank Communications Ltd.: Battery Reliability and How to Improve it 2014. http://www.mpoweruk.com/reliability.htm (Hivatkozva: 2014. szeptember) [13] Miguel Torres: Phone Tester alkalmazás 2014.https://play.google.com/store/apps/details?id=com.mtorres.phonetester&hl= hu (Hivatkozva: 2014. szeptember) [14] Oracle: Learn About Java Technology 2014. https://www.java.com/en/about/ (Hivatkozva: 2014. szeptember) [15] Microsoft: .NET Framework Development Guide 2014. http://msdn.microsoft.com/en-us/library/hh156542(v=vs.110).aspx (Hivatkozva: 2014. szeptember) [16] Parse: PHP Guide 2014. https://parse.com/docs/php_guide (Hivatkozva: 2014. szeptember) [17] First class Web Hosting: 000webhost.com 2014. http://www.000webhost.com/ (Hivatkozva: 2014. szeptember) [18] Xiang Chen, Yiran Chen, Zhan Ma, Felix C. A. Fernandes: How is Energy Consumed in Smartphone Display Applications 62
2014. http://www.hotmobile.org/2013/papers/full/17.pdf (Hivatkozva: 2014. szeptember) [19] Android Developer: Managing Your App's Memory 2014. https://developer.android.com/training/articles/memory.html (Hivatkozva: 2014. szeptember) [20] Android Developer: Storage Options 2014. http://developer.android.com/guide/topics/data/data-storage.html (Hivatkozva: 2014. szeptember) [21] Android Developer: Saving Data in SQL Databases 2014. http://developer.android.com/training/basics/data-storage/databases.html (Hivatkozva: 2014. szeptember) [22] Android Developer: Saving Key-Value Sets 2014. http://developer.android.com/training/basics/data-storage/sharedpreferences.html (Hivatkozva: 2014. szeptember) [23] Jonas Gehring: GrapView 2014. http://android-graphview.org/#features (Hivatkozva: 2014. október) [24] Google Developers: Google Maps Android API v2 2014. https://developers.google.com/maps/documentation/android/ (Hivatkozva: 2014. október) [25] Google Developers: Google Maps Android API v2 Getting Started 2014.https://developers.google.com/maps/documentation/android/start#getting_t he_google_maps_android_api_v2 (Hivatkozva: 2014. október) [26] Google Developers: Google Dashboard 2014. https://code.google.com/apis/console/?noredirect#project:44567110494 (Hivatkozva: 2014. október)
63
[27] Hodicska Gergely: PHP a frontvonalon, védekezés a bemeneten 2014. http://weblabor.hu/cikkek/phpkeretrendszer (Hivatkozva: 2014. november) [28] Android Developer: Performance Tips 2014http://developer.android.com/training/articles/perf-tips.html (Hivatkozva: 2014. november) [29] Android Developer: UI Testing 2014.http://developer.android.com/tools/testing/testing_ui.html (Hivatkozva: 2014. november) [30] Android Developer: UI/Application Exerciser Monkey 2014.http://developer.android.com/tools/help/monkey.html (Hivatkozva: 2014. november) [31] Pingfom: Pingdom Website Speed Test 2014. http://tools.pingdom.com/fpt/ (Hivatkozva: 2014. november) [32] Beyond Security: Scan My Server 2014. https://www.scanmyserver.com/ (Hivatkozva: 2014. november) [33] Eckler Péter, Fehér Marcell, Frostner Bertalan, Kelényi Imre: Android-Alapú Szoftverfejlesztés ISBN 978-963-9863-27-9, SZAK 2012.
64
Függelék A megvalósított kódok elérhetőek az alábbi svnből: https://riouxsvn.com/login/ Felhasználónév: dezsikrisz Jelszó: Semmi01
65
