Bachelor thesis: Design of aplication for monitoring physical activity

SLOVENSKÁ TECHNICKÁ UNIVERZITA V BRATISLAVE
FAKULTA ELEKTROTECHNIKY A INFORMATIKY
Evidenčné číslo: FEI-5382-6041
NÁVRH APLIKÁCIE NA MONITOROVANIE
FYZICKEJ AKTIVITY
BAKALÁRSKA PRÁCA
2014 Erich Stark

Evidenčné číslo: FEI-5382-6041
NÁVRH APLIKÁCIE NA MONITOROVANIE
FYZICKEJ AKTIVITY
BAKALÁRSKA PRÁCA
Študijný program: Aplikovaná informatika
Číslo študijného odboru: 2511
Názov študijného odboru: 9.2.9 Aplikovaná informatika
Školiace pracovisko: Ústav informatiky a matematiky
Vedúci záverečnej práce: Ing. Fedor Lehocki, PhD.
Bratislava 2014 Erich Stark

SÚHRN
Študijný program: Aplikovaná informatika
Autor: Erich Stark
Bakalárska práca:
Návrh aplikácie na monitorovanie fyzickej ak-
tivity
Vedúci záverečnej práce: Ing. Fedor Lehocki, PhD.
Miesto a rok predloženia práce: Bratislava 2014
Bakalárska práca sa zaoberá využitím zdravotníckej pomôcky v oblasti telemedicíny a
vytvorením Android aplikácie. Úvod práce je venovaný základným informáciám o eHealth,
telemedicíne a o chronickom ochorení diabetes. Tiež je v úvode spomenutý aj vplyv fyz-
ickej aktivity na zdravotný stav pacienta s diagnózou diabetes mellitus. Pre tieto účely
som dostal krokomer od vedúceho práce, pomocou ktorého sa zaznamenáva denná fyz-
ická aktivita. Dáta z krokomeru sa odosielajú do cloudu iHealth a odtiaľ je ich možné
získať pomocou oAuth2 autentiﬁkácie do mobilného zariadenia s Android systémom. V
implementačnej časti, na základe prijímaných dát bola vytvorená štruktúra databázy
cez SQLite. Ďalšia sekcia sa venuje zobrazovaniu nameraných hodnôt v grafe pomocou
AChartEngine. Posledná časť je venovaná vzhľadu Android aplikácie.
Kľúčové slová: android, ehealth, telemedicína, aplikácia, oauth2, ihealth, krokomer, sqlite,
json, java

ABSTRACTÚ
SLOVAK UNIVERSITY OF TECHNOLOGY IN BRATISLAVA
FACULTY OF ELECTRICAL ENGINEERING AND INFORMATION TECHNOLOGY
Study Programme: Applied Informatics
Author: Erich Stark
Bachelor Thesis:
Design of aplication for monitoring physical
activity
Supervisor: Ing. Fedor Lehocki, PhD.
Place and year of submission: Bratislava 2014
The aim of this bachelor thesis is usage of medical device in telemedicine and development
application on Android platform. In the ﬁrst part are explained the basic informations
about eHealth, telemedicine and chronic disease diabetes. In addition thesis mentions
also impact of physical activity on the health of the patient diagnosed with diabetes mel-
litus. For this purpose I received pedometer from my supervisor which was used for daily
recording of physical activity. Data from this pedometer are sent to the iHealth cloud and
from there they can be obtained via OAuth 2.0 authentication to my mobile device with
Android operating system. In the implementation section, based on the received data a
SQLite database structure was created. Next section of bachelor is devoted to display
measurement values to chart with usage of AChartEngine. Final section explores the user
interface of developed Android application.
Keywords: android, ehealth, telemedicine, application, oauth2, ihealth, pedometer, sqlite,
json, java

Vyhlásenie autora
Podpísaný Erich Stark čestne vyhlasujem, že som bakalársku prácu Návrh aplikácie
na monitorovanie fyzickej aktivity vypracoval na základe poznatkov získaných počas štú-
dia a informácií z dostupnej literatúry uvedenej v práci.
Uvedenú prácu som vypracoval pod vedením Ing. Fedor Lehocki, PhD..
Bratislava, dňa 12.6.2014
............................................
podpis autora

Poďakovanie
Chcem sa poďakovať vedúcemu záverečnej práce, ktorým bol Ing. Fedor Lehocki,
PhD., za odborné vedenie, rady a pripomienky, ktoré mi pomohli pri vypracovaní tejto
bakalárskej práce.

Obsah
Úvod 1
1 Úvod do problematiky 2
1.1 eHealth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Telemedicína . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.1 Služby telemedicíny . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.2 Mechanizmy pre doručenie dát . . . . . . . . . . . . . . . . . . . . . 4
1.2.3 Výhody telemedicíny . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Diabetes mellitus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3.1 Čo je to glykémia . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3.2 Čo je to inzulín . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.3 Hlavné typy diabetu . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.4 Typy inzulínu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3.5 Vplyv fyzickej aktivity na človeka s diabetes . . . . . . . . . . . . . 7
1.4 Analýza súčastného stavu aplikácií . . . . . . . . . . . . . . . . . . . . . . 7
1.4.1 Pedometer - brillientapp . . . . . . . . . . . . . . . . . . . . . . . . 8
1.4.2 Accupedo Pedometer . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.4.3 Rozbor aplikácie . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2 Použité technológie 11
2.1 Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1.1 História operačného systému . . . . . . . . . . . . . . . . . . . . . . 11
2.1.2 Verzie a API level . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1.3 Štatistika aktuálneho využitia verzií . . . . . . . . . . . . . . . . . . 12
2.1.4 Architektúra OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2 SQLite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.1 Implementácia normy SQLite . . . . . . . . . . . . . . . . . . . . . 14
2.2.2 Dátové typy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.3 Veľkosti a limity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3 JSON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3.1 Štruktúry JSON . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3.2 Realizácia štruktúr v JSON . . . . . . . . . . . . . . . . . . . . . . 15
2.4 OAuth 2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4.1 Role užívateľov a aplikácií . . . . . . . . . . . . . . . . . . . . . . . 16

2.4.2 Autorizácia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3 Implementácia 20
3.1 Popis použitého eHealth zariadenia - krokomer . . . . . . . . . . . . . . . . 20
3.2 Diagramy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2.1 Prípady použitia . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2.2 Diagramy tried . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.3 SQLite databáza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.4 Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.4.1 Vytváranie SQLite databázy . . . . . . . . . . . . . . . . . . . . . . 27
3.4.2 Spracovávanie JSON štruktúr . . . . . . . . . . . . . . . . . . . . . 28
3.4.3 Grafy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.4.4 Rozhranie aplikácie . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Záver 35
Zoznam použitej literatúry 36
Prílohy I
A Štruktúra elektronického nosiča II
B Algoritmus III

Zoznam obrázkov a tabuliek
Obrázok 1 Hodnoty glykémie . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Obrázok 2 Krokomer aplikácia 1 - hlavná obrazovka a nastavenia . . . . . . . 8
Obrázok 3 Krokomer aplikácia 2 - hlavná obrazovka a prehľad aktivity . . . . 9
Obrázok 4 Štatistika aktuálneho využitia verzií Androidu. . . . . . . . . . . . 12
Obrázok 5 Architektúra OS Android. . . . . . . . . . . . . . . . . . . . . . . 13
Obrázok 6 Role v OAuth 2.0. . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Obrázok 7 Proces získania dát. . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Obrázok 8 Vzhľad krokomeru od ﬁrmy iHealth Labs. . . . . . . . . . . . . . . 20
Obrázok 9 Diagram použitia prihlásenie do aplikácie. . . . . . . . . . . . . . . 21
Obrázok 10 Diagram tried pre StepItem a príslušný Adaptér. . . . . . . . . . . 22
Obrázok 11 Diagram tried pre SleepItem a príslušný Adaptér. . . . . . . . . . 23
Obrázok 12 SQL tabuľka login. . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Obrázok 13 SQL tabuľka user_t. . . . . . . . . . . . . . . . . . . . . . . . . . 24
Obrázok 14 SQL tabuľka activity_report. . . . . . . . . . . . . . . . . . . . 26
Obrázok 15 SQL tabuľka sleep_report. . . . . . . . . . . . . . . . . . . . . . 27
Obrázok 16 WebView s prihlasovacou obrazovkou iHealth. . . . . . . . . . . . 32
Obrázok 17 Fragment menu a proﬁl. . . . . . . . . . . . . . . . . . . . . . . . . 33
Obrázok 18 Fragment prehľad a odhlasovanie. . . . . . . . . . . . . . . . . . . 33
Obrázok 19 Fragment história chôdze a spánku. . . . . . . . . . . . . . . . . . 34
Obrázok 20 Graf krokov a počet naspaných hodín za jednotlivé dni. . . . . . . 34
Tabuľka 1 Verzie Androidu a API . . . . . . . . . . . . . . . . . . . . . . . . 11
Tabuľka 2 Prístupové údaje do aplikácie . . . . . . . . . . . . . . . . . . . . . 28

Zoznam skratiek a značiek
HIT - Health Information Technology
RDTF - Remote Diagnostic Testing Facility
EKG - Electrocardiogram
RTG - Rontgen
ICU - Intensive Care Unit
URL - Uniform Resource Locator
OHA - Open Handset Alliance
OS - Operačný Systém
DVM - Dalvik Virtual Machine
JVM - Java Virtual Machine
API - Application Programming Interface
ADB - Android Debug Bridge
JDK - Java Development Kit
GB - Giga Byte
MB - Mega Byte
JSON - JavaScript Object Notation
URI - Uniform Resource Identiﬁer
HTTP - Hypertext Transfer Protocol
SDK - Software Development Kit
UI - User Interface

Zoznam algoritmov
B.1 Základný kód pre vytvorenie DB. . . . . . . . . . . . . . . . . . . . . . . . III
B.2 AsyncTask pre prijatie access tokenu . . . . . . . . . . . . . . . . . . . . . IV
B.3 Základný kód pre vytvorenie grafu. . . . . . . . . . . . . . . . . . . . . . . V
B.4 Základný kód pre vytvorenie Fragmentu. . . . . . . . . . . . . . . . . . . . V

Úvod
V dnešnej dobe popularita mobilných zariadení prudko stúpa. Mobilné telefóny, in-
teligentné hodinky a tablety sa teda stávajú plnohodnotnými nástupcami stolových počí-
tačov. Cena týchto zariadení ich robí dostupnými aj pre širokú skupinu ľudí. Spomenuté
mobilné zariadenia sa zväčša používajú na surfovanie po internete, kancelárske aplikácie
alebo hry. Avšak existuje potenciál využiť ich pre zdravotnícke účely respektíve moni-
torovanie svojho zdravotného stavu.
Takto sa dostávame k eHealth a telemedicíne. Tieto pojmy naberajú v súčastnosti
veľký význam v zdravotníctve. Vďaka elektronizácií zdravotníctva sa zlepšuje aj jeho
kvalita a umožňuje pacientom pohodlnejší prístup k svojím údajom, poznámkam lekára
poprípade histórii svojich diagnóz.
Diabetes Melitus je chronické ochorenie. To znamená, že nie je možné ho liečiť,
ale dá sa s ním žiť ak pacient dodržuje správne stravovacie návyky a pokyny lekára.
Pacient, ktorý trpí týmto ochorením si musí pravidelne strážiť svoju stravu a stav cukru,
aby nemal problémy. Hlavne takýmto pacientom vedia mobilné aplikácie uľahčiť život.
Môžme si predstaviť viacero scenárov aplikácii aké by mohol potrebovať. Patria medzi
ne napríklad zaznamenávanie hodnôt glukózy v krvi, dávkovania inzulínu, kontrola jedál
skonzumovaných a tým spojený aj energetický výdaj počas dňa.
Vhodnou implementáciou týchto aktivít do aplikácie dokáže pacientovi ušetriť mnoho
času. Pacient nebude musieť chodiť na pravidelnej báze konzultovať zvýšené hodnoty
glukózy v krvi, zmenu jedálnička poprípade iné aspekty, ktorá sú dôležité pri cukrovke.
Lekárovi bude umožnené sledovať tieto hodnoty na diaľku a tak môže vykonať ďalšie
kroky a v prípade väčších problémov pacienta kontaktovať.
Cieľom tejto práce bude navrhnúť a implementovať mobilnú aplikáciu pre platformu
Android, vďaka ktorej by si pacient mohol zaznamenávať svoju fyzickú aktivitu meranú
krokomerom od ﬁrmy iHealth Labs Inc.
1

1 Úvod do problematiky
1.1 eHealth
Označenie eHealth pochádza z anglického označenia pre elektronické zdravotníctvo.
Elektronické zdravotníctvo prispeje k zlepšovaniu zdravotnej starostlivosti pre občanov
prostredníctvom informačných a komunikačných technológii. Je to vlastne informatizácia
činností, ktoré súvisia s poskytovaním zdravotnej starostlivosti. Plány do budúcnosti s
eHealth sú také, že sa zjednoduší práca lekárov v zdravotníctve, ale hlavne pre pacientov.
Medzi také základné vízie eHealthu patrí:
• lekári budú o sebe vedieť v reálnom čase, aké lieky ich pacienti využívajú, alebo aké
mal v minulosti, jeho diagnózy, nadchádzajúce vyšetrenia, priebeh liečby,
• pri predpisovaní lieku si lekár uvidí, či liek ktorý predpisuje nemá nejaké interakcie
už s aktuálne predpísanými liekmi,
• pacient dostane upozornenie, keď budú hotové jeho výsledky z vyšetrenia,
• pri RTG sa snímka uloží do proﬁlu pacienta a budú tam mať prístup rôzny lekári,
ktorých pacient schváli,
• pacientovi bude umožnené objednať sa elektronicky na nejaký konkrétny čas,
• bude zhotovený portál, kde pacient nájde všetky informácie o chorobách, diagnos-
tike, liečení, liekoch, ohrozeniach zdravia, poskytovateľoch zdravotníckej starostlivosti,
pričom tieto informácie budú dôveryhodné, autorizované, aktuálne a úplné,
• občan sa dostane k svojím zdravotným záznamom z rôznych miest s prístupom na
internet,
• pacientovi bude umožnené konzultovať svoj zdravotný problém aj cez telefón, mail,
chat,
• zdravotný stav pacienta bude môcť okamžite posúdiť špičkový špecialista, ktorý sa
môže nachádzať stovky kilometrov od neho.
Program implementácie eHealth sa zaoberá informatizáciou na národnej úrovni a integrá-
ciou informačných systémov poskytovateľov zdravotnej starostlivosti s národným riešením,
ktorým je Národný zdravotnícky informačný systém (NZIS).[3][4]
2

1.2 Telemedicína
Telemedicína je termín, ktorý sa používa pre výmenu lekárskych informácií z jedného
miesta na druhé prostredníctvom zdravotníckych elektronických zariadení pre zlepšenie
zdravotného stavu pacienta. Telemedicína zahŕňa rôzne služby a aplikácie, ktoré je možné
využiť na obojsmernú komunikáciu medzi lekárom a pacientom ako napríklad video,
e-mail, smartfóny, bezdrôtové zariadenia alebo ďalšie telekomunikačné technológie.
Telemedicína nie je samostatný lekársky odbor. Produkty a služby súvisiace s teleme-
dicínou sú často projekty, do ktorých investovali inštitúcie zaoberajúce sa zdravotnou
starostlivosťou v informačných technológiách. Dokonca pri platbách sa nerozlišuje, či
služby boli poskytnuté na mieste alebo prostredníctvom telemedicíny. Telemedicína a
eHealth sú podobné pojmy, ktoré zahŕňajú širokú definíciu diaľkového zdravotníctva.
Konzultácie s pacientom prostredníctvom videokonferencie, posielania snímok, eHealth
vrátane portálov pre pacientov, diaľkové monitorovanie vitálnych funkcií, ďalšie vzdelá-
vanie lekárov, bezdrôtové zariadenia orientované na spotrebiteľa a call centrum zo ses-
tričkami, sú považované za súčasť telemedicíny a telehealth. Aj keď sa termín telehealth
občas používa ako širšia definícia vzdialenej zdravotnej starostlivosti, nemusí vždy zahŕňať
klinické služby.
Telemedicína je úzko spojený termín s pojmom zdravotné informačné technológie
(HIT). Avšak HIT má viac spoločného s elektronickými zdravotnými záznamami a súvisia-
cimi informačnými systémami, zatiaľ čo telemedicína odkazuje na skutočné poskytovanie
klinických služieb pomocou diaľkových technológií. Niekedy je lepšie telemedicínu chápať
z hľadiska poskytovaných služieb a mechanizmov používaných pre poskytovanie týchto
služieb. [2]
1.2.1 Služby telemedicíny
Primárna starostlivosť a špecializované služby môže zahŕňať primárnu starostli-
vosť zdravotníckeho pracovníka, ktorý poskytuje konzultácie pacientom alebo špecialistom
asistujúcim pri primárnej starostlivosti v objasňovaní diagnózy. Toto môže zahŕňať použi-
tie interaktívneho videa alebo používanie posuvných obrázkov vitálnych funkcii s dátami
pacientov pre neskoršiu kontrolu.
Vzdialené monitorovanie pacientov, vrátane domáceho telehealthu, používa zari-
adenia na vzdialené zbieranie a posielanie dát do zdravotnej agentúry alebo diaľkového
diagnostického testovacieho zariadenia (RDTF) pre interpretáciu. Tieto dáta môžu za-
hŕňať špecifické vitálne funkcie, ako napríklad hladina cukru v krvi alebo srdcového EKG
alebo rôznych ukazovateľov pacientov nachádzajúcich sa doma. Tieto služby môžu byť
3

použité na doplnenie využívania zdravotných sestier.
Spotrebiteľské lekárske a zdravotné informácie zahŕňajú využitie internetu a
bezdrôtových zariadení pre spotrebiteľov na získanie odborných informácií o zdraví ale aj
online diskusné skupiny poskytujúce podporu.
Zdravotnícke vzdelanie poskytuje sústavné lekárske vzdelávanie pre zdravotníkov
a špeciálne lekárske semináre pre cieľové skupiny vo vzdialených lokalitách.[2]
1.2.2 Mechanizmy pre doručenie dát
Sieťové programy prepájajú tercíalnu starostlivosť nemocníc, odľahlých kliník a
komunitných zdravotných stredísk vo vidieckych alebo prímestských oblastiach. Pre spo-
jenie sa používajú vyhradené vysoko-rýchlostné linky alebo internet pre telekomunikačné
spojenie medzi jednotlivými pracoviskami.
Spojenia medzi jednotlivými bodmi sa používajú v nemocniciach a na klinikách
pomocou súkromných vysoko-rýchlostných sietí, ktoré poskytujú služby priamo alebo sú
dodávané s nezávislými poskytovateľmi zdravotných služieb. Tieto externe zaisťované
služby zahŕňajú RTG, vyhodnocovanie mŕtvice, duševné zdravie a služby intenzívnej
zdravotnej starostlivosti.
Monitorovacie centrá sú použité pre srdcové, pľúcne alebo pre monitorovanie
plodu, domácu starostlivosť a súvisiace služby, ktoré poskytujú starostlivosť pacientom
nachádzajúcich sa doma. Bežne využívané pevné linky alebo bezdrôtové pripojenia slúži-
ace na komunikáciu priamo medzi centrom a pacientom, aj keď niektoré systémy používajú
internet.
eHealth služby založené na webových technológiách poskytujú priamo službu
pre spotrebiteľa cez internet. V rámci telemedicíny medzi ne patria tie stránky, ktoré
poskytujú priamu starostlivosť o pacientov.[2]
1.2.3 Výhody telemedicíny
Telemedicína prudko rastie, pretože ponúka štyri základné výhody:
Lepší prístup – telemedicína vytvorila prínos pre pacientov vďaka službám zdravot-
nej starostlivosti vo vzdialených lokalitách. Telemedicína nielen zlepšila prístup k pa-
cientom, ale tiež umožňuje rozšíriť dosah lekárov a zdravotníckych zariadení. Vzhľadom
na nedostatok poskytovateľov na svete (hlavne v dedinách a mestských oblastiach) má
telemedicína unikátnu možnosť zvyšovať kapacitu služby pre nových pacientov.
Zlepšenie efektívnosti nákladov – znižovanie nákladov na zdravotnú starostlivosť
je jedným z najdôležitejších dôvodov pre ﬁnancovanie a adaptovanie telehealth technológií.
Ukázalo sa, že telemedicína znižuje náklady na zdravotnú starostlivosť a zvyšuje efek-
4

tivitu prostredníctvom lepšieho zvládania chronických ochorení, zdieľaný profesionálny
zdravotný personál, znížený čas na cestovanie a kratší pobyt v nemocnici.
Zlepšená kvalita – štúdie opakovane ukázali, že kvalita zdravotníckych služieb
dodaných prostredníctvom telemedicíny sú minimálne rovnako dobré ako tradičné os-
obné konzultácie. V niektorých špecializáciách, najmä v oblasti duševného zdravia a
starostlivosti ICU, telemedicína prináša špičkové výrobky s lepšími výsledkami a spoko-
jnosťou pacienta.
Dopyt pacienta – spotrebitelia chcú telemedicínu. Najväčší vplyv telemedicíny je
na pacientovi a jeho rodiny. Použitie technológií telemedicíny skracuje dobu cestovania
a súvisiaci stres pacienta. Počas posledných 15 rokov štúdie zdokumentovali spokojnosť
pacienta a podporu pre telemedicínske služby. Tieto služby poskytujú pacientom prístup
k poskytovateľom, ktorí by inak nemuseli byť dostupný, ako aj zdravotnícke služby bez
toho, aby ste museli cestovať na dlhé vzdialenosti.[2]
1.3 Diabetes mellitus
Diabetes mellitus je termín, ktorý sa používa pre označenie cukrovky. Je to skupina
ochorení, ktorých spoločným znakom je zvýšený cukor v krvi alebo aj v moči. Nie je
možné sa z cukrovky vyliečiť, ale je možné sa liečiť! Teda udržiavať hladinu cukru v
krvi (glykémia) na normálnej hodnote. Najväčší problém pri cukrovke je ten, že zvýšené
glykémie nie je cítiť. V prípade ak je glykémia zvýšená dlhodobo, tak vznikajú kompliká-
cie. K najhorším patrí poškodenie očí, obličiek, nervov, srdca a ciev. Pri veľmi vysokých
glykémiách je možné spozorovať aj nejaké charakteristické príznaky ako je veľký smäd,
nadmerné močenie, celková slabosť, zhoršenie zraku, nechcené chudnutie, svrbenie kože,
infekcie alebo zlé hojenie rán. Takýmto komplikáciám sa dá predísť tak, že budeme držať
cukrovku pod kontrolou a správne sa liečiť. Treba si udržiavať hodnoty glykémií, tlaku,
hmotnosti a tukových látok v krvi v normálnych hodnotách.[8]
1.3.1 Čo je to glykémia
„Glykémia je hladina alebo presnejšie koncentrácia cukru glukózy v krvi. Udáva sa v
množstve tisícin mili molekúl v jednom litri krvi (mmol/l = milimolov na liter). Molekula
je najmenšie možné množstvo glukózy.“
„Glukóza je jednoduchý cukor, ktorý potrebuje mať každý človek. Glukóza je hlavným
a najrýchlejším zdrojom energie – palivo pre bunky.“
„Glykogén je pohotovostná zásoba glukózy v pečeni a vo svaloch.“
Po vysvetlení základných pojmov sa dostávame k hodnotám glykémie, ktoré sa môžu
5

objaviť. U človeka, ktorý netrpí cukrovkou to bývajú hodnoty od 3,5 do 5,6 mmol/l
nalačno a po jedle maximálne 7,8 mmol/l. Väčšie hodnoty ako tieto sa nazývajú hy-
perglykémia a nižšie hypoglykémia. Glykémiu, pri ktorej sa cukor nachádza aj v moči
nazývame obličkový prah. Väčšinou sú to hodnoty okolo 10 mmol/l.[8]
Obrázok 1: Hodnoty glykémie
1.3.2 Čo je to inzulín
„Inzulín je hormón, ktorý sa vylučuje do krvi a pôsobí v celom organizme. Má kľúčovú
úlohu v premene látok – je hlavným regulátorom glykémie.“ Inzulín je vlastne bielkovina
a umožňuje vstup glukózy do bunky a potom glukóza poskytne bunkám okamžitú energiu
iba keď sa nachádza vo vnútri bunky. Vyrábajú ho beta bunky brušnej slinivky.[8]
1.3.3 Hlavné typy diabetu
Diabetes 1. typu vzniká vtedy keď si telo nedokáže dostatočne vytvárať inzulín.
Beta bunky sú poškodené a postupne zanikajú. Inzulín je v tomto prípade potrebný liek
na prežitie. Tento typ cukrovky väčšinou vzniká u detí, mladých a štíhlych, ale takisto
môže vzniknúť v rôznom veku. Pri type 1 je malá pravdepodobnosť, že by sa zdedil. Zo
všetkých diabetikov ho má asi len 10 – 15%.
6

Diabetes 2. typu sa vyskytuje častejšie u starších ľudí s nadváhou. Je tu väčšia
šanca dedičnosti ako pri type 1. Trpí ním až 90% diabetikov. Počet diabetikov veľmi
rýchlo narastá a do roku 2025 sa zvýši z 150 miliónov (r. 2000) až na 300 miliónov. Čo sa
týka Slovenska, tak diabetom trpí asi 7% obyvateľov. Hlavné problémy vzniku cukrovky
je nedostatok pohybu, nezdravá strava a s tým spojená nadváha. Miernejšia diabetická
porucha sa nazýva prediabetes. Z neho môže vzniknúť diabetes, ale aj nemusí.
Gestačný diabetes je cukrovka, ktorá sa zistí v priebehu tehotenstva. [8]
1.3.4 Typy inzulínu
Poznáme dva typy inzulínu: bazálny a bolus. Bazálny výdaj inzulínu sa stará o to,
aby aby hladina glykémie bola vyrovnaná pri jedlách a v noci. V prípade, že máme väčší
príjem energie ako výdaj, tak inzulín ten zvyšok ukladá do tukových zásob. Po jedle,
ktoré obsahovalo veľa cukrov a sacharidov treba zvýšiť hodnotu inzulínu v tele. To sa
dosahuje tak, že sa zvýši takzvaný inzulínový bolus. Tento bolus by mal byť taký rýchly
aby stihol do buniek prepraviť glukózu z jedla tak, aby glykémia nepresahovala hodnotu
7,8 mmol/l.[8]
1.3.5 Vplyv fyzickej aktivity na človeka s diabetes
Pri liečbe cukrovky u pacientov je fyzická aktivita veľmi dôležitým faktorom spolu s
diétnymi opatreniami. Patrí k základným liečebným metódam, ktoré by nemal zanedbá-
vať žiadny diabetik. Pri dlhodobej fyzickej aktivite sú u pacienta pozorovateľné viaceré
priaznivé účinky ako:
• zlepšenie citlivosti tkanív na inzulín (hlavne u 2. typu),
• priaznivý efekt pri ostatných klinických prejavoch metabolického syndrómu (vysoký
tlak, obezita, ...),
• zvýšenie fyzickej zdatnosti.
Pri cukrovke 1. aj 2. typu sa odporúča hlavne aeróbna aktivita, pri ktorom dochádza
hlavne k odbúravaniu tukov. Tento typ aktivity zlepšuje výkonnosť srdcovo-cievneho
systému.[10]
1.4 Analýza súčastného stavu aplikácií
Pri analýze súčastného stavu aplikácií ide vlastne o to, si urobiť rozhľad cez existu-
júce aplikácie. Tento rozhľad je vhodný práve kvôli tomu, že sa budeme venovať tvorbe
aplikácie na platforme Android a tak sa vieme inšpirovať, zistiť prípadné chyby, ktorých
7

sa vývojári mohli dopustiť a pouvažovať nad tým čo by bolo možné vylepšiť. Väčšina ap-
likácií boli dostupné na online obchode s mobilnými aplikáciami Google Play. Dôležitým
kritériom pri výbere aplikácie na zhodnotenie bolo, aby aplikácia prijímala údaje z ex-
terného zariadenia. Taká aplikácia medzi top najpoužívanejšími bohužiaľ nebola, tak sme
vybrali náhodne tieto dve, ktoré síce získavajú údaje z akcelerometra, ale dôležitý je aj
vzhľad pre inšpiráciu.
1.4.1 Pedometer - brillientapp
Táto aplikácia pre krokomer predstavuje jednoduché rozhranie pre meranie krokov a
takisto umožňuje nastaviť jednotky pre dané merané veličiny.
Názov: Pedometer
URL: https://play.google.com/store/apps/details?id=net.brillientapp.pedometer
Obrázok 2: Krokomer aplikácia 1 - hlavná obrazovka a nastavenia
8

1.4.2 Accupedo Pedometer
Oproti predošlej aplikácií táto obsahuje dokonca aj grafy a prehľad dní s aktivitou.
Má už pokročilejšiu graﬁku.
Názov: Accupedo Pedometer
URL: https://play.google.com/store/apps/details?id=com.corusen.accupedo.te
Obrázok 3: Krokomer aplikácia 2 - hlavná obrazovka a prehľad aktivity
9

1.4.3 Rozbor aplikácie
V analýze súčasných aplikácií boli náhodne vybrané dve, ktoré boli vhodné na analýzu.
Z nich budeme brať do úvahy vhodné elementy pri vytváraní aplikácie. Rozdiel nastáva
v tom, ako už bolo spomenuté na začiatku sekcie č. 1.4, že na Google Play obchode
nebola nájdená aplikácia takého krokomeru, ktorá by získavala údaje z externého senzora,
podobný tomu aký budeme využívať. Väčšina týchto aplikácií získava údaje o krokoch
zo senzorov, ktoré sa už nachádzajú v mobilnom telefóne. Budem využívať zariadenie
krokomer od ﬁrmy iHealth Labs, ktoré je popísané v kapitole č. 3.1.
Takže máme dva typy možných aplikácií: jeden môže využívať integrované senzory
v mobilnom telefóne na získanie údajov a druhý typ získava údaje z externého eHealth
zariadenia buď cez Bluetooth technológiu alebo WiFi. Každá z nich má svoje výhody
a nevýhody. Medzi výhody integrovaných senzorov je, že nie je potrebné dokupovať
ďalšie zariadenia na meranie aktivity a je to priamo v mobilnom telefóne. Ako nevýhodu
oproti externým zariadeniam, že vyžaduje ďalšie energeticky náročnejšie prostriedky a
tým znižuje výdrž batérie, kde pri externom stačí raz za čas synchronizovať údaje.
Ako prvá vec v aplikácií by sa mohla implementovať hlavná obrazovka po spustení
aplikácie, kde by sa zobrazil celkový súhrn nameraných údajov. To dáva celkom zmysel,
pretože užívateľ by chcel mať celkový rozhľad svojej aktivity. Medzi dôležité namerané
údaje patrí počet krokov, kilometrov a taktiež spálené kalórie. Aplikácia bude viesť
záznamy o všetkých aktivitách. Vhodné by bolo aj implementovať grafy ako vizualizáciu
stúpania a klesania aktivity počas daného obdobia.
10

2 Použité technológie
2.1 Android
Android je mobilný operačný systém, ktorý vyvíja Google. Je založený na open
source, to znamená, že je voľne dostupný pre všetkých a zdarma. Základ operačného
systému je Linuxové jadro a nad tým je postavené Android API s vlastným virtuálnym
strojom, ktorý sa píše v programovacom jazyku Java. [11]
2.1.1 História operačného systému
Android vznikol v roku 2003. Zakladatelia boli Andy Rubin, Rich Miner, Nick Seans
a Chris White. V roku 2005 ho odkúpila spoločnosť Google zo všetkými zamestnancami
a tým vstúpila na mobilný trh.
V roku 2007 vznikla Open Handset Alliance (ďalej len OHA), ktorej členovia boli
rôzne softwarové ﬁrmy, výrobci súčiastok a mobilných telefónov. OHA si kládla za cieľ
vytvoriť otvorený mobilný operačný systém. Pri vzniku hneď ohlásili prvý produkt An-
droid, ktorý bol založený na Linuxovom jadre 2.6.
Kým OHA vydala prvú oﬁciálnu verziu Android 1.0 tak systém prešiel mnohými
úpravami, opravy chýb a pridávaním novej funkcionality. Popri číslovanej verzii Android
vždy dostal aj názov podľa nejakého koláčiku. Väčšinou sa v každej verzii pridajú nové
funkcie a tak sa aj zvýši verzia API. To znamená ak chceme využiť funkcionalitu z na-
jnovšie pridaného API, tak musíme mať rovnakú verziu Androidu.[11]
2.1.2 Verzie a API level
Verzia Android Názov API level
1.0 a 1.1 - 1 a 2
1.5 Cupcake 3
1.6 Donut 4
2.0 - 2.1 Eclair 5, 6, 7
2.2.3 Froyo 8
2.3.7 Gingerbread 9, 10
3.0 - 3.2 Honeycomb 11, 12, 13
4.0 - 4.0.4 Ice Cream Sendwich 14, 15
4.1 - 4.3 Jelly Bean 16, 17, 18
4.4 - 4.4.2 KitKat 19
Tabuľka 1: Verzie Androidu a API
11

V tabuľke č.1 môžeme vidieť celú históriu Androidu s jednotlivými názvami, verzií a
k tomu príslušný API level.
2.1.3 Štatistika aktuálneho využitia verzií
Na obrázku je relatívna štatistika využitia verzií Androidu na aktivovaných zariade-
niach, resp. na zariadeniach ktoré majú nainštalovaný Google Play Store. Verzie, ktoré
majú menej ako 0.1% používateľov sú už vyradené zo štatistík. Údaje boli zozbierané ku
dňu 1.5.2014[1]
Obrázok 4: Štatistika aktuálneho využitia verzií Androidu.
2.1.4 Architektúra OS
Architektúra Androidu pozostáva z piatich vrstiev. Každá z nich má na starosti
isté úkony a tak pracuje skoro samostatne. Ale v praxi jednotlivé vrstvy navzájom
spolupracujú.
12

Ukážka na obrázku č.5. Každá z vrstiev na obrázku má aktualizovaný software pri
vydaní novej verzie Androidu. Linuxové jadro niekedy zachovávajú v rovnakej verzii.
Obrázok 5: Architektúra OS Android.
Linux Kernel (jadro) ako spodná vrstva je vlastne jadro operačného systému An-
droid. Táto vrstva implementuje abstraktnú vrstvu medzi hardwarom a softwarom vo
vyšších vrstvách. Jadro sa využíva tak, že pri štarte zariadenia prevezme celé riadenie a
kontroluje systém, spravuje procesy, pamäť, sieť a programy.
Libraries (knižnice) je vrstva nad Linux Kernelom. Pomocou týchto knižníc je možné
vytvárať aplikácie. Medzi ne patrí WebKit (po novom už Blink) čo je vlastne open source
renderovacie jadro JavaScriptu, HTML a CSS. Ďalej je tam libc, ktorá slúži pre beh C
aplikácií. SQLite pre lokálne databázy na zariadení a ďalšie rôzne knižnice ako SSL, SGL,
OpenGL, FreeType, Media Framework a Surface Manager.
Android Runtime je tretia vrstva v tejto architektúre a nachádza sa v druhej
vrstve. Runtime poskytuje kľúčový komponent nazývaný DVM, ktorý je vlastne typ JVM
špeciálne vytvorený pre Android, respektíve mobilné zariadenia. Obsahuje základné Java
knižnice. DVM používa Linuxové možnosti ako správa pamäti a viac-vláknové spracovanie
aplikácií, ktoré sú aj v jazyku Java.
13

„Aplikácie pre Android sú programované v jazyku Java, následne prekladané do Java
byte kódu, a nakoniec do medzikódu pomocou Dalvik kompilátoru. Výsledný byte kód je
spustený na DVM. Každá aplikácia je samostatný proces s vlastnou inštanciou DVM.“
Application Framework (aplikačný framework) patrí medzi najdôležitejšiu vrstvu
pre programátorov aplikácií. Táto vrstva umožňuje pristupovať k rôznym službám, ktoré
programátori môžu využívať priamo vo svojich aplikáciach.
Applications (aplikácie) je najvyššia vrstva obsahuje už konkrétne aplikácie, ktoré
sa používajú na dané účely. Sú tu aplikácie, ktoré sú už buď predinštalované, vložené cez
ADB alebo stiahnuté z Google Play. [11]
2.2 SQLite
SQLite je knižnica, ktorá implementuje sebestačný (self-contained), klientský (server-
less), bezkonﬁgurančný (zero-conﬁguration) a transakčný SQL databázový engine. SQLite
je vstavaný SQL databázový engine. Narozdiel od ostatných SQL databáz, SQLite nemá
samostatný serverový proces. SQLite priamo číta a zapisuje do bežných súborov. Kom-
pletná SQL databáza s viacerými tabulkami, indexami, triggermy a pohľadmi sú obsiah-
nuté v jedinom samostatnom súbore, ktorý možné zdielať naprieč platformami.[13]
2.2.1 Implementácia normy SQLite
Každá implementácia SQL pracuje rozdielne a môžu byť v nej aj nejaké výnimky.
Tak isto sú aj v SQLite. Medzi základné rozdiely patria nasledujúce veci. Vnorené
dotazy môžu byť iba statické, ich vyhodnotenie prebehne iba jeden krát a nie je možné
aby odkazovali na pole hlavného dotazu. Cudzie kľúče sa síce vyhodnocujú, ale nie sú
vyžadované obmedzenia, ktoré by sa mali uplatniť na ich základe. Čo sa týka trigerov,
tak nepodporujú konštrukciu "for each statement" a trigery "instead of" sú použiteľné iba
nad tabuľkami, taktiež chýba rekurzia trigerov. Nie je možné vykonávať ALTER TABLE a
zmeny tabuliek je možné spraviť len tak, že sa znovu vytvoria. Transakcie sú obmedzené
len na jedinú aktívnu. OUTER JOIN môže byť len v jedinej forme a to zľava.[9]
2.2.2 Dátové typy
V SQLite nie sú dátové typy. Databáza je beztypová. V prípade ak máme stĺpec
deklarovaný ako NUMBER a dám tam reťazec "číslo" tak databáza to berie bez problémov.
Existuje ale výnimka pri stĺpci, ktorý je deklarovaný ako INTEGER PRIMARY KEY, kde je
požadované jednoznačné celé číslo. Bežne sú údaje rozlišované ako číselné, textové alebo
podľa použitia. Môže sa vyskytnúť problém, pri často používanom údaji ako je dátum a
čas, kde si to treba riešiť už sám. Či ako INTEGER s unix time alebo typu TEXT. Iba v
14

jedinom prípade sa databáza pozerá čo by mal stĺpec obsahovať a to je pri volaní klauzule
ORDER BY v SELECT. SQLite plne podporuje hodnotu NULL v ľubovolnom stĺpci a chovanie
je rovnaké ako v iných databázach.[9]
2.2.3 Veľkosti a limity
Veľkosť databáze je limitovaná na 241
byte, čo sú asi 2 terabyty. Je to viacmenej
teoretická veľkosť. Starší formát mal obmedzenia len na 2 GB. Horší je limit veľkosti
jedného riadku na 1 MB. Tento limit je obmedzujúci ak by sme chceli využívať ukladanie
binárnych dát do databázy. Je možné tento limit zväčšiť až na 16 MB pri upravenej
kompilácii SQLite. Do daného 1 MB sa musí vojsť aj deﬁnície tabuľky, teda aj príkaz
CREATE TABLE. Mená funkcií sú limitované na 255 znakov, čo je pre väčšinu prípadov
postačujúce.[9]
2.3 JSON
JSON (JavaScript Object Notation) je zjednodušený formát pre výmenu dát. Má
zrozumiteľný čitateľný formát pre človeka a je možné ho jednoducho analyzovať a spracov-
ávať počítačom. Je založený na podmnožine programovacieho jazyka JavaScript, Stan-
dard ECMA-262 3rd Edition - December 1999. JSON je textový formát, nezávislý na
programovacom jazyku a je implementovaný pre použitie asi vo všetkých známych pro-
gramovacích jazykoch. Aj vďaka tomu je vhodný jazyk pre výmenu dát.[12]
2.3.1 Štruktúry JSON
JSON je založený na dvoch štruktúrach:
• Kolekcia párov názov / hodnota. V rozličných jazykoch býva realizovaná ako objekt,
záznam, štruktúra, slovník, hash tabuľka, kľúčový zoznam alebo asociativné pole.
• Zreťazený zoznam hodnôt. Ten je vo väčšine jazykov realizovaný ako pole, vektor,
zoznam alebo sekvencia.
Sú to univerzálne dátové štruktúry a programovacie jazyky ich majú v nejakej forme
implementované. Je teda logické, aby bol na nich založený aj na jazyku nezávislý formát
pre výmenu dát.[12]
2.3.2 Realizácia štruktúr v JSON
Štruktúry vyššie majú svoju realizáciu v JSON riešenú na základných typoch ako je
objekt, pole, hodnota, reťazec, číslo. Tieto konštrukcie si popíšeme nižšie.
Objekt je neusporiadaná množina párov názov / hodnota. Objekt je identiﬁkovaný
kučeravými zátvorkami {}. Po každom názve nasleduje znak dvojbodka : a páry názov
15

/ hodnota sú potom oddelené znakom , čiarka.
Pole je zoradená kolekcia hodnôt. Začína znakom [ a končí ], teda hranaté zátvorky.
Hodnoty sú oddelené znakom , čiarka.
Hodnota je vlastne reťazec uzavretý do dvojitých úvodzoviek. Číslo, true, false,
null, object alebo pole môžu byť vnorené.
Reťazec sú znaky v kódovaní Unicode, uzavretých do dvojitých úvodzoviek, ktoré
využívajú únikové sekvencie s použitím spätného lomítka. Znak je reprezentovaný tiež
ako reťazec s jedným znakom.
Číslo je podobné štruktúrou ako v iných programovacích jazykoch. Výnimka je, že
sa tu nepoužíva osmičkový ani hexadecimálny zápis. [12]
2.4 OAuth 2.0
Autentiﬁkácia na iHealth labs cloud prebieha pomocou OAuth 2.0 protokolu. OAuth
2.0 je otvorený autorizačný protokol, ktorý umožňuje aplikáciám prístup k údajom uží-
vateľa.
2.4.1 Role užívateľov a aplikácií
Oauth 2.0 deﬁnuje nasledujúce role užívateľov a a aplikácií:
• vlastník dát (resource owner)
• server s dátami (resource server)
• klientská aplikácia (client application)
• autorizačný server (autorization server)
Jednotlivé role sú zobrazené na nasledovnom diagrame č.6.
16

Obrázok 6: Role v OAuth 2.0.
Vlastník dát je osoba alebo aplikácia, ktorá ide zdielať svoje dáta. Server z dátami
je ako keby hosting, ktorý má u seba uložené jednotlivé údaje. Klientská aplikácia je
aplikácia, ktorá žiada prístup k zdrojom uložených na serveri s dátami. Zdroje sú dáta,
ktoré patria vlastníkovi dát. Server s dátami má uložené všetky údaje o jednotlivých
vlastníkoch dát. Konkrétne v mojom prípade sú tam uložené profilové údaje, namerané
hodnoty a fotka. Klientská aplikácia je aplikácia, ktorá žiada prístup k zdrojom uložených
na serveri s dátami. V našom prípade je to Android aplikácia, ktorá žiada prístup k pro-
filovým informáciám a k meraným údajom. Bez schválenia by bol prístup odmietnutý.
Autorizačný server autorizuje klientskú aplikáciu pre prístup k údajom vlastníka. Autor-
izačný server a server s dátami môžu byť na rovnakom stroji, ale aj nemusia. Špecifikácia
OAuth 2.0 nehovorí nič presne o týchto dvoch serveroch ako majú komunikovať, ak sú
zhotovené separátne. Záleží to na rozhodnutí vývojárov ako to implementujú.[6]
17

2.4.2 Autorizácia
V prípade ak chce klientská aplikácia pristupovať k údajom vlastníka uložených na
serveri tak musí najprv získať authorization grant. V nasledujúcom texte je vysvetlené
ako to funguje.
Client ID, Client Secret a Redirect URI
Predtým ako klientská aplikácia môže požiadať o prístup k údajom, musí byť najprv zareg-
istrovaná s autorizačným serverom a asociovaná zo serverom, kde sú údaje. Registrácia je
väčšinou iba jednorázová úloha. Pri registrácií klientská aplikácia dostane priradené client
ID, client secret od autorizačného servera. Client ID a client secret sú unikátne pre každú
aplikáciu. Vždy keď chce klientská aplikácia pristúpiť k údajom na serveri, tak musí vždy
poslať najprv svoje client ID a client secret. Pri registrácií treba tiež zaregistrovať redirect
URI. Toto URI sa používa vtedy keď vlastník dát potvrdí autorizáciu pre aplikáciu. Hneď
ako je vlastník úspešne autorizovaný v klientskej aplikácií cez autorizačný server, tak ho
presmeruje späť do klientskej aplikácie resp. na zadanú URI.
Authorization grant
Aplikácia získa povolený prístup k údajom vlastníka v spolupráci autorizačného servera
a servera s údajmi. Špeciﬁkácia OAuth 2.0 poskytuje rôzne typy autorization grants.
Každý typ má rôzne bezpečnostné charakteristiky.
Existujú tieto typy:
• Autorization Code
• Implicit
• Resource Owner Password Credentials
• Client Credentials
V tejto práci popíšeme typ Autorization Code, pretože je aj využívaný v našej
aplikácií.[6]
Celý proces získania autorizačného kódu je zobrazený na diagrame č.7. Začína sa to
tak, že užívateľ požiada cez aplikáciu o prístup na server, tak že zadá svoje prihlasovacie
údaje do cloudu. Po zadaní údajov sa spýta či chce sprístupniť dané údaje tejto aplikácií.
Nasledovne aplikácia odošle client ID a client secret na autorizačný server. Ak to celé pre-
behlo úspešne tak sa cez HTTP linku vráti aj náš potrebný autorizačný kód a presmeruje
nás späť do aplikácie resp. zadanej redirect URI. Ďalej je postup taký, že treba zaslať na
autorizačný server znovu client ID, client secret a novo získaný autorizačný kód. Následne
18

nám autorizačný server vráti access token a sme prihlásený. Access token potrebujeme
použiť ak chceme pristupovať už ku konkrétnym údajom a ten sa zasiela až na resource
server, ktorý nám hneď vráti požadované údaje.
Obrázok 7: Proces získania dát.
19

3 Implementácia
Na základe zozbieraných teoretických informácií z oblasti eHealthu, telemedicíny,
diabetesu a naštudovaných technológií ako JSON, SQLite, a tvorba natívnych aplikácií
pre Android sme implementovali aplikáciu, ktorá slúži na zaznamenávanie fyzickej aktivity
z externého eHealth zariadenia. Aplikáciu je možné spustiť od verzie Androide 4.0.4 a
vyššie. Z hľadiska aktuálneho využitia verzií Androidu je to logická voľba.
3.1 Popis použitého eHealth zariadenia - krokomer
Zariadenie, ktoré sa bude využívať v bakalárskej práci je krokomer od firmy iHealth
Lab Inc. Táto firma sa venuje distribúcií eHealth zariadení ako je krokomer, glukomer a
bezdrôtová váha.
Obrázok 8: Vzhľad krokomeru od firmy iHealth Labs.
Tento krokomer dokáže sledovať dennú aktivitu človeka pomocou krokov a takisto je
možné sledovať kvalitu spánku. Denné meranie zahŕňa počet krokov, prejdenú vzdialenosť
a spálené kalórie. Nočné meranie zahŕňa dĺžku spánku, kvalitu spánku a počet prebudení.
Nočný režim sa aktivuje dlhým pridržaním tlačidla. Od tohoto okamihu sa začne počítať
čas spánku až do rána a to ukončením dlhším stlačením. Popri tom v noci toto zariadenie
aj počíta počet zobudení, resp aktivitu popri spánku a na základe toho sa vypočíta aj
kvalita spánku v percentách. Na displayi sa zobrazuje čas počas dňa, nameraný počet
krokov, spálené kalórie, prejdenú vzdialenosť a celkovú úroveň aktivity. bežná výdrž
20

batérie na nabitie je 5-7 dní. Vnútorná pamäť dokáže uložiť cca 14 dní. Síce je odolný
proti vode, ale nie je určený pre plávanie.
Údaje sa prenášajú pomocou aplikácie od tejto ﬁrmy. Je možné ju nájsť na tomto
odkaze https://play.google.com/store/apps/details?id=androidNin1.Start. Ap-
likácia a senzor komunikuje cez Bluetooth 4.0 (low energy) a odosiela dáta priamo do
cloudu iHealth, z ktorého je možné údaje ďalej sťahovať pomocou OAuth 2.0 technológie.
3.2 Diagramy
3.2.1 Prípady použitia
Po spustení aplikácie sa vyžaduje prihlásenie na iHealth Labs cloud, kde má užívateľ
uložené všetky merania z krokomeru. Po úspešnom prihlásení sa zobrazí obrazovka zo
sumarizáciou. Aplikácia má implementované menu ako Navigation Drawer, čo znamená,
že po spustení aplikácie sa ovláda bočným panelom, ktorý sa vysúva z ľavej strany. Z tohto
menu je možné spúšťať jednotlivé fragmenty respektíve položky v menu, ktoré zastávajú
istú funkciu. Celé menu je zobrazené na jednoduchom diagrame použitia - obrázok č.9.
Obrázok 9: Diagram použitia prihlásenie do aplikácie.
21

3.2.2 Diagramy tried
Pri dokumentácii netreba zabúdať aj na diagramy tried. Tieto diagramy nám slúžia
na lepšiu orientáciu v kóde pre cudzích ľudí. Diagramy boli vytvorené cez plug-in pre
Eclipse s názvom ObjectAid UML. Vzhľadom na to, že v aplikácii je veľa tried, tak kvôli
rozsahu práce tu bude na ukážku len triedy z balíkov
com.erichstark.pedometer.customListView.sleep
com.erichstark.pedometer.customListView.steps
a zvyšok sa bude nachádzať na médiu v zložke dokumentaciadoc.zip.
Obrázok 10: Diagram tried pre StepItem a príslušný Adaptér.
22

Obrázok 11: Diagram tried pre SleepItem a príslušný Adaptér.
3.3 SQLite databáza
Dáta stiahnuté z iHealth cloudu je potrebné ukladať a následne zobrazovať do apliká-
cie. V Androide sa bežne na takéto účely používa SQLite databáza, ktorá vytvorí jeden
súbor a s tým pracujeme ako s databázou. Síce nemá pokročilejšie typy ako MySQL alebo
PostgreSQL, ale vystačíme si aj zo základnými.
Tabuľka na obrázku č.12 sa používa na uchovávanie údajov, ktoré slúžia pre prístup
do iHealth cloudu.
client_id, client_secret - sú identiﬁkačné reťazce zaregistrovanej aplikácie
access_token – reťazec, ktorý slúži na prístup k údajom
refresh_token – s refresh tokenom sa žiada nový access token
expires – číslo, ktoré určuje vypršanie prístupového reťazca
userid– identiﬁkačný reťazec užívateľa
user_para – dodatočné informácie, ktoré sa môžu odosielať
timestamp – čas, kedy sa vyžiada access token
23

Obrázok 12: SQL tabuľka login.
Údaje prihláseného užívateľa ukladám do tabuľky na obrázku č.13. height_unit –
číslo pre jednotku výšky
weight_unit – číslo pre jednotku váhy
date_of_birth – dátum narodenia
gender – pohlavie
logo – odkaz pre fotku užívateľa
nickname – meno užívateľa
userid – identiﬁkačný reťazec užívateľa
weight – váha užívateľa
Obrázok 13: SQL tabuľka user_t.
24

Obrázok č.14 je tabuľka, ktorá slúži na ukladanie údajov o fyzickej aktivite ako aj jej
názov napovedá.
id - je primárny kľúč pre tabuľku,
calories – celočíselná hodnota určujúca počet spálených kalorií,
dataid – identiﬁkačný reťazec aktuálneho záznamu distance_traveled – vzdialenosť,
ktorá bola nachodená / nabehaná za celý deň
latitude – reprezentuje zemepisnú šírku
longitude - reprezentuje zemepisnú dĺžku
mdate – (measurement date) je dátum, kedy bola fyzická aktivita vykonaná a je vo for-
máte Unix time
note – poznámka pri meraní
steps – počet vykonaných krokov za celý deň
current_record_count – je počet hodnôt na danej stránke
distance_unit – hodnoty pre jednotky dĺžky: 0 pre kilometre, 1 pre míle
next_page_url – odkaz na URL pre ďalšie merania
prev_page_url – odkaz na URL pre predchádzajúce merania
page_length – dĺžka jednej strany
page_number – číslo strany
record_count – počet všetkých záznamov
25

Obrázok 14: SQL tabuľka activity_report.
Obrázok č.15 je tabuľka, v ktorej sa ukladajú údaje o spánku. Zvyšné údaje, ktoré
nie sú popísané sa nachádzajú aj v predchádzajúcej tabuľke.
awaken – počet prebudení za noc
dataid – identiﬁkačný reťazec aktuálneho záznamu
start_time – čas začiatku spánku
end_time – čas zobudenia
fell_sleep – doba, ktorá ubehla pred zaspaním
hours_slept – počet hodín spánku
sleep_eficiency – kvalita spánku v percentách
26

Obrázok 15: SQL tabuľka sleep_report.
3.4 Android
V implementačnej časti Android je ukázané v akom formáte boli JSON štruktúry
prijaté z iHealth Labs cloudu a ako sa spracovávali respektíve získavali cez AsyncTask v
Androide. Ďalej bude ukážka vytvorenia SQLite databázy na Androide a ako sa vytvára
tabuľka. V nasledujúcej sekcii popíšem engine, ktorý bol využítý na vytváranie grafov.
A ako posledná časť je UI samotnej aplikácie.
3.4.1 Vytváranie SQLite databázy
Ako bolo spomenuté, tak je potrebné ukladať niekam údaje a najvhodnejšia tech-
nológia je SQLite databáza. Postup vytvorenia databázy na Androide je nasledovný. V
prvom rade je potrebné vytvoriť triedy reprezentujúce dané tabuľky. Tieto triedy majú
konštruktor na nastavenie dát a bežné get/set metódy. A teraz hlavnou časťou je trieda
DatabaseHelper zobrazený v prílohe ukážka kódu č.B.1.
DATABASE_VERSION je reťazec, ktorý určuje verziu databázy. Vždy keď sa zmení
štruktúra, treba toto číslo inkrementovať manuálne a tabuľky sa znovu vytvoria a zmažú
sa všetky dáta. DATABASE_NAME deﬁnuje názov pre databázu v aplikácií. Ďalej treba
27

definovať všetky stĺpce ako reťazec a prideliť im názov. Toto sa využije pri vytváraní
tabuľky, kde sa to klasicky pospája plusovým znamienkom. A potom sa metóda onCreate
automaticky volá po zmene verzie databázy.
3.4.2 Spracovávanie JSON štruktúr
Ak chceme získať nejakú štruktúru s dátami, musíme prejsť celým procesom auten-
tifikácie ako bolo vysvetlené v kapitole č. 2.4.2. Pri registrácii na iHealth Labs som získal
prihlasovacie dáta pre moju aplikáciu a tie budem využívať ďalej.
Client ID 417483e552844d0a8bd37fb7166401a0
Client Secret 4f6afba3cf624833807e9f64ca2638d6
Redirect Domain http://erichstark.com
API names
OpenApiActivity SC: 17979dfde8cb4c30813ad612d0b974e9
OpenApiActivity SV: e9495e71db784657a16edfadf6f06754
OpenApiSleep SC: 17979dfde8cb4c30813ad612d0b974e9
OpenApiSleep SV: a14d9e8e73aa4dcb98f2db0acaaff690
OpenApiUserInfo SC: 17979dfde8cb4c30813ad612d0b974e9
OpenApiUserInfo SV: 54820bbf0a80476e9718b76389ad40cd
Tabuľka 2: Prístupové údaje do aplikácie
Ako prvá štruktúra pri tomto procese je potrebná tá, v ktorej je obsiahnutý access
token. Ten sa získava počas autentifikácie a je potrebný HTTP odkaz, ktorý sa nachádza na
stránke: http://developer.ihealthlabs.com/dev_documentation_Authentication.
htm. Do všetkých týchto HTTP odkazov je potrebné vkladať prihlasovacie údaje aplikácie
a access token, ktorý je získaný na začiatku.
1 JSON š t r u k t ú r a č . 1 pre z í s k a n i e access token .
2 {
3 "APIName" : " OpenApiWeight OpenApiBPLittle OpenApiBG
4 OpenApiWeightLittle OpenApiActive OpenApiSpO2" ,
5 " AccessToken " : wo∗PaoQkLMSdkV−Zqx−UHoYzQo"∗∗∗∗∗" ,
6 " E x p i r e s " : 172800 ,
7 " RefreshToken " : "vGQentnJBO1kz9WdKCRaMcf"∗∗∗∗∗" ,
8 " UserID " : "05 d f f b e 0dd ∗∗∗∗∗" , " c l i e n t _ p a r a " : " xxx "
9 }
28

1 JSON š t r u k t ú r a č . 2 pre z í s k a n i e u ž í v a t e ľ s k ý c h dát .
2 {
3 " HeightUnit " : 0 ,
4 " WeightUnit " : 0 ,
5 " d a t e o f b i r t h " : 1362355200 ,
6 " gender " : " Male " ,
7 " height " : 179 ,
8 " logo " : " https : // cloud . i h e a l t h . com/716 fccd 2203bd288 . png" ,
9 " nickname " : " xstark@stuba . sk " ,
10 " u s e r i d " : "05 d f f b e 0dd ∗∗∗∗∗" ,
11 " weight " : 81 . 5
12 }
1 JSON š t r u k t ú r a č . 3 pre z í s k a n i e záznamu f y z i c k e j a k t i v i t y .
2 {
3 " ARDataList " : [
4 {
5 " C a l o r i e s " : 109 ,
6 " DataID " : " e34032089471451b926a6a4∗∗∗∗∗" ,
7 " DistanceTraveled " : 0 . 36088 ,
8 " Lat " : 19 . 579758571265153 ,
9 "Lon" : 86 . 49735491466585 ,
10 "MDate" : 1362483513 ,
11 " Note " : "" ,
12 " Steps " : 694
13 }
14 ] ,
15 " CurrentRecordCount " : 50 ,
16 " DistanceUnit " : 0 ,
17 " NextPageUrl " : " http : // cloud . i h e a l t h . com/4a6/ nextpage . . . " ,
18 " PageLength " : 50 ,
19 "PageNumber" : 1 ,
20 " PrevPageUrl " : "" ,
21 " RecordCount " : 256
22 }
V podobných štruktúrach sú prijaté aj údaje pre aktivitu počas spánku (sleep activ-
ity).
29

1 JSON š t r u k t ú r a č . 4 pre z í s k a n i e záznamu o k v a l i t e spánku .
2 {
3 " CurrentRecordCount " : 50 ,
4 " NextPageUrl " : " http : // cloud . i h e a l t h . com/4a6/ nextpage . . . " " ,
5 " PageLength " : 50 ,
6 "PageNumber" : 1 ,
7 " PrevPageUrl " : "" ,
8 " RecordCount " : 288 ,
9 " SRDataList " : [
10 {
11 "Awaken" : 5 ,
12 " DataID " : "6ca9e6 f 4c8c34e4d9a9 eccc ∗∗∗∗∗" ,
13 "EndTime" : 1372103460 ,
14 " F e l l S l e e p " : 25 ,
15 " HoursSlept " : 260 ,
16 " Lat " : 28 . 584006583590064 ,
17 "Lon" : 69 . 43493275457757 ,
18 " Note " : "" ,
19 " S l e e p E f f i c i e n c y " : 92 ,
20 " StartTime " : 1372085160
21 }
22 ]
23 }
Všetky tieto prijaté dáta v JSON formáte treba aj nejak získať a následne spracovať.
Pre získanie dát z HTTP sa v Androide používa AsyncTask. Je to vlastne samostatné
asynchrónne vlákno volané na pozadí, ktoré sa väčšinou používa na sťahovanie dát, ale
môže byť využité aj na zložité výpočty a rôzne podobné veci, ktoré treba vykonať na
pozadí, aby nezamrzlo hlavné UI vlákno, na ktorom je celé rozhranie aplikácie. AsyncTask
je definovaný tromi všeobecnými typmi, volané Params, Progress a Result. A ďalej
má definované štyri kroky volané onPreExecute, doInBackground, onProgressUpdate
a onPostExecute. Pre každé získanie dát máme definovaný samostatný AsyncTask, ale
pre ukážku bude stačiť popísanie jedného, ktorý je v prílohe B.2.
Celý proces funguje tak, že keď sa zavolá AsyncTask, tak do neho vchádza URL kde sú
v parametroch zadané údaje, ktoré sú potrebné v tomto prípade na získanie access tokenu
a to je client id, client secret a auth code. Vytvorí sa nova inštancia triedy ServiceHandler,
ktorá vytvori GET požiadavku na iHealth server a vráti mi požadované údaje ako string.
30

V tomto stringu sa nachádza celá JSON štruktúra. Tú si parsujeme pomocou štandardnej
triedy v JAVE, ktorá sa nazýva JSONObject a jej príslušných metód. Údaje si uložíme
do pripraveného objektu a ten pošlem do metódy onPostExecute. Tá sa vykoná až keď
skončí sťahovanie dát. V nej si už len ukladáme údaje do SQLite databázy pre ďalšie
spracovanie.
3.4.3 Grafy
V aplikácií bolo potrebné aj vizuálne zobrazovať namerané údaje. V Android SDK
sa nenachádza žiadna knižnica na tvorbu grafov, čo je možno škoda, ale existuje veľa
dostupných knižníc pre ich tvorbu. Časť z nich je open-source a niektoré sú platené.
Vybrali sme si open-source knižnicu, ktorá sa volá AChartEngine.
AChartEngine je maličká knižnica ale pritom obsahuje všetku potrebnú funkcional-
itu pre vytváranie rôznych typov grafov. Je možné ju spustiť na všetkých Android zari-
adeniach z verziou 1.6 a vyššie. Podporuje priblíženie grafu, ktoré som ale ja vypol.
Podporuje tri hlavné typy grafov:
• XY grafy: zobrazenie dát na dvoch osiach (čiara, stĺpec, rozsah),
• Kruhové grafy: koláčový,
• Kombinované grafy: dokáže zobraziť kombináciu XY grafov.[5]
Na ukážke kódu č.B.3 v prílohe je základný postup pre vytvorenie grafu cez túto
knižnicu. V XYMultipleSeriesRenderer je možné nastaviť dodatočné parametre ako
titulky pre X aj Y os, mriežku, farby, veľkosť písma, legendu a mnoho ďalšieho. Cez
XYMultipleSeriesDataset sa priradí nejaký dataset, ktorého sa budú brať údaje. A
nasledovne cez private GraphicalView mChart sa vytvorí inštancia grafu.
3.4.4 Rozhranie aplikácie
Celé rozhranie aplikácie je tvorené pomocou Fragmentov. Fragment sa považuje za
nový prístup pri tvorbe užívateľského rozrania, kde medzi Activity a View vstupuje ešte
jedna vrstva a to je Fragment. Fragment ale nevie spracovať všetko. Napríklad nevie,
čo sa má stať po kliknutí na nejaký item. Práve pre tento účel sú tu Activity. Každá
Activity môže obsahovať ľubovoľný počet Fragmentov, ktoré sa chovajú ako View. Dajú
sa deklarovať v layoutových XML súboroch alebo aj pridať v java kóde. Activity môže
volať ich metódy a nastavovať im listenery.[7]
Na kúsku kódu č.B.4 v prílohe je ukázané ako je možné vytvoriť Fragment. Treba v
ňom vždy prepísať metódu onCreateView, ktorá sa vždy volá po otvorení fragmentu. V
31

jej vnútri sa vyskytuje logika, ktorú chceme vykonávať. Toto je konkrétne Fragment, ktorý
využívam na odhlásenie, ale kvôli stručnosti je odstránená logika. Pri vytváraní View je
dôležité mať pripravený XML layout súbor, ktorý definuje vzhľad. V tomto prípade sa
nazýva fragment_logout. Na následujúcich obrázkoch sa nachádza vzhľad aplikácie. Pri
jeho vytváraní sa používali XML prvky ako TextView, ImageView a o ich rozpoloženie sa
starali RelativeLayout a LinearLayout.
Obrázky, ktoré boli vytvorené z Android aplikácie si môžeme všimnúť nižšie. Apliká-
cia funguje tak, že pri spustení sa načíta WebView (obrázok č.16) rozhranie od iHealth,
ktoré slúži na autentifikáciu užívateľa. Po úspešnom prihlásení sa zobrazí hlavná obra-
zovka ako na obrázku č.18 vľavo. Je to vlastne celkový prehľad. Menu aplikácie je im-
plementované ako NavigationDrawer, ktorý sa vysúva zľava aplikácie a sú tam na výber
položky: Užívateľ, Prehľad, História chôdze, Graf chôdze, Kvalita spánku, Graf
spánku a odhlásenie. Hneď vedľa menu je zobrazený užívateľský profil, kde sa aj fo-
tografia sťahuje z iHealth cloud. Na obrázku č.19 vidíme fragmenty histórie chôdze a
kvalitu spánku. Na obrázku č.20 je zobrazenie grafov. V navigačnej lište aplikácie je aj
tlačítko na synchronizáciu údajov zo serverom a tlačítko informácie o aplikácie.
Obrázok 16: WebView s prihlasovacou obrazovkou iHealth.
32

Obrázok 17: Fragment menu a proﬁl.
Obrázok 18: Fragment prehľad a odhlasovanie.
33

Obrázok 19: Fragment história chôdze a spánku.
Obrázok 20: Graf krokov a počet naspaných hodín za jednotlivé dni.
34

Záver
Bakalárska práca nám ozrejmila o čom je eHealth, telemedicína a akú to ma spojitosť
s dnešnými mobilnými zariadeniami. Dozvedeli sme sa o čom je chronické ochorenie
Diabetes Mellitus a pojmy, ktoré s ním súvisia.
Cieľom tejto práce bolo naštudovať si túto problematiku, zanalyzovať súčasný stav a
vytvoriť aplikáciu pre mobilné zariadenie. Väčšinu cieľov sa nám podarilo splniť a teda
najprv sme zistili aký je momentálny stav a potom sme pracovali na implementácií. Výsle-
dok je mobilná aplikácia fungujúca na platforme Android od verzie 4.0.4. Ako prvá vec
sa navrhla lokálna databáza pre SQLite. Ďalšou dôležitou úlohou bola komunikácia zari-
adenia zo serverom na báze protokolu OAuth 2.0. Pomocou tohto protokolu sa získavali
údaje vo formáte JSON a ďalej sa spracovávali a boli zobrazované. Nasledovná úloha bola
zobrazovať dané údaje aj v grafoch.
Aj keď táto aplikácia nie je plnohodnotným riešením, aké by diabetik potreboval, tak
dúfam že aspoň časť z nej bude využitá v budúcnosti v nejakom komplexnom riešení a
uľahčí diabetikom život pri už aj tak zákernom ochorení.
35

Zoznam použitej literatúry
[1] Android.com. Aktuálne využitie verzií androidu. Rok: máj 2014. http://developer.
android.com/about/dashboards/index.html.
[2] American Telemedicine Association. Čo je telemedicína. Rok: 2012. http:
//www.americantelemed.org/about-telemedicine/what-is-telemedicine#
.U4uuAPl_uT5.
[3] Národné centrum zdravotníckych informácií. Elektronické zdravotníctvo - eHealth.
Rok: 2011. http://www.nczisk.sk/eHealth/Pages/default.aspx.
[4] Národné centrum zdravotníckych informácií. Vízia eHealth. Rok:
2011. http://www.ezdravotnictvo.sk/Elektronicke-zdravotnictvo/
Otazky-a-odpovede-o-eHealth/Stranky/Elektronicke-zdravotnictvo.aspx.
[5] Dromereschi, Dan. Eﬀort-free graphs on Android with
AChartEngine. Rok: 2013. http://jaxenter.com/
effort-free-graphs-on-android-with-achartengine-46199.html.
[6] Jenkov, Jakob. OAuth 2.0. Rok: 2014. http://tutorials.jenkov.com/oauth2/
index.html.
[7] Konečný, Matěj. Vyvíjíme pro Android: Fragmenty. Rok: 2012. http://www.
zdrojak.cz/clanky/vyvijime-pro-android-fragmenty-a-sqlite-databaze/.
[8] Kreze-Spirová, Eva. Moja kniha o cukrovke. Bratislava : EVYAN spol s.r.o., 2007.
s. 120. ISBN: 978-80-968599-7-9.
[9] Lebeda, Martin. SQLite - Ultra lehké SQL. Rok: 2003. http://www.root.cz/
clanky/sqlite-ultra-lehke-sql/.
[10] MUDr. Zbynek Schroner, PhD. a MUDr. Vladimír Uličiansky. Vplyv fyzickej aktivity
na pacienta s cukrovkou. Rok: 2012. http://www.diabezita.sk/index/article?
title=fyzicka-aktivita-u-pacienta-s-cukrovkou.
[11] Ujbányai, Miroslav. Programujeme pro Android. 1. Praha : Grada Publishing, a.s.,
2012. s. 192. ISBN: 978-80-247-3995-3.
[12] www.json.org. Špeciﬁkácia JSON formátu. Rok: 2014. http://www.json.org/.
[13] www.sqlite.org. O SQLite. Rok: 2014. http://www.sqlite.org/about.html.
36

Prílohy
A Štruktúra elektronického nosiča . . . . . . . . . . . . . . . . . . . . . . . . . . . II
B Algoritmus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . III
I

A Štruktúra elektronického nosiča
pracabakalarska_praca.pdf
zdrojovy_kodprojekt.zip
dokumentaciadoc.zip
nastrojeadt-bundle-windows-x86-20140321.zip
nastrojejdk-7u60-windows-i586.exe
navodnavod_na_pouzitie.pdf
spustitelna_aplikaciaFeiStuNctsKrokomer.apk
II

B Algoritmus
Algoritmus B.1 Základný kód pre vytvorenie DB.
1 public class DatabaseHelper extends SQLiteOpenHelper {
2 // database v e r s i o n − minimum 1
3 private s t a t i c f i n a l int DATABASE_VERSION = 7;
4 // database name
5 private s t a t i c f i n a l S t r i n g DATABASE_NAME = " pedometer . db" ;
6 // t a b l e name
7 private s t a t i c f i n a l S t r i n g TABLE_LOGIN = " l o g i n " ;
8 // l o g i n columns
9 private s t a t i c f i n a l S t r i n g ACCESS_TOKEN = " access_token " ;
10 // c r e a t e t a b l e l o g i n
11 private s t a t i c f i n a l S t r i n g CREATE_TABLE_LOGIN =
12 "CREATE TABLE " + TABLE_LOGIN + " ( " + KEY_ID +
13 " INTEGER PRIMARY KEY, " + CLIEND_ID + " TEXT, "
14 + CLIENT_SECRET + " TEXT, " + ACCESS_TOKEN + " TEXT, "
15 + REFRESH_TOKEN + " TEXT, " + EXPIRES + " INTEGER , "
16 + USER_ID + " TEXT, " + USER_PARA + " TEXT, " + TIMESTAMP
17 + " TEXT" + " ) " ;
18
19 @Override
20 public void onCreate ( SQLiteDatabase db ) {
21 // CREATE TABLES
22 db . execSQL (CREATE_TABLE_LOGIN ) ;
23 }
III

Algoritmus B.2 AsyncTask pre prijatie access tokenu
1 public class AsyncTaskLoginData
2 extends AsyncTask<String , Void , Login> {
3 @Override
4 protected Login doInBackground ( S t r i n g . . . arg0 ) {
5 // Creating s e r v i c e handler c l a s s i n s t a n c e
6 ServiceHandler sh = new ServiceHandler ( ) ;
7 // Making a request to u r l and g e t t i n g response
8 S t r i n g j s o n S t r = sh . makeServiceCall ( arg0 [ 0 ] ,
9 . . . ServiceHandler .GET) ;
10 Login l o g i n = new Login ( ) ;
11 i f ( j s o n S t r != n u l l ) {
12 try {
13 JSONObject jObjLogin = new JSONObject ( j s o n S t r ) ;
14 l o g i n . setAccess_token (
15 . . . jObjLogin . g e t S t r i n g ( " AccessToken " ) ) ;
16 } catch ( JSONException e ) {
17 e . printStackTrace ( ) ;
18 }
19 }
20 return l o g i n ;
21 }
22 @Override
23 protected void onPostExecute ( Login r e s u l t ) {
24 db = new DatabaseHelper ( context ) ;
25 long logee = db . createLogin ( r e s u l t ) ;
26 S t r i n g u s e r U r l = " https :// api . i h e a l t h l a b s . com:8443/ "
27 + " openapiv2 / user /" + "db . getLogin ( 1 ) . getUser_id () "
28 + " . json /? c l i e n t _ i d=" + MainActivity . CLIENT_ID
29 + "&c l i e n t _ s e c r e t=" + MainActivity . CLIENT_SECRET
30 + "&r e d i r e c t _ u r i=http :// e r i c h s t a r k . com&access_token="
31 + db . getLogin ( 1 ) . getAccess_token ()
32 +"&sc =17979 dfde8cb4c30813ad612d0b974e9 "
33 + "&sv =54820 bbf0a80476e9718b76389ad40cd " ;
34 db . c l o s e ( ) ;
35 }
IV

Algoritmus B.3 Základný kód pre vytvorenie grafu.
1 XYMultipleSeriesRenderer multiRenderer =
2 new XYMultipleSeriesRenderer ( ) ;
3 . . .
4 // Creating a dataset to hold each s e r i e s
5 XYMultipleSeriesDataset dataset = new XYMultipleSeriesDataset ( ) ;
6 . . .
7 // Adding V i s i t s S e r i e s to dataset
8 dataset . addSeries ( v i e w s S e r i e s ) ;
9 . . .
10 private GraphicalView mChart = ( GraphicalView )
11 ChartFactory . getTimeChartView ( g e t A c t i v i t y () ,
12 dataset , multiRenderer , "dd−MMM−yyyy " ) ;
Algoritmus B.4 Základný kód pre vytvorenie Fragmentu.
1 public class LogoutFragment extends Fragment {
2 @Override
3 public View onCreateView ( L a y o u t I n f l a t e r i n f l a t e r ,
4 ViewGroup container ,
5 Bundle s a v e d I n s t a n c e S t a t e ) {
6 View rootView = ( View ) i n f l a t e r . i n f l a t e (
7 R. layout . fragment_logout ,
8 container ,
9 f a l s e ) ;
10 // l o g i c
11 return rootView ;
12 }
13 }
V

Bachelor thesis: Design of aplication for monitoring physical activity

More Related Content

Featured (20)

Bachelor thesis: Design of aplication for monitoring physical activity