Embed Size (px)
Citation preview
MISKOLCI EGYETEM GÉPÉSZMÉRNÖKI ÉS INFORMATIKAI KAR
TUDOMÁNYOS DIÁKKÖRI DOLGOZAT
Android alkalmazás fejlesztése egészségügyi állapotfelmérő rendszerhez
Bartók Roland Mérnök informatikus hallgató
Konzulens: Dr. Gáti Attila egyetemi docens
Elektrotechnikai-Elektronikai Tanszék
Miskolc, 2011
Tartalomjegyzék GÉPÉSZMÉRNÖKI ÉS INFORMATIKAI KAR............................................................................................... 1 TUDOMÁNYOS DIÁKKÖRI DOLGOZAT ..................................................................................................... 1
1. AZ ÁLLAPOTFELMÉRŐ RENDSZER .................................................................................................... 2
1.1. AZ ÁLLAPOTFELMÉRŐ RENDSZER LÉTREHOZÁSÁNAK CÉLJA.................................................................... 3 1.2. A RENDSZER ÁLTALÁNOS MŰKÖDÉSE ...................................................................................................... 3
2. NÉHÁNY SZÓ A NULLSZÉRIÁRÓL ....................................................................................................... 5
2.1. A PROTOTÍPUS FELÉPÍTÉSE ....................................................................................................................... 5 2.2. A PROTOTÍPUS MŰKÖDÉSE ....................................................................................................................... 5
3. FEJLESZTÉSI TERVEK, FELADATOK ELOSZTÁSA ........................................................................ 7
3.1. A TELJES RENDSZER VÁZLATA ................................................................................................................. 8 3.2. A MOBIL ALKALMAZÁS VÁZLATA ............................................................................................................ 8
4. MOBIL KÖRNYEZET .............................................................................................................................. 10
4.1. MIÉRT JÖHET SZÓBA A MOBIL TECHNOLÓGIA?....................................................................................... 10 4.2. KÖRNYEZET KIVÁLASZTÁSA .................................................................................................................. 11
4.2.1. Az okos telefonokon használt rendszerek ...................................................................................... 12 4.2.2. A cél rendszer................................................................................................................................ 13
5. ANDROID – A LÁTHATÓ ÉS TAPINTHATÓ OPERÁCIÓS RENDSZER ....................................... 14
5.1. AZ ANDROID FELÉPÍTÉSE ....................................................................................................................... 15 5.1.1. Könyvtárak .................................................................................................................................... 16 5.1.2. A Dalvik VM és a futtatható állományok....................................................................................... 16
5.2. AZ ALKALMAZÁSOK FELÉPÍTÉSE............................................................................................................ 16 5.2.1. Az Activity ..................................................................................................................................... 17 5.2.2. Az Intent ........................................................................................................................................ 18 5.2.3. A Service - háttérszolgáltatás........................................................................................................ 18 5.2.4. Content Provider........................................................................................................................... 19
5.3. A FORRÁS FELÉPÍTÉSE............................................................................................................................ 19 5.3.1. bin könyvtár................................................................................................................................... 19 5.3.2. gen könyvtár .................................................................................................................................. 19 5.3.3. res könyvtár................................................................................................................................... 19 5.3.4. AndroidManifest.xml ..................................................................................................................... 20
5.4. AZ ÖSSZECSOMAGOLT ALKALMAZÁS ..................................................................................................... 21 5.5. FEJLESZTÉS ............................................................................................................................................ 21
5.5.1. A fejlesztőkörnyezet ....................................................................................................................... 21 5.5.2. Az emulátor ................................................................................................................................... 22 5.5.3. Kiegészítő lehetőség – valós készülék használata ......................................................................... 22
6. KOMMUNIKÁCIÓ A HARDWARE-EL................................................................................................. 23
6.1. BLUETOOTH – AZ INTELLIGENSEBB ESZKÖZÖKÉRT ................................................................................ 23 6.1.1. Bluetooth az egészségügyben ........................................................................................................ 24 6.1.2. Jellemzői........................................................................................................................................ 24 6.1.3. Az alkalmazott modul .................................................................................................................... 25
6.2. A SAJÁT KOMMUNIKÁCIÓS KERET.......................................................................................................... 25 6.3. AZ ADATOK FOGADÁSA ......................................................................................................................... 27 6.4. UTASÍTÁSOK KÜLDÉSE........................................................................................................................... 27
7. ADATTÁROLÁS ........................................................................................................................................ 28
7.1. LEHETŐSÉGEK AZ ANDROID RENDSZERBEN ........................................................................................... 28 7.1.1. Belső adatbázis – SQLite............................................................................................................... 28 7.1.2. A rendszer saját cache lehetősége................................................................................................. 28 7.1.3. Saját mappa létrehozása ............................................................................................................... 29
7.2. ÁTMENETI FILE-OK ................................................................................................................................ 29 7.2.1. Mérés közben................................................................................................................................. 30
1
7.2.2. Egy vizsgálat megnyitásakor......................................................................................................... 30 7.3. EGY VIZSGÁLAT MENTÉSE ..................................................................................................................... 30
7.3.1. Az adatállomány............................................................................................................................ 30 7.4. AZ ADATÁLLOMÁNY SZERKEZETE ......................................................................................................... 31
7.4.1. A vizsgált személy adatai............................................................................................................... 31 7.4.2. Az állományhoz fűzött megjegyzés ................................................................................................ 32 7.4.3. Reakcióidő..................................................................................................................................... 32 7.4.4. A bináris adatok helye................................................................................................................... 33
8. FELHASZNÁLÓI FELÜLET ................................................................................................................... 34
8.1. AZ ANDROID KÉPERNYŐ ........................................................................................................................ 34 8.2. ANDROID GOMBOK – FIZIKAI VEZÉRLŐ ELEMEK .................................................................................... 35 8.3. A KÉSZÜLŐ ALKALMAZÁS KÉPERNYŐI ................................................................................................... 36
8.3.1. Vizsgálat........................................................................................................................................ 36 8.3.2. Adatfelvitel párbeszédnézet ........................................................................................................... 37 8.3.3. Megnyitás párbeszédnézet............................................................................................................. 38 8.3.4. Bluetooth párbeszédnézet .............................................................................................................. 38
9. FEJLESZTÉSI TERVEK .......................................................................................................................... 39
10. ÖSSZEFOGLALÁS................................................................................................................................ 40
11. KÖSZÖNET ............................................................................................................................................ 41
FORRÁSOK........................................................................................................................................................ 42
2
1. Az állapotfelmérő rendszer
Egy pécsi biofizikus, feltaláló, villamosmérnök Dr. Kellényi Lóránd, MSc, Ph.D,
a MTA Idegélettani Tanszéki Kutatócsoport nyugalmazott tudományos főmunkatársa
felismerte, hogy az időskorban illetve nagyobb, altatásos műtétek után az ember
szellemi teljesítőképessége csökken és e változások még idejében kimutathatóak és
a folyamat lassítható vagy akár a szellemi frissesség szinten tartható. Az agy
egészségi állapota szorosan összefügg a keringési rendszer állapotával is. A
kutatásai közben az adatgyűjtéshez tervezett egy mérőműszert, amelyet az évek
során folyamatosan fejlesztett, módosított. A kutatási időszak alatt nagyon jó
eredményeket ért el, ezért szükségessé vált az addig egyetlen műszert néhány
példányban sokszorosítani, ezzel lehetővé téve a vizsgálatok szélesebb körű
folytatását.
Tervével 2009-ben keresett saját találmányának nullszériás legyártására fiatal
egyetemistákat. A Bay Zoltán Alkalmazott Kutatási Közalapítvány Nanotechnológiai
Kutatóintézetének közreműködésével az Elektrotechnikai-Elektronikai Tanszéken
került sor a készülékek tervezésére és legyártására. A feladat elvégzésére alkalmas
villamosmérnök és informatikus hallgatókból alakult egy csapat, mely Dr. Pungor
András, a kutatóintézet akkori igazgatója és Dr. Gáti Attila docens szakmai
vezetésével folyt a munka. A feltaláló több kapcsolási rajzot, egy általa készített
működő prototípust és egy kezdetleges kiértékelő programot bocsájtott
rendelkezésünkre. A prototípusok elkészültek és használatuk során elért
kimagaslóan jó eredmények azt indokolták, hogy egy, a kor technológiai lehetőségeit
kihasználó, kisméretű, könnyen kezelhető eszközt tervezzünk a mérőrendszer új
verziójához. Szükségesnek bizonyult a számítógépes alkalmazás újragondolása is,
valamint a hardware eszköz megjelenítő részeit a napjainkban nagy népszerűségnek
örvendő okos telefonokra bíztuk. A munka könnyen felosztható részfeladatokra úgy,
mint a hardware eszköz és a hozzá tartozó vezérlő program, a számítógépes
alkalmazás és a mobiltelefonokra készült megjelenítő és adatgyűjtő alkalmazás. A
csapat tagjaként utóbbi alkalmazást vállaltam.
A csapat tagjai még Ferenc István Csaba mérnök informatikus hallgató, aki a
hardware vezérlőprogramját készíti, Fodor Gábor Dénes mérnök informatikus és
villamosmérnök hallgató, aki magát a hardware-t készíti és Simon Csaba mérnök
3
2. ábra Szívgörbe képe
informatikus hallgató, aki a PC-s kiértékelő programot írja Java nyelven. A
résztvevők mind a Miskolci Egyetem informatikus hallgatói.
Az 5 prototípus elkészítése és a most készülő modernizált rendszer tervezése,
kivitelezése nagyon értékes tapasztalatot és a félévek alatt meg nem szerezhető
kiegészítő tudást biztosít számunkra a mérnöki és a csapatmunka terén egyaránt.
Nem csak azt sajátíthattuk el, hogyan lehet megbízható, használható és esztétikus
terméket létrehozni, hanem azt is, hogy a feladatot megtervezzük, részekre osszuk,
és egymáshoz hangolva megoldjuk őket egy közös cél érdekében.
1.1. Az állapotfelmérő rendszer létrehozásának célja
A készülék azért jött létre, hogy idejében kimutatható legyen több olyan
időskori betegség, mint például keringési
problémák, szívproblémák, idegrendszeri
elváltozások, amelyek megelőzhetők vagy
hatásuk csökkenthető, ha időben felismerik.
A mérő berendezés alkalmas arra, hogy
altatásos műtétek előtt és után alkalmazva
megállapítható, hogy az altatott személy
agyi működése milyen mértékben romlottak
az altatás hatására.
1.2. A rendszer általános működése
Az állapotfelmérő rendszer a vizsgálat során az emberi szervezet négy
tulajdonságát vizsgálja:
• Bőrfelszíni keringés vizsgálata (pletizmográfia): a bőrfelszín 1-3mm-es
mélységében keringő vér nyomásváltozását
vizsgálja infra adó-vevő párral. Ez az érrendszer és
a szív állapotáról ad információt. (2. ábra)
• Tremor vizsgálat: A végtagok, esetünkben a kar
és kéz természetes rezgését méri gyorsulásmérő segítségével. Ez a
rezgés abból származik, hogy a végtag adott helyzetben tartását az
1. ábra Dr. Kellényi Lóránd teszt készüléke
4
izomzat folyamatos apró mozgásokkal biztosítja a végtagra ható erő
ellenében. A vizsgálat e része a mozgásért felelős agyterület és az
idegrendszer állapotát térképezi fel.
• sRT, cRT – reakcióidő mérés: A reakcióidő mérés egy, a műszer által
fejhallgatón keresztül szolgáltatott 1000Hz-es hang és erre
gombnyomással adott válasz között eltelt idő mérésén alapul. Utóbbi meg
is felel az egyszerű (sRT – simple reaction time) reakcióidőnek. A feltételes
(cRT - choice) reakcióidő-mérés esetén egy másik, mélyebb hangot is hall
a vizsgált személy, amelyet figyelmen kívül kell hagynia. Ez a vizsgálat a
szellemi frissességét méri. Az átlagos idő 200 és 300ms közé esik.
Befolyásolhatják olyan tényezők, mint a fáradtság, a környezet zavaró
hatásai, stressz. A vizsgálat során a vizsgált személy kaphat egyszerű
számolási feladatot, amelyet a célingerre adott válasz közben kell
végrehajtania. Ezzel is további információkra lehet szert tenni a vizsgált
személy állapotát illetően.
Az előbbi vizsgálatok eredményeit egy számítógépes program dolgozza fel. A
bőrfelszíni keringésből kiszámítja a pulzusszámot, ennek változását, végül
statisztikát is készít belőle. Tremor vizsgálat esetén a jel FFT vizsgálat
eredményében a kiugró frekvenciaértékek utalnak bizonyos idegrendszeri
betegségekre, mint például a Parkinson-kór. A reakcióidő adataiból átlagot, mediánt
és szórást számít.
5
2. Néhány szó a nullszériáról
2.1. A prototípus felépítése
A prototípusok csak a kísérleti mérések lebonyolítását szolgálják, ezért
robosztusak, szükség esetén módosíthatóak és szerelhetőek. Annyiban különböznek
a mintapéldánytól, hogy az alkatrészeket az áramkör számára tervezett nyomtatott
áramköri lapra szereltük így biztosítottuk a megbízható működést. Maga az áramkör
furatszerelt alkatrészekből épül fel, melyek hely-, és energiaigénye is viszonylag
nagy, így csak konnektor közelében használható. A méréshez szükség van egy
személyi számítógépre és egy külső, általunk
módosított hangkártyára, és egy fejhallgatóra is. A
kísérleti mérések során ez megfelelő, azonban a
széleskörű használat során leginkább bosszúságot
okoz a nagy mennyiségű vezeték, sok kapcsoló és
ezek meghibásodásának lehetősége.
2.2. A prototípus működése
A prototípus működésének egyik jellemzője, hogy az érzékelők jeleit maga az
alapműszer méri, majd analóg feldolgozás után analóg jelként továbbítja a
hangkártya felé. Ilyen feldolgozás például a szívgörbe jelén végzett csúcsérzékelés,
amely segítségével egy LED felvillantásával tájékoztat az érzékelő helyes
működéséről. Az alapműszer képes trend görbét készíteni (vagyis ennek megfelelő
jelet) a szívfrekvencia változásáról.
A hangkártyát át kellett alakítani két vonal bemeneti leválasztó
kondenzátorának rövidre zárásával, hogy DC jeleket is képesek legyen digitalizálni a
PC számára.
A PC-s kiértékelő program, amely Delphi nyelven íródott, a hangkártya
vonalbemenetéről gyűjti az adatot és rajzolja ki folyamatosan két grafikonra, a stereo
csatornáknak megfelelően. Az esetleges erősítést magán a műszeren kell elvégezni,
az alkalmazás maga csak a jel kiértékelésére képes. A műszer semmilyen adatot
3. ábra Az elkészült prototípus
6
nem közöl arról, hogy éppen melyik mérés folyik. Ezt a mérést végző személynek
kell tudnia később az elemzésnél, hogy a grafikonnak azt a szakaszát (a grafikonon
végezhető kijelölés) milyen mérésnek megfelelő menüponttal kell elemezni. Egyes
jelek (szívgörbe jele) elemzéséhez azonban szükség van az orvos tapasztalatára és
tudására, hogy „szemmel” tudja elemezni a görbéket.
Az elemzés rögzítését segíti egy egyszerű szövegszerkesztő a kiértékelő
programban, amelybe beilleszthető a grafikon egy-egy kijelölt darabja. Az elkészült
szöveges értékelés elmenthető, kinyomtatható. Az, hogy az elemzés melyik
méréshez tartozik legfeljebb onnan tudható, ha az írója valahol lejegyzi.
4. ábra A prototípusok kiértékelő programja (a két grafikon a hangkártya jobb és bal csatorna jelét rajzolja ki)
7
3. Fejlesztési tervek, feladatok elosztása
A rendszert, korszerű eszközök felhasználásával fejlesztjük egy hatékony és
olcsó, ezáltal az orvosok számára könnyen hozzáférhető rendszerré.
A mérő hardware lelke egy mikrovezérlő, amely fogadja a gyorsulásmérő és
digitalizálja az infradióda felerősített jelét, elvégzi a reakcióidő mérést a hangok
generálásával együtt. A mért értékeket ezután USB vagy Bluetooth kapcsolaton
keresztül küldi a PC vagy a mobilkészülék felé. Az áramellátását korszerű lítium
alapú akkumulátorral oldjuk meg. A mikrovezérlő köré csak minimális mennyiségű
alkatrészt kell építeni. Saját állapotát LED-ekkel jelzi, illetve elküldi azt a feldolgozó
alkalmazásnak. A vezetéknélküli Bluetooth kapcsolatnak köszönhetően a vizsgált
személy számára is kényelmesebb lesz az állapotfelmérés, nem kell a vezetékekre
figyelnie. A vizsgálatot végző orvos pedig egyszerűen PC esetén kattintásokkal,
mobilkészülék esetén érintésekkel irányíthatja a mérést. Ezzel a résszel Ferenc
István Csaba, mint a firmware készítője és Fodor Gábor Dénes, mint a hardware
tervezője foglalkozik.
A PC-s alkalmazás teszi lehetővé a teljes körű kiértékelését, megjelenítését és
tárolását a jeleknek. Egyszerű adatbázis-kezelő feladatot is ellát az mérési
eredmények rendszerezésére. A fejlesztési nyelv választása a Java nyelvre esett. A
program elkészítését Simon Csaba végzi.
A mobilkészülékekre, ezen belül is az Android rendszerre készülő alkalmazás
teszi lehetővé, hogy PC nélkül is elvégezhető legyen a vizsgálat szinte bárhol.
Feladatait tekintve Bluetooth kapcsolaton keresztül fogadja a mérő hardware adatait,
melyeket megjeleníti és tárolja. Ez nagy segítség az orvosnak, mert nem kell
magával cipelnie súlyos és nagy számítógépet ellenben egy okos telefonnal, amely
akár a megszokott táskájában is elfér a mérő hardware-el együtt. Természetesen ez
az alkalmazás nem a PC-s alkalmazás kiváltására, hanem a lehetőségek és
kényelmi funkciók kiterjesztésére szolgál. Bár a nem túl távoli jövőben akár ki is
válthatja a PC feladatát.
8
3.1. A teljes rendszer vázlata
A rendszer fizikailag két fő egységből áll, a mérőegység és a feldolgozó
egység. Előbbi a mikrovezérlővel ellátott kézi eszköz, amely a vizsgált személyre
kerül utóbbi pedig a PC-t illetve a mobil eszközt jelöli. A rendszer vázlata az 5. ábrán
látható.
A mérőegység feladata az adatok digitalizálása, gyűjtése, majd keretbe
foglalva vezetékes (USB) vagy vezeték nélküli (Bluetooth) kapcsolaton továbbítja a
feldolgozó egység felé.
A feldolgozó egység végzi az adatok tárolását, elemzését. A PC-re készülő
program teljes körű azonnali és utólagos elemzési feladatokat lát el az adatgyűjtés
mellett. A hordozhatóság kényelme érdekében készül a mobil alkalmazás, amely a
PC-s program egy egyszerűsített változata, főleg az adatgyűjtésre kihegyezve
néhány hasznos elemzési kiegészítéssel és természetesen rendelkezik a nyers
illetve feldolgozott adatok megjelenítéséért felelős részekkel is.
3.2. A mobil alkalmazás vázlata
A mobil alkalmazás egyszerű vázlata a 6. ábrán látható. A nyilak az
adatáramlás irányait mutatják.
A Keret modul felelős a bejövő keretek feldolgozásáért és a típusának
megfelelően továbbítani az adatfeldolgozásért illetve állapot üzenetek esetén a
felhasználói felület kezelésére készült modul felé. Az fogadáson kívül szükséges a
mérőegység számára különféle utasításokat küldeni, mint például melyik mérésre
van szükség, esetleg kikapcsolás. Ezeket az üzeneteket az Keret modul foglalja
5. ábra A teljes rendszer vázlata
9
keretbe és továbbítja a Bluetooth modul felé. A Bluetooth a telefon belső
kapcsolatkezelő modulját ábrázolja.
Az Adatfeldolgozás a bejövő adatok főleg a megjelenítés számára történő
elemzését végzi, FFT analízis a tremor jelből, csúcsérzékelés és ebből pulzus
számítás a pletizmográf jeléből. Ezeket vagy a megjelenítő modul felé vagy a file
kezelő modul felé továbbítja, amely a tárolóba írja az adatokat. A nyers adatokat
átmeneti file-okban tárolja az alkalmazás. A felhasználó szándékait a megjelenítő és
vezérlő modultól fogadja. Innen kapja az utasítást, hogy feldolgozza, vagy
elmentésre küldje az adatot.
A File kezelés modul a kapott adatot az utasításnak megfelelően átmeneti
állományba vagy a végleges állományba menti. Az alkalmazás képes az elmentett
méréseket megnyitni és megjeleníteni illetve egy valamilyen hiba miatt megszakadt
mérés már meglévő adatait végleges formában elmenteni.
A Felhasználói felület/vezérlés egy különleges modul, a két feladat az
érintőképernyő miatt került egy csoportba. Az adatok kirajzolását grafikonokra végzi
tartalmaz adatfelviteli lehetőséget és állapotsávot is kezel. A vezérlés a különböző
gombokhoz tartozó utasításokat továbbítja a megfelelő modul felé.
6. ábra A mobil alkalmazás vázlata
10
4. Mobil környezet
4.1. Miért jöhet szóba a mobil technológia?
A kezdetben méretes, nehéz és csak beszédhívásra alkalmas rádiótelefonok
(1973) az 1980-90-es években indultak rohamos fejlődésnek. Az egyszerű
hanghívás mellett megjelent a rövid szöveges üzenet szolgáltatás (SMS) - mely
eredetileg szerviz szolgáltatás volt, azonban brit fiatalok akkor még ingyenessége
miatt elkezdték kommunikációs célokra használni - , képüzenet, továbbítási
lehetőség (MMS). A kijelzők a kezdetben egyszínű számkijelzőkből a nagyobb
felbontású egyszínű majd árnyalatos kijelzőkön keresztül mára nagy felbontású
színes kijelzőkké fejlődtek. Közben megjelentek új szolgáltatások úgy, mint a
mobiltelefonon is elérhető Internet. Megjelentek az okos telefonok, melyek most a
műszer szempontjából a cél-hardware-t jelentik. A továbbiakban is inkább ezekről
írok.
A hardware is közben egyre nagyobb számítási teljesítményre lett képes.
Olyan dolgokra használhatóak mára, mint a számítógépek: játékok futtatása
viszonylag bonyolult akár 3D-s grafikával, fényképszerkesztés, zenelejátszás, GPS
helymeghatározás, WEB böngészés… a sor szinte végtelen. Általánossá vált a
nagyméretű kijelző, érintéses vezérléssel.
Láttam példát futároknál, a telefon segítségével regisztrálták az áru átadását,
aláírást az érintés érzékeny képernyőn kellett elvégezni.
Alkalmas kérdőív kitöltésére, adatfelvételre fénykép csatolással, akár a pincéreknek
is segítséget nyújthat a rendelés felvételekor, az elküld gomb nyomására a szakács
már tudja mit kell készítenie. Az USA-ban az orvosok a betegek adatait olvassák ki
okos telefonból, amelyet egyelőre maguk visznek fel, de mégis gyorsabb, mint egy
több oldalas kartont átböngészni.
Másik érdekes fiatal készülékcsoport a tábla PC-k csoportja. Ezek már
legalább 7” képátlójú kijelzővel rendelkeznek, nincs billentyűzetük, szinte minden
vezérlést a képernyő érintésével lehet megoldani. A telefonokhoz hasonlóan akár
kézírást is képesek felismerni, szöveggé alakítani. Hardware szempontjából inkább
11
laptopnak számítanak, méret szempontjából nagyobb okos telefon vagy kisebb
laptop. Operációs rendszerüket tekintve is elég széles a paletta.
Tehát érdemes figyelembe venni ezeket a zsebszámítógépeket a mi
műszerünk esetén is, melynél fontos a hordozhatóság és egyszerű használat.
Véleményem szerint számítási teljesítményük az állapotfelmérő rendszerhez több
mint elegendő. Kommunikációs képességeik lehetővé teszik, hogy magával a
műszerhez készített hardware eszközzel vezeték nélküli kommunikációt folytasson.
4.2. Környezet kiválasztása
A Java környezetet a megalkotása idején kis elektronikai eszközök közös
nyelvének tervezték (kezdetben Oak néven futott). Elterjedése mégis a weboldalakba
ágyazható applet-ek hatására történt meg, ma használatos az asztali és szerver
gépek között felhasználói és szerver alkalmazásként is.
Azonban mindig újra felmerült az igény a kis elektronikai eszközök
programozási nyelvére, egy egységes rendszer kialakítására. Mivel a Java
Virtuálisgép (JVM – Java Virtual Machine ) erőforrás igénye folyamatosan nőtt, már
nem volt alkalmas ezen eszközökön történő futtatására. A Java 2 bevezetésével
létrejött a J2SE (Standard Edition) a felhasználói és a J2EE (Enterprise Edition)
üzleti változat. Ezek mellé létrehozták a J2ME-t (Micro Edition) a telefonok, beltéri
egységek, autók, tv-k és egyéb eszközök számára.
Utóbbi a J2SE korlátozott változata, szabványokat, profilokat
tartalmaz. A J2ME elterjedése a telefonok népszerűvé válásának és
rohamos hardware-es fejlődésének hatására történhetett meg. A
telefonok fejlődésük során már nem csak telefonálásra váltak
alkalmassá, hanem kiegészítő programok futtatására is. A
felhasználók leginkább játékprogramokat futtattak a telefonjukon.
Ezért a J2ME szinte összenőtt a játékprogramokkal. Természetesen a játékok mellett
egyéb hasznos alkalmazást is készítenek a telefonokra (például Miskolc Városi
Közlekedési Zrt. mobiltelefonos menetrendje).
A Java ME bővebb kifejtésére nem kerül sor, ugyanis a cél készülékeket a
gyártók más, olyan operációs rendszerrel látják el, amelyek általában nem
támogatják a Java ME-et. Kivételt képez a BlackBerry által használt RIM (Research
12
In Motion) operációs rendszer, amelyet a Java ME-n alapuló programokkal lehet
kiegészíteni. További probléma a Java ME-vel, hogy sok készülék saját csomagot
igényel a megfelelő működéshez, főleg a hardware eszközök használatakor úgy,
mint a Bluetooth kapcsolat, kamera használata esetén, ez igaz a RIM-re is. A Java
ME megmaradt a „kevésbé okos” telefonok nyelvének.
4.2.1. Az okos telefonokon használt rendszerek
Az okos telefonokat a gyártók alapjaiban más operációs rendszerrel látják el,
mint a hagyományos telefonokat. Ennek oka az erősebb hardware jobb
kihasználása, a felhasználói élmény fokozása. Továbbá az, hogy egy egész
szolgáltatáscsomagot hoznak létre az adott rendszerhez, mint például az
alkalmazások számára létrehozott piactér, irodai szolgáltatások, szervező és e-mail
és tárhely szolgáltatások.
A jelenlegi népszerű rendszerek eloszlását a 7. ábra mutatja. Növekvő
sorrendben az első az egyéb
kategória, ezek a kevésbé ismert
gyártók saját rendszerei illetve
direkt mobil telefonok számára
átalakított Linux változatok.
A Bada a Samsung által
2010-ben bemutatott operációs
rendszer főként a csúcskategóriás
okos telefonok, tábla PC-k és TV
készülékek számára. A Bada
koreai nyelven óceánt jelent.
Linux, freeBSD alapú. C és Java
nyelvet támogat.
A Microsoft 2000 óta jelen
van a mobil piacon, jelenleg
Windows Phone-nak hívja a mobil
operációs rendszerét. C++, C#
nyelven programozható.
7. ábra A mobil operációs rendszerek aránya 2011. 2. negyedévében
13
A RIM a BlackBerry-k operációs rendszere. Zárt forráskódú és Java
segítségével programozható.
Az Apple 2007. június 28-án adta ki az első iPhone-t. Ez a készülék alapjaiban
változtatta meg, amit addig az okos telefonoktól vártak az emberek. Eddig 5
változata jelent meg. Programozása Objective C nyelven lehetséges.
A Symbian a Nokia által fejlesztett és használt rendszer a felsőkategóriás
illetve okos telefonjain. Java és C nyelven programozható.
Végül a legdinamikusabban fejlődő rendszer az Android következik. A Google
fejlesztése egy régebbi azonos nevű terv folytatásaként. Jelenleg a legtöbb
készüléken érhetőek el különböző verziói, melyből a 4. éppen a napokban került
nyilvánosságra.
4.2.2. A cél rendszer
Az egészségügyi állapotfelmérő rendszer számára az Android rendszert
választottam. Jelenleg ez a legelterjedtebb rendszer, a belépőtől a csúcs kategóriáig
széles a készülék-kínálat, mindenki megtalálhatja a számára megfelelőt. Többek
között ez is segíti az Android-ot a gyors terjedésében.
A dolgozat írása idején, a világon a legelterjedtebb a 2.3-as változat, azonban
a hazai szolgáltatóknál szép számmal vásárolható olyan készülék, amely a 2.1-es
változatot futtatja. Ez az oka, hogy a készülő alkalmazás megkívánja legalább az
Android 2.1-et. Az ettől idősebb rendszerek gyors ütemben tűnnek el készülékváltás
vagy rendszerfrissítés következtében, az újak közül a 2.1 a legkisebb elérhető
változat.
14
5. Android – a látható és tapintható operációs rendszer
Az Android platform abból a célból született, hogy egységes nyílt forráskódú
rendszere legyen a mobil eszközöknek (okos telefonok, tábla gépek). Alapját egy
Linux operációs rendszer alkotja, amelyet úgy alakítottak át, hogy képes legyen gond
nélkül kezelni a mobil eszközök hardware egységeit (érintőképernyőt, WiFi,
Bluetooth, GPS, HSDPA) és kicsi legyen az erőforrásigénye.
2005-ben a Google megvásárolta az eredeti fejlesztő céget, az Android Inc.-t.
Ez új irányt adott a fejlesztésnek. A Linux kernel fölé egy virtuális gép került, amely
felelős a programok futtatásáért és a felhasználói felület kezeléséért. Ekkor került
bele a Java nyelv is, mint az Android alkalmazások programozási nyelve.
2007. november 5-én bejelentették az Android disztribúciót az Open Handset
Alliance alapításával együtt, amely összesen 84, hardware gyártó, software fejlesztő
és telekommunikációs cég szövetsége. Az Android Open Source Project célja az
Android fejlesztése és karbantartása.
2008. szeptember 20-án került nyilvánosság elé az első kiadása az Android-
nak. Napjainkra már nem csak az okos telefonok elterjedt rendszere, hanem
megtalálható a tábla PC-ken, TV készülékeken is. Hasonlóan a Sun Java-hoz
(amelyet később felvásárolt az Oracle), fokozott érdeklődés mutatkozik iránta, hogy
gépjárművek fedélzeti és navigációs rendszereként, ipari automatizálási területen
alkalmazzák, illetve minden olyan helyen, ahol korlátozott erőforrások állnak
rendelkezésre, kisméretű képernyő és egy egér vagy billentyűzet használata
nehézkes lenne, így előnyt jelent az érintő kijelző.
Az általunk modernizált egészségügyi állapotfelmérő rendszernek is egy
kényelmes és hasznos kiterjesztése lehet egy Android alapú kiértékelő program.
Ezáltal nem csak könnyen hordozhatóvá válik, hanem az elkészítendő mérő
hardware is egyszerűbb lehet, nem kell rá például külön kijelző, nagy belső memória,
mert az már ott van a telefonban. A szinte általánossá vált érintőképernyők mára
teljesen használhatóvá váltak, képesek helyettesíteni a mutató és beviteli
eszközöket, ez tovább csökkenti a csatlakoztatott külső hardware egységek számát.
15
5.1. Az Android felépítése
Az Android felépítését szemlélteti a 8. ábra. A piros színnel jelölt rész a
rendszer alapja egy monolitikus Linux kernel. Ez tartalmazza a hardware-n kezelhető
eszközök meghajtó programjait. Ezeket azok készítik el, akiknél senki sem tudhatja
jobban, hogyan működik az adott eszköz, vagyis azok a gyártók, akik Android-ot
szeretnének használni a saját eszközeiken. Ez a kis méretű kernel biztosítja a
memória kezelését, a folyamatok kezelését.
A kernel szolgáltatásait használják a rendszer különféle könyvtárai, az ábrán
zöld színnel jelölt részek. Ezek közvetlenül a kernelen futnak, részben ezekre épül a
Dalvik VM (Virtuális gép) is. C, C++ nyelven íródtak.
A felső kék rész már az alkalmazások területe, Java nyelven programozható
és a virtuális gép futtatja a megírt programokat. A rendszer magját szinte teljesen
elrejti. Lehetőség van egy külön fejlesztői csomag segítségével C nyelvű
programokat is készíteni az Anrdoid-ra.
8. ábra Az Android rendszer felépítése
16
5.1.1. Könyvtárak
• libc: BSD-ből származó szabványos C könyvtár megvalósítása, mobil Linux alapú
készülékek számára optimalizálva.
• Media Framework: Több népszerű hang, állókép és mozgókép formátum
lejátszását és felvételét támogatja, a PacketVideo OpenCORE-ja alapján.
• Surface Manager: A megjelenítő alrendszerhez való hozzáférést kezeli a
zökkenőmentes 2D és 3D megjelenítés érdekében.
• LibWebCore: Egy modern web-böngésző mag az Android böngésző és a
beágyazható webes nézet számára.
• SGL: 2D-s grafikus motor
• OpenGL|ES: OpenGL ES 1.0 megvalósítása. A könyvtár a 3D-s megjelenítéshez,
ha elérhető hardware-es gyorsítást használ, vagy az erősen optimalizált software-
es 3D raszterezőt.
• FreeType: bittérképes és vektoros betűtípusok megjelenítése
• SQLite: egy könnyűsúlyú relációs adatbázis megvalósítása minden alkalmazás
számára.
5.1.2. A Dalvik VM és a futtatható állományok
A Dalvik VM egyáltalán nem kompatibilis a Java VM-el. Más, tömörebb, mobil
eszközökre optimalizált byte-kódot futtat. A *.java állományokat a fordító nem *.class,
hanem *.dex file-okba fordítja ( Dalvik Executable ). Ennek kisebb a mérete is, mint a
*.class file-oknak. Ez annak is köszönhető, hogy a konstansokat egyszer fordítja bele
az állományba és egyéb optimálásokat is alkalmaznak.
5.2. Az alkalmazások felépítése
Mobil környezetben, ahol viszonylag kicsi a megjelenítő felülete és kevés az
erőforrás nem elterjedt az ablakos felhasználói felület. Az Android esetén is inkább
képernyőkről kell beszélni a Java ME-hez hasonlóan. Ezek a képernyők általában az
egész megjelenítő felületet elfoglalják kivéve az állapotsort, de grafikus alkalmazások
esetén előfordul, hogy ténylegesen az egész képernyőt veszik birtokba.
17
5.2.1. Az Activity
Az Android-ban ezek a képernyők két részből épülnek fel. Az egyik a
megjelenésért felel, egy XML alapú leíró file, amely megadja, milyen elemek hogyan
vannak elrendezve a képernyőn. A másik a hozzá tartozó Activity osztály
leszármazottja, amely a hozzá tartozó képernyő eseményeit kezeli, válaszol rá.
Egyszerűbb programok esetén nem feltétlenül fontos az XML file létrehozása, a Java
forrásból is (ahogy az a Java esetén megszokott) létrehozható a grafikus felület.
Egyszerre mindig egyetlen Activity látszik, és külön életciklussal rendelkezik.
Az életciklus minden Activity saját jellemzője, a 9. ábrán látható milyen állapotai
vannak.
9. ábra Az Activity életciklusa
18
Lényegében az Activity az onStart() és onStop() állapot között látható és
használható a képernyőn. Az ábrán látható állapotok azonos nevű metódusát az
Activity ősosztályból örökli a saját képernyőnk és a platform hívja meg a megfelelő
időben. A fontosabbakról néhány szó röviden:
Az onCreate() metódus az Activity létrehozásakor hívódik meg, ebben lehet
elvégezni az objektumok létrehozását, beállítását, az előzőleg elmentett állapot
ilyenkor már visszatölthető.
Az onPause() metódus a tevékenység háttérbe kerülésekor hívódik meg,
ekkor elvégezhető az állapot mentése, szálak leállítása, szüneteltetése.
Az onDestroy() metódus akkor hívódik meg, amikor a tevékenység már nem
látható és kevés a rendelkezésre álló memória. Ugyanis az Android rendszer nem
állítja le a programokat, csak felfüggesztett állapotba helyezi. Ennek köszönhetően a
gyakran használt programok gyorsan indulnak, akár az előzőleg használt állapottól is
folytatható a használatuk. Ez azért fontos, mert a program használatakor történhet
olyan esemény, ami a program azonnali felfüggesztését kéri (bejövő telefonhívás,
üzenet).
5.2.2. Az Intent
Az Intent - magyarul szándék, egy összetett objektum. Arra használható, hogy
az egyes Activity-k adatot cserélhessenek egymással vagy használható egy új
Activity indítására is.
Ilyen Intent-et nem csak saját magunk hozhatunk létre és kaphatunk el. A
rendszer is küldhet Intent-et, például telefonhíváskor, ébresztéskor. A különböző
Intent-ekre a BoradcastReciever osztály leszármaztatása segítségével iratkozhatunk
fel. Ezt meg lehet tenni a program futása közben is vagy úgy, hogy az
AndroidManifest.xml file-ban megadjuk milyen Intent eseményekre figyeljen az adott
Activity. Ha egy alkalmazás feliratkozott az esemény figyelésére és az esemény
bekövetkezik, akkor a platform gondoskodik az alkalmazás elindításáról.
5.2.3. A Service - háttérszolgáltatás
Ha egy alkalmazásnak szükséges, hogy akkor is fusson, amikor éppen az
alkalmazás be van zárva – az egészségügyi állapotfelmérő rendszer esetében
például akár egy telefonhívás közben sem szakadhat meg az adatgyűjtés – akkor
19
szükség van a Service-re. Minden ilyen szolgáltatást addig futtat a platform, ameddig
azok be nem fejeződnek. Minden alkalmazás képes kapcsolódni a
szolgáltatásokhoz, hogy azokat vezérelni is lehessen.
5.2.4. Content Provider
Mivel az alkalmazások nem minden esetben csak az éppen rendelkezésre álló
adatokkal dolgoznak, szükség van a két futás közötti adatok tárolására. Ezt
támogatja a Content Provider, amely vagy az SQLite adatbázist vagy átmeneti file-ok
használatát támogatja az alkalmazás számára.
5.3. A forrás felépítése
A forrás csomag több könyvtárból áll, melyeknek kitüntetett szerepe van.
5.3.1. bin könyvtár
Ebben a könyvtárban tárolja a fejlesztő környezet a *.class file-okat,
amelyekből majd a *.dex file-okat fogja elkészíteni. Ebben a mappában található az
utóbb említett *.dex file is. Tehát itt tárolja a byte-kódot és a *.apk file-t, amelyről
később lesz szó.
5.3.2. gen könyvtár
A gen könyvtárban található az R.java osztály. Ez egy különleges osztály a
fejlesztőkörnyezet generálja és kezeli, létrehozásával memóriát és erőforrást takarít
meg a rendszer.
Ez a statikus osztály több belső statikus osztályt és azok statikus
konstansokat tartalmaznak. A konstansok memóriacímeket tárolnak a különböző
erőforrásokra (például egy gomb a képernyőn vagy egy elrendezés).
5.3.3. res könyvtár
Ez a könyvtár több alkönyvtárból áll. Az erőforrásokat tartalmazza:
• drawable könyvtár: Az alkalmazás által használt képeket tárolja. Előfordul, hogy
több is létrejön belőle: drawable-ldpi – kis méretű képek az alacsony kijelzőkhöz,
20
drawable-mdpi – közepes méretű képek, drawable-hdpi – nagy méretű képek. Ez
a tulajdonság jellemző a többi itt található könyvtárra is.
• layout könyvtár: Az alkalmazás egyes képernyőinek elrendezését, kinézetének
leírását tartalmazza egy-egy XML file-ban. Ebből is létezhet több, a különböző
képernyőfelbontásoknak megfelelően.
• menu könyvtár: Az alkalmazás tartalmazhat a menü gomb megnyomásának
hatására felugró menüt. Az ilyen menük kinézetét írják le az itt található XML file-
ok.
• values könyvtár: itt találhatóak az egyéb erőforrások, mint a strings.xml az
alkalmazásban található szövegek tárolására (akár string tömböt is!), HTML
alapon a formázására használható, a style.xml az alkalmazásban található
stílusok leírására, továbbá lehetséges egy külön XML file-ban primitíveket tárolni
az alkalmazás környezetének beállításához.
A fentebb felsorolt erőforrásokra az R osztályon keresztül lehet hivatkozni
(R.id.txtSzoveg például egy szövegmezőre hivatkozhat) vagy az XML file-okon belül
például egy gomb feliratának a layout könyvtár main.xml által leírt képernyő egy
gombjának a szövegét a következő hivatkozással lehet beállítani:
@strings/visszaGomb. Hasonló módon hivatkozhatunk egy képre is. Közös
jellemzője még ezeknek az erőforrásoknak, ha több képernyőfelbontást vagy több
nyelvet kezel az alkalmazás, akkor sem kell a hivatkozásokat megváltoztatni. A
rendszer gondoskodik a kiválasztásról. ( Például a felsorolt 3 drawable könyvtárban
ugyanazzal a névvel, de különböző méretben elmentett ikonok közül mindig az
éppen szükségeset választja ki ezzel a hivatkozással: @drawable/startIkon.)
5.3.4. AndroidManifest.xml
A címben szereplő file az alkalmazás lelke, a fő leírása itt található. Egy rövid
leírás róla a teljesség igénye nélkül, mivel nagyon sok dolgot lehet ebben a file-ban
beállítani az alkalmazással kapcsolatban. Ebben az állományban kell leírni, milyen
jogokat igényel a program (például írás jog az SD kártyára, érzékelők olvasása,
Bluetooth használata). Azt, hogy milyen verzión fut az alkalmazás, mely a minimális
esetleg cél verzió. Itt kell bejegyezni az alkalmazást alkotó Activity-ket, a hozzájuk
21
regisztrált Intent-eket. Ezzel azt is megadja, melyik Activity az alkalmazás első, indító
képernyője. A szolgáltatásokat, figyelőket is itt lehet bejegyezni.
5.4. Az összecsomagolt alkalmazás
Fordítás után a futtatható byte-kódok és az erőforrások egyetlen file-ban
kerülnek elhelyezésre, mint a Java nyelv esetén a *.jar file, csak az Android ezt *.apk
kiterjesztéssel látja el (Application Package). A *.apk file a *.jar file egy változata,
ugyanúgy zip tömörítési eljárást használ a csomag létrehozásához. Ezt a file-t kell a
telefon rendszerére telepíteni.
5.5. Fejlesztés
5.5.1. A fejlesztőkörnyezet
Az Android honlapjának ajánlását követve az Eclipse fejlesztőkörnyezetet
használtam az alkalmazás elkészítéséhez. Az Eclipse Indigo változata volt elérhető a
fejlesztés kezdetén.
Az Eclipse egy ingyenes és sokoldalú fejlesztőkörnyezet, amely több
programozási nyelvet is támogat. Telepíteni nem szükséges, különféle kiegészítőkkel
nagyon sok feladatra alkalmas.
Az Android támogatását is egy kiegészítő telepítésével lehet elérni, amelyet az
Android honlapján találhat meg a fejlesztő az Android SDK-val együtt, amely
szükséges az alkalmazások fejlesztéséhez. A kiegészítő teljes körű segítséget nyújt
az Android alkalmazások elkészítéséhez, beleértve a grafikus felhasználói felület
tervezését segítő grafikus szerkesztő modult. Utóbbi segítségével egyszerűen, fogd
és vidd módszerrel alakítható ki az alkalmazás felülete, az esetleges hibákat azonnal
láthatja a tervező. Persze elengedhetetlen kipróbálni az emulátoron vagy inkább egy
valós készüléken is.
A kiegészítő segítségével lehetővé válik az Android XML állományainak
felhasználóbarát szerkesztése, ennek ellenére időnként érdemesebb magát az
állományt „kézzel” szerkeszteni.
22
5.5.2. Az emulátor
Az Android SDK tartalmaz a készülő alkalmazások futtatásához egy emulátort,
amely nagy segítséget nyújt az fejlesztés idején. Virtuális gép, egy telefont
széleskörűen képes helyettesíteni kivéve néhány apróságot.
Bár az emulátorban akár szimulált telefonhívást lehet indítani és fogadni,
hálózati kapcsolatot létesíteni akár másik emulátorral is, néhány hiányossága is
akad. Nem támogatja többek között az érzékelők használatát (beépített
gyorsulásmérő, fényérzékelő, akkumulátor felügyelő), a Bluetooth kapcsolatot, több
érintést és hosszú érintést. Ezek nem létszükségletek, de az alkalmazás tényleges
kipróbálásához mégis szükséges egy valós készülék megléte, az emulátor leginkább
ellenőrzési, gyors kipróbálási célokat szolgál.
Az Eclipse DDMS (Dalvik Debug Monitor Server) nézetében az emulátorban
zajló folyamatok követhetők figyelemmel. Ekkor jelenik meg a programozáskor
nagyon hasznos konzol, amelyre a futó folyamatok írják az állapotüzeneteiket,
elérhető a virtuális SD kártya tartalma, a futó folyamatok és utóbbiak
monitorozhatóak is. Ebben a nézetben lehet GPS koordinátákat megadni a
rendszernek, telefonhívást szimulálni. A folyamatok monitorozása kiterjed a folyamat
futási idejének, memóriahasználatának jelzésére is.
5.5.3. Kiegészítő lehetőség – valós készülék használata
Mivel az emulátor korlátozott és igen lassú is, lehetőség van egy arra alkalmas
valós Android készülék használatára is. Ehhez csak a készülékhez szükséges
meghajtó programot kell telepíteni és csatlakoztatni a PC-hez és az SDK-nak
kijelölni, hogy a valós készüléket használja. Ekkor az emulátornál már megszokott
információk jelennek meg, gyorsabb működés mellett. Sajnos ezt a lehetőséget nem
volt alkalmam kipróbálni, az általam használt készülékhez nem készítettek erre
alkalmas meghajtó programot.
23
6. Kommunikáció a hardware-el
Az okos telefonok legelterjedtebb kapcsolata a külvilággal USB porton illetve
valamilyen rádiós kapcsolaton keresztül valósul meg. Az egészségügyi
állapotfelmérő rendszer követelménye szerint utóbbit kell figyelembe venni.
A GSM alapú rádiós kapcsolat mellett szinte alapvető a Bluetooth és a WiFi
jelenléte ezen eszközökben, bár utóbbi nem feltétlenül van jelen minden
készülékben. A mindkét rádiós technológia a 2,4GHz körüli frekvenciatartományt
használja, mégis a Bluetooth mellett döntöttünk főként az alacsonyabb
energiafogyasztása miatt.
6.1. Bluetooth – az intelligensebb eszközökért
AZ 1994-ben az Ericsson által megalkotott technológia a kis
elektronikai eszközök egységes kommunikációs felületévé vált.
Eredetileg az egyszerű RS-232 vagyis soros porton keresztüli
kommunikáció vezeték nélküli változatának készült. Mára, annyira
elterjedt kommunikációs szabvány lett, hogy szinte minden
elektronikai eszköz, amelynek szükséges más eszközzel kapcsolatot létesítenie
használja a Bluetooth kapcsolatot. Nevét angol fordításban Harold Bluetooth, X.
században élt dán királyról kapta, aki az akkori Dánia és Norvégia egy részét
egyesítette egyetlen birodalommá, a kékfogát pedig a folyamatos
áfonyafogyasztásának köszönhette. A Bluetooth logója a király nevének
kezdőbetűiből áll skandináv rúna jelekkel (ᚼ-Hagall ᛒ-Bjarkan).
A Bluetooth egyszerű, kis energiaigényű kapcsolatot biztosíthat egy
viszonylag egyszerű és egy bonyolultabb eszköz között. Ezzel az egyszerűbb eszköz
(és a bonyolultabb) lehetőségei is kibővülnek, összességében egy intelligens
rendszert alkotnak. Az állapotfelmérő rendszer esetén is hasonló a helyzet, amikor
az egyszerű mérő hardware a PC-re vagy telefonra küldi az adatot és fogadja az
utasításokat. A beépített, az egész rendszert jelentősen drágító, nagy teljesítményű
hardware-t igénylő megjelenítő és vezérlő modulok helyett egy már meglévő
rendszer (PC, telefon) részeként működik, amelyhez akár több, más hasonló kis
eszköz is kapcsolódhat.
24
6.1.1. Bluetooth az egészségügyben
Az ipari, kutatási és szórakoztató elektronikai eszközök mellett a Bluetooth
egyre inkább terjed az egészségügyi eszközök kommunikációs technológiájaként.
Alkalmazzák lázmérők, vérnyomás és mellkasra csatolható pulzus és légzésmérők
adatinak továbbításához. Ez kényelmet jelent a vizsgált személynek is, elég
elképzelni egy sportolót a futópadon tele vezetékekkel vagy egyetlen Bluetooth
modul segítségével csak az érzékelőkkel teleaggatva, amelyek bár saját áramforrást
igényelnek mégsem annyira zavaróak, mintha egy oldalra futó vezetékre/vezetékekre
kell figyelnie edzés, felmérés közben. A kis hatótáv és az interferencia elkerülésére
alkalmazott megoldások lehetővé teszik, hogy egy viszonylag kis térben sok eszköz
is használhassa különösebb zavarás nélkül a Bluetooth-t.
6.1.2. Jellemzői
A Bluetooth, a kis hatótávú ipari, tudomány és gyógyászati sávba tartozó
2,4GHz-es tartományban működik. 2,4-2,485GHz-es tartományban üzemel, 72
frekvencián, amelyek 1MHz-re találhatóak egymástól. Az interferenciát elkerülendő
ezeken a frekvenciák között másodpercenként 1600-szor vált adatátvitel során, ezt
osztott spektrumú frekvencia-ugrásnak nevezik. Full-Duplex kapcsolatot valósít meg.
Eredetileg GFSK (Gaussian Frequency Shift-Keying) modulációt használt, az újabb
verziók π/4 DQPSK (Differential Quadrature Phase Shift Keying) és 8DPSK
(Differential Phase Shift-Keying) séma szerint működnek. Az eredetit a
kapcsolatfelvételhez használja a rendszer az alap, 1Mbit/s-al valósul meg a
kapcsolatfelvétel.
Hatótávolsága és adóteljesítménye szerint 3 osztályba sorolják az egyes
eszközöket:
• Class 1: főleg az iparban alkalmazott 100mW-os adóteljesítménnyel, melyhez
100 méteres hatótáv párosul.
• Class 2: mobil eszközökben elterjedt 2,5mW teljesítmény és 10 méter hatótáv
jellemzi.
• Class 3: a legkisebb, 1 méteres hatótávú eszközök osztálya 1mW
adóteljesítménnyel.
25
Az átviteli sebességet tekintve az első, 1.0 verzió 1Mbit/s névleges
sebességre képes, 768kbit/s sebességet lehet valójában kihasználni. A 2.x verziók
3Mbit/s névleges és 2,1Mbit/s sebességre képesek. A következő 3.0 és 4.0 már
24Mbit/s névleges sebességen működik.
Léteznek különféle Bluetooth profilok, amelyek különféle kommunikációs
módokat írnak le az eszközök között. Egyik közülük az SPP vagyis Serial Port
Profile, amelyet a készülő műszer is alkalmaz a kommunikációhoz. Az SPP az RS-
232 portot bővíti vezeték nélküli kapcsolattá. Mivel az alkalmazott mikrovezérlő, az
Android rendszer és a Java is képes kezelni a soros portot kézenfekvőnek tűnt, hogy
ezt alkalmazzuk. Talán a legegyszerűbb kommunikációs forma. Másik elnevezése az
RFCOMM.
6.1.3. Az alkalmazott modul
A rendszerhez jelenleg a BTM-112 jelű Class 2-es Bluetooth modult
használjuk, több kapcsolódási felülettel rendelkezik, mint USB, SPI, UART. Ezek
közül az UART-on kapcsolódik a mérőrendszerhez, mely lehetővé teszi a kétirányú
adatáramlást is, ezáltal vezérelhető is a mérés.
Bár létezik az egészségügyi eszközök számára külön profil a Bluetooth
szabványban HDP (Health Device Profile), az új változat prototípusához szerelhető
méretben az egyszerűbb SPP-t támogató modult sikerült beszerezni. Az SPP-t ezen
felül biztosan támogatja a legtöbb mobil eszköz is.
6.2. A saját kommunikációs keret
A műszer és a feldolgozó egység közötti párbeszédhez létrehoztunk egy
keretet, amely az egyes utasításokat és a az adatokat továbbítja rendezett formában.
A keret kitalálója Ferenc István Csaba aki a hardware vezérlő programját készíti,
ebben a bekezdésben kerül ismertetésre maga a keret, amely a 10. ábrán látható.
10. ábra A kommunikációs keret
26
A keret két részből áll, egy fejrészből (Header) és egy adattérből (Payload). A
fejrész tartalmazza a keret kezdetének jelzését 1 byte-ban, melyet a keret típusának
kódja követ. A típusok listája a 11. ábrán látható. Az adattér adatküldés esetén
értelmezendő, 4 byte hosszúságú, amely az egyes mintavételezések eredményét
tartalmazza.
Csoport Jelentés C/Java konstans neve Érték Adat bájtok tartalma
cRT induljon START_CRT 231
sRT induljon START_SRT 232 Pletizm. ind. START_PLET 241 Tremor ind. START_TREM 251
cRT állj STOP_CRT 211 sRT állj STOP_SRT 212 Plet. állj STOP_PLET 214
Tremor állj STOP_TREM 215
üres PC → µC utasítások
PC oldali hiba PC_ERROR 1 hibakód
cRT elindult ACK_START_CRT 131
sRT elindult ACK_START_SRT 132 Plet. elindult ACK_START_PLET 141
µC → PC nyugták
Trem. elindult ACK_START_TREM 151
üres
Magas sípszó elh. BEEP_H 31
Mély sípszó elh. BEEP_L 32 üres
Gombnyomás BTN 33 reakcióidő [ms] Hibás gombnyomás BTN_ERR 34
Időtúllépés TIMEOUT 35 üres
Pletizmográfia adat PLET 41 érték [0,216] (fs=250Hz) X tremor adat TREM_X 51 érték [előjeles 16 bites] (fs=250Hz) Y tremor adat TREM_Y 52 érték [előjeles 16 bites] (fs=250Hz) Z tremor adat TREM_Z 53 érték [előjeles 16 bites] (fs=250Hz)
µC → PC adatok
µC oldali hiba UC_ERROR 2 hibakód 11. ábra A keret típusai (µC – mikrovezérlő)
A táblázatból látható, hogy az a keret tekinthető érvényes keretnek, amely a
szinkronjelzéssel kezdődik, majd valamely típussal folytatódik, a típus fogja
eldönteni, hogy az adatmezőt csak megvárni kell vagy értelmezni is.
Egy keret egyszerre két adatot továbbít egy típusból, amely lehet a valamely
reakcióidő mérés (cRT, sRT), szívgörbe (Pletizmográfia) vagy a gyorsulásmérő adata
(tremor). Szükséges, hogy a mérőegység is közölje az állapotát, ezzel ellenőrizhető,
hogy rendben végbe ment-e a kívánt mérés elindítása, illetve, ha bármi hiba adódik,
azt szövegesen a feldolgozó alkalmazás közli a felhasználóval. Ilyen például az
akkumulátor töltöttsége, hibás érzékelő. A keret üresnek nevezett adatterét nem kell
27
a feldolgozó alkalmazásnak értelmezni, ott akármilyen adat is állhat, jelen esetben 1-
es értékekkel töltöttük fel.
6.3. Az adatok fogadása
A fentebb ismertetett Bluetooth kapcsolatot használja a mobil alkalmazás az
adatok fogadására. Az Android kényelmes lehetőséget kínál a kapcsolat
létrehozására, beállítására és kezelésére. Egyszerűen megoldható, hogy az
alkalmazás egy keresés után magától kapcsolódjon a mérőeszközhöz.
Az adatok a felderítés és kapcsolódás után a Java-ban jól ismert InputStream
osztály példányán keresztül egy byte-folyamként olvasható. Az alkalmazás gyűjti a
beérkezett adatokat, az első keretszinkrontól átmeneti tárolóba helyezi a byte-okat
majd keretként értelmezi. Az érvénytelen keretet eldobja, ha 5-nél több keret hibás,
jelzi a felhasználónak.
6.4. Utasítások küldése
Az Android az adatküldésre az InputStream párját, az OutputStream osztályt
használja a Bluetooth kapcsolatnál. Egyszerűen byte-onként lehet az adatfolyamba
írni a keretet. Az egyes utasítások elküldése után az alkalmazás vár a mérő
hardware által küldött nyugtára, amennyiben 2 másodpercen belül nem érkezik
nyugta az alkalmazás hibát jelez.
28
7. Adattárolás
7.1. Lehetőségek az Android rendszerben
Az Android több különféle lehetőségeket kínál az adatok tárolására, két fő
felhasználható tárolóval rendelkezik: az eszköz belső memóriája és az SD kártya,
amely a bővíthető külső tároló.
A belső memóriát a rendszer elrejti a felhasználó elől, a file rendszer tallózása
a beépített böngészővel is az SD kártyára korlátozódik. (Léteznek az Android
Market-en olyan alkalmazások, amelyek képesek a teljes file rendszer tallózására, de
ezek jelenlétére a céleszközökön nem lehet építeni.) USB-re csatlakozáskor is az SD
kártya tartalma kezelhető, olyan egyszerűen, mintha egy pendrive-ot csatlakoztattak
volna a PC-hez.
7.1.1. Belső adatbázis – SQLite
Az alkalmazásoknak lehetősége nyílik a saját adataikat az SQLite
segítségével egy relációs adatbázisban tárolni. Használata megegyezik egy SQL
adatbázis használatával. Maga az adatbázis a mobil készülék belső memóriáját
használja.
Az állapotfelmérő rendszernél az átmeneti adatok tárolásánál szóba került ez
a lehetőség, azonban az adatállományok esetleges nagy mérete miatt (egy órás
vizsgálat akár 5-10 MB adatot is jelenthet) elvetettem az ötletet. Ugyanis a belső
memória főleg az alacsonyabb kategóriába tartozó készülékeknél néhány száz MB-
ot tesz ki, amelyen helyet kapnak a telepített programok és azok által használt
esetlegesen az adatbázisban lévő adatok is. Tehát előfordulhat, hogy olyan sok
program kerül telepítésre, hogy már nincs hely egy vizsgálat adatai számára.
Az itt tárolt adatok legkésőbb az alkalmazás törlésével automatikusan
törlődnek.
7.1.2. A rendszer saját cache lehetősége
Az alkalmazásoknak lehetősége van az SD kártyán is tárolni a saját adataikat
egy adott helyen. A hely elérési útvonala az alkalmazás Java nyelven megadott
29
csomagnak felel meg az Android/data könyvtáron belül (például, ha az
alkalmazás a com.example.program csomagban található, akkor az
Android/data/Com.example.program könyvtárat lehet használni).
A könyvtárat beépített metódussal lehet létrehozni. Ez a metódus és
használata az Android 2.2-től eltér az alacsonyabb verzióktól.
Az ezen a helyen tárolt adatokat a rendszer számon tartja, az alkalmazás
tulajdonságait lekérve jelzi, mennyi átmeneti tárolót használ, a program törlésével
üríti a felhasznált területet is, mivel törli az alkalmazáshoz tartozó könyvtárat.
7.1.3. Saját mappa létrehozása
Elterjedt módszer és talán a legegyszerűbb, (több, általam is kipróbált Android
alkalmazás él ezzel a megoldással), hogy létrehoz az SD kártyán egy könyvtárat és
abban helyezi el a működése közben szükséges átmeneti file-okat. Ennek jellemzője,
hogy a program törlése után is megmarad, illetve a cache ürítésekor a rendszer nem
törli.
A file-okat olyan beállítással is létre lehet hozni, hogy az alkalmazáshoz
tartozó virtuális gép bezárásakor (tehát a alkalmazás normális leállításakor) a file
törlődjön, ellenkező esetben nem (vagyis, ha egy telefonhívás tette háttérbe az
alkalmazást vagy valamiért nem rendesen állt le).
7.2. Átmeneti file-ok
A mobil alkalmazáshoz a 7.1.3-as pontban leírt lehetőséget választottam. Az
indításkor egy folyamat ellenőrzi az SD kártya meglétét, ha nincs csatolva, akkor a
program leáll, mert anélkül nem érdemes működnie. Ha van SD kártya, akkor
ellenőrzi a Tremometer könyvtár és alkönyvtárainak a meglétét, ha nincs, akkor
létrehozza a Tremometer könyvtárat és azon belül egy temp könyvtárat. A
Tremometer könyvtáron belül találhatóak a lezárt mérések és a temp könyvtárban a
mérések átmeneti adatai vagy a megnyitott mérésekből készült átmeneti file-ok.
Mivel az SD kártya használatával lehetőség van az alkalmazás memóriahasználatát
csökkenteni. Ismert módszer Android rendszer esetén, hogy a készülék esetenként
szűkös memóriakészletét úgy növelik, hogy az SD kártya egy részét is RAM-ként
30
használja a rendszer. Jelen esetben ez azt jelenti, hogy az átmeneti file-okból mindig
csak a szükséges adatmennyiséget olvassa be a készülő alkalmazás.
Az alkalmazás a szükséges adatállományokat egyedi névvel látja el, hogy a
már meglévőt ne írja felül, egyszerű sorszámozással. Egy külön osztály tartja
számon, hogy az adott állományok melyik személyhez tartoznak.
7.2.1. Mérés közben
Mérés alatt az alkalmazás a pletizmográf és tremor mérések eredményeit 4
bináris átmeneti file-ba menti folyamatosan (a pletizmográfia egy adatállományt
igényel a tremor vizsgálat a gyorsulásmérő 3 tengelyének adatait 3 állományba
menti).
A reakcióidő mérés nem jelent túl nagy adatmennyiséget, az adatvesztés
elkerülése végett ezt is külön átmeneti file-ba menti az alkalmazás. Minden
gombnyomáshoz tartozó értékeket külön-külön sorban helyezkednek el.
7.2.2. Egy vizsgálat megnyitásakor
Egy mérés állományai kis átalakítást követően egyetlen zip file-ba kerülnek,
ennek megnyitásakor szintén létrejönnek az átmeneti állományok, mint méréskor.
Ezeken végezhető el néhány művelet, így az eredeti adatok véletlen
megváltoztatását is el lehet kerülni.
7.3. Egy vizsgálat mentése
Az Android alkalmazás és a PC-s programnak közös állományt kell
használnia, hogy bármelyiken készített, szerkesztett mérést a másikon is meg
lehessen jeleníteni. Ezért a feladat e része igényelte a legfőbb csapatmunkát a PC-s
program készítőjével, Simon Csabával.
7.3.1. Az adatállomány
Az adatállomány a *.jar vagy *.apk file-ok mintájára egy több file-t tartalmazó
zip eljárással tömörített állomány. Tartalmaz egy XML file-t, amely a vizsgált alany
személyes adatait tartalmazza RSA kódolással és egy másik XML állomány kódolás
nélkül a reakcióidő mérés adatait. Továbbá több bináris állományt, amely az egyes
31
mérésekhez tartoznak, lényegében az átmeneti állományokat másolja ide az
alkalmazás, így nem szükséges külön átalakítás és visszaalakítás, amely csak
lassítaná a folyamatot. Az mérés eredményeit nem titkosítjuk, mert csak azokból
nem lehet kitalálni, hogy kihez tartoznak.
7.4. Az adatállomány szerkezete
Az alkalmazás által épített zip eljárással tömörített adatállomány több belső
állományban tartalmazza a szükséges információkat, a következő szakaszokban
ezek szerepe, felépítése kerül bemutatásra.
7.4.1. A vizsgált személy adatai
A szemelyesAdatok nevű XML állomány tartalmazza a vizsgált személyhez
tartozó legfontosabb információkat. Az állomány felépítését a 12. ábra szemlélteti.
Ilyen a neve, címe (város, utca, házszám), születési dátuma és a TAJ száma. Ezek
az adatok RSA titkosítással kerülnek elrejtésre az illetéktelenek szeme elől, csak az
tudja, kiről készült a vizsgálat, aki rendelkezik a mobil vagy a PC-s kiértékelő
alkalmazással.
<?xml version="1.0" encoding="UTF-8"?>
<tremometer>
<patient>
<name>Név</name>
<TAJ>111111111</TAJ>
<birthdate>1900-01-01</birthdate>
<city>Város</city>
<street>Utca</street>
<number>00</number> <!--nem csak szám lehet -->
</patient>
<comments>
<comment id="0" priority="1" from="0" to="0"
meastype="plet">Megjegyzés</comment>
<!--id: a megjegyzés azonosítója, 0 azonosító a leletet jelöli, a további
tulajdonságok figyelmen kívül hagyhatóak.
priority: fontosság 0,1,2
from: adatállományban kezdőpont, egész szám
to: adatállományban végpont, egész szám
meastype: melyik adatállományhoz tartozik a megjegyzés, szöveg-->
</comments>
</tremometer>
12. ábra szemelyesAdatok szerkezete
32
Ez az állomány tartalmazza a adatokhoz fűzött megjegyzéseket is szintén
RSA kódolással. A megjegyzések tag-ek tulajdonságai tartalmazzák, hogy mely
adatsorhoz és azon belül melyik szakaszhoz tartozik. Az egyes megjegyzések
elláthatók fontossági jelzővel, mely egy egész szám és a 0 a kevésbé fontos a 2
pedig a nagyon fontos megjegyzéseket jelöli. A tag-en belül található a megjegyzés
szövege, amely kódolt.
A megjegyzések közül az első kitüntetett szereppel rendelkezik, ez a lelet
vagy összegzés a vizsgált személy állapotáról. Ez a megjegyzés nem tartozik
egyetlen adatsorhoz sem.
7.4.2. Az állományhoz fűzött megjegyzés
Egy Comment nevű állomány tartalmazza a vizsgálat körülményeit, időpontját
és bármilyen kiegészítést, amely megkönnyíti, hogy az adott személyhez tartozó
méréseket el lehessen különíteni, azonosítani. Szintén kódolt szöveget tartalmaz az
állomány.
7.4.3. Reakcióidő
A reakcióidő mérés eredményeit egy külön RT nevű XML állomány tárolja. Az
egyes tag-ek tulajdonságai rögzítik a reakcióidő mérés típusát (sRT, cRT), a
beérkezett jeleket és az azokra érkezett reakciót. Tárolja azt is, ha a vizsgált személy
nem a célingerre reagált vagy csak megnyomta a gombot cél vagy zavaró inger
nélkül is. Ez az állomány nem kerül titkosításra, mivel nem azonosítható az adatok
alapján, hogy kivel készült a vizsgálat.
<?xml version="1.0" encoding="UTF-8"?>
<tremometer>
<rt id="32" type="SRT" event="BEEP_H" rtime="300" />
<!--
id: az esemény sorszáma, egész típus
type: CRT vagy SRT
event: a keretnek megfelelően: BEEP_H, BEEP_L,
BTN, BTN_ERR, TIMEOUT szöveg
rtime: a reakció ideje ms-ban, pozitív egész szám.
-->
</tremometer>
13. ábra Az RT állomány szerkezete
33
7.4.4. A bináris adatok helye
A pletizmográfia eredményeit a plet, és a tremor vizsgálat gyorsulásmérője
által közvetített, három jelfolyam adatait az irányoknak megfelelően a trem_x,
trem_y, trem_z nevű állományok tárolják binárisan. Egy-egy adat 4 byte hosszú
bináris szám.
34
8. Felhasználói felület
A felhasználói felület tervezése egy egészen fiatal és új irányát kell
megismerni, mégpedig egy érintéssel vezérelt felület kialakítása a feladat. Némileg
hasonlít az egér és billentyűzet által vezérelt rendszerekre, mégis sok új lehetőség
rejtőzik benne. Azoknak a tervezőknek, akik a hosszú idő alatt bejáratott rendszerhez
szoktak, sokszor furcsa és nehézkes ennek az új iránynak a használata,
kihasználása. Saját tapasztalat, hogy a fejlesztésre szánt telefon használatát
megtanulni néhány hétbe telt, utána értettem csak meg miben kell másként
gondolkodni, a hagyományos alkalmazásokhoz képest. Annak ellenére, hogy nem
tudhatok magam mögött több száz programfelületet, mint sok hivatásos és tapasztalt
fejlesztő a kész programok használata nyomán megtanultam nagyjából milyen a
kényelmes felhasználói felület és melyik az, amit borzalmas használni. Nem
egyértelmű az sem, mi a kényelmes és mi nem, például egér használata esetén, egy
PC monitorán szinte mindegy hol van a gördítő sáv, de ha a számítógépet balkezes
embernek egy tollal kell vezérelni, a rendszeresen jobb oldalra helyezett gördítő
sávok inkább bosszantóak, mint hasznosak…
8.1. Az Android képernyő
Az Android más rendszerekhez hasonlóan,
egy keretrendszert nyújt a grafikus felület
kialakításához. A lehetőségeket tekintve
különféle elrendezés kezelőket, esemény
figyelőket és vezérlő elemek széles palettája áll
rendelkezésre a felület tervezéséhez, ha
mégsem elég, akkor a tervező saját magának is
létrehozhat új képernyőelemet valamely meglévő
osztályának leszármaztatásával.
Az 14. ábrán látható egy képernyőkép az
Android rendszerről. Az emulátoron található
változat alapképernyője. A képen legfelül
14. ábra Az alap képernyő az emulátoron
35
helyezkedik el az állapotsáv. Ez tartalmazza a szolgáltatások ikonjait, szöveges
üzeneteit. Ilyen például az óra, akku töltöttség jelzés, hálózat jelszintje és típusa. Ezt
az állapotsávot lehúzva részletezi a program milyen éppen futó szolgáltatások
érhetőek el, különféle állapotüzenetek listája (USB tároló csatlakoztatva, új
alkalmazás települt és innen azonnal el is indítható).
A képernyő nagy részét az ikonok és úgynevezett widget-ek számára
fenntartott hely foglalja el, amelyet egy felhasználó által választott háttérkép díszít.
Az emulátoron a telepített alkalmazások listáját a legalsó szürke nyíl felfelé
húzásával lehet elérni.
A főképernyőre és az alkalmazások listájára is érvényes, hogy lapozható vagy
gördíthető, bár a főképernyőből nagyrészt lapozható változat létezik.
A haza gomb bárhonnan azonnal a főképernyőre viszi a felhasználót, ha az
adott alkalmazás készítője másként nem rendelkezett.
8.2. Android gombok – fizikai vezérlő elemek
Az Android rendszert futtató készülékeken általában 4 gombot lehet találni,
esetleg kiegészítik hangerőszabályzó gombokkal és fényképező gombbal.
A 4 gomb közül az egyik, a haza gomb, amely bárhonnan a főképernyőhöz
lép, az éppen megnyitott alkalmazás háttérbe, leállított állapotba kerül, ha
szolgáltatás, akkor csak a háttérbe. Hosszan lenyomva tartva a legutóbb használt
hat alkalmazás közül lehet választani.
A másik a vissza gomb. Ismerős lehet a böngésző programokból, szerepe is
hasonló, mindig az előző képernyőre lép vissza.
Következő a menü gomb, amely hatására bármely alkalmazás, amely reagál
erre a gombra előhoz egy menüt. Általában ez a képernyő aljáról úszik fel, de akár
egy párbeszédablak-szerű menü is lehet. Az alapértelmezett menü 6 menüpontot
tartalmaz, ha azonban hatnál több menüpontot tartalmaz a menü, akkor a hatodik
pont egy továbbiak menüpont lesz. A továbbiakra bökve egy lista jelenik meg a
további menüpontokkal. Az egyes menüpontok ikonokkal díszíthetők.
Végül a keresés gomb, amely sok készülékről lemarad, de mégis lehet
hasznos is. Hatására vagy az alapértelmezett kereső vagy az alkalmazás saját
36
keresője jön elő (ha a programozó készített ilyet az alkalmazásba, ha nem akkor
általában a Google keresője bukkan elő).
8.3. A készülő alkalmazás képernyői
Az alkalmazás működését a főbb képernyők segítségével mutatom be.
8.3.1. Vizsgálat
Az alkalmazás elindítását követően a 15.
ábrán látható képernyő fogadja a felhasználót. A
vezérlő gombok a PC-s alkalmazáshoz
igazítottan kaptak ikonokat. A gombok közül
mindig az aktív, amelyet használhat a
felhasználó, ezért kezdetben csak az
adatrögzítés gomb elérhető.
Az adatrögzítés gomb hatására elindul a
kiválasztott vizsgálat, ha még nem csatlakozott a
felhasználó a mérőegységhez, ezt megteheti a
felugró párbeszédablakban (külön jelzi, ha nincs
elérhető Bluetooth kapcsolat), majd az elvégezni
kívánt vizsgálatokat kell kiválasztania.
A vizsgálat szüneteltetését is kérheti a
felhasználó, például akkor, ha meg kell igazítani
a vizsgált személyen a készüléket.
A stop gomb segítségével fejezi be a
vizsgálatot és mentheti el az adatokat.
A vizsgált személy adatait a vizsgálat ideje
alatt egy párbeszédablakban veheti fel a felhasználó.
A gombok alatt a grafikonok láthatók. Az első a pletizmográf adatait jeleníti
meg, a második a tremoron végzett FFT analízis eredményét az utolsó pedig a
reakcióidő-mérés eredményeit. Utóbbinál lehetőség van választani sRT és cRT mód
között (egyszerű vagy feltételes reakció idő).
15. ábra A vizsgálat képernyője éppen megállított szimulált mintavételezéssel, látható menüvel, kikapcsolt Plet vezérlővel és láthatóvá tett nagyító gombbal a tremor grafikonon. (Az emulátor megjelenítési hibája miatt nem látszik a grafikon teteje.)
37
A grafikonok érintésére eltűnnek a vezérlő elemek, hogy ne zavarják a jelek
figyelemmel kísérését, újabb érintésre láthatóak lesznek. A grafikonok simításra
gördülnek a simítás irányának megfelelően. A pozíciót gördítésnél a grafikon tetején
megjelenő sáv jelzi. A nagyítás, kicsinyítés lehetőségét biztosító vezérlő is érintésre
jelenik, meg majd tűnik el.
A grafikonok kirajzolását egy háttérszál végzi. A mérés háttérszolgáltatásként
fut, így egy telefonhívás sem szakíthatja meg az vizsgálatot.
A vizsgálatot segíti egy külön bekapcsolható időzítő, amely rezgéssel és a
képernyőre írt üzenettel tájékoztatja a vizsgáló és a vizsgált személyt a következő
teendőkről. Vizsgálat közbeni súgóként üzemel. Az utasítások megjelenítésére a
Toast nevű osztályt használtam.
A menü elemei fentről kezdve és balról jobbra haladva: új személy felvétele,
mentett mérés megnyitása, mérés mentése, kapcsolódás Bluetooth-on keresztül egy
mérőegységhez, vizsgálatot segítő időzített súgó.
8.3.2. Adatfelvitel párbeszédnézet
A vizsgált személy adatait akár a mérés
közben is fel lehet vinni. Ezt szolgálja a 16. ábrán
látható űrlap. A szöveget váró mezők érintése
esetén a rendszer szolgáltatásaként
szövegbevitelre alkalmas billentyűzet jelenik
meg, számmező esetén (TAJ) számbillentyűzet
jelenik meg, a hónapokat pedig egy, a hónapok
neveit tartalmazó billentyűzet áll a felhasználó
segítségére. A mentés gombra bökve az adatok
mentésre kerülnek, újbóli megnyitás esetén a
már kitöltött mezők kitöltve jelennek meg.
Felülírásuk az adott rész felülírását eredményezi
(csak akkor, ha tényelegesen írnak is bele,
véletlen érintéskor nem törlődik az adat).
A bevitelt a rendszer által nyújtott
úgynevezett HintText segíti, amely beírásig jelzi, 16. ábra Az adatfelvitel űrlap teteje. Az emulátor angol beállításainak megfelelően rendezi a rendszer a dátum mezőit.
38
hogy mit kell az adott mezőbe írni az ábrán ilyen például a „Vezetéknév Keresztnév”
szöveg.
A teljes űrlap nem fér ki a képernyőre, a Lelet és a vezérlőgombokhoz ilyen kis
képernyőn a felhasználónak egy egyszerű mozdulattal kell gördítenie a további
elemek eléréséhez.
8.3.3. Megnyitás párbeszédnézet
Az alkalmazás a saját könyvtárában található mentett méréseket egy
párbeszédablakban listázza. A kiválasztott személy adatai kirajzolódnak a
grafikonokra, ekkor az adatgyűjtést vezérlő gombok eltűnnek.
8.3.4. Bluetooth párbeszédnézet
A Bluetooth kapcsolat a mérés kezdetekor vagy bármikor a menüből
választható. A megtalált mérőegységeket listába foglalja az alkalmazás, a
kiválasztotthoz kapcsolódik. Jelvesztés esetén megpróbál önállóan újracsatlakozni a
már kiválasztott mérőegységhez, ha az újra hatókörön belül van. A jelvesztést
természetesen jelzi a felhasználónak, addig az adatgyűjtés is leáll.
39
9. Fejlesztési tervek
Az alkalmazás ezen leírása csak egy pillanatkép a fejlesztés folyamatából.
Ahogy a hardware-k is egyre fejlettebbek, egyre több hasznos szolgáltatást lehet
elhelyezni a mobil alkalmazásban. A lehetőségek sora szinte végtelen, azonban meg
kell találni azokat, amelyek ténylegesen segítik a mobilizált mérést. Bár a jelenlegi
alkalmazás sem aknázza még ki a fejlesztésre használt készülék nyújtotta
lehetőségeket.
Bár jelenleg az országban nem üzemel egységes egészségügyi adatkezelő
rendszer, a jövőben egy ilyen hálózathoz is csatlakozhat ez az állapotfelmérő
rendszer. Esetleg ennek a rendszernek egy saját adatbázis létrehozható, ahová a
lezárult vizsgálatok adatait az orvos feltöltheti, ahol szakemberek illetve egy
automata rendszer elemezheti, összevetheti az adatokat a régebbi esetleg más
vizsgálatokkal. Az eredményeket pedig kérésre visszaküldheti a vizsgálatot végző
orvosnak. Egyfajta felhő szolgáltatásként működhet a rendszer. További haszna,
hogy a mobilinternet segítségével bárhol elérhetővé válik az orvosok az éppen
vizsgált beteg kórelőzménye. Egy ilyen rendszer nem csak az állapotfelmérő
készülék számára lenne előnyös, hanem általában az egészségügyben is, ugyanis
jelenleg szinte minden kórház és rendelőintézet saját, egymástól független, sokszor
elavult, zárt rendszert használ, így ha valakit a szokott intézetétől távol szükséges
gyógyítani, vagy önmaga mondja el a kórelőzményét vagy az ellátó orvos kénytelen
nyomozni.
További lehetőség az is, ha egy mobilszolgáltató támogatni kezdi ezt az
egészségügyi állapotfelmérő rendszert. Elképzelhető egy célirányosan erre a
rendszerre létrehozott díjcsomag, egy korszerű készülékkel, amelyen megtalálható
az állapotfelmérő rendszer is előre telepítve, hogy a felhasználónak már ne kelljen
bajlódni vele. Ehhez további szükséges fejlesztés az önmagát frissítő mobil
alkalmazás. Az egészségügyi rendszereket támogatja például a Telenor, a Telenor
Connexion elnevezésű program keretében.
40
10. Összefoglalás
Egy egészségügyi állapotfelmérő rendszer tervének megvalósítására alakult a
Miskolci Egyetem mérnök informatikus és villamosmérnök hallgatóiból egy néhány
fős csapat, hogy a prototípusból sorozatgyártásra alkalmas, olcsó és az orvosok által
széles körben hozzáférhető eszközt tervezzen.
A rendszer egyszerű vizsgálatok segítségével (pletizmográfia, tremor analízis
és egyszerű vagy feltételes reakcióidő-mérés) képes több idegrendszeri és keringési
és időskori betegséget eredményesen előre jelezni. Ugyan nem helyettesíti a drága
és precíz mérőberendezéseket, csupán egy gyors és eredményes előszűrésre
alkalmazható, amely megadja, hogy szükséges-e a további vizsgálat vagy sem. A
vizsgálat elvégzése után még időben elkezdhető a felismert probléma kezelése, így
javítható az emberek jövőbeli életminősége.
Mivel a rendszer tervezése egy embernek túl nagy feladatot jelentett volna,
több részre osztottuk. A felosztás szerint külön feladattá vált a mérőegység és annak
a firmware-ének elkészítése, másik feladat az asztali számítógépre egy adatgyűjtő,
kiértékelő és egyszerű adatbázis-kezelést megvalósító program és az általam vállalt,
mobil készülékek számára Android operációs rendszerre készített adatgyűjtő és
megjelenítő alkalmazás készítése.
A jelen kor rohamosan fejlődő készülékei, az okos telefonok lehetővé tették,
hogy a mérőegység egyszerű kivitelű, könnyen hordozható és külön asztali
számítógép vagy laptop jelenléte nélkül is szinte bárhol bevethető legyen. Magának
a mérőegységnek nincs saját kezelőszerve, külön belső adattárolója. A vezérlést és
az adattárolást, adatok grafikus megjelenítését az okos telefon végzi, az
információcsere a kiselektronikai eszközök körében elterjedt Bluetooth kapcsolaton
keresztül történik. A kisméretű mérőegység és az elterjedt, naponta használt
telefonok segítségével az orvosi táska kellékévé válhat az állapotfelmérő készülék.
A telefonra készített adatgyűjtő és megjelenítő alkalmazás képes néhány
gyors elemzés elvégzésére és lehetővé teszi rövid jegyzet készítését a vizsgált
személy adatainak rögzítése mellett. A vizsgálatok eredményeit aztán az orvosok az
asztali számítógépekre készített program segítségével tovább elemezhetik,
összevethetik régebbi vagy más eredményekkel is.
41
11. Köszönet
Köszönet illeti a dolgozatban felsorolt személyeket, hogy a feltaláló Dr.
Kellényi Lóránd a Miskolci Egyetemet bízta meg a Bay Zoltán Alkalmazott Kutatási
Közalapítvány Nanotechnológiai Kutatóintézetének akkori igazgatóján, Dr. Pungor
Andráson keresztül, aki értesítette Dr. Gáti Attila egyetemi docenst az ipari feladatról.
Dr. Gáti Attila élt a lehetőséggel és hallgatókat toborzott, akik számára a feladatból
remek szakdolgozat és TDK téma válhat, amely eltér a szokásos feladatoktól és
kézzel fogható eredményhez vezet. A valós volta miatt sokkal érdekesebb, mint egy
általános szakdolgozati téma, mely talán egy fiók mélyén végzi. A feladat megoldása
alatt kiváló szakmai irányításával és támogatásával segítette a lelkes hallgatók
munkáját. Akkor, 2009 januárjában engem Fodor Gábor Dénes hallgatótársam hívott
fel, hogy volna-e kedvem egy kutatási feladathoz. Szerencsére igennel válaszoltam,
mint a csapat másik tagja Ferenc István Csaba. Szintén a csapat tagja, bár csak idén
csatlakozott a PC-s program fejlesztéséhez, Simon Csaba. A nullszéria tervezésénél
és gyártásánál a csapat tagja volt Tóth Gábor villamosmérnök hallgató is, aki sokat
segített a tervezésben és kivitelezésben. Köszönet illeti Dr. Zambóné Benkő Máriát,
aki vezette és erőforrásokat biztosított a feladat megoldásához. Továbbá az
Elektrotechnikai és Elektronikai Tanszék dolgozóit és a tanszék vezetőjét, akik
megengedték, hogy használjuk az V. labort a munkánk során.
A feladatot belátható időn belül egyedül egyikünk sem tudta volna elvégezni,
egyértelműen több ember összehangolt munkáját kívánó feladatot kaptunk és
értékes útravalót az életünk további állomásaira.
42
Források
• Dr. Kellényi Lóránd által rendelkezésünkre bocsájtott dokumentumok
• Simple and choice reaction times are prolonged following extracorporeal circulation: A potential method for the assessment of acute neurocognitive deficit, © Med Sci Monit, 2009; 15(9): CR470-476, PMID: 19721398
• Dr. Norbert Kovács Electrophysiological investigations in neurosorgically treated movement disorders, Ph.D. thesis, University of Pécs, 2008
• Kovács Norbert, Balás István, Illés Zsolt, Kellényi Lóránt, Nagy Ferenc: A tremorometria szerepe az ablatív műtétek eredményességének előrejelzésében, Ideggyogy Sz 2006;59(11–12):438–440
• www.android.com
• http://developer.android.com
• http://developer.apple.com
• http://nyelvek.inf.elte.hu/leirasok/MOBIL_J2ME/index.php?chapter=2
• http://create.msdn.com/en-us/home/getting_started
• www.bluetooth.com
• http://en.wikipedia.org/wiki/File:Smartphone_share_current.png
• http://www.oracle.com/technetwork/java/javame/java-me-overview-402920.html
• http://www.hazipatika.com/articles/iPhone_uj_diagnosztikai_eszkoz_az_orvosok_kezeben?aid=20101026162213
• http://www.telenor.hu/uzleti-megoldas/m2m/telenor-connexion/egeszsegugy/
• http://www.youtube.com/user/androiddevelopers
• Nyékyné Dr. Gaizler Judit: Java 2 útikalauz programozóknak 5.0 I-II. (2009) ISBN: 9789630640923
Hivatkozások ellenőrizve: 2011-11-07.
