Kiwiki - Príspevky používateľa [sk]

Testovanie aplikácie nSoric aAurela

2020-09-03T20:59:19Z

Matus:

{{Praca_uvod|5|Návrh a implementácia Android aplikácie pre monitoring priemyselného procesu|Informačný systém Sensorical|Platforma Android|Návrh aplikácie nSoric aAurela|Implementácia aplikácie nSoric aAurela|Testovanie aplikácie nSoric aAurela}}

__TOC__

= =
Finálnou fázou vývoja aplikácie bolo jej testovanie a následné nasadenie do praxe. Testovanie aplikácie bolo zamerané výhradne na používateľské testy, ktoré boli rozdelené na dve kategórie: testovanie scenármi a testovanie používateľských rozhraní. Počas celého procesu vývoja aplikácie boli používané logovacie správy (konzolové výpisy), pomocou ktorých sa sledovali sekvencie vykonávaných krokov aplikácie. Vďaka použitiu logovacích správ bolo možné odstrániť logické chyby a výrazne optimalizovať jednotlivé funkcionality aplikácie. Vo finálnej verzii aplikácie boli všetky logovacie správy odstránené.

==== Testovacie scenáre ====

Podstatou tejto skupiny testov bolo testovanie funkcií a správania aplikácie na základe vopred definovaných scenárov. Každý testovací scenár mal vopred definované vstupy a akcie, ktoré bolo nutné vykonať. Po vykonaní vstupných akcií sa sledovalo správanie aplikácie a jej vhodné zareagovanie na výstupe.

==== Testovací scenár č.1 ====

* '''Akcia''' - pokus o pripojenie na server so zle zadanou adresou.
* '''Vstup''' - zadaná neplatná webová adresa Sensorical servera.
* '''Výstup''' - aplikácia zareagovala správne, zobrazila upozornenie, že daný server nebol rozpoznaný a vyzvala používateľa na opravu zadaných údajov.

==== Testovací scenár č.2 ====

* '''Akcia''' - pokus o prihlásenie do aplikácie bez vyplnenia prihlasovacích údajov.
* '''Vstup''' - prázdne polia prihlasovacích údajov.
* '''Výstup''' - aplikácia zobrazila oznámenie s nevhodným textom: “Nesprávne zadané prihlasovacie meno alebo heslo”.
* '''Oprava''' - text oznámenia bol zmenený na: “Musíte vyplniť všetky polia”.

==== Testovací scenár č.3 ====

* '''Akcia''' - odhlásenie a opätovné prihlásenie do aplikácie.
* '''Vstup''' - výber akcie z kontextového menu “Odhlásiť sa”.
* '''Výstup''' - v aplikácii boli zapamätané prihlasovacie údaje naposledy prihláseného používateľa a týmito údajmi boli automaticky predvyplnené polia prihlasovacej obrazovky.
* '''Oprava''' - chyba bola odstránená: po odhlásení z aplikácie sú odstránené údaje o naposledy prihlásenom používateľovi.

==== Testovací scenár č.4 ====

* '''Akcia''' - spustenie aplikácie bez internetového pripojenia.
* '''Vstup''' - používateľ je prihlásený - otvorená obrazovka prehľadu.
* '''Výstup''' - aplikácia zareagovala správne, zobrazila dialóg o nedostupnosti internetového pripojenia a ponúkla možné riešenia (pokračovať s naposledy stiahnutými údajmi, aktivácia internetového pripojenia).

==== Testovací scenár č.5 ====

* '''Akcia''' - prioritné otvorenie prehľadu obľúbených senzorov.
* '''Vstup''' - používateľ pridá ľubovoľný senzor do zoznamu obľúbených, ukončí a znova spustí aplikáciu.
* '''Výstup''' - aplikácia zareagovala správne, po spustení prednostne otvorila používateľom vytvorený prehľad obľúbených senzorov.

==== Testovací scenár č.6 ====

* '''Akcia''' - zmena orientácie obrazovky zariadenia.
* '''Vstup''' - používateľ zmení orientáciu obrazovky zariadenia z vertikálnej na horizontálnu a naopak.
* '''Výstup''' - aplikácia zareagovala správne, zmenila rozloženie obrazovky. Pre horizontálnu orientáciu boli použité horizontálne rozloženia, pre vertikálnu orientáciu, rozloženia vertikálne.

==== Testovanie na rôznych zariadeniach ====

Druhá skupina testov bola zameraná na grafické používateľské rozhranie jednotlivých obrazoviek aplikácie. Tieto testy zahŕňali inštaláciu aplikácie na zariadeniach s rôznymi verziami OS Android (5.0 Lollipop až 9.0 Pie) a následné testovanie správneho zobrazenia jednotlivých komponentov na obrazovke. Aplikácia bola testovaná celkovo na 8 rôznych zariadeniach:

==== Telefóny ====

* Samsung Galaxy S9: OS - 9.0 Pie, uhlopriečka - 5.8", rozlíšenie - 1440x2960 px
* Sony Xperia XZ2: OS - 9.0 Pie, uhlopriečka - 5.7", rozlíšenie - 1080x2160 px
* Samsung Galaxy S7: OS - 8.1 Oreo, uhlopriečka - 5.1", rozlíšenie - 1440x2560 px
* Huawei P10: OS - 9 Pie, uhlopriečka - 5.1", rozlíšenie - 1080x1920 px
* Huawei P Smart: OS - 8.0 Oreo, uhlopriečka - 5.65", rozlíšenie - 1080x2160 px
* Samsung Galaxy S5: OS - 6.0.1 Marshmallow, uhlopriečka - 5.1", rozlíšenie - 1080x1920 px
* Google Pixel XL (emulátor) - OS - 9 Pie, uhlopriečka - 5.5", rozlíšenie - 1440x2560 px
* Google Pixel 2 XL (emulátor): OS - 5.0 Lollipop, uhlopriečka - 6.0", rozlíšenie - 1440x2880 px
* Nexus 6P (emulátor): OS - 9 Pie, uhlopriečka - 5.7", rozlíšenie - 1440x2560 px

==== Tablety ====

* Samsung Galaxy Tab S2: OS - 7.0 Nougat, uhlopriečka - 9.7", rozlíšenie - 1536x2048 px
* Nexus 10 (emulátor): OS - 9.0 Pie, uhlopriečka - 10.1", rozlíšenie - 2560x1600 px

Výsledkom týchto testov boli odhalené nasledujúce chyby: texty pri spustení aplikácie na tablete boli príliš veľké, rozhádzané rozloženie komponentov prihlasovacej obrazovky pri horizontálnej orientácii obrazovky zariadenia. Všetky odhalené chyby boli opravené.

= Záver =

Výstupom tejto bakalárskej práce je funkčná Android aplikácia pre prístup a vizuálnu prezentáciu dát meracieho systému Sensorical. Aplikácia má interné využitie obmedzené len na používateľov evidovaných v tomto systéme.

Každý používateľ má možnosť voľby adresy servera, ku ktorému sa chce prihlásiť a ktorého dáta chce zobraziť. Najnovšie dáta sú zo servera sťahované automaticky vždy pri spustení resp. prihlásení do aplikácie. V prípade nedostupnosti internetového pripojenia sú používateľovi zobrazené naposledy stiahnuté dáta uložené v SQLite databáze. Obsah zobrazený prihlásenému používateľovi je filtrovaný na základe prístupových oprávnení, ktoré má každý používateľ pridelené administrátorom systému.

Výsledná aplikácia disponuje funkcionalitami ako vykresľovanie grafov nameraných hodnôt za zvolené obdobie, zobrazovanie trendov nameraných hodnôt, zobrazovanie štatistík nameraných hodnôt za zvolené obdobie (priemerná, maximálna, minimálna hodnota) a iné. Každý používateľ má taktiež možnosť vytvoriť si vlastný zoznam obľúbených senzorov, ktorý mu bude zobrazovaný prioritne. Aplikácia bola implementovaná s dôrazom na intuitívne používateľské rozhranie vytvorené podľa sprievodcu Material Design. Pre vyšší používateľský komfort a pre efektívnejšie využívanie rozložení obrazoviek boli vytvorené rôzne rozloženia komponentov pre vertikálnu a horizontálnu orientáciu obrazovky. Aplikácia bola implementovaná v dvoch jazykových mutáciách anglickej a slovenskej, medzi ktorými sa prepína automaticky podľa predvoleného jazyka zariadenia.

Po vytvorení bola aplikácia podrobená používateľským testom. Na základe týchto testov boli odstránené nedostatky a chyby. Tieto testy taktiež poskytli viaceré námety na zlepšenie (napr. zmena štýlu tlačidla pre pridanie senzora do obľúbených), ktoré boli zakomponované do finálnej verzie aplikácie. Odladená verzia aplikácie bola nasadená do praxe a prevádzkovaná na dvoch rôznych serveroch. Jeden zo serverov prijímal namerané dáta s miernymi výpadkami s čím si aplikácia dokázala poradiť a zobrazovala správne hodnoty adekvátne realite.

Z vyššie uvedených funkcií a vlastností môžeme konštatovať, že výsledná aplikácia spĺňa všetky požiadavky, ktoré boli pre jej vývoj definované. Na druhú stranu existujú funkcie, ktoré by mohli byť v budúcnosti a v prípade záujmu pridané ako napr. administrátorská časť systému, alebo možnosť registrácie do systému priamo cez aplikáciu.

Vývoj tejto mobilnej aplikácie bol pre mňa veľkým prínosom. Oboznámil som sa so základnými princípmi tvorby mobilných aplikácií pre platformu Android, naučil som sa pracovať s efektívnymi Android knižnicami Room a RxJava a rozšíril som svoje znalosti v objektovo orientovanom programovaní a jazyku Java.

Súbor:Snackbar.png

2020-09-03T20:50:21Z

Matus:

Testovanie aplikácie nSoric aAurela

2020-09-03T20:49:49Z

Matus:

Súbor:Graph view land.png

2020-09-03T20:34:16Z

Matus:

Súbor:Graph view.png

2020-09-03T20:33:26Z

Matus:

Súbor:Recycler view dashboard edit.png

2020-09-03T20:32:34Z

Matus:

Súbor:Favourites.png

2020-09-03T20:32:23Z

Matus:

Súbor:Api call diagram final.png

2020-09-03T20:31:48Z

Matus:

Súbor:Completable class final.png

2020-09-03T20:31:30Z

Matus:

Implementácia aplikácie nSoric aAurela

2020-09-03T20:31:09Z

Matus: /* Vytvorenie, odoslanie a spracovanie požiadavky */

{{Praca_uvod|4|Návrh a implementácia Android aplikácie pre monitoring priemyselného procesu|Informačný systém Sensorical|Platforma Android|Návrh aplikácie nSoric aAurela|Implementácia aplikácie nSoric aAurela|Testovanie aplikácie nSoric aAurela}}

__TOC__

= =
Implementácia používateľského rozhrania a jednotlivých funkcionalít aplikácie vychádza zo špecifikácie požiadaviek a navrhnutej štruktúry aplikácie v kapitole [[#navrh|[navrh]]]. V tejto kapitole sú postupne opísané: implementácia používateľského rozhrania aplikácie, práca s dátami, komunikácia so serverom a samotná vizualizácia dát v aplikácii.

== Používateľské rozhranie aplikácie ==

Jednotlivé obrazovky tvoriace používateľské rozhranie aplikácie, prostredníctvom ktorých používateľ s aplikáciou interaguje, sú implementované podľa navrhnutej štruktúry aplikácie (časť [[#navrh_aktivity|[navrh_aktivity]]]) ako jednotlivé triedy Android aktivít. Tieto Android aktivity rozdeľujú aplikáciu na dve časti: primárnu a sekundárnu.

Aktivity primárnej časti poskytujú používateľovi priamy prístup k prehľadu aktuálneho stavu meracieho systému Sensorical. Aktivity sekundárnej časti predstavujú pomocné aktivity, ktoré sú však nevyhnutné pre prístup do primárnej časti, tj. nutnosť výberu adresy servera, ku ktorému sa chce používateľ pripojiť, ako aj samotné prihlásenie do aplikácie. '''Android aktivity primárnej časti'''

* Dashboard - aktivita, ktorá sprostredkováva prehľad všetkých aktuálne dostupných senzorov a ich údajov, kategorizovaných v rámci oblastí a sektorov
* Favourites - aktivita, ktorá zobrazuje prehľad vybraných, obľúbených senzorov a ich údaje
* GraphView - aktivita ktorá zobrazuje detailný prehľad konkrétneho senzora, históriu nameraných hodnôt (grafy a štatistiky)

'''Android aktivity sekundárnej časti'''

* ServerSelect - aktivita pre výber adresy servera
* Login - aktivita pre prihlásenie do aplikácie
* About - aktivita zobrazujúca doplňujúce informácie o aplikácií

=== Android a Material Design ===

Material Design predstavuje dizajnérsky jazyk vyvinutý spoločnosťou Google v roku 2014, ktorý priniesol množstvo inovácií a zmien do spôsobu tvorby grafických používateľských rozhraní. Filozofia konceptu Material Design vychádza z fyzikálnych vlastností reálnych objektov ako 3D kontúry, odraz svetla, tiene…

Medzi inovácie, ktoré Material Design prináša patria nové komponenty ako napr. karty (Cards), plávajúce tlačidlo (Floating action button), oznámenia (Snackbars), animácie, prechody a iné. Najväčšou zmenou, ktorú Material Design priniesol je tzv. efekt hĺbky resp. používanie osi z. Jednotlivé komponenty sú zobrazované v pomyselných vrstvách v rôznych hladinách (radené nad sebou). Najdôležitejší komponent, s ktorým môže požívateľ aktuálne pracovať je zobrazený ponad ostatné komponenty (vo vyššej hladine osi z). Výhodou používateľských rozhraní, využívajúcich princíp radenia komponentov do vrstiev, je intuitívne prostredie, v ktorom sa používateľ ľahko zorientuje, s ktorými komponentmi môže aktuálne pracovať.

=== Implementácia Material Design v aplikácii ===

Pri implementácii používateľského rozhrania aplikácie boli odporúčania Material Design aplikované priamo v jednotlivých grafických rozhraniach Android aktivít a ich komponentoch. Tieto odporúčania (napr. odsadenie, vyvýšenie, farby, tlačidlá a tvary) presne definujú prípady použitia - kedy a ako môže byť daný komponent použitý, ako má vyzerať a ako sa má správať.

Pri tvorbe grafických používateľských rozhraní a taktiež pre exaktný popis parametrov jednotlivých komponentov sú používané abstraktné jednotky - dp (density pixel). Jednotky dp sú prepočítavané k referenčnému rozlíšeniu v pixeloch: 1dp=1 pixel na obrazovke s rozlíšením 160dpi (bodov na palec).

=== Material Design komponenty využité v aplikácii ===

==== Cards ====

'''Funkcia:''' Cards (Karty) zobrazujú obsah a akcie súvisiace s jedným senzorom (). Každá karta senzora zobrazuje: názov senzora, tlačidlo pre akciu pridania/odstránenia do/zo zoznamu obľúbených senzorov, priemernú hodnotu, poslednú nameranú hodnotu a dátum kedy bola nameraná. Na karte senzora je taktiež vykresľovaný trend meraní daného senzora. Trend predstavuje smer rastu resp. poklesu nameraných hodnôt za poslednú hodinu.

'''Material Design odporúčania:'''

* Vyvýšenie karty od 1dp do 8dp, optimálne 2dp.
* Ak sú v karte použité oddeľovače obsahu, nemali by prechádzať cez celú kartu, ale len cez jej časť.

[[File:card_sensor.png|thumb|none|510px|alt=Karta zobrazujúca údaje jedného senzora|Karta zobrazujúca údaje jedného senzora]]

==== Floating Action Button ====

'''Funkcia:''' plávajúce tlačidlo (FAB) je používané na vyhľadávanie v aktivitách prehľadu (Dashboard, Favourites). Tlačidlo je štandardne viditeľné, avšak pri posunutí v zozname smerom dolu je skryté, z dôvodu úplnej viditeľnosti údajov poslednej karty zoznamu. Pri posunutí v zozname smerom hore sa stane tlačidlo znova viditeľné.

'''Material Design odporúčania:'''

* FAB je zobrazené ponad všetok ostatný obsah, štandardne v pravom dolnom rohu.
* Optimálne rodičovské rozloženie - CoordinatorLayout (umožňuje automatické posunutie FAB smerom hore, napr. v prípade zobrazenia Snackbar oznámenia).
* Odporúčaná veľkosť je 56x56dp pre zariadenia s rozlíšením nad 460dp, pre zariadenia s nižším rozlíšením 46x46dp.
* Farba plávajúceho tlačidla je rovnaká ako hlavná farebná schéma aplikácie.
* Odsadenie od okraja obrazovky 16dp, vyvýšenie ponad ostatný obsah do 6dp.

==== AppBar ====

'''Funkcia:''' horná nástrojová lišta sprostredkováva informácie a akcie súvisiace s aktuálnou obrazovkou. Zobrazuje názov aktuálnej obrazovky, rýchle akcie (napr. otvorenie zoznamu obľúbených) a kontextové menu.

'''Material Design odporúčania:'''

* Názov obrazovky je umiestnený na ľavej strane nástrojovej lišty.
* Kontextové akcie sú umiestnené na pravú stranu.
* Ak je použité kontextové menu, je umiestené úplne na pravej strane.
* Vyvýšenie nástrojovej lišty je štandardne 4dp.

==== Snackbar ====

'''Funkcia:''' rýchle oznámenia ukotvené k spodnej časti obrazovky, ktoré informujú o aktuálnom dianí v aplikácii.

'''Material Design odporúčania:'''

* Optimálne rodičovské rozloženie - CoordinatorLayout.
* Snackbar má byť zobrazený len po určitú dobu, bez nutnosti explicitného zrušenia používateľom.

[[File:snackbar.png|207px|Material Design komponenty použité v aplikácii: Snackbar (aktivita Login), AppBar, Card a FAB (aktivita Dashboard)]] [[File:card_app_bar_fab.png|207px|Material Design komponenty použité v aplikácii: Snackbar (aktivita Login), AppBar, Card a FAB (aktivita Dashboard)]]

== Práca s dátami v aplikácii ==

Dáta, s ktorými aplikácia pracuje sú sťahované zo vzdialených serverov a po stiahnutí sú ukladané do SQLite databázy, z ktorej sú sprostredkovávané v aplikácii. Sťahovanie najaktuálnejších meraní prebieha automaticky vždy po spustení resp. prihlásení do aplikácie. V prípade potreby manuálnej aktualizácie nameraných hodnôt, prípadne synchronizácie všetkých dát s aktuálne dostupnými dátami daného servera sú v aplikácii implementované dva rôzne spôsoby manuálnej synchronizácie: aktualizácia len nameraných hodnôt alebo synchronizácia všetkých dát.

Pre zefektívnenie a zrýchlenie sťahovania nameraných hodnôt sa v aplikácii vytvárajú záznamy o dátumoch, za ktoré boli namerané hodnoty úspešne stiahnuté. Vždy pred každým ďalším sťahovaním nových meraní sú tieto záznamy prečítané a stiahnu sa len merania tých dátumov, ktoré nie sú evidované ako stiahnuté.

Keďže aplikácia slúži na monitorovanie aktuálneho stavu a krátkodobejších trendov, maximálny rozsah zobrazenia nameraných hodnôt bol stanovený na jeden týždeň. Aby sa predišlo prílišnému zväčšeniu veľkosti aplikácie dôsledkom sťahovania množstva údajov, sú po každom stiahnutí najnovších nameraných hodnôt vymazané nepotrebné záznamy (merania) staršie ako jeden týždeň.

=== Implementácia SQLite databázy ===

SQLite databáza, ktorá slúži na archiváciu stiahnutých dát a ich následnú prezentáciu v aplikácii, bola vytvorená pomocou knižnice Room (viď [[#room|[room]]]), pričom je implementovaná tak, aby presne korešpondovala s dátovým modelom systému Sensorical (). Aplikácia je navrhnutá tak, že umožňuje vytvárať a pracovať s ľubovoľným počtom SQLite databáz, ktoré sú vytvárané na základe webovej adresy servera, ku ktorej je používateľ aktuálne prihlásený.

Každý server, ku ktorému sa používateľ prihlási, má v aplikácii vytvorenú vlastnú SQLite databázu. Vždy po úspešnom prihlásení k niektorému zo serverov sa aplikácia pokúsi vytvoriť novú databázu s názvom webovej adresy daného servera. Ak už databáza s takýmto názvom existuje, aplikácia ju použije a otvorí.

Pri samotnej implementácii SQLite databázy v aplikácii, boli ako prvé vytvorené jednotlivé triedy reprezentujúce entity databázy ([[#listing:entity|[listing:entity]]]). Každá trieda entity obsahuje premenné, ktoré predstavujú jednotlivé atribúty danej entity. Každá premenná triedy entity je prístupná prostredníctvom metód get a set.

<source lang="java"> @Entity(tableName = "area")
public class Area {
@PrimaryKey
private int id;
private String name;

public void setId(int id) { this.id = id; }
public int getId() { return id; }
public String getName() { return name; }
public void setName(String name) { this.name = name; }
}</source>
Ako ďalšie boli vytvorené potrebné DAO rozhrania ([[#listing:dao|[listing:dao]]] rozhranie AreaDao) a ich metódy pre prístup k dátam databázy. Návratové typy týchto metód boli zvolené na základe očakávaného výsledku SQL dotazu, ktorý daná metóda vykonáva. V prípade DAO metód, ktoré slúžia na výber údajov z SQLite databázy, sú návratové typy zabalené do generickej triedy Maybe, knižnice RxJava, ktorá umožňuje vykonávať prácu týchto metód asynchrónne v paralelných vláknach.

DAO metódy, ktoré do SQLite databázy vkladajú záznamy nameraných hodnôt, využívajú v prípade konfliktu hodnôt primárnych kľúčov parameter IGNORE (ignorovať). Parameter IGNORE zabezpečí neprepísanie existujúceho záznamu v SQLite databáze, pretože nameraná hodnota nemôže byť spätne modifikovaná a teda nie je nutné už existujúce záznamy prepisovať (skrátenie času vykonávania operácie).

DAO metódy zabezpečujúce vkladanie ostatných údajov, majú v prípade konfliktu hodnôt primárnych kľúčov nastavený parameter REPLACE (nahradiť). V prípade modifikácie záznamu na strane servera sa síce nemení hodnota jeho primárneho kľúča, ale hodnota niektorého z atribútov je zmenená. Parameter REPLACE v takomto prípade zabezpečí prepísanie záznamu uloženého v SQLite databáze modifikovaným záznamom stiahnutým zo servera.

<source lang="java"> @Dao
public interface AreaDao {
@Insert(onConflict = OnConflictStrategy.REPLACE)
void insertAllAreas(List<Area> areas);

@Query("select group_view.area_id from group_view
where group_view.user_id=:userID")
Maybe<List<Integer>> getAllAreaIDsforUser(int userID);
}</source>
Ako posledná bola implementovaná abstraktná trieda databázy ([[#listing:database|[listing:database]]]), ktorá je potomkom triedy RoomDatabase. Trieda databázy v aplikácii využíva návrhový vzor Singleton, ktorý zabezpečí vytvorenie a dostupnosť jedinej inštancie triedy databázy počas behu aplikácie. Inštanciu triedy databázy je možné vytvoriť (získať) prostredníctvom statickej metódy getInstance().

<source lang="java"> @Database(entities = {Area.class, Sensor.class}, version = 1)
public abstract class AppDatabase extends RoomDatabase {
public abstract AreaDao areaDao();
private static AppDatabase INSTANCE;

public static AppDatabase getInstance(final Context context){
synchronized (AppDatabase.class) {
if (INSTANCE == null){
INSTANCE = buildDatabase(context.getApplicationContext()); }
} return INSTANCE; }

private static AppDatabase buildDatabase(final Context context){
String DATABASE_NAME = context
.getSharedPreferences("preferences", Context.MODE_PRIVATE)
.getString("server_name", "default_name");
return Room.databaseBuilder(
context, AppDatabase.class, DATABASE_NAME).build(); }
}</source>
V triede databázy sú zadefinované všetky Java triedy jednotlivých entít, z ktorých SQLite databáza pozostáva a taktiež abstraktné metódy všetkých DAO rozhraní, prostredníctvom ktorých môžno vytvoriť inštancie rozhraní v iných triedach. V aplikácii je v triede databázy implementovaná metóda buildDatabase(), ktorá zisťuje názov aktuálneho webového servera (čítanie zo SharedPreferences - ukladanie menších dát formou kľúč - hodnota), ku ktorému je používateľ prihlásený a tento názov použije pre vytvorenie resp. otvorenie databázy s daným názvom, volaním metódy build().

=== Práca s SQLite databázou ===

Práca s SQLite databázou, konkrétne vykonávanie dotazov na výber údajov pre niektorú z aktivít prehľadu (Dashboard, Favourites, GraphView) je v aplikácii realizované sekvenčne. Najskôr sa vykoná referenčný výber, pričom všetky ostatné dotazy čakajú vo fronte. V momente, kedy sa aktuálny výber dokončí, začne sa vykonávať nasledujúci (čakajúci). Sekvenčný spôsob vykonávania práce je zvolený z dôvodu závislosti vstupných parametrov (podmienok pre vykonanie) čakajúceho dotazu, na výsledku jemu predchádzajúcemu výberu.

Aby aplikácia zobrazila len ten obsah, na ktorý má prihlásený používateľ pridelené práva je využitý jedinečný identifikátor každého používateľa aplikácie - ID. Hodnota ID daného používateľa je využitá práve pri referenčnom výbere, na základe ktorého sú vybrané len tie vstupné parametre, na ktoré má používateľ definované oprávnenia.

demonštruje postupnosť volania DAO metód, ktoré vyberajú z SQLite databázy údaje pre aktivitu Dashboard. Obdobným spôsobom sú riešené výbery pre ostatné dve aktivity prehľadov (Favourites a GraphView).

[[File:load_data_for_dashboard_data_flow_final.png|thumb|none|529px|alt=Volanie DAO metód na výber dát z SQLite databázy pre aktivitu Dashboard|Volanie DAO metód na výber dát z SQLite databázy pre aktivitu Dashboard]]

Referenčný výber pre aktivitu Dashboard je výber zoznamu ID všetkých oblastí na základe ID prihláseného používateľa. Následne sa sekvenčne vykonávajú ďalšie výbery, ktorých parametrami sú vždy výsledky predchádzajúceho výberu. V metóde createDashboardData() sa vytvára dátová štruktúra, ktorá obsahuje vlastnosti potrebné pre zobrazenie údajov v Dashboard aktivite: názvy oblastí, sektorov a senzorov, fyzikálne jednotky senzorov, namerané hodnoty a ďalšie. Naplnená dátová štruktúra je odoslaná triede adaptéra (viď [[#vizualizacia|1.3]]), ktorá tieto dáta vizualizuje.

Vykonávanie výberov dát z SQLite databázy prostredníctvom DAO metód predstavuje časovo náročnejšie operácie, ktoré musia prebiehať asynchrónne, v paralelnom vlákne. Pre účel vykonávania DAO metód v paralelnom vlákne je v aplikácii využitá RxJava generická trieda Maybe. znázorňuje princíp návrhového vzoru Observer, ktorý je implementovaný knižnicou RxJava a ktorý je v aplikácii využívaný pre vykonávanie dotazov na výber dát z SQLite databázy použitím triedy Maybe. Tento návrhový vzor zabezpečuje sledovanie priebehu práce časovo náročných DAO metód vykonávaných v paralelných vláknach ([[#listing:rx_operators|[listing:rx_operators]]], metóda getAllAreaIDsForUser()). Po dokončení práce týchto metód dôjde k automatickej notifikácii vlákna špecifikovaného operátorom observeOn() ([[#listing:rx_operators|[listing:rx_operators]]] - hlavné vlákno), na ktoré sú publikované výsledky prostredníctvom rozhrania Consumer a jeho metódy accept(). Metóda accept() prijíma prostredníctvom parametra výsledky vykonaného SQL dotazu danej DAO metódy.

[[File:dao_class_final.png|thumb|none|x188px|alt=Návrhový vzor Observer využitý na výber dát z SQLite databázy|Návrhový vzor Observer využitý na výber dát z SQLite databázy]]

<source lang="java"> areaDao.getAllAreaIDsForUser(userID)
.subscribeOn(Schedulers.io())
.observeOn(AndroidSchedulers.mainThread())
.subscribe(new Consumer<List<Integer>>() {
@Override
public void accept(List<Integer> areaIDs) { }
});</source>
=== Komunikácia so vzdialeným serverom ===

Pre komunikáciu aplikácie so serverovým API je využitý socketový dátový prenos. Požiadavky/odpovede sú odosielané/prijímané v textovom formáte JSON. Po prijatí odpovede sa prechádza tá časť odpovede, ktorá obsahuje relevantné dáta (hodnota kľúča JSON objektu “data”). Časť odpovede “data” a jej hodnoty sa prechádzajú a ukladajú do dátových štruktúr (triedy jednotlivých entít), ktoré sú po naplnení vložené do SQLite databázy.

==== Vytvorenie, odoslanie a spracovanie požiadavky ====

Vytvorenie a odoslanie požiadavky na API a následné spracovanie odpovede zabezpečujú v aplikácii tri triedy (ClientSocket, ApiResponses, ApiDataPresenter), ktorých zjednodušenú štruktúru znázorňuje diagram tried na obrázku [[#fig:class_diagram|1.6]].

* trieda '''ClientSocket''' (odoslanie požiadavky) - konvertuje požiadavku do formátu JSON, otvára spojenie so serverom, odosiela požiadavku, čaká na odpoveď a vracia ju späť metóde triedy ApiResponses, ktorá požiadavku vyvolala.
* trieda '''ApiResponses''' (vytvorenie požiadavky) - vytvára a posiela triede ClientSocket údaje potrebné pre odoslanie požiadavky prostredníctvom parameterov metódy sendRequest(). Trieda ApiResponses zároveň prijíma a vracia späť textovú odpoveď metóde triedy ApiDataPresenter, ktorá danú požiadavku vyvolala.
* trieda '''ApiDataPresenter''' (spracovanie odpovede) - inicializuje proces vytvárania požiadavky volaním príslušnej metódy triedy ApiResponses, transformuje prijatú odpoveď na JSON objekt, ktorého hodnoty ukladá do dátovej štruktúry.

[[File:class_diagram.png|thumb|none|x205px|alt=Zjednodušený diagram tried zabezpečujúcich komunikáciu so serverovým API|Zjednodušený diagram tried zabezpečujúcich komunikáciu so serverovým API]]

Proces komunikácie so vzdialeným serverom je časovo náročná operácia, ktorá musí byť vykonávaná asynchrónne, v paralelnom vlákne. V aplikácii je pre tento účel využitá RxJava trieda Completable. znázorňuje návrhový vzor Observer, ktorý je implementovaný knižnicou RxJava a ktorý je v aplikácii využívaný pre komunikáciu so serverovým API použitím triedy Completable. Podstata tohoto návrhového vzoru spočíva v tom, že po ukončení časovo náročnej metódy ([[#listing:completable|[listing:completable]]] riadok 3, metóda run()) dôjde k automatickej notifikácii vlákna špecifikovaného operátorom observeOn(). Notifikáciu špecifikovaného vlákna ([[#listing:completable|[listing:completable]]] - hlavné vlákno) zabezpečuje rozhranie CompletableObserver a jeho metóda onComplete(), ktorá je zavolaná, ak komunikácia so serverom a spracovanie odpovede prebehli v poriadku. Samotná komunikácia so serverom prebieha v tele metódy run() volaním metódy apiDataPresenter.getAreas(), ktorá vyvolá konkrétnu požiadavku.

[[File:completable_class_final.png|thumb|none|x188px|alt=Návrhový vzor Observer využitý na komunikáciu so serverovým API|Návrhový vzor Observer využitý na komunikáciu so serverovým API]]

<source lang="java"> Completable.fromRunnable(new Runnable() {
@Override
public void run() {
areaDao.insertAllAreas(apiDataPresenter.getAreas());
}
}).subscribeOn(Schedulers.io())
.observeOn(AndroidSchedulers.mainThread()
.subscribe(new CompletableObserver() {
@Override
public void onSubscribe(Disposable d) { }
@Override
public void onComplete() { }
@Override
public void onError(Throwable e) { } });</source>
Textový formát odpovede z API je vrátený do triedy ApiDataPresenter, v ktorej sa transformuje na JSON objekt ([[#listing:api_data_presenter|[listing:api_data_presenter]]], metóda parseAreaResponse()). V tejto metóde sa prechádza pole hodnôt s hodnotou kľúča “data”, pričom jednotlivé hodnoty tohto poľa sú opäť polia, ktorých hodnoty sa ukladajú do dátovej štruktúry, ktorá je vrátená späť do miesta volania ([[#listing:completable|[listing:completable]]], riadok 4). Spôsob vytvárania JSON objektu z prijatej odpovede, prechádzanie a ukladanie jeho hodnôt do dátovej štruktúry zobrazuje [[#listing:api_data_presenter|[listing:api_data_presenter]]]. Postupnosť prechodu medzi triedami a formát dát v jednotlivých triedach počas komunikácie s API znázorňuje .

<source lang="java"> public ArrayList<Area> getAreas() {
parseAreaResponse();
return this.areaList;
}

private void parseAreaResponse() {
String serverResponse = apiResponses.getAreaResponse();
if (!serverResponse.isEmpty()) {
JSONObject response = new JSONObject(serverResponse);
JSONArray array = response.getJSONArray("data");
for (int i = 0; i < array.length(); i++) {
Area area = new Area();
area.setId(array.getJSONArray(i).getInt(0));
area.setName(array.getJSONArray(i).getString(1));
this.areaList.add(area);
}
}
}</source>
[[File:api_call_diagram_final.png|thumb|none|585px|alt=Prenos a formát dát v jednotlivých triedach počas komunikácie s API|Prenos a formát dát v jednotlivých triedach počas komunikácie s API]]

== Vizualizácia dát v aplikácii ==

Prezentáciu dát v aktivitách prehľadu (Dashboard, Favourites) zabezpečujú komponenty - CardView, RecyclerView a Adaptér. V aktivite detailného prehľadu konkrétneho senzora (GraphView) sú dáta vizualizované prostredníctvom grafov - knižnica MPAndroidChart.

=== Vizualizácia dát v aktivitách Dashboard a Favourites ===

==== CardView ====

CardView je grafická reprezentácia karty (Card [[#design|1.1.2]]), predstavuje rodičovské rozloženie pre všetky v nej obsiahnuté View prvky (textové polia, tlačidlá, obrázky…).

==== RecyclerView ====

RecylerView predstavuje model, ktorý umožňuje zobraziť väčšie množstvo údajov vo forme zoznamu. V aplikácii sú ako jednotlivé položky zobrazené v RecyclerView použité karty. Výhodou používania RecyclerView je jeho rýchlosť, pretože sa nevykresľujú (nevytvárajú) naraz všetky karty, ale vytvárajú sa len tie, ktoré sa aktuálne zmestia na obrazovku. Pre naplnenie RecyclerView kartami a ich následné zobrazenie sa využívajú návrhové vzory (triedy) ViewHolder a Adaptér. Jednotlivé karty zobrazené v RecyclerView sú reprezentované objektmi nazývanými view holders. Tieto objekty sú inštanciami tried, ktoré sú potomkami triedy RecyclerView.ViewHolder.

==== ViewHolder ====

ViewHolder je návrhový vzor, ktorý zabezpečuje vytvorenie objektu daného CardView rozloženia spolu s jej View prvkami. Takto vytvorený objekt môže byť použitý viacnásobne, bez nutnosti opakovanej inicializácie View prvkov tohto objektu, volaním metódy findViewById(), čo znižuje pamäťovú náročnosť a zároveň výrazne zrýchľuje proces listovania v RecyclerView. Vytvorené view holder objekty reprezentujú karty, ktoré sú zobrazené v RecyclerView. Tento návrhový vzor možno použiť vytvorením vnútornej triedy, potomok triedy RecyclerView.ViewHolder, v triede adaptéra.

==== Adaptér ====

Adaptér je návrhový vzor, ktorý funguje ako most medzi používateľským rozhraním a dátami. V Androide predstavuje adaptér triedu, ktorá sprostredkováva dáta RecyclerView. Trieda adaptéra (potomok triedy RecyclerView.Adapter) zabezpečuje správu jednotlivých view holder objektov prostredníctvom preťažených metód rodičovskej triedy: vytvorenie view holder objektov - metóda onCreateViewHolder, pridávanie vytvorených view holder objektov do RecyclerView - metóda onBindViewHolder().

V aplikácii sú vytvorené dve triedy adaptérov, kde každá z nich sprostredkováva dáta konkrétnej aktivite: DashboardAdapter (Dashboard aktivita), FavouritesAdapter (Favourites aktivita). Triedy adaptérov v aplikácii využívajú návrhový vzor Singleton, pričom vytvorenie (získanie) inštancie triedy oboch adaptérov je možné prostredníctvom statickej metódy getInstance(). Spôsob implementácie triedy adaptéra v aplikácii je demonštrovaný na jednoduchšej triede FavouritesAdapter, ktorá vykresľuje len jeden typ view holder objektu (len karta senzora, vľavo). Trieda DashboardAdapter vykresľuje tri typy view holder objektov, kde každý z nich reprezentuje kartu: oblasti, sektoru, alebo senzora ( vpravo).

Vytvorenie inštancie triedy FavouritesAdapter a následné nastavenie tejto inštancie ako adaptér objektu recylerView demonštruje kód [[#listing:adapter|[listing:adapter]]].

<source lang="java"> RecyclerView recyclerView = findViewById(R.id.recycler_view);
FavouritesAdapter adapter = FavouritesAdapter.getInstance();
recyclerView.setAdapter(adapter);</source>
[[File:favourites.png|x264px|RecyclerView - aktivita Dashboard (vpravo), aktivita Favourites (vľavo)]] [[File:recycler_view_dashboard_edit.png|x264px|RecyclerView - aktivita Dashboard (vpravo), aktivita Favourites (vľavo)]]

Nasledujúca ukážka ([[#listing:viewHolder|[listing:viewHolder]]]) zobrazuje implementáciu návrhového vzoru ViewHolder v triede adaptéra (FavouritesAdapter), vytvorením vnútornej triedy DataViewHolder. Trieda DataViewHolder inicializuje jednotlivé View prvky CardView rozloženia karty senzora. Každý vytvorený objekt tejto triedy reprezentuje jednu kartu v RecyclerView.

<source lang="java"> public static class DataViewHolder extends RecyclerView.ViewHolder {
private TextView textViewSensorName;
// iné View prvky CardView rozloženia karty senzora...
public DataViewHolder(@NonNull final View itemView) {
super(itemView);
textViewSensorName =
itemView.findViewById(R.id.text_view_sensor_name);
}
}</source>
Metóda triedy adaptéra - onCreateViewHolder() ([[#listing:onCreate|[listing:onCreate]]]) slúži pre dynamické vytváranie view holder objektov. Táto metóda vytvára len taký počet view holder objektov (kariet), koľko sa aktuálne zmestí na obrazovku. Pri listovaní v RecyclerView sú dynamicky vytvárané ďalšie potrebné objekty, pričom nahrádzajú tie, ktoré už na obrazovke nie sú vidieť (recycling).

<source lang="java"> @NonNull
@override
public RecyclerView.ViewHolder onCreateViewHolder(
@NonNull ViewGroup viewGroup, int i) {
View v;
LayoutInflater mInflater =
LayoutInflater.from(viewGroup.getContext());
v = mInflater.inflate(
R.layout.card_view_sensor, viewGroup, false);
return new FavouritesAdapter.DataViewHolder(v); }</source>
Samotné pridanie vytvoreného view holder objektu do RecyclerView zabezpečuje metóda - onBindViewHolder() ([[#listing:onBind|[listing:onBind]]]). Každý view holder objekt v RecyclerView má definovanú pozíciu, na ktorej sa nachádza. Hodnotu aktuálnej pozície, na ktorú má byť ďalší view holder objekt pridaný/vykreslený prijíma metóda onBindViewHolder() prostredníctvom parametra. Na základe pozície je možné naviazať konkrétny view holder objekt na dáta.

<source lang="java"> @override
public void onBindViewHolder(
@NonNull RecyclerView.ViewHolder viewHolder, int position) {
((DataViewHolder) viewHolder).
textViewSensorName.setText(
filteredList.get(position).getSensorName()); }</source>
=== Vizualizácia dát v aktivite GraphView ===

Prezentáciu dát v aktivite GraphView zabezpečujú grafy, vytvárané pomocou knižnice MPAndroidChart. Táto knižnica umožňuje vytvárať rôzne typy grafov: koláčové, stĺpcové, čiarové a iné. V aplikácii je využitý čiarový graf - LineChart. V aplikácii sú v grafe vykresľované dva typy čiar: LimitLine - horizontálna čiara pre zobrazenie priemernej hodnoty a samotná čiara grafu LineChart pre vykreslenie priebehu meraných hodnôt. Hodnoty osi x sú reprezentované časovými značkami jednotlivých meraní, ktoré sú explicitne konvertované na textový formát dátumu, ktorý je v grafe zobrazený ako legenda osi x. Hodnoty osi y sú reprezentované nameranými hodnotami. Jednotlivé body grafu sú vytvárané ako usporiadaná dvojica [časová značka, hodnota] ([[#listing:graph_creation|[listing:graph_creation]]] trieda Entry). Tieto usporiadané dvojice hodnôt sú postupne pridávané do poľa ([[#listing:graph_creation|[listing:graph_creation]]] objekt xyValues), ktoré je po naplnení priradené vytváranému objektu triedy LineDataSet v jej konštruktore. Metódy triedy LineDataSet umožňujú nastaviť požadované parametre čiary grafu (hrúbka, farba a iné). Objekt triedy LineDataSet je nakoniec priradený samotnému objektu grafu inicializovaného prostredníctvom metódy findViewById(). V aplikácii je v grafoch implementovaná možnosť zoomovania a taktiež možnosť zobrazenia hodnoty konkrétneho bodu pri kliknutí na ľubovoľnú hodnotu v grafe ( vpravo).

[[File:graph_view.png|151px|Vykresľovanie priebehu nameraných hodnôt v aktivite GraphView]] [[File:graph_view_land.png|264px|Vykresľovanie priebehu nameraných hodnôt v aktivite GraphView]]

<source lang="java"> ArrayList<Entry> xyValues = new ArrayList<>();
for (int i = 0; i < values.size; i++) {
Entry xy = new Entry(values.get(i).getDate().getTime(),
values.getValue());
xyValues.add(xy);
}
LineDataSet dataSet = new LineDataSet(xyValues, "hodnoty");
dataSet.setLineWidth(2f);
// iné nastavenia vlastností dataSetu...
LineData lineData = new LineData(dataSet);
LineChart chart = findViewById(R.id.chart);
chart.setData(lineData);</source>

Súbor:Class diagram.png

2020-09-03T20:30:43Z

Matus:

Súbor:Dao class final.png

2020-09-03T20:30:17Z

Matus:

Súbor:Load data for dashboard data flow final.png

2020-09-03T20:29:58Z

Matus:

Súbor:Card app bar fab.png

2020-09-03T20:28:47Z

Matus:

Implementácia aplikácie nSoric aAurela

2020-09-03T20:28:31Z

Matus: /* Snackbar */

{{Praca_uvod|4|Návrh a implementácia Android aplikácie pre monitoring priemyselného procesu|Informačný systém Sensorical|Platforma Android|Návrh aplikácie nSoric aAurela|Implementácia aplikácie nSoric aAurela|Testovanie aplikácie nSoric aAurela}}

__TOC__

= =
Implementácia používateľského rozhrania a jednotlivých funkcionalít aplikácie vychádza zo špecifikácie požiadaviek a navrhnutej štruktúry aplikácie v kapitole [[#navrh|[navrh]]]. V tejto kapitole sú postupne opísané: implementácia používateľského rozhrania aplikácie, práca s dátami, komunikácia so serverom a samotná vizualizácia dát v aplikácii.

== Používateľské rozhranie aplikácie ==

Jednotlivé obrazovky tvoriace používateľské rozhranie aplikácie, prostredníctvom ktorých používateľ s aplikáciou interaguje, sú implementované podľa navrhnutej štruktúry aplikácie (časť [[#navrh_aktivity|[navrh_aktivity]]]) ako jednotlivé triedy Android aktivít. Tieto Android aktivity rozdeľujú aplikáciu na dve časti: primárnu a sekundárnu.

Aktivity primárnej časti poskytujú používateľovi priamy prístup k prehľadu aktuálneho stavu meracieho systému Sensorical. Aktivity sekundárnej časti predstavujú pomocné aktivity, ktoré sú však nevyhnutné pre prístup do primárnej časti, tj. nutnosť výberu adresy servera, ku ktorému sa chce používateľ pripojiť, ako aj samotné prihlásenie do aplikácie. '''Android aktivity primárnej časti'''

* Dashboard - aktivita, ktorá sprostredkováva prehľad všetkých aktuálne dostupných senzorov a ich údajov, kategorizovaných v rámci oblastí a sektorov
* Favourites - aktivita, ktorá zobrazuje prehľad vybraných, obľúbených senzorov a ich údaje
* GraphView - aktivita ktorá zobrazuje detailný prehľad konkrétneho senzora, históriu nameraných hodnôt (grafy a štatistiky)

'''Android aktivity sekundárnej časti'''

* ServerSelect - aktivita pre výber adresy servera
* Login - aktivita pre prihlásenie do aplikácie
* About - aktivita zobrazujúca doplňujúce informácie o aplikácií

=== Android a Material Design ===

Material Design predstavuje dizajnérsky jazyk vyvinutý spoločnosťou Google v roku 2014, ktorý priniesol množstvo inovácií a zmien do spôsobu tvorby grafických používateľských rozhraní. Filozofia konceptu Material Design vychádza z fyzikálnych vlastností reálnych objektov ako 3D kontúry, odraz svetla, tiene…

Medzi inovácie, ktoré Material Design prináša patria nové komponenty ako napr. karty (Cards), plávajúce tlačidlo (Floating action button), oznámenia (Snackbars), animácie, prechody a iné. Najväčšou zmenou, ktorú Material Design priniesol je tzv. efekt hĺbky resp. používanie osi z. Jednotlivé komponenty sú zobrazované v pomyselných vrstvách v rôznych hladinách (radené nad sebou). Najdôležitejší komponent, s ktorým môže požívateľ aktuálne pracovať je zobrazený ponad ostatné komponenty (vo vyššej hladine osi z). Výhodou používateľských rozhraní, využívajúcich princíp radenia komponentov do vrstiev, je intuitívne prostredie, v ktorom sa používateľ ľahko zorientuje, s ktorými komponentmi môže aktuálne pracovať.

=== Implementácia Material Design v aplikácii ===

Pri implementácii používateľského rozhrania aplikácie boli odporúčania Material Design aplikované priamo v jednotlivých grafických rozhraniach Android aktivít a ich komponentoch. Tieto odporúčania (napr. odsadenie, vyvýšenie, farby, tlačidlá a tvary) presne definujú prípady použitia - kedy a ako môže byť daný komponent použitý, ako má vyzerať a ako sa má správať.

Pri tvorbe grafických používateľských rozhraní a taktiež pre exaktný popis parametrov jednotlivých komponentov sú používané abstraktné jednotky - dp (density pixel). Jednotky dp sú prepočítavané k referenčnému rozlíšeniu v pixeloch: 1dp=1 pixel na obrazovke s rozlíšením 160dpi (bodov na palec).

=== Material Design komponenty využité v aplikácii ===

==== Cards ====

'''Funkcia:''' Cards (Karty) zobrazujú obsah a akcie súvisiace s jedným senzorom (). Každá karta senzora zobrazuje: názov senzora, tlačidlo pre akciu pridania/odstránenia do/zo zoznamu obľúbených senzorov, priemernú hodnotu, poslednú nameranú hodnotu a dátum kedy bola nameraná. Na karte senzora je taktiež vykresľovaný trend meraní daného senzora. Trend predstavuje smer rastu resp. poklesu nameraných hodnôt za poslednú hodinu.

'''Material Design odporúčania:'''

* Vyvýšenie karty od 1dp do 8dp, optimálne 2dp.
* Ak sú v karte použité oddeľovače obsahu, nemali by prechádzať cez celú kartu, ale len cez jej časť.

[[File:card_sensor.png|thumb|none|510px|alt=Karta zobrazujúca údaje jedného senzora|Karta zobrazujúca údaje jedného senzora]]

==== Floating Action Button ====

'''Funkcia:''' plávajúce tlačidlo (FAB) je používané na vyhľadávanie v aktivitách prehľadu (Dashboard, Favourites). Tlačidlo je štandardne viditeľné, avšak pri posunutí v zozname smerom dolu je skryté, z dôvodu úplnej viditeľnosti údajov poslednej karty zoznamu. Pri posunutí v zozname smerom hore sa stane tlačidlo znova viditeľné.

'''Material Design odporúčania:'''

* FAB je zobrazené ponad všetok ostatný obsah, štandardne v pravom dolnom rohu.
* Optimálne rodičovské rozloženie - CoordinatorLayout (umožňuje automatické posunutie FAB smerom hore, napr. v prípade zobrazenia Snackbar oznámenia).
* Odporúčaná veľkosť je 56x56dp pre zariadenia s rozlíšením nad 460dp, pre zariadenia s nižším rozlíšením 46x46dp.
* Farba plávajúceho tlačidla je rovnaká ako hlavná farebná schéma aplikácie.
* Odsadenie od okraja obrazovky 16dp, vyvýšenie ponad ostatný obsah do 6dp.

==== AppBar ====

'''Funkcia:''' horná nástrojová lišta sprostredkováva informácie a akcie súvisiace s aktuálnou obrazovkou. Zobrazuje názov aktuálnej obrazovky, rýchle akcie (napr. otvorenie zoznamu obľúbených) a kontextové menu.

'''Material Design odporúčania:'''

* Názov obrazovky je umiestnený na ľavej strane nástrojovej lišty.
* Kontextové akcie sú umiestnené na pravú stranu.
* Ak je použité kontextové menu, je umiestené úplne na pravej strane.
* Vyvýšenie nástrojovej lišty je štandardne 4dp.

==== Snackbar ====

'''Funkcia:''' rýchle oznámenia ukotvené k spodnej časti obrazovky, ktoré informujú o aktuálnom dianí v aplikácii.

'''Material Design odporúčania:'''

* Optimálne rodičovské rozloženie - CoordinatorLayout.
* Snackbar má byť zobrazený len po určitú dobu, bez nutnosti explicitného zrušenia používateľom.

[[File:snackbar.png|207px|Material Design komponenty použité v aplikácii: Snackbar (aktivita Login), AppBar, Card a FAB (aktivita Dashboard)]] [[File:card_app_bar_fab.png|207px|Material Design komponenty použité v aplikácii: Snackbar (aktivita Login), AppBar, Card a FAB (aktivita Dashboard)]]

== Práca s dátami v aplikácii ==

Dáta, s ktorými aplikácia pracuje sú sťahované zo vzdialených serverov a po stiahnutí sú ukladané do SQLite databázy, z ktorej sú sprostredkovávané v aplikácii. Sťahovanie najaktuálnejších meraní prebieha automaticky vždy po spustení resp. prihlásení do aplikácie. V prípade potreby manuálnej aktualizácie nameraných hodnôt, prípadne synchronizácie všetkých dát s aktuálne dostupnými dátami daného servera sú v aplikácii implementované dva rôzne spôsoby manuálnej synchronizácie: aktualizácia len nameraných hodnôt alebo synchronizácia všetkých dát.

Pre zefektívnenie a zrýchlenie sťahovania nameraných hodnôt sa v aplikácii vytvárajú záznamy o dátumoch, za ktoré boli namerané hodnoty úspešne stiahnuté. Vždy pred každým ďalším sťahovaním nových meraní sú tieto záznamy prečítané a stiahnu sa len merania tých dátumov, ktoré nie sú evidované ako stiahnuté.

Keďže aplikácia slúži na monitorovanie aktuálneho stavu a krátkodobejších trendov, maximálny rozsah zobrazenia nameraných hodnôt bol stanovený na jeden týždeň. Aby sa predišlo prílišnému zväčšeniu veľkosti aplikácie dôsledkom sťahovania množstva údajov, sú po každom stiahnutí najnovších nameraných hodnôt vymazané nepotrebné záznamy (merania) staršie ako jeden týždeň.

=== Implementácia SQLite databázy ===

SQLite databáza, ktorá slúži na archiváciu stiahnutých dát a ich následnú prezentáciu v aplikácii, bola vytvorená pomocou knižnice Room (viď [[#room|[room]]]), pričom je implementovaná tak, aby presne korešpondovala s dátovým modelom systému Sensorical (). Aplikácia je navrhnutá tak, že umožňuje vytvárať a pracovať s ľubovoľným počtom SQLite databáz, ktoré sú vytvárané na základe webovej adresy servera, ku ktorej je používateľ aktuálne prihlásený.

Každý server, ku ktorému sa používateľ prihlási, má v aplikácii vytvorenú vlastnú SQLite databázu. Vždy po úspešnom prihlásení k niektorému zo serverov sa aplikácia pokúsi vytvoriť novú databázu s názvom webovej adresy daného servera. Ak už databáza s takýmto názvom existuje, aplikácia ju použije a otvorí.

Pri samotnej implementácii SQLite databázy v aplikácii, boli ako prvé vytvorené jednotlivé triedy reprezentujúce entity databázy ([[#listing:entity|[listing:entity]]]). Každá trieda entity obsahuje premenné, ktoré predstavujú jednotlivé atribúty danej entity. Každá premenná triedy entity je prístupná prostredníctvom metód get a set.

<source lang="java"> @Entity(tableName = "area")
public class Area {
@PrimaryKey
private int id;
private String name;

public void setId(int id) { this.id = id; }
public int getId() { return id; }
public String getName() { return name; }
public void setName(String name) { this.name = name; }
}</source>
Ako ďalšie boli vytvorené potrebné DAO rozhrania ([[#listing:dao|[listing:dao]]] rozhranie AreaDao) a ich metódy pre prístup k dátam databázy. Návratové typy týchto metód boli zvolené na základe očakávaného výsledku SQL dotazu, ktorý daná metóda vykonáva. V prípade DAO metód, ktoré slúžia na výber údajov z SQLite databázy, sú návratové typy zabalené do generickej triedy Maybe, knižnice RxJava, ktorá umožňuje vykonávať prácu týchto metód asynchrónne v paralelných vláknach.

DAO metódy, ktoré do SQLite databázy vkladajú záznamy nameraných hodnôt, využívajú v prípade konfliktu hodnôt primárnych kľúčov parameter IGNORE (ignorovať). Parameter IGNORE zabezpečí neprepísanie existujúceho záznamu v SQLite databáze, pretože nameraná hodnota nemôže byť spätne modifikovaná a teda nie je nutné už existujúce záznamy prepisovať (skrátenie času vykonávania operácie).

DAO metódy zabezpečujúce vkladanie ostatných údajov, majú v prípade konfliktu hodnôt primárnych kľúčov nastavený parameter REPLACE (nahradiť). V prípade modifikácie záznamu na strane servera sa síce nemení hodnota jeho primárneho kľúča, ale hodnota niektorého z atribútov je zmenená. Parameter REPLACE v takomto prípade zabezpečí prepísanie záznamu uloženého v SQLite databáze modifikovaným záznamom stiahnutým zo servera.

<source lang="java"> @Dao
public interface AreaDao {
@Insert(onConflict = OnConflictStrategy.REPLACE)
void insertAllAreas(List<Area> areas);

@Query("select group_view.area_id from group_view
where group_view.user_id=:userID")
Maybe<List<Integer>> getAllAreaIDsforUser(int userID);
}</source>
Ako posledná bola implementovaná abstraktná trieda databázy ([[#listing:database|[listing:database]]]), ktorá je potomkom triedy RoomDatabase. Trieda databázy v aplikácii využíva návrhový vzor Singleton, ktorý zabezpečí vytvorenie a dostupnosť jedinej inštancie triedy databázy počas behu aplikácie. Inštanciu triedy databázy je možné vytvoriť (získať) prostredníctvom statickej metódy getInstance().

<source lang="java"> @Database(entities = {Area.class, Sensor.class}, version = 1)
public abstract class AppDatabase extends RoomDatabase {
public abstract AreaDao areaDao();
private static AppDatabase INSTANCE;

public static AppDatabase getInstance(final Context context){
synchronized (AppDatabase.class) {
if (INSTANCE == null){
INSTANCE = buildDatabase(context.getApplicationContext()); }
} return INSTANCE; }

private static AppDatabase buildDatabase(final Context context){
String DATABASE_NAME = context
.getSharedPreferences("preferences", Context.MODE_PRIVATE)
.getString("server_name", "default_name");
return Room.databaseBuilder(
context, AppDatabase.class, DATABASE_NAME).build(); }
}</source>
V triede databázy sú zadefinované všetky Java triedy jednotlivých entít, z ktorých SQLite databáza pozostáva a taktiež abstraktné metódy všetkých DAO rozhraní, prostredníctvom ktorých môžno vytvoriť inštancie rozhraní v iných triedach. V aplikácii je v triede databázy implementovaná metóda buildDatabase(), ktorá zisťuje názov aktuálneho webového servera (čítanie zo SharedPreferences - ukladanie menších dát formou kľúč - hodnota), ku ktorému je používateľ prihlásený a tento názov použije pre vytvorenie resp. otvorenie databázy s daným názvom, volaním metódy build().

=== Práca s SQLite databázou ===

Práca s SQLite databázou, konkrétne vykonávanie dotazov na výber údajov pre niektorú z aktivít prehľadu (Dashboard, Favourites, GraphView) je v aplikácii realizované sekvenčne. Najskôr sa vykoná referenčný výber, pričom všetky ostatné dotazy čakajú vo fronte. V momente, kedy sa aktuálny výber dokončí, začne sa vykonávať nasledujúci (čakajúci). Sekvenčný spôsob vykonávania práce je zvolený z dôvodu závislosti vstupných parametrov (podmienok pre vykonanie) čakajúceho dotazu, na výsledku jemu predchádzajúcemu výberu.

Aby aplikácia zobrazila len ten obsah, na ktorý má prihlásený používateľ pridelené práva je využitý jedinečný identifikátor každého používateľa aplikácie - ID. Hodnota ID daného používateľa je využitá práve pri referenčnom výbere, na základe ktorého sú vybrané len tie vstupné parametre, na ktoré má používateľ definované oprávnenia.

demonštruje postupnosť volania DAO metód, ktoré vyberajú z SQLite databázy údaje pre aktivitu Dashboard. Obdobným spôsobom sú riešené výbery pre ostatné dve aktivity prehľadov (Favourites a GraphView).

[[File:load_data_for_dashboard_data_flow_final.png|thumb|none|529px|alt=Volanie DAO metód na výber dát z SQLite databázy pre aktivitu Dashboard|Volanie DAO metód na výber dát z SQLite databázy pre aktivitu Dashboard]]

Referenčný výber pre aktivitu Dashboard je výber zoznamu ID všetkých oblastí na základe ID prihláseného používateľa. Následne sa sekvenčne vykonávajú ďalšie výbery, ktorých parametrami sú vždy výsledky predchádzajúceho výberu. V metóde createDashboardData() sa vytvára dátová štruktúra, ktorá obsahuje vlastnosti potrebné pre zobrazenie údajov v Dashboard aktivite: názvy oblastí, sektorov a senzorov, fyzikálne jednotky senzorov, namerané hodnoty a ďalšie. Naplnená dátová štruktúra je odoslaná triede adaptéra (viď [[#vizualizacia|1.3]]), ktorá tieto dáta vizualizuje.

Vykonávanie výberov dát z SQLite databázy prostredníctvom DAO metód predstavuje časovo náročnejšie operácie, ktoré musia prebiehať asynchrónne, v paralelnom vlákne. Pre účel vykonávania DAO metód v paralelnom vlákne je v aplikácii využitá RxJava generická trieda Maybe. znázorňuje princíp návrhového vzoru Observer, ktorý je implementovaný knižnicou RxJava a ktorý je v aplikácii využívaný pre vykonávanie dotazov na výber dát z SQLite databázy použitím triedy Maybe. Tento návrhový vzor zabezpečuje sledovanie priebehu práce časovo náročných DAO metód vykonávaných v paralelných vláknach ([[#listing:rx_operators|[listing:rx_operators]]], metóda getAllAreaIDsForUser()). Po dokončení práce týchto metód dôjde k automatickej notifikácii vlákna špecifikovaného operátorom observeOn() ([[#listing:rx_operators|[listing:rx_operators]]] - hlavné vlákno), na ktoré sú publikované výsledky prostredníctvom rozhrania Consumer a jeho metódy accept(). Metóda accept() prijíma prostredníctvom parametra výsledky vykonaného SQL dotazu danej DAO metódy.

[[File:dao_class_final.png|thumb|none|x188px|alt=Návrhový vzor Observer využitý na výber dát z SQLite databázy|Návrhový vzor Observer využitý na výber dát z SQLite databázy]]

<source lang="java"> areaDao.getAllAreaIDsForUser(userID)
.subscribeOn(Schedulers.io())
.observeOn(AndroidSchedulers.mainThread())
.subscribe(new Consumer<List<Integer>>() {
@Override
public void accept(List<Integer> areaIDs) { }
});</source>
=== Komunikácia so vzdialeným serverom ===

Pre komunikáciu aplikácie so serverovým API je využitý socketový dátový prenos. Požiadavky/odpovede sú odosielané/prijímané v textovom formáte JSON. Po prijatí odpovede sa prechádza tá časť odpovede, ktorá obsahuje relevantné dáta (hodnota kľúča JSON objektu “data”). Časť odpovede “data” a jej hodnoty sa prechádzajú a ukladajú do dátových štruktúr (triedy jednotlivých entít), ktoré sú po naplnení vložené do SQLite databázy.

==== Vytvorenie, odoslanie a spracovanie požiadavky ====

Vytvorenie a odoslanie požiadavky na API a následné spracovanie odpovede zabezpečujú v aplikácii tri triedy (ClientSocket, ApiResponses, ApiDataPresenter), ktorých zjednodušenú štruktúru znázorňuje diagram tried na obrázku [[#fig:class_diagram|1.6]].

* trieda '''ClientSocket''' (odoslanie požiadavky) - konvertuje požiadavku do formátu JSON, otvára spojenie so serverom, odosiela požiadavku, čaká na odpoveď a vracia ju späť metóde triedy ApiResponses, ktorá požiadavku vyvolala.
* trieda '''ApiResponses''' (vytvorenie požiadavky) - vytvára a posiela triede ClientSocket údaje potrebné pre odoslanie požiadavky prostredníctvom parameterov metódy sendRequest(). Trieda ApiResponses zároveň prijíma a vracia späť textovú odpoveď metóde triedy ApiDataPresenter, ktorá danú požiadavku vyvolala.
* trieda '''ApiDataPresenter''' (spracovanie odpovede) - inicializuje proces vytvárania požiadavky volaním príslušnej metódy triedy ApiResponses, transformuje prijatú odpoveď na JSON objekt, ktorého hodnoty ukladá do dátovej štruktúry.

[[File:class_diagram.png|thumb|none|x205px|alt=Zjednodušený diagram tried zabezpečujúcich komunikáciu so serverovým API|Zjednodušený diagram tried zabezpečujúcich komunikáciu so serverovým API]]

Proces komunikácie so vzdialeným serverom je časovo náročná operácia, ktorá musí byť vykonávaná asynchrónne, v paralelnom vlákne. V aplikácii je pre tento účel využitá RxJava trieda Completable. znázorňuje návrhový vzor Observer, ktorý je implementovaný knižnicou RxJava a ktorý je v aplikácii využívaný pre komunikáciu so serverovým API použitím triedy Completable. Podstata tohoto návrhového vzoru spočíva v tom, že po ukončení časovo náročnej metódy ([[#listing:completable|[listing:completable]]] riadok 3, metóda run()) dôjde k automatickej notifikácii vlákna špecifikovaného operátorom observeOn(). Notifikáciu špecifikovaného vlákna ([[#listing:completable|[listing:completable]]] - hlavné vlákno) zabezpečuje rozhranie CompletableObserver a jeho metóda onComplete(), ktorá je zavolaná, ak komunikácia so serverom a spracovanie odpovede prebehli v poriadku. Samotná komunikácia so serverom prebieha v tele metódy run() volaním metódy apiDataPresenter.getAreas(), ktorá vyvolá konkrétnu požiadavku.

[[File:obrazky/completable_class_final.png|thumb|none|x188px|alt=Návrhový vzor Observer využitý na komunikáciu so serverovým API|Návrhový vzor Observer využitý na komunikáciu so serverovým API]]

<source lang="java"> Completable.fromRunnable(new Runnable() {
@Override
public void run() {
areaDao.insertAllAreas(apiDataPresenter.getAreas());
}
}).subscribeOn(Schedulers.io())
.observeOn(AndroidSchedulers.mainThread()
.subscribe(new CompletableObserver() {
@Override
public void onSubscribe(Disposable d) { }
@Override
public void onComplete() { }
@Override
public void onError(Throwable e) { } });</source>
Textový formát odpovede z API je vrátený do triedy ApiDataPresenter, v ktorej sa transformuje na JSON objekt ([[#listing:api_data_presenter|[listing:api_data_presenter]]], metóda parseAreaResponse()). V tejto metóde sa prechádza pole hodnôt s hodnotou kľúča “data”, pričom jednotlivé hodnoty tohto poľa sú opäť polia, ktorých hodnoty sa ukladajú do dátovej štruktúry, ktorá je vrátená späť do miesta volania ([[#listing:completable|[listing:completable]]], riadok 4). Spôsob vytvárania JSON objektu z prijatej odpovede, prechádzanie a ukladanie jeho hodnôt do dátovej štruktúry zobrazuje [[#listing:api_data_presenter|[listing:api_data_presenter]]]. Postupnosť prechodu medzi triedami a formát dát v jednotlivých triedach počas komunikácie s API znázorňuje .

<source lang="java"> public ArrayList<Area> getAreas() {
parseAreaResponse();
return this.areaList;
}

private void parseAreaResponse() {
String serverResponse = apiResponses.getAreaResponse();
if (!serverResponse.isEmpty()) {
JSONObject response = new JSONObject(serverResponse);
JSONArray array = response.getJSONArray("data");
for (int i = 0; i < array.length(); i++) {
Area area = new Area();
area.setId(array.getJSONArray(i).getInt(0));
area.setName(array.getJSONArray(i).getString(1));
this.areaList.add(area);
}
}
}</source>
[[File:api_call_diagram_final.png|thumb|none|585px|alt=Prenos a formát dát v jednotlivých triedach počas komunikácie s API|Prenos a formát dát v jednotlivých triedach počas komunikácie s API]]

== Vizualizácia dát v aplikácii ==

Prezentáciu dát v aktivitách prehľadu (Dashboard, Favourites) zabezpečujú komponenty - CardView, RecyclerView a Adaptér. V aktivite detailného prehľadu konkrétneho senzora (GraphView) sú dáta vizualizované prostredníctvom grafov - knižnica MPAndroidChart.

=== Vizualizácia dát v aktivitách Dashboard a Favourites ===

==== CardView ====

CardView je grafická reprezentácia karty (Card [[#design|1.1.2]]), predstavuje rodičovské rozloženie pre všetky v nej obsiahnuté View prvky (textové polia, tlačidlá, obrázky…).

==== RecyclerView ====

RecylerView predstavuje model, ktorý umožňuje zobraziť väčšie množstvo údajov vo forme zoznamu. V aplikácii sú ako jednotlivé položky zobrazené v RecyclerView použité karty. Výhodou používania RecyclerView je jeho rýchlosť, pretože sa nevykresľujú (nevytvárajú) naraz všetky karty, ale vytvárajú sa len tie, ktoré sa aktuálne zmestia na obrazovku. Pre naplnenie RecyclerView kartami a ich následné zobrazenie sa využívajú návrhové vzory (triedy) ViewHolder a Adaptér. Jednotlivé karty zobrazené v RecyclerView sú reprezentované objektmi nazývanými view holders. Tieto objekty sú inštanciami tried, ktoré sú potomkami triedy RecyclerView.ViewHolder.

==== ViewHolder ====

ViewHolder je návrhový vzor, ktorý zabezpečuje vytvorenie objektu daného CardView rozloženia spolu s jej View prvkami. Takto vytvorený objekt môže byť použitý viacnásobne, bez nutnosti opakovanej inicializácie View prvkov tohto objektu, volaním metódy findViewById(), čo znižuje pamäťovú náročnosť a zároveň výrazne zrýchľuje proces listovania v RecyclerView. Vytvorené view holder objekty reprezentujú karty, ktoré sú zobrazené v RecyclerView. Tento návrhový vzor možno použiť vytvorením vnútornej triedy, potomok triedy RecyclerView.ViewHolder, v triede adaptéra.

==== Adaptér ====

Adaptér je návrhový vzor, ktorý funguje ako most medzi používateľským rozhraním a dátami. V Androide predstavuje adaptér triedu, ktorá sprostredkováva dáta RecyclerView. Trieda adaptéra (potomok triedy RecyclerView.Adapter) zabezpečuje správu jednotlivých view holder objektov prostredníctvom preťažených metód rodičovskej triedy: vytvorenie view holder objektov - metóda onCreateViewHolder, pridávanie vytvorených view holder objektov do RecyclerView - metóda onBindViewHolder().

V aplikácii sú vytvorené dve triedy adaptérov, kde každá z nich sprostredkováva dáta konkrétnej aktivite: DashboardAdapter (Dashboard aktivita), FavouritesAdapter (Favourites aktivita). Triedy adaptérov v aplikácii využívajú návrhový vzor Singleton, pričom vytvorenie (získanie) inštancie triedy oboch adaptérov je možné prostredníctvom statickej metódy getInstance(). Spôsob implementácie triedy adaptéra v aplikácii je demonštrovaný na jednoduchšej triede FavouritesAdapter, ktorá vykresľuje len jeden typ view holder objektu (len karta senzora, vľavo). Trieda DashboardAdapter vykresľuje tri typy view holder objektov, kde každý z nich reprezentuje kartu: oblasti, sektoru, alebo senzora ( vpravo).

Vytvorenie inštancie triedy FavouritesAdapter a následné nastavenie tejto inštancie ako adaptér objektu recylerView demonštruje kód [[#listing:adapter|[listing:adapter]]].

<source lang="java"> RecyclerView recyclerView = findViewById(R.id.recycler_view);
FavouritesAdapter adapter = FavouritesAdapter.getInstance();
recyclerView.setAdapter(adapter);</source>
[[File:favourites.png|x264px|RecyclerView - aktivita Dashboard (vpravo), aktivita Favourites (vľavo)]] [[File:recycler_view_dashboard_edit.png|x264px|RecyclerView - aktivita Dashboard (vpravo), aktivita Favourites (vľavo)]]

Nasledujúca ukážka ([[#listing:viewHolder|[listing:viewHolder]]]) zobrazuje implementáciu návrhového vzoru ViewHolder v triede adaptéra (FavouritesAdapter), vytvorením vnútornej triedy DataViewHolder. Trieda DataViewHolder inicializuje jednotlivé View prvky CardView rozloženia karty senzora. Každý vytvorený objekt tejto triedy reprezentuje jednu kartu v RecyclerView.

<source lang="java"> public static class DataViewHolder extends RecyclerView.ViewHolder {
private TextView textViewSensorName;
// iné View prvky CardView rozloženia karty senzora...
public DataViewHolder(@NonNull final View itemView) {
super(itemView);
textViewSensorName =
itemView.findViewById(R.id.text_view_sensor_name);
}
}</source>
Metóda triedy adaptéra - onCreateViewHolder() ([[#listing:onCreate|[listing:onCreate]]]) slúži pre dynamické vytváranie view holder objektov. Táto metóda vytvára len taký počet view holder objektov (kariet), koľko sa aktuálne zmestí na obrazovku. Pri listovaní v RecyclerView sú dynamicky vytvárané ďalšie potrebné objekty, pričom nahrádzajú tie, ktoré už na obrazovke nie sú vidieť (recycling).

<source lang="java"> @NonNull
@override
public RecyclerView.ViewHolder onCreateViewHolder(
@NonNull ViewGroup viewGroup, int i) {
View v;
LayoutInflater mInflater =
LayoutInflater.from(viewGroup.getContext());
v = mInflater.inflate(
R.layout.card_view_sensor, viewGroup, false);
return new FavouritesAdapter.DataViewHolder(v); }</source>
Samotné pridanie vytvoreného view holder objektu do RecyclerView zabezpečuje metóda - onBindViewHolder() ([[#listing:onBind|[listing:onBind]]]). Každý view holder objekt v RecyclerView má definovanú pozíciu, na ktorej sa nachádza. Hodnotu aktuálnej pozície, na ktorú má byť ďalší view holder objekt pridaný/vykreslený prijíma metóda onBindViewHolder() prostredníctvom parametra. Na základe pozície je možné naviazať konkrétny view holder objekt na dáta.

<source lang="java"> @override
public void onBindViewHolder(
@NonNull RecyclerView.ViewHolder viewHolder, int position) {
((DataViewHolder) viewHolder).
textViewSensorName.setText(
filteredList.get(position).getSensorName()); }</source>
=== Vizualizácia dát v aktivite GraphView ===

Prezentáciu dát v aktivite GraphView zabezpečujú grafy, vytvárané pomocou knižnice MPAndroidChart. Táto knižnica umožňuje vytvárať rôzne typy grafov: koláčové, stĺpcové, čiarové a iné. V aplikácii je využitý čiarový graf - LineChart. V aplikácii sú v grafe vykresľované dva typy čiar: LimitLine - horizontálna čiara pre zobrazenie priemernej hodnoty a samotná čiara grafu LineChart pre vykreslenie priebehu meraných hodnôt. Hodnoty osi x sú reprezentované časovými značkami jednotlivých meraní, ktoré sú explicitne konvertované na textový formát dátumu, ktorý je v grafe zobrazený ako legenda osi x. Hodnoty osi y sú reprezentované nameranými hodnotami. Jednotlivé body grafu sú vytvárané ako usporiadaná dvojica [časová značka, hodnota] ([[#listing:graph_creation|[listing:graph_creation]]] trieda Entry). Tieto usporiadané dvojice hodnôt sú postupne pridávané do poľa ([[#listing:graph_creation|[listing:graph_creation]]] objekt xyValues), ktoré je po naplnení priradené vytváranému objektu triedy LineDataSet v jej konštruktore. Metódy triedy LineDataSet umožňujú nastaviť požadované parametre čiary grafu (hrúbka, farba a iné). Objekt triedy LineDataSet je nakoniec priradený samotnému objektu grafu inicializovaného prostredníctvom metódy findViewById(). V aplikácii je v grafoch implementovaná možnosť zoomovania a taktiež možnosť zobrazenia hodnoty konkrétneho bodu pri kliknutí na ľubovoľnú hodnotu v grafe ( vpravo).

[[File:graph_view.png|151px|Vykresľovanie priebehu nameraných hodnôt v aktivite GraphView]] [[File:graph_view_land.png|264px|Vykresľovanie priebehu nameraných hodnôt v aktivite GraphView]]

<source lang="java"> ArrayList<Entry> xyValues = new ArrayList<>();
for (int i = 0; i < values.size; i++) {
Entry xy = new Entry(values.get(i).getDate().getTime(),
values.getValue());
xyValues.add(xy);
}
LineDataSet dataSet = new LineDataSet(xyValues, "hodnoty");
dataSet.setLineWidth(2f);
// iné nastavenia vlastností dataSetu...
LineData lineData = new LineData(dataSet);
LineChart chart = findViewById(R.id.chart);
chart.setData(lineData);</source>

Súbor:Card sensor.png

2020-09-03T20:27:31Z

Matus:

Implementácia aplikácie nSoric aAurela

2020-09-03T20:27:09Z

Matus:

{{Praca_uvod|4|Návrh a implementácia Android aplikácie pre monitoring priemyselného procesu|Informačný systém Sensorical|Platforma Android|Návrh aplikácie nSoric aAurela|Implementácia aplikácie nSoric aAurela|Testovanie aplikácie nSoric aAurela}}

__TOC__

= =
Implementácia používateľského rozhrania a jednotlivých funkcionalít aplikácie vychádza zo špecifikácie požiadaviek a navrhnutej štruktúry aplikácie v kapitole [[#navrh|[navrh]]]. V tejto kapitole sú postupne opísané: implementácia používateľského rozhrania aplikácie, práca s dátami, komunikácia so serverom a samotná vizualizácia dát v aplikácii.

== Používateľské rozhranie aplikácie ==

Jednotlivé obrazovky tvoriace používateľské rozhranie aplikácie, prostredníctvom ktorých používateľ s aplikáciou interaguje, sú implementované podľa navrhnutej štruktúry aplikácie (časť [[#navrh_aktivity|[navrh_aktivity]]]) ako jednotlivé triedy Android aktivít. Tieto Android aktivity rozdeľujú aplikáciu na dve časti: primárnu a sekundárnu.

Aktivity primárnej časti poskytujú používateľovi priamy prístup k prehľadu aktuálneho stavu meracieho systému Sensorical. Aktivity sekundárnej časti predstavujú pomocné aktivity, ktoré sú však nevyhnutné pre prístup do primárnej časti, tj. nutnosť výberu adresy servera, ku ktorému sa chce používateľ pripojiť, ako aj samotné prihlásenie do aplikácie. '''Android aktivity primárnej časti'''

* Dashboard - aktivita, ktorá sprostredkováva prehľad všetkých aktuálne dostupných senzorov a ich údajov, kategorizovaných v rámci oblastí a sektorov
* Favourites - aktivita, ktorá zobrazuje prehľad vybraných, obľúbených senzorov a ich údaje
* GraphView - aktivita ktorá zobrazuje detailný prehľad konkrétneho senzora, históriu nameraných hodnôt (grafy a štatistiky)

'''Android aktivity sekundárnej časti'''

* ServerSelect - aktivita pre výber adresy servera
* Login - aktivita pre prihlásenie do aplikácie
* About - aktivita zobrazujúca doplňujúce informácie o aplikácií

=== Android a Material Design ===

Material Design predstavuje dizajnérsky jazyk vyvinutý spoločnosťou Google v roku 2014, ktorý priniesol množstvo inovácií a zmien do spôsobu tvorby grafických používateľských rozhraní. Filozofia konceptu Material Design vychádza z fyzikálnych vlastností reálnych objektov ako 3D kontúry, odraz svetla, tiene…

Medzi inovácie, ktoré Material Design prináša patria nové komponenty ako napr. karty (Cards), plávajúce tlačidlo (Floating action button), oznámenia (Snackbars), animácie, prechody a iné. Najväčšou zmenou, ktorú Material Design priniesol je tzv. efekt hĺbky resp. používanie osi z. Jednotlivé komponenty sú zobrazované v pomyselných vrstvách v rôznych hladinách (radené nad sebou). Najdôležitejší komponent, s ktorým môže požívateľ aktuálne pracovať je zobrazený ponad ostatné komponenty (vo vyššej hladine osi z). Výhodou používateľských rozhraní, využívajúcich princíp radenia komponentov do vrstiev, je intuitívne prostredie, v ktorom sa používateľ ľahko zorientuje, s ktorými komponentmi môže aktuálne pracovať.

=== Implementácia Material Design v aplikácii ===

Pri implementácii používateľského rozhrania aplikácie boli odporúčania Material Design aplikované priamo v jednotlivých grafických rozhraniach Android aktivít a ich komponentoch. Tieto odporúčania (napr. odsadenie, vyvýšenie, farby, tlačidlá a tvary) presne definujú prípady použitia - kedy a ako môže byť daný komponent použitý, ako má vyzerať a ako sa má správať.

Pri tvorbe grafických používateľských rozhraní a taktiež pre exaktný popis parametrov jednotlivých komponentov sú používané abstraktné jednotky - dp (density pixel). Jednotky dp sú prepočítavané k referenčnému rozlíšeniu v pixeloch: 1dp=1 pixel na obrazovke s rozlíšením 160dpi (bodov na palec).

=== Material Design komponenty využité v aplikácii ===

==== Cards ====

'''Funkcia:''' Cards (Karty) zobrazujú obsah a akcie súvisiace s jedným senzorom (). Každá karta senzora zobrazuje: názov senzora, tlačidlo pre akciu pridania/odstránenia do/zo zoznamu obľúbených senzorov, priemernú hodnotu, poslednú nameranú hodnotu a dátum kedy bola nameraná. Na karte senzora je taktiež vykresľovaný trend meraní daného senzora. Trend predstavuje smer rastu resp. poklesu nameraných hodnôt za poslednú hodinu.

'''Material Design odporúčania:'''

* Vyvýšenie karty od 1dp do 8dp, optimálne 2dp.
* Ak sú v karte použité oddeľovače obsahu, nemali by prechádzať cez celú kartu, ale len cez jej časť.

[[File:card_sensor.png|thumb|none|510px|alt=Karta zobrazujúca údaje jedného senzora|Karta zobrazujúca údaje jedného senzora]]

==== Floating Action Button ====

'''Funkcia:''' plávajúce tlačidlo (FAB) je používané na vyhľadávanie v aktivitách prehľadu (Dashboard, Favourites). Tlačidlo je štandardne viditeľné, avšak pri posunutí v zozname smerom dolu je skryté, z dôvodu úplnej viditeľnosti údajov poslednej karty zoznamu. Pri posunutí v zozname smerom hore sa stane tlačidlo znova viditeľné.

'''Material Design odporúčania:'''

* FAB je zobrazené ponad všetok ostatný obsah, štandardne v pravom dolnom rohu.
* Optimálne rodičovské rozloženie - CoordinatorLayout (umožňuje automatické posunutie FAB smerom hore, napr. v prípade zobrazenia Snackbar oznámenia).
* Odporúčaná veľkosť je 56x56dp pre zariadenia s rozlíšením nad 460dp, pre zariadenia s nižším rozlíšením 46x46dp.
* Farba plávajúceho tlačidla je rovnaká ako hlavná farebná schéma aplikácie.
* Odsadenie od okraja obrazovky 16dp, vyvýšenie ponad ostatný obsah do 6dp.

==== AppBar ====

'''Funkcia:''' horná nástrojová lišta sprostredkováva informácie a akcie súvisiace s aktuálnou obrazovkou. Zobrazuje názov aktuálnej obrazovky, rýchle akcie (napr. otvorenie zoznamu obľúbených) a kontextové menu.

'''Material Design odporúčania:'''

* Názov obrazovky je umiestnený na ľavej strane nástrojovej lišty.
* Kontextové akcie sú umiestnené na pravú stranu.
* Ak je použité kontextové menu, je umiestené úplne na pravej strane.
* Vyvýšenie nástrojovej lišty je štandardne 4dp.

==== Snackbar ====

'''Funkcia:''' rýchle oznámenia ukotvené k spodnej časti obrazovky, ktoré informujú o aktuálnom dianí v aplikácii.

'''Material Design odporúčania:'''

* Optimálne rodičovské rozloženie - CoordinatorLayout.
* Snackbar má byť zobrazený len po určitú dobu, bez nutnosti explicitného zrušenia používateľom.

[[File:snackbar.png|207px|Material Design komponenty použité v aplikácii: Snackbar (aktivita Login), AppBar, Card a FAB (aktivita Dashboard)]] [[File:obrazky/card_app_bar_fab.png|207px|Material Design komponenty použité v aplikácii: Snackbar (aktivita Login), AppBar, Card a FAB (aktivita Dashboard)]]

== Práca s dátami v aplikácii ==

Dáta, s ktorými aplikácia pracuje sú sťahované zo vzdialených serverov a po stiahnutí sú ukladané do SQLite databázy, z ktorej sú sprostredkovávané v aplikácii. Sťahovanie najaktuálnejších meraní prebieha automaticky vždy po spustení resp. prihlásení do aplikácie. V prípade potreby manuálnej aktualizácie nameraných hodnôt, prípadne synchronizácie všetkých dát s aktuálne dostupnými dátami daného servera sú v aplikácii implementované dva rôzne spôsoby manuálnej synchronizácie: aktualizácia len nameraných hodnôt alebo synchronizácia všetkých dát.

Pre zefektívnenie a zrýchlenie sťahovania nameraných hodnôt sa v aplikácii vytvárajú záznamy o dátumoch, za ktoré boli namerané hodnoty úspešne stiahnuté. Vždy pred každým ďalším sťahovaním nových meraní sú tieto záznamy prečítané a stiahnu sa len merania tých dátumov, ktoré nie sú evidované ako stiahnuté.

Keďže aplikácia slúži na monitorovanie aktuálneho stavu a krátkodobejších trendov, maximálny rozsah zobrazenia nameraných hodnôt bol stanovený na jeden týždeň. Aby sa predišlo prílišnému zväčšeniu veľkosti aplikácie dôsledkom sťahovania množstva údajov, sú po každom stiahnutí najnovších nameraných hodnôt vymazané nepotrebné záznamy (merania) staršie ako jeden týždeň.

=== Implementácia SQLite databázy ===

SQLite databáza, ktorá slúži na archiváciu stiahnutých dát a ich následnú prezentáciu v aplikácii, bola vytvorená pomocou knižnice Room (viď [[#room|[room]]]), pričom je implementovaná tak, aby presne korešpondovala s dátovým modelom systému Sensorical (). Aplikácia je navrhnutá tak, že umožňuje vytvárať a pracovať s ľubovoľným počtom SQLite databáz, ktoré sú vytvárané na základe webovej adresy servera, ku ktorej je používateľ aktuálne prihlásený.

Každý server, ku ktorému sa používateľ prihlási, má v aplikácii vytvorenú vlastnú SQLite databázu. Vždy po úspešnom prihlásení k niektorému zo serverov sa aplikácia pokúsi vytvoriť novú databázu s názvom webovej adresy daného servera. Ak už databáza s takýmto názvom existuje, aplikácia ju použije a otvorí.

Pri samotnej implementácii SQLite databázy v aplikácii, boli ako prvé vytvorené jednotlivé triedy reprezentujúce entity databázy ([[#listing:entity|[listing:entity]]]). Každá trieda entity obsahuje premenné, ktoré predstavujú jednotlivé atribúty danej entity. Každá premenná triedy entity je prístupná prostredníctvom metód get a set.

<source lang="java"> @Entity(tableName = "area")
public class Area {
@PrimaryKey
private int id;
private String name;

public void setId(int id) { this.id = id; }
public int getId() { return id; }
public String getName() { return name; }
public void setName(String name) { this.name = name; }
}</source>
Ako ďalšie boli vytvorené potrebné DAO rozhrania ([[#listing:dao|[listing:dao]]] rozhranie AreaDao) a ich metódy pre prístup k dátam databázy. Návratové typy týchto metód boli zvolené na základe očakávaného výsledku SQL dotazu, ktorý daná metóda vykonáva. V prípade DAO metód, ktoré slúžia na výber údajov z SQLite databázy, sú návratové typy zabalené do generickej triedy Maybe, knižnice RxJava, ktorá umožňuje vykonávať prácu týchto metód asynchrónne v paralelných vláknach.

DAO metódy, ktoré do SQLite databázy vkladajú záznamy nameraných hodnôt, využívajú v prípade konfliktu hodnôt primárnych kľúčov parameter IGNORE (ignorovať). Parameter IGNORE zabezpečí neprepísanie existujúceho záznamu v SQLite databáze, pretože nameraná hodnota nemôže byť spätne modifikovaná a teda nie je nutné už existujúce záznamy prepisovať (skrátenie času vykonávania operácie).

DAO metódy zabezpečujúce vkladanie ostatných údajov, majú v prípade konfliktu hodnôt primárnych kľúčov nastavený parameter REPLACE (nahradiť). V prípade modifikácie záznamu na strane servera sa síce nemení hodnota jeho primárneho kľúča, ale hodnota niektorého z atribútov je zmenená. Parameter REPLACE v takomto prípade zabezpečí prepísanie záznamu uloženého v SQLite databáze modifikovaným záznamom stiahnutým zo servera.

<source lang="java"> @Dao
public interface AreaDao {
@Insert(onConflict = OnConflictStrategy.REPLACE)
void insertAllAreas(List<Area> areas);

@Query("select group_view.area_id from group_view
where group_view.user_id=:userID")
Maybe<List<Integer>> getAllAreaIDsforUser(int userID);
}</source>
Ako posledná bola implementovaná abstraktná trieda databázy ([[#listing:database|[listing:database]]]), ktorá je potomkom triedy RoomDatabase. Trieda databázy v aplikácii využíva návrhový vzor Singleton, ktorý zabezpečí vytvorenie a dostupnosť jedinej inštancie triedy databázy počas behu aplikácie. Inštanciu triedy databázy je možné vytvoriť (získať) prostredníctvom statickej metódy getInstance().

<source lang="java"> @Database(entities = {Area.class, Sensor.class}, version = 1)
public abstract class AppDatabase extends RoomDatabase {
public abstract AreaDao areaDao();
private static AppDatabase INSTANCE;

public static AppDatabase getInstance(final Context context){
synchronized (AppDatabase.class) {
if (INSTANCE == null){
INSTANCE = buildDatabase(context.getApplicationContext()); }
} return INSTANCE; }

private static AppDatabase buildDatabase(final Context context){
String DATABASE_NAME = context
.getSharedPreferences("preferences", Context.MODE_PRIVATE)
.getString("server_name", "default_name");
return Room.databaseBuilder(
context, AppDatabase.class, DATABASE_NAME).build(); }
}</source>
V triede databázy sú zadefinované všetky Java triedy jednotlivých entít, z ktorých SQLite databáza pozostáva a taktiež abstraktné metódy všetkých DAO rozhraní, prostredníctvom ktorých môžno vytvoriť inštancie rozhraní v iných triedach. V aplikácii je v triede databázy implementovaná metóda buildDatabase(), ktorá zisťuje názov aktuálneho webového servera (čítanie zo SharedPreferences - ukladanie menších dát formou kľúč - hodnota), ku ktorému je používateľ prihlásený a tento názov použije pre vytvorenie resp. otvorenie databázy s daným názvom, volaním metódy build().

=== Práca s SQLite databázou ===

Práca s SQLite databázou, konkrétne vykonávanie dotazov na výber údajov pre niektorú z aktivít prehľadu (Dashboard, Favourites, GraphView) je v aplikácii realizované sekvenčne. Najskôr sa vykoná referenčný výber, pričom všetky ostatné dotazy čakajú vo fronte. V momente, kedy sa aktuálny výber dokončí, začne sa vykonávať nasledujúci (čakajúci). Sekvenčný spôsob vykonávania práce je zvolený z dôvodu závislosti vstupných parametrov (podmienok pre vykonanie) čakajúceho dotazu, na výsledku jemu predchádzajúcemu výberu.

Aby aplikácia zobrazila len ten obsah, na ktorý má prihlásený používateľ pridelené práva je využitý jedinečný identifikátor každého používateľa aplikácie - ID. Hodnota ID daného používateľa je využitá práve pri referenčnom výbere, na základe ktorého sú vybrané len tie vstupné parametre, na ktoré má používateľ definované oprávnenia.

demonštruje postupnosť volania DAO metód, ktoré vyberajú z SQLite databázy údaje pre aktivitu Dashboard. Obdobným spôsobom sú riešené výbery pre ostatné dve aktivity prehľadov (Favourites a GraphView).

[[File:load_data_for_dashboard_data_flow_final.png|thumb|none|529px|alt=Volanie DAO metód na výber dát z SQLite databázy pre aktivitu Dashboard|Volanie DAO metód na výber dát z SQLite databázy pre aktivitu Dashboard]]

Referenčný výber pre aktivitu Dashboard je výber zoznamu ID všetkých oblastí na základe ID prihláseného používateľa. Následne sa sekvenčne vykonávajú ďalšie výbery, ktorých parametrami sú vždy výsledky predchádzajúceho výberu. V metóde createDashboardData() sa vytvára dátová štruktúra, ktorá obsahuje vlastnosti potrebné pre zobrazenie údajov v Dashboard aktivite: názvy oblastí, sektorov a senzorov, fyzikálne jednotky senzorov, namerané hodnoty a ďalšie. Naplnená dátová štruktúra je odoslaná triede adaptéra (viď [[#vizualizacia|1.3]]), ktorá tieto dáta vizualizuje.

Vykonávanie výberov dát z SQLite databázy prostredníctvom DAO metód predstavuje časovo náročnejšie operácie, ktoré musia prebiehať asynchrónne, v paralelnom vlákne. Pre účel vykonávania DAO metód v paralelnom vlákne je v aplikácii využitá RxJava generická trieda Maybe. znázorňuje princíp návrhového vzoru Observer, ktorý je implementovaný knižnicou RxJava a ktorý je v aplikácii využívaný pre vykonávanie dotazov na výber dát z SQLite databázy použitím triedy Maybe. Tento návrhový vzor zabezpečuje sledovanie priebehu práce časovo náročných DAO metód vykonávaných v paralelných vláknach ([[#listing:rx_operators|[listing:rx_operators]]], metóda getAllAreaIDsForUser()). Po dokončení práce týchto metód dôjde k automatickej notifikácii vlákna špecifikovaného operátorom observeOn() ([[#listing:rx_operators|[listing:rx_operators]]] - hlavné vlákno), na ktoré sú publikované výsledky prostredníctvom rozhrania Consumer a jeho metódy accept(). Metóda accept() prijíma prostredníctvom parametra výsledky vykonaného SQL dotazu danej DAO metódy.

[[File:dao_class_final.png|thumb|none|x188px|alt=Návrhový vzor Observer využitý na výber dát z SQLite databázy|Návrhový vzor Observer využitý na výber dát z SQLite databázy]]

<source lang="java"> areaDao.getAllAreaIDsForUser(userID)
.subscribeOn(Schedulers.io())
.observeOn(AndroidSchedulers.mainThread())
.subscribe(new Consumer<List<Integer>>() {
@Override
public void accept(List<Integer> areaIDs) { }
});</source>
=== Komunikácia so vzdialeným serverom ===

Pre komunikáciu aplikácie so serverovým API je využitý socketový dátový prenos. Požiadavky/odpovede sú odosielané/prijímané v textovom formáte JSON. Po prijatí odpovede sa prechádza tá časť odpovede, ktorá obsahuje relevantné dáta (hodnota kľúča JSON objektu “data”). Časť odpovede “data” a jej hodnoty sa prechádzajú a ukladajú do dátových štruktúr (triedy jednotlivých entít), ktoré sú po naplnení vložené do SQLite databázy.

==== Vytvorenie, odoslanie a spracovanie požiadavky ====

Vytvorenie a odoslanie požiadavky na API a následné spracovanie odpovede zabezpečujú v aplikácii tri triedy (ClientSocket, ApiResponses, ApiDataPresenter), ktorých zjednodušenú štruktúru znázorňuje diagram tried na obrázku [[#fig:class_diagram|1.6]].

* trieda '''ClientSocket''' (odoslanie požiadavky) - konvertuje požiadavku do formátu JSON, otvára spojenie so serverom, odosiela požiadavku, čaká na odpoveď a vracia ju späť metóde triedy ApiResponses, ktorá požiadavku vyvolala.
* trieda '''ApiResponses''' (vytvorenie požiadavky) - vytvára a posiela triede ClientSocket údaje potrebné pre odoslanie požiadavky prostredníctvom parameterov metódy sendRequest(). Trieda ApiResponses zároveň prijíma a vracia späť textovú odpoveď metóde triedy ApiDataPresenter, ktorá danú požiadavku vyvolala.
* trieda '''ApiDataPresenter''' (spracovanie odpovede) - inicializuje proces vytvárania požiadavky volaním príslušnej metódy triedy ApiResponses, transformuje prijatú odpoveď na JSON objekt, ktorého hodnoty ukladá do dátovej štruktúry.

[[File:class_diagram.png|thumb|none|x205px|alt=Zjednodušený diagram tried zabezpečujúcich komunikáciu so serverovým API|Zjednodušený diagram tried zabezpečujúcich komunikáciu so serverovým API]]

Proces komunikácie so vzdialeným serverom je časovo náročná operácia, ktorá musí byť vykonávaná asynchrónne, v paralelnom vlákne. V aplikácii je pre tento účel využitá RxJava trieda Completable. znázorňuje návrhový vzor Observer, ktorý je implementovaný knižnicou RxJava a ktorý je v aplikácii využívaný pre komunikáciu so serverovým API použitím triedy Completable. Podstata tohoto návrhového vzoru spočíva v tom, že po ukončení časovo náročnej metódy ([[#listing:completable|[listing:completable]]] riadok 3, metóda run()) dôjde k automatickej notifikácii vlákna špecifikovaného operátorom observeOn(). Notifikáciu špecifikovaného vlákna ([[#listing:completable|[listing:completable]]] - hlavné vlákno) zabezpečuje rozhranie CompletableObserver a jeho metóda onComplete(), ktorá je zavolaná, ak komunikácia so serverom a spracovanie odpovede prebehli v poriadku. Samotná komunikácia so serverom prebieha v tele metódy run() volaním metódy apiDataPresenter.getAreas(), ktorá vyvolá konkrétnu požiadavku.

[[File:obrazky/completable_class_final.png|thumb|none|x188px|alt=Návrhový vzor Observer využitý na komunikáciu so serverovým API|Návrhový vzor Observer využitý na komunikáciu so serverovým API]]

<source lang="java"> Completable.fromRunnable(new Runnable() {
@Override
public void run() {
areaDao.insertAllAreas(apiDataPresenter.getAreas());
}
}).subscribeOn(Schedulers.io())
.observeOn(AndroidSchedulers.mainThread()
.subscribe(new CompletableObserver() {
@Override
public void onSubscribe(Disposable d) { }
@Override
public void onComplete() { }
@Override
public void onError(Throwable e) { } });</source>
Textový formát odpovede z API je vrátený do triedy ApiDataPresenter, v ktorej sa transformuje na JSON objekt ([[#listing:api_data_presenter|[listing:api_data_presenter]]], metóda parseAreaResponse()). V tejto metóde sa prechádza pole hodnôt s hodnotou kľúča “data”, pričom jednotlivé hodnoty tohto poľa sú opäť polia, ktorých hodnoty sa ukladajú do dátovej štruktúry, ktorá je vrátená späť do miesta volania ([[#listing:completable|[listing:completable]]], riadok 4). Spôsob vytvárania JSON objektu z prijatej odpovede, prechádzanie a ukladanie jeho hodnôt do dátovej štruktúry zobrazuje [[#listing:api_data_presenter|[listing:api_data_presenter]]]. Postupnosť prechodu medzi triedami a formát dát v jednotlivých triedach počas komunikácie s API znázorňuje .

<source lang="java"> public ArrayList<Area> getAreas() {
parseAreaResponse();
return this.areaList;
}

private void parseAreaResponse() {
String serverResponse = apiResponses.getAreaResponse();
if (!serverResponse.isEmpty()) {
JSONObject response = new JSONObject(serverResponse);
JSONArray array = response.getJSONArray("data");
for (int i = 0; i < array.length(); i++) {
Area area = new Area();
area.setId(array.getJSONArray(i).getInt(0));
area.setName(array.getJSONArray(i).getString(1));
this.areaList.add(area);
}
}
}</source>
[[File:api_call_diagram_final.png|thumb|none|585px|alt=Prenos a formát dát v jednotlivých triedach počas komunikácie s API|Prenos a formát dát v jednotlivých triedach počas komunikácie s API]]

== Vizualizácia dát v aplikácii ==

Prezentáciu dát v aktivitách prehľadu (Dashboard, Favourites) zabezpečujú komponenty - CardView, RecyclerView a Adaptér. V aktivite detailného prehľadu konkrétneho senzora (GraphView) sú dáta vizualizované prostredníctvom grafov - knižnica MPAndroidChart.

=== Vizualizácia dát v aktivitách Dashboard a Favourites ===

==== CardView ====

CardView je grafická reprezentácia karty (Card [[#design|1.1.2]]), predstavuje rodičovské rozloženie pre všetky v nej obsiahnuté View prvky (textové polia, tlačidlá, obrázky…).

==== RecyclerView ====

RecylerView predstavuje model, ktorý umožňuje zobraziť väčšie množstvo údajov vo forme zoznamu. V aplikácii sú ako jednotlivé položky zobrazené v RecyclerView použité karty. Výhodou používania RecyclerView je jeho rýchlosť, pretože sa nevykresľujú (nevytvárajú) naraz všetky karty, ale vytvárajú sa len tie, ktoré sa aktuálne zmestia na obrazovku. Pre naplnenie RecyclerView kartami a ich následné zobrazenie sa využívajú návrhové vzory (triedy) ViewHolder a Adaptér. Jednotlivé karty zobrazené v RecyclerView sú reprezentované objektmi nazývanými view holders. Tieto objekty sú inštanciami tried, ktoré sú potomkami triedy RecyclerView.ViewHolder.

==== ViewHolder ====

ViewHolder je návrhový vzor, ktorý zabezpečuje vytvorenie objektu daného CardView rozloženia spolu s jej View prvkami. Takto vytvorený objekt môže byť použitý viacnásobne, bez nutnosti opakovanej inicializácie View prvkov tohto objektu, volaním metódy findViewById(), čo znižuje pamäťovú náročnosť a zároveň výrazne zrýchľuje proces listovania v RecyclerView. Vytvorené view holder objekty reprezentujú karty, ktoré sú zobrazené v RecyclerView. Tento návrhový vzor možno použiť vytvorením vnútornej triedy, potomok triedy RecyclerView.ViewHolder, v triede adaptéra.

==== Adaptér ====

Adaptér je návrhový vzor, ktorý funguje ako most medzi používateľským rozhraním a dátami. V Androide predstavuje adaptér triedu, ktorá sprostredkováva dáta RecyclerView. Trieda adaptéra (potomok triedy RecyclerView.Adapter) zabezpečuje správu jednotlivých view holder objektov prostredníctvom preťažených metód rodičovskej triedy: vytvorenie view holder objektov - metóda onCreateViewHolder, pridávanie vytvorených view holder objektov do RecyclerView - metóda onBindViewHolder().

V aplikácii sú vytvorené dve triedy adaptérov, kde každá z nich sprostredkováva dáta konkrétnej aktivite: DashboardAdapter (Dashboard aktivita), FavouritesAdapter (Favourites aktivita). Triedy adaptérov v aplikácii využívajú návrhový vzor Singleton, pričom vytvorenie (získanie) inštancie triedy oboch adaptérov je možné prostredníctvom statickej metódy getInstance(). Spôsob implementácie triedy adaptéra v aplikácii je demonštrovaný na jednoduchšej triede FavouritesAdapter, ktorá vykresľuje len jeden typ view holder objektu (len karta senzora, vľavo). Trieda DashboardAdapter vykresľuje tri typy view holder objektov, kde každý z nich reprezentuje kartu: oblasti, sektoru, alebo senzora ( vpravo).

Vytvorenie inštancie triedy FavouritesAdapter a následné nastavenie tejto inštancie ako adaptér objektu recylerView demonštruje kód [[#listing:adapter|[listing:adapter]]].

<source lang="java"> RecyclerView recyclerView = findViewById(R.id.recycler_view);
FavouritesAdapter adapter = FavouritesAdapter.getInstance();
recyclerView.setAdapter(adapter);</source>
[[File:favourites.png|x264px|RecyclerView - aktivita Dashboard (vpravo), aktivita Favourites (vľavo)]] [[File:recycler_view_dashboard_edit.png|x264px|RecyclerView - aktivita Dashboard (vpravo), aktivita Favourites (vľavo)]]

Nasledujúca ukážka ([[#listing:viewHolder|[listing:viewHolder]]]) zobrazuje implementáciu návrhového vzoru ViewHolder v triede adaptéra (FavouritesAdapter), vytvorením vnútornej triedy DataViewHolder. Trieda DataViewHolder inicializuje jednotlivé View prvky CardView rozloženia karty senzora. Každý vytvorený objekt tejto triedy reprezentuje jednu kartu v RecyclerView.

<source lang="java"> public static class DataViewHolder extends RecyclerView.ViewHolder {
private TextView textViewSensorName;
// iné View prvky CardView rozloženia karty senzora...
public DataViewHolder(@NonNull final View itemView) {
super(itemView);
textViewSensorName =
itemView.findViewById(R.id.text_view_sensor_name);
}
}</source>
Metóda triedy adaptéra - onCreateViewHolder() ([[#listing:onCreate|[listing:onCreate]]]) slúži pre dynamické vytváranie view holder objektov. Táto metóda vytvára len taký počet view holder objektov (kariet), koľko sa aktuálne zmestí na obrazovku. Pri listovaní v RecyclerView sú dynamicky vytvárané ďalšie potrebné objekty, pričom nahrádzajú tie, ktoré už na obrazovke nie sú vidieť (recycling).

<source lang="java"> @NonNull
@override
public RecyclerView.ViewHolder onCreateViewHolder(
@NonNull ViewGroup viewGroup, int i) {
View v;
LayoutInflater mInflater =
LayoutInflater.from(viewGroup.getContext());
v = mInflater.inflate(
R.layout.card_view_sensor, viewGroup, false);
return new FavouritesAdapter.DataViewHolder(v); }</source>
Samotné pridanie vytvoreného view holder objektu do RecyclerView zabezpečuje metóda - onBindViewHolder() ([[#listing:onBind|[listing:onBind]]]). Každý view holder objekt v RecyclerView má definovanú pozíciu, na ktorej sa nachádza. Hodnotu aktuálnej pozície, na ktorú má byť ďalší view holder objekt pridaný/vykreslený prijíma metóda onBindViewHolder() prostredníctvom parametra. Na základe pozície je možné naviazať konkrétny view holder objekt na dáta.

<source lang="java"> @override
public void onBindViewHolder(
@NonNull RecyclerView.ViewHolder viewHolder, int position) {
((DataViewHolder) viewHolder).
textViewSensorName.setText(
filteredList.get(position).getSensorName()); }</source>
=== Vizualizácia dát v aktivite GraphView ===

Prezentáciu dát v aktivite GraphView zabezpečujú grafy, vytvárané pomocou knižnice MPAndroidChart. Táto knižnica umožňuje vytvárať rôzne typy grafov: koláčové, stĺpcové, čiarové a iné. V aplikácii je využitý čiarový graf - LineChart. V aplikácii sú v grafe vykresľované dva typy čiar: LimitLine - horizontálna čiara pre zobrazenie priemernej hodnoty a samotná čiara grafu LineChart pre vykreslenie priebehu meraných hodnôt. Hodnoty osi x sú reprezentované časovými značkami jednotlivých meraní, ktoré sú explicitne konvertované na textový formát dátumu, ktorý je v grafe zobrazený ako legenda osi x. Hodnoty osi y sú reprezentované nameranými hodnotami. Jednotlivé body grafu sú vytvárané ako usporiadaná dvojica [časová značka, hodnota] ([[#listing:graph_creation|[listing:graph_creation]]] trieda Entry). Tieto usporiadané dvojice hodnôt sú postupne pridávané do poľa ([[#listing:graph_creation|[listing:graph_creation]]] objekt xyValues), ktoré je po naplnení priradené vytváranému objektu triedy LineDataSet v jej konštruktore. Metódy triedy LineDataSet umožňujú nastaviť požadované parametre čiary grafu (hrúbka, farba a iné). Objekt triedy LineDataSet je nakoniec priradený samotnému objektu grafu inicializovaného prostredníctvom metódy findViewById(). V aplikácii je v grafoch implementovaná možnosť zoomovania a taktiež možnosť zobrazenia hodnoty konkrétneho bodu pri kliknutí na ľubovoľnú hodnotu v grafe ( vpravo).

[[File:graph_view.png|151px|Vykresľovanie priebehu nameraných hodnôt v aktivite GraphView]] [[File:graph_view_land.png|264px|Vykresľovanie priebehu nameraných hodnôt v aktivite GraphView]]

<source lang="java"> ArrayList<Entry> xyValues = new ArrayList<>();
for (int i = 0; i < values.size; i++) {
Entry xy = new Entry(values.get(i).getDate().getTime(),
values.getValue());
xyValues.add(xy);
}
LineDataSet dataSet = new LineDataSet(xyValues, "hodnoty");
dataSet.setLineWidth(2f);
// iné nastavenia vlastností dataSetu...
LineData lineData = new LineData(dataSet);
LineChart chart = findViewById(R.id.chart);
chart.setData(lineData);</source>

Testovanie aplikácie nSoric aAurela

2020-09-03T20:12:06Z

Matus: Vytvorená stránka „{{Praca_uvod|5|Návrh a implementácia Android aplikácie pre monitoring priemyselného procesu|Informačný systém Sensorical|Platforma Android|Návrh aplikácie nSori…“

Implementácia aplikácie nSoric aAurela

2020-09-03T20:11:55Z

Matus: Vytvorená stránka „{{Praca_uvod|3|Návrh a implementácia Android aplikácie pre monitoring priemyselného procesu|Informačný systém Sensorical|Platforma Android|Návrh aplikácie nSori…“

Návrh aplikácie nSoric aAurela

2020-09-03T20:10:48Z

Matus: /* Funkčné požiadavky */

{{Praca_uvod|3|Návrh a implementácia Android aplikácie pre monitoring priemyselného procesu|Informačný systém Sensorical|Platforma Android|Návrh aplikácie nSoric aAurela|Implementácia aplikácie nSoric aAurela|Testovanie aplikácie nSoric aAurela}}

__TOC__

= =
V tejto kapitole sú postupne opísané jednotlivé fázy návrhu aplikácie ako: špecifikácia funkčných a nefunkčných požiadaviek, definícia minimálnych požiadaviek na inštaláciu, identifikácia prípadov použitia, návrh štruktúry, funkcionality a spôsob práce jednotlivých samostatných častí aplikácie. Výsledná aplikácia nebude zahŕňať akcie spojené s administráciou systému, tie budú i naďalej dostupné len cez desktopovú aplikáciu.

== Špecifikácia požiadaviek aplikácie ==

Definované požiadavky pre vývoj aplikácie boli rozdelené na dve skupiny: funkčné - popisujúce funkcie a vlastnosti, ktoré musí aplikácia poskytovať a nefunkčné požiadavky - bližšie špecifikujúce nároky na spôsob realizácie funkčných vlastností aplikácie.

==== Funkčné požiadavky ====

Zoznam funkčných požiadaviek bol vytvorený na základe požadovaných funkcií, ktoré musí aplikácia zabezpečovať a poskytovať. Pri definovaní jednotlivých funkčných požiadaviek aplikácie sa vychádzalo z jej primárnej úlohy - prístup k dátam rôznych serverov systému Sensorical a ich vizuálna reprezentácia v aplikácii. Tabuľka 3.2 zobrazuje zoznam funkčných požiadaviek.

Tabuľka 3.2: Nefunkčné požiadavky aplikácie aAurela
{| class="wikitable"
|-
!
!Funkčné požiadavky
!Doplňujúce informácie
|-
|R01
|Voľba vzdialeného servera
|Možnosť zvoliť si ľubovoľný Sensorical server, ku ktorému sa má aplikácia pripojiť
|-
|R02
|Zobrazenie relevantných údajov
|Prihlásenému používateľovi sú zobrazené len tie údaje, ku ktorým má definované prístupové práva
|-
|R03
|Kategorizácia umiestnenia
|Kategorizácia jednotlivých senzorov v rámci hierarchie umiestnenia (zaradenie do oblasti a sektoru)
|-
|R04
|Zobrazovanie nameraných hodnôt
|Zobrazenie nameraných hodnôt jednotlivých senzorov spolu s údajmi o dátume a čase kedy meranie prebehlo
|-
|R05
|Zobrazovanie trendov
|Zobrazenie trendov nameraných hodnôt jednotlivých senzorov za poslednú hodinu merania
|-
|R06
|Vytvorenie zoznamu obľúbených
|Možnosť vytvorenia vlastného zoznamu obľúbených resp. dôležitých senzorov
|-
|R07
|Editácia zoznamu obľúbených
|Možnosť pridania/odstránenia senzorov do/zo zoznamu obľúbených
|-
|R08
|Vyhľadávanie v prehľade
|Možnosť vyhľadávať v prehľade všetkých dostupných senzorov a v používateľom vytvorenom zozname obľúbených
|-
|R09
|Zobrazenie grafov
|Vykresľovanie grafov nameraných hodnôt jednotlivých senzorov ako závislosť zmeny nameranej hodnoty za časový horizont
|-
|R10
|Zmena časového rozpätia
|Možnosť zmeniť časové rozpätie, za ktoré má aplikácia zobraziť namerané hodnoty senzorov v prehľadoch a grafoch
|-
|R11
|Offline dostupnosť údajov
|Aplikácia umožní prehliadať archivované dáta aj bez dostupnosti internetového pripojenia
|}

==== Nefunkčné požiadavky ====

Zoznam nefunkčných požiadaviek bol zostavený na základe doplnkových požiadaviek a nárokov na aplikáciu. Definovanie týchto požiadaviek je spojené so špecifikáciou samotnej platformy, pre ktorú je aplikácia určená, ako aj jednotlivých nárokov na používateľské rozhranie a distribúciu aplikácie. Tabuľka 3.2 zobrazuje zoznam nefunkčných požiadaviek.

Tabuľka 3.2: Nefunkčné požiadavky aplikácie aAurela
{| class="wikitable"
|-
!
!Nefunkčné požiadavky
!Doplňujúce informácie
|-
|R01
|Aplikácia pre platformu Android
|
|-
|R02
|Implementácia odporúčaní Material Design
|Použitie odporúčaní Material Design pre tvorbu grafických používateľských rozhraní
|-
|R03
|Implementácia aplikácie v jazykových mutáciách
|Implementácia aplikácie v slovenskej a anglickej jazykovej mutácii
|-
|R04
|Možnosť budúceho rozšírenia
|Implementácia aplikácie tak, aby bolo možné jej budúce rozšírenie o ďalšie funkcie
|}

==== Minimálne požiadavky na inštaláciu aplikácie ====

Pre aplikáciu bola ako minimálna podporovaná verzia systému Android zvolená verzia 5.0 Lollipop (API 21) a ako cielená verzia, verzia 9.0 Pie (API 28). Minimálna podporovaná verzia systému bola vybraná na základe štatistík spoločnosti Google Inc tak, aby bežala na značnej väčšine zariadení. V čase vývoja aplikácie je API 21 a vyššie používané na viac ako 85% všetkých zariadení s OS Android.

[tab_nefunkcne_poziadavky]

== Funkcionality a štruktúra aplikácie ==

Na základe definovaných funkčných požiadaviek a nárokov na aplikáciu boli identifikované jednotlivé prípady použitia aplikácie. Táto podkapitola je venovaná bližšiemu opisu identifikovaných aktivít z prípadov použitia, ich významu resp. podstate. V tejto podkapitole je taktiež opísaná navrhnutá štruktúra aplikácie, funkcionality a princíp práce jednotlivých jej častí.

=== Prípady použitia ===

'''Aktéri''' - aktéri sú všetci používatelia, ktorí môžu v aplikácii vykonávať jednotlivé aktivity. V prípade aplikácie aAurela, ktorá má interné využitie, boli ako aktéri identifikovaní používatelia, ktorí sú evidovaní v databáze na vzdialenom serveri a majú tak oprávnenie systém a teda aj aplikáciu používať. '''Aktivity''' - predstavujú akcie, ktoré môžu aktéri s aplikáciou vykonávať. Jednotlivé aktivity boli navrhnuté tak, aby boli zabezpečené všetky funkčné požiadavky špecifikované v Tabuľke [[#tab_funkcne_poziadavky|[tab_funkcne_poziadavky]]]. zobrazuje vrcholový diagram prípadov použitia aplikácie aAurela.

[[File:vrcholovy_use_case.png|thumb|none|566px|alt=Diagram prípadov použitia aplikácie aAurela|Diagram prípadov použitia aplikácie aAurela]]

==== Aktivity prípadov použitia ====

* Výber adresy servera - zadanie webovej adresy vzdialeného servera, ku ktorému sa má aplikácia pripojiť.
* Prihlásiť sa - zadanie mena a hesla pre autentifikáciu na zvolenom serveri a prihlásenie sa do aplikácie.
* Zobraziť hlavný prehľad - zobrazenie a prechádzanie zoznamu všetkých dostupných senzorov kategorizovaných v rámci umiestnenia spolu so základnými údajmi naposledy nameraných hodnôt.
* Zobraziť prehľad obľúbených - zobrazenie a prechádzanie vytvoreného zoznamu obľúbených senzorov spolu so základnými údajmi naposledy nameraných hodnôt.
* Zobraziť graf - zobrazenie detailného pohľadu na históriu nameraných hodnôt vybraného senzora formou grafu a rôznych štatistík meraní.
* Editovať obľúbené - pridanie/odstránenie senzora do/zo zoznamu obľúbených.
* Aktualizovať merané hodnoty - stiahnutie najaktuálnejších nameraných hodnôt zo servera.
* Synchronizovať všetky údaje - synchronizácia všetkých údajov aplikácie s aktuálne dostupnými údajmi na serveri.
* Zmeniť zobrazovaný rozsah - zmena počtu dní, za ktoré má aplikácia zobrazovať a vyhodnocovať namerané hodnoty.
* Zobraziť informácie o aplikácii - zobrazenie informačnej obrazovky s bližším popisom o aplikácii.
* Odhlásiť sa - odhlásenie sa z aplikácie.

=== Návrh štruktúry aplikácie ===

Štruktúra aplikácie bola navrhnutá na základe vymedzenia hlavných aktivít z prípadov použitia. Každá z týchto aktivít predstavuje samostatnú časť (obrazovku) aplikácie, kde každá z obrazoviek slúži pre prístup do samostatnej, funkčne a logicky oddelenej časti, v ktorej je možné vykonávať rôzne ďalšie aktivity. Aplikáciu aAurela tvoria nasledujúce obrazovky:

* ServerSelect - obrazovka pre výber adresy servera
* Login - obrazovka pre prihlásenie do aplikácie
* Dashboard - obrazovka hlavného prehľadu
* Favourites - obrazovka prehľadu obľúbených senzorov
* GraphView - obrazovka pre zobrazenie grafov a štatistík merania
* About - informačná obrazovka

Takto definované funkčné časti aplikácie sú vo fáze implementácie implementované ako jednotlivé triedy Android aktivít.

=== Funkcie a spôsob práce jednotlivých častí aplikácie ===

==== Výber adresy servera a prihlásenie do aplikácie ====

Skôr, ako používateľ získa v aplikácii prístup k dátam, musí prejsť voľbou adresy servera, ku ktorému sa chce pripojiť a následne prihlásiť. Pre výber adresy servera a následné prihlásenie do aplikácie slúžia obrazovky ServerSelect a Login.

==== ServerSelect ====

Pri prvotnom spustení aplikácie bude používateľ vyzvaný na zadanie adresy vzdialeného Sensorical servera, ku ktorému sa chce pripojiť. Po zadaní údajov aplikácia overí správnosť a dostupnosť zadanej adresy. Ak sú zadané údaje správne, používateľ bude presmerovaný na prihlasovaciu obrazovku (Login) a zadané údaje sa uložia pre rýchle načítanie pri ďalšom spustení aplikácie. V prípade nesprávne zadaných údajov nebude používateľ pripustený k prihláseniu, ale bude vyzvaný na opravu zle zadanej adresy.

==== Login ====

Po otvorení prihlasovacej obrazovky sa používateľovi zobrazia polia pre zadanie prihlasovacieho mena a hesla. Po zadaní údajov aplikácia odošle na server autentifikačnú požiadavku so zadanými prihlasovacími údajmi. Ak sú zadané údaje správne, používateľ bude prihlásený. Ak zadané údaje nie sú správne, zobrazí sa oznámenie o zle zadaných prihlasovacích údajoch. Používateľ bude mať pred prihlásením možnosť voľby zapamätania prihlasovacích údajov pre automatické prihlásenie pri ďalšom spustení aplikácie.

==== Diagram aktivít ServerSelect a Login ====

Pri spustení aplikácie bude vždy otvorená obrazovka pre výber adresy servera - ServerSelect. Po úspešnom overení zadanej adresy sa bude pokračovať na prihlasovaciu obrazovku - Login. Prihlasovacou obrazovkou používateľ neprechádza v prípade, keď už bol do aplikácie prihlásený a zvolil možnosť zapamätania prihlásenia. Celý proces výberu adresy servera a následné prihlásenie do aplikácie znázorňuje diagram aktivít na obrázku [[#fig:activity_diagram_before_login|1.2]].

[[File:state_diagram_befor_login.png|thumb|none|566px|alt=Diagram aktivít - práca aplikácie pred prihlásením|Diagram aktivít - práca aplikácie pred prihlásením]]

==== Po prihlásení do aplikácie ====

Po zadaní správnej adresy servera a následnom úspešnom prihlásení do aplikácie získa používateľ prístup k dátam systému Sensorical. Možnosť prístupu k dátam bude mať prostredníctvom troch obrazoviek: Dashboard, Favourites a GraphView.

==== Dashboard ====

Obrazovka, ktorá bude štandardne zobrazená prihlásenému používateľovi. Slúži na sprostredkovanie celkového prehľadu základných dostupných dát systému. Používateľ tu uvidí zoznam všetkých jemu dostupných senzorov, kategorizovaných v rámci hierarchie prvej úrovne (oblasti) a druhej úrovne (sektoru). Obrazovka Dashboard taktiež zobrazí údaje o naposledy nameraných hodnotách jednotlivých senzorov za zvolené časové obdobie, priemernú hodnotu a trendy nameraných hodnôt jednotlivých senzorov za poslednú hodinu.

==== Favourites ====

Obrazovka, ktorá zobrazí prehľad používateľom vytvoreného zoznamu obľúbených senzorov. Používateľ bude mať k tejto obrazovke umožnený prístup len v prípade, ak má vytvorený vlastný zoznam obľúbených senzorov. Po prvotnom prihlásení do aplikácie nebude k dispozícii žiadny zoznam obľúbených senzorov. Ak však používateľ pridá v hlavnom prehľade (Dashboard) alebo obrazovke konkrétneho senzoru (GraphView) ľubovolný senzor do obľúbených, bude obrazovka Favourties zobrazovaná prednostne. To znamená, ak bude mať používateľ vytvorený zoznam obľúbených senzorov, zobrazí sa tento prehľad prioritne po prihlásení do aplikácie. Obrazovka Favourites taktiež zobrazí údaje o naposledy nameraných hodnotách jednotlivých senzorov za zvolené časové obdobie, priemernú hodnotu a trendy nameraných hodnôt jednotlivých senzorov za poslednú hodinu, podobne ako obrazovka Dashboard.

==== GraphView ====

Táto obrazovka slúži pre zobrazenie detailného náhľadu na históriu meraní konkrétneho senzora. Obrazovka GraphView bude zobrazená pri výbere ľubovoľného senzoru z prehľadu, či už na obrazovke Dashboard alebo Favourites. Podstatou obrazovky GraphView je zobraziť priebeh hodnôt meranej veličiny v závislosti od času vizuálnou formou (graf), ako aj štatistiky meraní daného senzora formou extrémov meraní.

==== Diagram aktivít Dashboard, Favourites, GraphView ====

Po prihlásení do aplikácie dôjde k overeniu, či má prihlásený používateľ vytvorený zoznam obľúbených senzorov. Ak má takýto zoznam vytvorený, bude prednostne otvorená obrazovka prehľadu obľúbených senzorov - Favourites. Ak takýto zoznam používateľ vytvorený nemá, bude otvorená obrazovka s prehľadom všetkých senzorov - Dashboard. Obe tieto obrazovky poskytnú používateľovi možnosť zobraziť detailný náhľad ľubovoľného, dostupného senzoru z prehľadu - GraphView. Postupnosť prechodu medzi obrazovkami Dashboard, Favourites a GraphView znázorňuje diagram aktivít na obrázku [[#fig:activity_diagram_after_login|1.3]].

[[File:state_diagram_after_login.png|thumb|none|566px|alt=Diagram aktivít - práca aplikácie po úspešnom prihlásení|Diagram aktivít - práca aplikácie po úspešnom prihlásení]]

Súbor:State diagram after login.png

2020-09-03T19:53:45Z

Matus:

Súbor:State diagram befor login.png

2020-09-03T19:53:28Z

Matus:

Súbor:Vrcholovy use case.png

2020-09-03T19:52:42Z

Matus:

Návrh aplikácie nSoric aAurela

2020-09-03T19:52:11Z

Matus: /* */

{{Praca_uvod|3|Návrh a implementácia Android aplikácie pre monitoring priemyselného procesu|Informačný systém Sensorical|Platforma Android|Návrh aplikácie nSoric aAurela|Implementácia aplikácie nSoric aAurela|Testovanie aplikácie nSoric aAurela}}

__TOC__

= =
V tejto kapitole sú postupne opísané jednotlivé fázy návrhu aplikácie ako: špecifikácia funkčných a nefunkčných požiadaviek, definícia minimálnych požiadaviek na inštaláciu, identifikácia prípadov použitia, návrh štruktúry, funkcionality a spôsob práce jednotlivých samostatných častí aplikácie. Výsledná aplikácia nebude zahŕňať akcie spojené s administráciou systému, tie budú i naďalej dostupné len cez desktopovú aplikáciu.

== Špecifikácia požiadaviek aplikácie ==

Definované požiadavky pre vývoj aplikácie boli rozdelené na dve skupiny: funkčné - popisujúce funkcie a vlastnosti, ktoré musí aplikácia poskytovať a nefunkčné požiadavky - bližšie špecifikujúce nároky na spôsob realizácie funkčných vlastností aplikácie.

==== Funkčné požiadavky ====

Zoznam funkčných požiadaviek bol vytvorený na základe požadovaných funkcií, ktoré musí aplikácia zabezpečovať a poskytovať. Pri definovaní jednotlivých funkčných požiadaviek aplikácie sa vychádzalo z jej primárnej úlohy - prístup k dátam rôznych serverov systému Sensorical a ich vizuálna reprezentácia v aplikácii. Tabuľka [[#tab_funkcne_poziadavky|[tab_funkcne_poziadavky]]] zobrazuje zoznam funkčných požiadaviek.

[tab_funkcne_poziadavky]

==== Nefunkčné požiadavky ====

Zoznam nefunkčných požiadaviek bol zostavený na základe doplnkových požiadaviek a nárokov na aplikáciu. Definovanie týchto požiadaviek je spojené so špecifikáciou samotnej platformy, pre ktorú je aplikácia určená, ako aj jednotlivých nárokov na používateľské rozhranie a distribúciu aplikácie. Tabuľka [[#tab_nefunkcne_poziadavky|[tab_nefunkcne_poziadavky]]] zobrazuje zoznam nefunkčných požiadaviek.

==== Minimálne požiadavky na inštaláciu aplikácie ====

Pre aplikáciu bola ako minimálna podporovaná verzia systému Android zvolená verzia 5.0 Lollipop (API 21) a ako cielená verzia, verzia 9.0 Pie (API 28). Minimálna podporovaná verzia systému bola vybraná na základe štatistík spoločnosti Google Inc tak, aby bežala na značnej väčšine zariadení. V čase vývoja aplikácie je API 21 a vyššie používané na viac ako 85% všetkých zariadení s OS Android.

[tab_nefunkcne_poziadavky]

== Funkcionality a štruktúra aplikácie ==

Na základe definovaných funkčných požiadaviek a nárokov na aplikáciu boli identifikované jednotlivé prípady použitia aplikácie. Táto podkapitola je venovaná bližšiemu opisu identifikovaných aktivít z prípadov použitia, ich významu resp. podstate. V tejto podkapitole je taktiež opísaná navrhnutá štruktúra aplikácie, funkcionality a princíp práce jednotlivých jej častí.

=== Prípady použitia ===

'''Aktéri''' - aktéri sú všetci používatelia, ktorí môžu v aplikácii vykonávať jednotlivé aktivity. V prípade aplikácie aAurela, ktorá má interné využitie, boli ako aktéri identifikovaní používatelia, ktorí sú evidovaní v databáze na vzdialenom serveri a majú tak oprávnenie systém a teda aj aplikáciu používať. '''Aktivity''' - predstavujú akcie, ktoré môžu aktéri s aplikáciou vykonávať. Jednotlivé aktivity boli navrhnuté tak, aby boli zabezpečené všetky funkčné požiadavky špecifikované v Tabuľke [[#tab_funkcne_poziadavky|[tab_funkcne_poziadavky]]]. zobrazuje vrcholový diagram prípadov použitia aplikácie aAurela.

[[File:vrcholovy_use_case.png|thumb|none|566px|alt=Diagram prípadov použitia aplikácie aAurela|Diagram prípadov použitia aplikácie aAurela]]

==== Aktivity prípadov použitia ====

* Výber adresy servera - zadanie webovej adresy vzdialeného servera, ku ktorému sa má aplikácia pripojiť.
* Prihlásiť sa - zadanie mena a hesla pre autentifikáciu na zvolenom serveri a prihlásenie sa do aplikácie.
* Zobraziť hlavný prehľad - zobrazenie a prechádzanie zoznamu všetkých dostupných senzorov kategorizovaných v rámci umiestnenia spolu so základnými údajmi naposledy nameraných hodnôt.
* Zobraziť prehľad obľúbených - zobrazenie a prechádzanie vytvoreného zoznamu obľúbených senzorov spolu so základnými údajmi naposledy nameraných hodnôt.
* Zobraziť graf - zobrazenie detailného pohľadu na históriu nameraných hodnôt vybraného senzora formou grafu a rôznych štatistík meraní.
* Editovať obľúbené - pridanie/odstránenie senzora do/zo zoznamu obľúbených.
* Aktualizovať merané hodnoty - stiahnutie najaktuálnejších nameraných hodnôt zo servera.
* Synchronizovať všetky údaje - synchronizácia všetkých údajov aplikácie s aktuálne dostupnými údajmi na serveri.
* Zmeniť zobrazovaný rozsah - zmena počtu dní, za ktoré má aplikácia zobrazovať a vyhodnocovať namerané hodnoty.
* Zobraziť informácie o aplikácii - zobrazenie informačnej obrazovky s bližším popisom o aplikácii.
* Odhlásiť sa - odhlásenie sa z aplikácie.

=== Návrh štruktúry aplikácie ===

Štruktúra aplikácie bola navrhnutá na základe vymedzenia hlavných aktivít z prípadov použitia. Každá z týchto aktivít predstavuje samostatnú časť (obrazovku) aplikácie, kde každá z obrazoviek slúži pre prístup do samostatnej, funkčne a logicky oddelenej časti, v ktorej je možné vykonávať rôzne ďalšie aktivity. Aplikáciu aAurela tvoria nasledujúce obrazovky:

* ServerSelect - obrazovka pre výber adresy servera
* Login - obrazovka pre prihlásenie do aplikácie
* Dashboard - obrazovka hlavného prehľadu
* Favourites - obrazovka prehľadu obľúbených senzorov
* GraphView - obrazovka pre zobrazenie grafov a štatistík merania
* About - informačná obrazovka

Takto definované funkčné časti aplikácie sú vo fáze implementácie implementované ako jednotlivé triedy Android aktivít.

=== Funkcie a spôsob práce jednotlivých častí aplikácie ===

==== Výber adresy servera a prihlásenie do aplikácie ====

Skôr, ako používateľ získa v aplikácii prístup k dátam, musí prejsť voľbou adresy servera, ku ktorému sa chce pripojiť a následne prihlásiť. Pre výber adresy servera a následné prihlásenie do aplikácie slúžia obrazovky ServerSelect a Login.

==== ServerSelect ====

Pri prvotnom spustení aplikácie bude používateľ vyzvaný na zadanie adresy vzdialeného Sensorical servera, ku ktorému sa chce pripojiť. Po zadaní údajov aplikácia overí správnosť a dostupnosť zadanej adresy. Ak sú zadané údaje správne, používateľ bude presmerovaný na prihlasovaciu obrazovku (Login) a zadané údaje sa uložia pre rýchle načítanie pri ďalšom spustení aplikácie. V prípade nesprávne zadaných údajov nebude používateľ pripustený k prihláseniu, ale bude vyzvaný na opravu zle zadanej adresy.

==== Login ====

Po otvorení prihlasovacej obrazovky sa používateľovi zobrazia polia pre zadanie prihlasovacieho mena a hesla. Po zadaní údajov aplikácia odošle na server autentifikačnú požiadavku so zadanými prihlasovacími údajmi. Ak sú zadané údaje správne, používateľ bude prihlásený. Ak zadané údaje nie sú správne, zobrazí sa oznámenie o zle zadaných prihlasovacích údajoch. Používateľ bude mať pred prihlásením možnosť voľby zapamätania prihlasovacích údajov pre automatické prihlásenie pri ďalšom spustení aplikácie.

==== Diagram aktivít ServerSelect a Login ====

Pri spustení aplikácie bude vždy otvorená obrazovka pre výber adresy servera - ServerSelect. Po úspešnom overení zadanej adresy sa bude pokračovať na prihlasovaciu obrazovku - Login. Prihlasovacou obrazovkou používateľ neprechádza v prípade, keď už bol do aplikácie prihlásený a zvolil možnosť zapamätania prihlásenia. Celý proces výberu adresy servera a následné prihlásenie do aplikácie znázorňuje diagram aktivít na obrázku [[#fig:activity_diagram_before_login|1.2]].

[[File:state_diagram_befor_login.png|thumb|none|566px|alt=Diagram aktivít - práca aplikácie pred prihlásením|Diagram aktivít - práca aplikácie pred prihlásením]]

==== Po prihlásení do aplikácie ====

Po zadaní správnej adresy servera a následnom úspešnom prihlásení do aplikácie získa používateľ prístup k dátam systému Sensorical. Možnosť prístupu k dátam bude mať prostredníctvom troch obrazoviek: Dashboard, Favourites a GraphView.

==== Dashboard ====

Obrazovka, ktorá bude štandardne zobrazená prihlásenému používateľovi. Slúži na sprostredkovanie celkového prehľadu základných dostupných dát systému. Používateľ tu uvidí zoznam všetkých jemu dostupných senzorov, kategorizovaných v rámci hierarchie prvej úrovne (oblasti) a druhej úrovne (sektoru). Obrazovka Dashboard taktiež zobrazí údaje o naposledy nameraných hodnotách jednotlivých senzorov za zvolené časové obdobie, priemernú hodnotu a trendy nameraných hodnôt jednotlivých senzorov za poslednú hodinu.

==== Favourites ====

Obrazovka, ktorá zobrazí prehľad používateľom vytvoreného zoznamu obľúbených senzorov. Používateľ bude mať k tejto obrazovke umožnený prístup len v prípade, ak má vytvorený vlastný zoznam obľúbených senzorov. Po prvotnom prihlásení do aplikácie nebude k dispozícii žiadny zoznam obľúbených senzorov. Ak však používateľ pridá v hlavnom prehľade (Dashboard) alebo obrazovke konkrétneho senzoru (GraphView) ľubovolný senzor do obľúbených, bude obrazovka Favourties zobrazovaná prednostne. To znamená, ak bude mať používateľ vytvorený zoznam obľúbených senzorov, zobrazí sa tento prehľad prioritne po prihlásení do aplikácie. Obrazovka Favourites taktiež zobrazí údaje o naposledy nameraných hodnotách jednotlivých senzorov za zvolené časové obdobie, priemernú hodnotu a trendy nameraných hodnôt jednotlivých senzorov za poslednú hodinu, podobne ako obrazovka Dashboard.

==== GraphView ====

Táto obrazovka slúži pre zobrazenie detailného náhľadu na históriu meraní konkrétneho senzora. Obrazovka GraphView bude zobrazená pri výbere ľubovoľného senzoru z prehľadu, či už na obrazovke Dashboard alebo Favourites. Podstatou obrazovky GraphView je zobraziť priebeh hodnôt meranej veličiny v závislosti od času vizuálnou formou (graf), ako aj štatistiky meraní daného senzora formou extrémov meraní.

==== Diagram aktivít Dashboard, Favourites, GraphView ====

Po prihlásení do aplikácie dôjde k overeniu, či má prihlásený používateľ vytvorený zoznam obľúbených senzorov. Ak má takýto zoznam vytvorený, bude prednostne otvorená obrazovka prehľadu obľúbených senzorov - Favourites. Ak takýto zoznam používateľ vytvorený nemá, bude otvorená obrazovka s prehľadom všetkých senzorov - Dashboard. Obe tieto obrazovky poskytnú používateľovi možnosť zobraziť detailný náhľad ľubovoľného, dostupného senzoru z prehľadu - GraphView. Postupnosť prechodu medzi obrazovkami Dashboard, Favourites a GraphView znázorňuje diagram aktivít na obrázku [[#fig:activity_diagram_after_login|1.3]].

[[File:state_diagram_after_login.png|thumb|none|566px|alt=Diagram aktivít - práca aplikácie po úspešnom prihlásení|Diagram aktivít - práca aplikácie po úspešnom prihlásení]]

Návrh aplikácie nSoric aAurela

2020-09-03T19:51:13Z

{{Praca_uvod|3|Návrh a implementácia Android aplikácie pre monitoring priemyselného procesu|Informačný systém Sensorical|Platforma Android|Návrh aplikácie nSoric aAurela|Implementácia aplikácie nSoric aAurela|Testovanie aplikácie nSoric aAurela}}

__TOC__

= =
V tejto kapitole sú postupne opísané jednotlivé fázy návrhu aplikácie ako: špecifikácia funkčných a nefunkčných požiadaviek, definícia minimálnych požiadaviek na inštaláciu, identifikácia prípadov použitia, návrh štruktúry, funkcionality a spôsob práce jednotlivých samostatných častí aplikácie. Výsledná aplikácia nebude zahŕňať akcie spojené s administráciou systému, tie budú i naďalej dostupné len cez desktopovú aplikáciu.

== Špecifikácia požiadaviek aplikácie ==

Definované požiadavky pre vývoj aplikácie boli rozdelené na dve skupiny: funkčné - popisujúce funkcie a vlastnosti, ktoré musí aplikácia poskytovať a nefunkčné požiadavky - bližšie špecifikujúce nároky na spôsob realizácie funkčných vlastností aplikácie.

==== Funkčné požiadavky ====

Zoznam funkčných požiadaviek bol vytvorený na základe požadovaných funkcií, ktoré musí aplikácia zabezpečovať a poskytovať. Pri definovaní jednotlivých funkčných požiadaviek aplikácie sa vychádzalo z jej primárnej úlohy - prístup k dátam rôznych serverov systému Sensorical a ich vizuálna reprezentácia v aplikácii. Tabuľka [[#tab_funkcne_poziadavky|[tab_funkcne_poziadavky]]] zobrazuje zoznam funkčných požiadaviek.

[tab_funkcne_poziadavky]

==== Nefunkčné požiadavky ====

Zoznam nefunkčných požiadaviek bol zostavený na základe doplnkových požiadaviek a nárokov na aplikáciu. Definovanie týchto požiadaviek je spojené so špecifikáciou samotnej platformy, pre ktorú je aplikácia určená, ako aj jednotlivých nárokov na používateľské rozhranie a distribúciu aplikácie. Tabuľka [[#tab_nefunkcne_poziadavky|[tab_nefunkcne_poziadavky]]] zobrazuje zoznam nefunkčných požiadaviek.

==== Minimálne požiadavky na inštaláciu aplikácie ====

Pre aplikáciu bola ako minimálna podporovaná verzia systému Android zvolená verzia 5.0 Lollipop (API 21) a ako cielená verzia, verzia 9.0 Pie (API 28). Minimálna podporovaná verzia systému bola vybraná na základe štatistík spoločnosti Google Inc tak, aby bežala na značnej väčšine zariadení. V čase vývoja aplikácie je API 21 a vyššie používané na viac ako 85% všetkých zariadení s OS Android.

[tab_nefunkcne_poziadavky]

== Funkcionality a štruktúra aplikácie ==

Na základe definovaných funkčných požiadaviek a nárokov na aplikáciu boli identifikované jednotlivé prípady použitia aplikácie. Táto podkapitola je venovaná bližšiemu opisu identifikovaných aktivít z prípadov použitia, ich významu resp. podstate. V tejto podkapitole je taktiež opísaná navrhnutá štruktúra aplikácie, funkcionality a princíp práce jednotlivých jej častí.

=== Prípady použitia ===

'''Aktéri''' - aktéri sú všetci používatelia, ktorí môžu v aplikácii vykonávať jednotlivé aktivity. V prípade aplikácie aAurela, ktorá má interné využitie, boli ako aktéri identifikovaní používatelia, ktorí sú evidovaní v databáze na vzdialenom serveri a majú tak oprávnenie systém a teda aj aplikáciu používať. '''Aktivity''' - predstavujú akcie, ktoré môžu aktéri s aplikáciou vykonávať. Jednotlivé aktivity boli navrhnuté tak, aby boli zabezpečené všetky funkčné požiadavky špecifikované v Tabuľke [[#tab_funkcne_poziadavky|[tab_funkcne_poziadavky]]]. zobrazuje vrcholový diagram prípadov použitia aplikácie aAurela.

[[File:obrazky/vrcholovy_use_case.png|thumb|none|566px|alt=Diagram prípadov použitia aplikácie aAurela|Diagram prípadov použitia aplikácie aAurela]]

==== Aktivity prípadov použitia ====

* Výber adresy servera - zadanie webovej adresy vzdialeného servera, ku ktorému sa má aplikácia pripojiť.
* Prihlásiť sa - zadanie mena a hesla pre autentifikáciu na zvolenom serveri a prihlásenie sa do aplikácie.
* Zobraziť hlavný prehľad - zobrazenie a prechádzanie zoznamu všetkých dostupných senzorov kategorizovaných v rámci umiestnenia spolu so základnými údajmi naposledy nameraných hodnôt.
* Zobraziť prehľad obľúbených - zobrazenie a prechádzanie vytvoreného zoznamu obľúbených senzorov spolu so základnými údajmi naposledy nameraných hodnôt.
* Zobraziť graf - zobrazenie detailného pohľadu na históriu nameraných hodnôt vybraného senzora formou grafu a rôznych štatistík meraní.
* Editovať obľúbené - pridanie/odstránenie senzora do/zo zoznamu obľúbených.
* Aktualizovať merané hodnoty - stiahnutie najaktuálnejších nameraných hodnôt zo servera.
* Synchronizovať všetky údaje - synchronizácia všetkých údajov aplikácie s aktuálne dostupnými údajmi na serveri.
* Zmeniť zobrazovaný rozsah - zmena počtu dní, za ktoré má aplikácia zobrazovať a vyhodnocovať namerané hodnoty.
* Zobraziť informácie o aplikácii - zobrazenie informačnej obrazovky s bližším popisom o aplikácii.
* Odhlásiť sa - odhlásenie sa z aplikácie.

=== Návrh štruktúry aplikácie ===

Štruktúra aplikácie bola navrhnutá na základe vymedzenia hlavných aktivít z prípadov použitia. Každá z týchto aktivít predstavuje samostatnú časť (obrazovku) aplikácie, kde každá z obrazoviek slúži pre prístup do samostatnej, funkčne a logicky oddelenej časti, v ktorej je možné vykonávať rôzne ďalšie aktivity. Aplikáciu aAurela tvoria nasledujúce obrazovky:

* ServerSelect - obrazovka pre výber adresy servera
* Login - obrazovka pre prihlásenie do aplikácie
* Dashboard - obrazovka hlavného prehľadu
* Favourites - obrazovka prehľadu obľúbených senzorov
* GraphView - obrazovka pre zobrazenie grafov a štatistík merania
* About - informačná obrazovka

Takto definované funkčné časti aplikácie sú vo fáze implementácie implementované ako jednotlivé triedy Android aktivít.

=== Funkcie a spôsob práce jednotlivých častí aplikácie ===

==== Výber adresy servera a prihlásenie do aplikácie ====

Skôr, ako používateľ získa v aplikácii prístup k dátam, musí prejsť voľbou adresy servera, ku ktorému sa chce pripojiť a následne prihlásiť. Pre výber adresy servera a následné prihlásenie do aplikácie slúžia obrazovky ServerSelect a Login.

==== ServerSelect ====

Pri prvotnom spustení aplikácie bude používateľ vyzvaný na zadanie adresy vzdialeného Sensorical servera, ku ktorému sa chce pripojiť. Po zadaní údajov aplikácia overí správnosť a dostupnosť zadanej adresy. Ak sú zadané údaje správne, používateľ bude presmerovaný na prihlasovaciu obrazovku (Login) a zadané údaje sa uložia pre rýchle načítanie pri ďalšom spustení aplikácie. V prípade nesprávne zadaných údajov nebude používateľ pripustený k prihláseniu, ale bude vyzvaný na opravu zle zadanej adresy.

==== Login ====

Po otvorení prihlasovacej obrazovky sa používateľovi zobrazia polia pre zadanie prihlasovacieho mena a hesla. Po zadaní údajov aplikácia odošle na server autentifikačnú požiadavku so zadanými prihlasovacími údajmi. Ak sú zadané údaje správne, používateľ bude prihlásený. Ak zadané údaje nie sú správne, zobrazí sa oznámenie o zle zadaných prihlasovacích údajoch. Používateľ bude mať pred prihlásením možnosť voľby zapamätania prihlasovacích údajov pre automatické prihlásenie pri ďalšom spustení aplikácie.

==== Diagram aktivít ServerSelect a Login ====

Pri spustení aplikácie bude vždy otvorená obrazovka pre výber adresy servera - ServerSelect. Po úspešnom overení zadanej adresy sa bude pokračovať na prihlasovaciu obrazovku - Login. Prihlasovacou obrazovkou používateľ neprechádza v prípade, keď už bol do aplikácie prihlásený a zvolil možnosť zapamätania prihlásenia. Celý proces výberu adresy servera a následné prihlásenie do aplikácie znázorňuje diagram aktivít na obrázku [[#fig:activity_diagram_before_login|1.2]].

[[File:obrazky/state_diagram_befor_login.png|thumb|none|566px|alt=Diagram aktivít - práca aplikácie pred prihlásením|Diagram aktivít - práca aplikácie pred prihlásením]]

==== Po prihlásení do aplikácie ====

Po zadaní správnej adresy servera a následnom úspešnom prihlásení do aplikácie získa používateľ prístup k dátam systému Sensorical. Možnosť prístupu k dátam bude mať prostredníctvom troch obrazoviek: Dashboard, Favourites a GraphView.

==== Dashboard ====

Obrazovka, ktorá bude štandardne zobrazená prihlásenému používateľovi. Slúži na sprostredkovanie celkového prehľadu základných dostupných dát systému. Používateľ tu uvidí zoznam všetkých jemu dostupných senzorov, kategorizovaných v rámci hierarchie prvej úrovne (oblasti) a druhej úrovne (sektoru). Obrazovka Dashboard taktiež zobrazí údaje o naposledy nameraných hodnotách jednotlivých senzorov za zvolené časové obdobie, priemernú hodnotu a trendy nameraných hodnôt jednotlivých senzorov za poslednú hodinu.

==== Favourites ====

Obrazovka, ktorá zobrazí prehľad používateľom vytvoreného zoznamu obľúbených senzorov. Používateľ bude mať k tejto obrazovke umožnený prístup len v prípade, ak má vytvorený vlastný zoznam obľúbených senzorov. Po prvotnom prihlásení do aplikácie nebude k dispozícii žiadny zoznam obľúbených senzorov. Ak však používateľ pridá v hlavnom prehľade (Dashboard) alebo obrazovke konkrétneho senzoru (GraphView) ľubovolný senzor do obľúbených, bude obrazovka Favourties zobrazovaná prednostne. To znamená, ak bude mať používateľ vytvorený zoznam obľúbených senzorov, zobrazí sa tento prehľad prioritne po prihlásení do aplikácie. Obrazovka Favourites taktiež zobrazí údaje o naposledy nameraných hodnotách jednotlivých senzorov za zvolené časové obdobie, priemernú hodnotu a trendy nameraných hodnôt jednotlivých senzorov za poslednú hodinu, podobne ako obrazovka Dashboard.

==== GraphView ====

Táto obrazovka slúži pre zobrazenie detailného náhľadu na históriu meraní konkrétneho senzora. Obrazovka GraphView bude zobrazená pri výbere ľubovoľného senzoru z prehľadu, či už na obrazovke Dashboard alebo Favourites. Podstatou obrazovky GraphView je zobraziť priebeh hodnôt meranej veličiny v závislosti od času vizuálnou formou (graf), ako aj štatistiky meraní daného senzora formou extrémov meraní.

==== Diagram aktivít Dashboard, Favourites, GraphView ====

Po prihlásení do aplikácie dôjde k overeniu, či má prihlásený používateľ vytvorený zoznam obľúbených senzorov. Ak má takýto zoznam vytvorený, bude prednostne otvorená obrazovka prehľadu obľúbených senzorov - Favourites. Ak takýto zoznam používateľ vytvorený nemá, bude otvorená obrazovka s prehľadom všetkých senzorov - Dashboard. Obe tieto obrazovky poskytnú používateľovi možnosť zobraziť detailný náhľad ľubovoľného, dostupného senzoru z prehľadu - GraphView. Postupnosť prechodu medzi obrazovkami Dashboard, Favourites a GraphView znázorňuje diagram aktivít na obrázku [[#fig:activity_diagram_after_login|1.3]].

[[File:obrazky/state_diagram_after_login.png|thumb|none|566px|alt=Diagram aktivít - práca aplikácie po úspešnom prihlásení|Diagram aktivít - práca aplikácie po úspešnom prihlásení]]

Súbor:Lifecycle.png

2020-09-03T19:44:23Z

Matus:

Platforma Android

2020-09-03T19:43:21Z

Matus: /* Životný cyklus aktivity */

{{Praca_uvod|2|Návrh a implementácia Android aplikácie pre monitoring priemyselného procesu|Informačný systém Sensorical|Platforma Android|Návrh aplikácie nSoric aAurela|Implementácia aplikácie nSoric aAurela|Testovanie aplikácie nSoric aAurela}}

__TOC__

= =

Platforma Android a životný cyklus aplikácií bežiacich na tejto platforme je výrazne odlišný od životného cyklu aplikácií bežiacich na desktope. Desktopové aplikácie bežia ako relatívne samostatné procesy nezávisle od iných, paralelne bežiacich procesov.

Na rozdiel od desktopových aplikácií, Android aplikácie prechádzajú počas svojho behu (životného cyklu) rôznymi štádiami v závislosti na rôznych systémových udalostiach resp. prerušeniach (viď [[#lifecycle|1.1.1]]). Samotná Android aplikácia môže pozostávať zo štyroch základných súčastí medzi ktoré patria: Activity (aktivita), Content providers (poskytovatelia obsahu), Broadcast recievers (prijímatelia vysielania), Services (služby). Každá aplikácia môže byť tvorená ľubovolnou kombináciou týchto súčastí . V Aplikácii aAurela sa používa len komponenta Activity, ktorá bude ďalej bližšie opísaná.

== Komponenta Activity ==

Komponenta Activity (ďalej len aktivita) tvorí základ používateľského rozhrania a predstavuje obdobu okna desktopovej aplikácie, prostredníctvom ktorého používateľ s aplikáciou interaguje. Jednu aplikáciu môže tvoriť niekoľko aktivít, kde každá má svoj význam a umožňuje používateľovi grafický vstup do rozdielnych častí aplikácie. Pre vývojárov reprezentuje každá aktivita samostatnú triedu.

=== Životný cyklus aktivity ===

Každá aktivita v rámci jednej a tej istej aplikácie má svoj vlastný životný cyklus. Životný cyklus je reprezentovaný rôznymi stavmi, ktorými aktivita počas svojho behu prechádza. Jednotlivé stavy životného cyklu Android aktivity sú nesmierne dôležité pre správne fungovanie aplikácie ako celku. Ich úlohou je zabrániť „pádu“ aplikácie pri práci s viacerými aktivitami, prípadne pri rôznych prerušeniach behu aktivity danej aplikácie.

Zmena stavu životného cyklu Android aktivity nastáva napr. pri zmene orientácie obrazovky zariadenia, minimalizovaní aplikácie stlačením domovského tlačidla, alebo pri prerušení aplikácie prichádzajúcim hovorom. Stavy, v ktorých sa Android aktivita môže nachádzať sú: Resumed, Paused, Stopped, Destroyed.

* '''Resumed''' - stav kedy je aktivita v popredí, v interakcii s používateľom.
* '''Paused''' - stav, v ktorom je aktivita pozastavená, mimo interakcie s používateľom (čiastočne viditeľná) napr. prekrytá dialógovým oknom.
* '''Stoped''' - stav, v ktorom sa aktivita dostala na pozadie, stratila „pozornosť“ (úplne skrytá) napr. iná aktivita sa dostala do popredia.
* '''Destroyed''' - stav, kedy je aktivita úplne ukončená, odstránená zo systémovej pamäte.

Created a Started nepovažujeme za samostatné stavy, označujú sa za stavy prechodné, čo znamená, že aktivita v nich nie je schopná zotrvať po určitý čas a takmer okamžite sa z nich posúva do stavu nasledujúceho.

* '''Created''' - je moment, kedy systém vytvorí danú aktivitu.
* '''Started''' - je moment, kedy sa aktivita stáva viditeľná.

[[File:lifecycle.png|thumb|none|566px|alt=Životný cyklus Android aktivity spolu s metódami spätného volania |Životný cyklus Android aktivity spolu s metódami spätného volania ]]

Metódy spätného volania slúžia na zachytenie zmeny stavu a na vykonanie akcie ešte pred tým, než sa aktivita dostane do stavu iného. Metódy spätného volania je možné implementovať v triede samotnej aktivity. V závislosti na zmene stavu aktivity sú volané metódy: onCreate(), onStart(), onResume(), onPause(), onRestart(), onStop(), onDestroy(). Jediná povinná metóda spätného volania, ktorá musí byť v triede aktivity implementovaná je metóda onCreate(). Metóda onCreate() je volaná vždy pri prvotnom vytvorení aktivity a štandardne sa v nej nastavuje grafické rozhranie aktivity, inicializujú sa potrebné objekty a podobne. V tejto časti bol použitý zdroj .

== Princípy a nástroje využité pri vývoji aplikácie ==

Táto časť pojednáva o základných princípoch systému Android a nástrojoch, ktoré boli pri vývoji aplikácie využité. Nástroje reprezentujú dve dôležité knižnice, na ktorých je postavené jadro aplikácie: - SQLite databáza a - asynchrónna práca s vláknami. Knižnice Room a RxJava sú vzájomne kompatibilné a v spolupráci výrazne uľahčujú vývoj robustnejších aplikácií na platforme Android.

=== SQLite databáza na platforme Android ===

SQLite je lokálna SQL databáza (uložená ako súbor v zariadení), ktorá disponuje všetkými funkciami relačných databáz. Platforma Android umožňuje pre ukladanie väčšieho množstva štruktúrovaných dát implementovať práve databázu typu SQLite.

Pre implementáciu SQLite databázy v aplikácii je využitá knižnica Room. Výhody, pre ktoré bola knižnica Room zvolená sú: výrazné skrátenie a sprehľadnenie kódu, validácia správnosti SQL príkazov už počas kompilácie, priama podpora knižnice RxJava.

=== Knižnica Room ===

Knižnica Room predstavuje abstraktnú vrstvu nad vrstvou SQLite databázy. Slúži pre vytvorenie databázy ako aj pre prístup k jej dátam.

Knižnica Room sprostredkováva mapovanie databázových relácií na objekty v jazyku Java na základe spracovávania anotácií. Anotácie sú špeciálne príkazy, ktoré sú v prípade knižnice Room priradené k definíciám tried, metód a premenných. Pri kompilácii Room na základe použitej anotácie vygeneruje Java kód, na ktorý sa prostredníctvom anotácií odkazuje. Tento spôsob práce je označovaný aj ako ORM (Object-Relational Mapping). V tejto časti je použitý zdroj informácii .

==== Množina tried pre vytvorenie SQLite databázy pomocou knižnice Room ====

Pre vytvorenie a prácu s SQLite databázou pomocou knižnice Room je potrebné implementovať základnú množinu Java tried: Entita, DAO a Databáza. Pri týchto triedach je potrebné použiť anotácie @Entity, @DAO, @Database.

''@Entity'' - anotácia triedy, ktorá reprezentuje entitu databázy. Jednotlivé premenné triedy reprezentujú atribúty danej entity. K atribútom je potrebné umožniť prístup cez metódy get a set .

''@DAO'' - (Data accessing object) anotácia rozhrania, ktoré obsahuje metódy pre prístup do databázy. Jednotlivé metódy majú priradené anotácie na základe SQL operácie, ktorú vykonávajú:

''@Insert'' - vkladanie záznamov do databázy,

''@Update'' - aktualizovanie existujúcich záznamov,

''@Delete'' - mazanie záznamov,

''@Query'' - alternatívna možnosť definovania vlastných SQL príkazov.

Parameterom týchto anotácií je textový reťazec reprezentujúci SQL príkaz, ktorý daná metóda vykonáva. Návratový typ metód DAO musí korešpondovať s výstupom SQL príkazu, ktorý daná metóda vykonáva .

''@Database'' - anotácia triedy, z ktorej Room vytvorí databázu. Parameter anotácie musí obsahovať zoznam všetkých entít, resp. Java tried s anotáciou @Entity, ktoré majú byť transformované na entity databázy. Pri triede databázy je dôležité uplatnenie Singleton návrhového vzoru, ktorý zabezpečí vytvorenie a prístupnosť jedinej inštancie triedy databázy po celý čas behu aplikácie .

==== Ďalšie anotácie knižnice Room ====

Použitie nasledujúcich anotácií je nepovinné, avšak pri samotnej implementácii značne uľahčuje prácu s databázou. Tieto anotácie sa používajú ako anotácie premenných tried jednotlivých entít .

''@PrimaryKey'' - anotácia premennej triedy entity, ktorá v databáze reprezentuje primárny kľúč. Voliteľný parameter tejto anotácie umožňuje explicitne zadeklarovať automatické generovanie primárneho kľúča (autoincrement).

''@ForeignKey'' - umožňuje vytvorenie relácie medzi jednotlivými entitami pomocou cudzích kľúčov.

''@ColumnInfo'' - ako parameter tejto anotácie je použitý textový reťazec, ktorý definuje názov atribútu, pod ktorým bude premenná triedy entity vložená do databázy.

''@Ignore'' - anotácia, ktorú je možné použiť v prípade, ak má Room ignorovať danú premennú triedy, napr. nepoužiť premennú ako atribút entity v databáze.

Použitie knižnice Room demonštrujú ukážky priamo z jej implementácie v aplikácii v časti [[#implementacia_sql|[implementacia_sql]]].

=== Práca s vláknami v systéme Android ===

Pri spustení Android aplikácie (nebežiacej na pozadí), vytvorí systém pre túto aplikáciu nový Linux proces, ktorý má pre svoj beh vyhradené jednovláknové operácie. Systémové nastavenie všetkých komponentov jednej aplikácie je také, že všetky bežia na jednom procesorovom vlákne nazývanom hlavné vlákno (main thread).

Úlohou hlavného vlákna je zabezpečiť responzívnosť a správne fungovanie používateľského rozhrania. Hlavné vlákno zodpovedá za delegovanie udalostí na jednotlivé View komponenty (tlačidlá, textové polia…). Všetky tieto komponenty bežiace na hlavnom vlákne musia byť neustále dostupné pre interakciu s používateľom aplikácie. To znamená, ak používateľ klikne na tlačidlo, musí mať hlavné vlákno dostatok pamäťových prostriedkov na spracovanie obsluhy tejto udalosti.

V prípade vykonávania iného, časovo náročnejšieho (blokujúceho) procesu na hlavnom vlákne, je hlavné vlákno zablokované, prestáva odpovedať a systém celý proces aplikácie ukončí. Z tohto dôvodu je potrebné časovo náročnejšie operácie vykonávať v inom, paralelnom tzv. pracovnom vlákne (worker thread) . Pre potrebu obsluhy časovo náročných operácií v paralelných vláknach je v aplikácii použitá knižnica RxJava.

=== Knižnica RxJava ===

RxJava je knižnica, ktorá umožňuje reaktívne resp. udalosťami riadené programovanie. Základný návrhový vzor využívaný touto knižnicou je Observer. Tento návrhový vzor funguje na princípe akcie a reakcie. Observer predstavuje objekt, ktorý sleduje stav iného objektu a v prípade zmeny stavu sledovaného objektu je Observer automaticky notifikovaný. Tento návrhový vzor je v knižnici RxJava využitý pri sledovaní priebehu asynchrónne vykonávanej práce na pracovných vláknach.

Práve možnosť asynchrónneho vykonávania operácií predstavuje jednu z najväčších predností knižnice RxJava. V nasledujúcej časti je použitý zdroj , pričom je zachovaná terminológia oficiálnej dokumentácie knižnice RxJava.

==== Spolupráca knižníc RxJava a Room ====

implicitne zakazuje prácu s SQLite databázou na hlavnom aplikačnom vlákne, pretože práca s databázou predstavuje časovo náročnejšie operácie. Z tohto dôvodu je nutné operácie spojené s SQLite databázou vykonávať asynchrónne.

* '''Observable''' reprezentuje ľubovoľný objekt, ktorý môže získavať dáta z dátového zdroja (generuje hodnoty - metódy DAO) a ktorého stav môže byť sledovaný ďalšími objektmi (observers).
* '''Observer''' predstavuje ľubovoľný objekt, ktorý sleduje stav Observable a má byť v prípade zmeny jeho stavu notifikovaný (prijíma hodnoty).

Vďaka vzájomnej kompatibilite knižníc RxJava a Room je možné použiť niektorú z tried knižnice RxJava ako wrapper (obal) návratového typu metódy DAO. Použitím niektorej observable triedy knižnice RxJava ako wrapper návratového typu metódy DAO, môže byť následne celá práca tejto metódy presmerovaná na pracovné vlákno aplikovaním RxJava operátorov pre asynchrónnu prácu.

==== Základné observable triedy knižnice RxJava ====

* trieda '''Single''' - Observable, ktorá vracia buď jeden objekt alebo chybu.
* trieda '''Completable''' - Observable, vracajúca len výsledok operácie vo forme informácie, či bola úloha dokončená, alebo prišlo k chybe, samotné dáta nevracia.
* trieda '''Maybe''' - Observable, ktorá podobne ako Single vracia jeden objekt, ale nemusí žiaden. Na rozdiel od Single nevyhlási chybu a vráti prázdnu hodnotu.

Príklad použitia observable triedy Maybe demonštruje [[#listing:dao|[listing:dao]]], z jej implementácie priamo v aplikácii.

==== Operátory knižnice RxJava pre asynchrónne vykonávanie operácií ====

Operátory knižnice RxJava slúžia nielen na zadefinovanie pracovného vlákna, na ktorom sa bude asynchrónna práca (metóda) vykonávať, ale aj na špecifikáciu vlákna, ktoré má prijímať výsledky generované týmto pracovným vláknom. Medzi tieto operátory patria: subscribeOn(), observeOn(), subscribe().

==== Operátor subsribeOn() ====

Tento operátor slúži na definovanie vlákna, v ktorom sa má práca metódy, na ktorú je operátor subscribeOn() volaný vykonať. Ako parameter operátora subscribeOn() môžeme použiť triedu Schedulers, ktorá disponuje metódami io(), computation(), single() a iné. Každá z týchto metód slúži pre definovanie špecifického vlákna, na ktorom bude práca metódy, na ktorú je operátor subscribeOn() aplikovaný vykonávaná . Každé z týchto vlákien má svoj špecifický účel :

* computation() - sprístupňuje vlákno určené pre komplikovanejšiu, časovo náročnejšiu výpočtovú prácu. Maximálny počet spustených vlákien metódou computation() je limitovaný počtom procesorov.
* io() - sprístupňuje vlákno určené pre I/O prácu, tzn. vlákno pre asynchrónne vykonávanie inak blokujúcej I/O práce. Umožňuje vytvoriť ľubovoľný počet potrebných vlákien.
* single() - sprístupňuje jediné zdielané vlákno. Toto vlákno je určené pre operácie, ktoré majú byť vykonávané výhradne sekvenčne na jednom a tom istom zdielanom vlákne na pozadí.

==== Operátor subsribe() ====

Operátor, ktorý spája observera spolu s Observable tak, že sprostredkováva observerovi výsledky generované Observable objetkom. Aby observer mohol vidieť jednotlivé objekty generované Observable, alebo dostať informáciu o tom, či operácia skončila úspešne alebo chybou, musí byť najskôr na Observable pripojený práve použitím metódy subscribe(). Operátor subscribe() prijíma ako parameter objekt (nazývaný Observer alebo Subscriber), ktorý implementuje rozhranie obsahujúce niektorú z týchto metód :

* onNext() - Observable volá túto metódu vždy, ak publikuje nový objekt. Parameter metódy je práve publikovaný objekt.
* onError() - Observable zavolá túto metódu, ak dôjde k chybe pri generovaní objektov očakávaných metódou onNext(). Pri zavolaní metódy onError(), je Observable zastavený a nepríde k ďalším volaniam metód onNext() a onComplete().
* onCompleted() - Observable zavolá túto metódu, ak je metóda onNext() zavolaná poslednýkrát a nenastala žiadna chyba.

==== Operátor observeOn() ====

Ak použijeme operátor subsribeOn(), práca Observable je presmerovaná na v ňom definované pracovné vlákno. Použitím operátora observeOn() špecifikujeme iné vlákno, v ktorom má byť po dokončení práce notifikovaný observer.

Operátor observeOn() určuje vlákno, na ktoré má Observable prostredníctvom operátora subscribe() publikovať výsledky. Zabezpečuje presmerovanie výsledku prúdu z pracovného vlákna definovaného v operátore subscribeOn() na vlákno definované v operátore observeOn(). Ako parameter observeOn() operátora môžeme špecifikovať napríklad hlavné vlákno použitím triedy AndroidSchedulers a jej metódy mainThread() . Príklad použitia operátorov RxJava priamo v aplikácii demonštruje [[#listing:rx_operators|[listing:rx_operators]]].

Platforma Android

2020-09-03T19:39:30Z

Matus:

{{Praca_uvod|2|Návrh a implementácia Android aplikácie pre monitoring priemyselného procesu|Informačný systém Sensorical|Platforma Android|Návrh aplikácie nSoric aAurela|Implementácia aplikácie nSoric aAurela|Testovanie aplikácie nSoric aAurela}}

__TOC__
Platforma Android a životný cyklus aplikácií bežiacich na tejto platforme je výrazne odlišný od životného cyklu aplikácií bežiacich na desktope. Desktopové aplikácie bežia ako relatívne samostatné procesy nezávisle od iných, paralelne bežiacich procesov.

Na rozdiel od desktopových aplikácií, Android aplikácie prechádzajú počas svojho behu (životného cyklu) rôznymi štádiami v závislosti na rôznych systémových udalostiach resp. prerušeniach (viď [[#lifecycle|1.1.1]]). Samotná Android aplikácia môže pozostávať zo štyroch základných súčastí medzi ktoré patria: Activity (aktivita), Content providers (poskytovatelia obsahu), Broadcast recievers (prijímatelia vysielania), Services (služby). Každá aplikácia môže byť tvorená ľubovolnou kombináciou týchto súčastí . V Aplikácii aAurela sa používa len komponenta Activity, ktorá bude ďalej bližšie opísaná.

== Komponenta Activity ==

Komponenta Activity (ďalej len aktivita) tvorí základ používateľského rozhrania a predstavuje obdobu okna desktopovej aplikácie, prostredníctvom ktorého používateľ s aplikáciou interaguje. Jednu aplikáciu môže tvoriť niekoľko aktivít, kde každá má svoj význam a umožňuje používateľovi grafický vstup do rozdielnych častí aplikácie. Pre vývojárov reprezentuje každá aktivita samostatnú triedu.

=== Životný cyklus aktivity ===

Každá aktivita v rámci jednej a tej istej aplikácie má svoj vlastný životný cyklus. Životný cyklus je reprezentovaný rôznymi stavmi, ktorými aktivita počas svojho behu prechádza. Jednotlivé stavy životného cyklu Android aktivity sú nesmierne dôležité pre správne fungovanie aplikácie ako celku. Ich úlohou je zabrániť „pádu“ aplikácie pri práci s viacerými aktivitami, prípadne pri rôznych prerušeniach behu aktivity danej aplikácie.

Zmena stavu životného cyklu Android aktivity nastáva napr. pri zmene orientácie obrazovky zariadenia, minimalizovaní aplikácie stlačením domovského tlačidla, alebo pri prerušení aplikácie prichádzajúcim hovorom. Stavy, v ktorých sa Android aktivita môže nachádzať sú: Resumed, Paused, Stopped, Destroyed.

* '''Resumed''' - stav kedy je aktivita v popredí, v interakcii s používateľom.
* '''Paused''' - stav, v ktorom je aktivita pozastavená, mimo interakcie s používateľom (čiastočne viditeľná) napr. prekrytá dialógovým oknom.
* '''Stoped''' - stav, v ktorom sa aktivita dostala na pozadie, stratila „pozornosť“ (úplne skrytá) napr. iná aktivita sa dostala do popredia.
* '''Destroyed''' - stav, kedy je aktivita úplne ukončená, odstránená zo systémovej pamäte.

Created a Started nepovažujeme za samostatné stavy, označujú sa za stavy prechodné, čo znamená, že aktivita v nich nie je schopná zotrvať po určitý čas a takmer okamžite sa z nich posúva do stavu nasledujúceho.

* '''Created''' - je moment, kedy systém vytvorí danú aktivitu.
* '''Started''' - je moment, kedy sa aktivita stáva viditeľná.

[[File:obrazky/lifecycle.png|thumb|none|566px|alt=Životný cyklus Android aktivity spolu s metódami spätného volania |Životný cyklus Android aktivity spolu s metódami spätného volania ]]

Metódy spätného volania slúžia na zachytenie zmeny stavu a na vykonanie akcie ešte pred tým, než sa aktivita dostane do stavu iného. Metódy spätného volania je možné implementovať v triede samotnej aktivity. V závislosti na zmene stavu aktivity sú volané metódy: onCreate(), onStart(), onResume(), onPause(), onRestart(), onStop(), onDestroy(). Jediná povinná metóda spätného volania, ktorá musí byť v triede aktivity implementovaná je metóda onCreate(). Metóda onCreate() je volaná vždy pri prvotnom vytvorení aktivity a štandardne sa v nej nastavuje grafické rozhranie aktivity, inicializujú sa potrebné objekty a podobne. V tejto časti bol použitý zdroj .

== Princípy a nástroje využité pri vývoji aplikácie ==

Táto časť pojednáva o základných princípoch systému Android a nástrojoch, ktoré boli pri vývoji aplikácie využité. Nástroje reprezentujú dve dôležité knižnice, na ktorých je postavené jadro aplikácie: - SQLite databáza a - asynchrónna práca s vláknami. Knižnice Room a RxJava sú vzájomne kompatibilné a v spolupráci výrazne uľahčujú vývoj robustnejších aplikácií na platforme Android.

=== SQLite databáza na platforme Android ===

SQLite je lokálna SQL databáza (uložená ako súbor v zariadení), ktorá disponuje všetkými funkciami relačných databáz. Platforma Android umožňuje pre ukladanie väčšieho množstva štruktúrovaných dát implementovať práve databázu typu SQLite.

Pre implementáciu SQLite databázy v aplikácii je využitá knižnica Room. Výhody, pre ktoré bola knižnica Room zvolená sú: výrazné skrátenie a sprehľadnenie kódu, validácia správnosti SQL príkazov už počas kompilácie, priama podpora knižnice RxJava.

=== Knižnica Room ===

Knižnica Room predstavuje abstraktnú vrstvu nad vrstvou SQLite databázy. Slúži pre vytvorenie databázy ako aj pre prístup k jej dátam.

Knižnica Room sprostredkováva mapovanie databázových relácií na objekty v jazyku Java na základe spracovávania anotácií. Anotácie sú špeciálne príkazy, ktoré sú v prípade knižnice Room priradené k definíciám tried, metód a premenných. Pri kompilácii Room na základe použitej anotácie vygeneruje Java kód, na ktorý sa prostredníctvom anotácií odkazuje. Tento spôsob práce je označovaný aj ako ORM (Object-Relational Mapping). V tejto časti je použitý zdroj informácii .

==== Množina tried pre vytvorenie SQLite databázy pomocou knižnice Room ====

Pre vytvorenie a prácu s SQLite databázou pomocou knižnice Room je potrebné implementovať základnú množinu Java tried: Entita, DAO a Databáza. Pri týchto triedach je potrebné použiť anotácie @Entity, @DAO, @Database.

''@Entity'' - anotácia triedy, ktorá reprezentuje entitu databázy. Jednotlivé premenné triedy reprezentujú atribúty danej entity. K atribútom je potrebné umožniť prístup cez metódy get a set .

''@DAO'' - (Data accessing object) anotácia rozhrania, ktoré obsahuje metódy pre prístup do databázy. Jednotlivé metódy majú priradené anotácie na základe SQL operácie, ktorú vykonávajú:

''@Insert'' - vkladanie záznamov do databázy,

''@Update'' - aktualizovanie existujúcich záznamov,

''@Delete'' - mazanie záznamov,

''@Query'' - alternatívna možnosť definovania vlastných SQL príkazov.

Parameterom týchto anotácií je textový reťazec reprezentujúci SQL príkaz, ktorý daná metóda vykonáva. Návratový typ metód DAO musí korešpondovať s výstupom SQL príkazu, ktorý daná metóda vykonáva .

''@Database'' - anotácia triedy, z ktorej Room vytvorí databázu. Parameter anotácie musí obsahovať zoznam všetkých entít, resp. Java tried s anotáciou @Entity, ktoré majú byť transformované na entity databázy. Pri triede databázy je dôležité uplatnenie Singleton návrhového vzoru, ktorý zabezpečí vytvorenie a prístupnosť jedinej inštancie triedy databázy po celý čas behu aplikácie .

==== Ďalšie anotácie knižnice Room ====

Použitie nasledujúcich anotácií je nepovinné, avšak pri samotnej implementácii značne uľahčuje prácu s databázou. Tieto anotácie sa používajú ako anotácie premenných tried jednotlivých entít .

''@PrimaryKey'' - anotácia premennej triedy entity, ktorá v databáze reprezentuje primárny kľúč. Voliteľný parameter tejto anotácie umožňuje explicitne zadeklarovať automatické generovanie primárneho kľúča (autoincrement).

''@ForeignKey'' - umožňuje vytvorenie relácie medzi jednotlivými entitami pomocou cudzích kľúčov.

''@ColumnInfo'' - ako parameter tejto anotácie je použitý textový reťazec, ktorý definuje názov atribútu, pod ktorým bude premenná triedy entity vložená do databázy.

''@Ignore'' - anotácia, ktorú je možné použiť v prípade, ak má Room ignorovať danú premennú triedy, napr. nepoužiť premennú ako atribút entity v databáze.

Použitie knižnice Room demonštrujú ukážky priamo z jej implementácie v aplikácii v časti [[#implementacia_sql|[implementacia_sql]]].

=== Práca s vláknami v systéme Android ===

Pri spustení Android aplikácie (nebežiacej na pozadí), vytvorí systém pre túto aplikáciu nový Linux proces, ktorý má pre svoj beh vyhradené jednovláknové operácie. Systémové nastavenie všetkých komponentov jednej aplikácie je také, že všetky bežia na jednom procesorovom vlákne nazývanom hlavné vlákno (main thread).

Úlohou hlavného vlákna je zabezpečiť responzívnosť a správne fungovanie používateľského rozhrania. Hlavné vlákno zodpovedá za delegovanie udalostí na jednotlivé View komponenty (tlačidlá, textové polia…). Všetky tieto komponenty bežiace na hlavnom vlákne musia byť neustále dostupné pre interakciu s používateľom aplikácie. To znamená, ak používateľ klikne na tlačidlo, musí mať hlavné vlákno dostatok pamäťových prostriedkov na spracovanie obsluhy tejto udalosti.

V prípade vykonávania iného, časovo náročnejšieho (blokujúceho) procesu na hlavnom vlákne, je hlavné vlákno zablokované, prestáva odpovedať a systém celý proces aplikácie ukončí. Z tohto dôvodu je potrebné časovo náročnejšie operácie vykonávať v inom, paralelnom tzv. pracovnom vlákne (worker thread) . Pre potrebu obsluhy časovo náročných operácií v paralelných vláknach je v aplikácii použitá knižnica RxJava.

=== Knižnica RxJava ===

RxJava je knižnica, ktorá umožňuje reaktívne resp. udalosťami riadené programovanie. Základný návrhový vzor využívaný touto knižnicou je Observer. Tento návrhový vzor funguje na princípe akcie a reakcie. Observer predstavuje objekt, ktorý sleduje stav iného objektu a v prípade zmeny stavu sledovaného objektu je Observer automaticky notifikovaný. Tento návrhový vzor je v knižnici RxJava využitý pri sledovaní priebehu asynchrónne vykonávanej práce na pracovných vláknach.

Práve možnosť asynchrónneho vykonávania operácií predstavuje jednu z najväčších predností knižnice RxJava. V nasledujúcej časti je použitý zdroj , pričom je zachovaná terminológia oficiálnej dokumentácie knižnice RxJava.

==== Spolupráca knižníc RxJava a Room ====

implicitne zakazuje prácu s SQLite databázou na hlavnom aplikačnom vlákne, pretože práca s databázou predstavuje časovo náročnejšie operácie. Z tohto dôvodu je nutné operácie spojené s SQLite databázou vykonávať asynchrónne.

* '''Observable''' reprezentuje ľubovoľný objekt, ktorý môže získavať dáta z dátového zdroja (generuje hodnoty - metódy DAO) a ktorého stav môže byť sledovaný ďalšími objektmi (observers).
* '''Observer''' predstavuje ľubovoľný objekt, ktorý sleduje stav Observable a má byť v prípade zmeny jeho stavu notifikovaný (prijíma hodnoty).

Vďaka vzájomnej kompatibilite knižníc RxJava a Room je možné použiť niektorú z tried knižnice RxJava ako wrapper (obal) návratového typu metódy DAO. Použitím niektorej observable triedy knižnice RxJava ako wrapper návratového typu metódy DAO, môže byť následne celá práca tejto metódy presmerovaná na pracovné vlákno aplikovaním RxJava operátorov pre asynchrónnu prácu.

==== Základné observable triedy knižnice RxJava ====

* trieda '''Single''' - Observable, ktorá vracia buď jeden objekt alebo chybu.
* trieda '''Completable''' - Observable, vracajúca len výsledok operácie vo forme informácie, či bola úloha dokončená, alebo prišlo k chybe, samotné dáta nevracia.
* trieda '''Maybe''' - Observable, ktorá podobne ako Single vracia jeden objekt, ale nemusí žiaden. Na rozdiel od Single nevyhlási chybu a vráti prázdnu hodnotu.

Príklad použitia observable triedy Maybe demonštruje [[#listing:dao|[listing:dao]]], z jej implementácie priamo v aplikácii.

==== Operátory knižnice RxJava pre asynchrónne vykonávanie operácií ====

Operátory knižnice RxJava slúžia nielen na zadefinovanie pracovného vlákna, na ktorom sa bude asynchrónna práca (metóda) vykonávať, ale aj na špecifikáciu vlákna, ktoré má prijímať výsledky generované týmto pracovným vláknom. Medzi tieto operátory patria: subscribeOn(), observeOn(), subscribe().

==== Operátor subsribeOn() ====

Tento operátor slúži na definovanie vlákna, v ktorom sa má práca metódy, na ktorú je operátor subscribeOn() volaný vykonať. Ako parameter operátora subscribeOn() môžeme použiť triedu Schedulers, ktorá disponuje metódami io(), computation(), single() a iné. Každá z týchto metód slúži pre definovanie špecifického vlákna, na ktorom bude práca metódy, na ktorú je operátor subscribeOn() aplikovaný vykonávaná . Každé z týchto vlákien má svoj špecifický účel :

* computation() - sprístupňuje vlákno určené pre komplikovanejšiu, časovo náročnejšiu výpočtovú prácu. Maximálny počet spustených vlákien metódou computation() je limitovaný počtom procesorov.
* io() - sprístupňuje vlákno určené pre I/O prácu, tzn. vlákno pre asynchrónne vykonávanie inak blokujúcej I/O práce. Umožňuje vytvoriť ľubovoľný počet potrebných vlákien.
* single() - sprístupňuje jediné zdielané vlákno. Toto vlákno je určené pre operácie, ktoré majú byť vykonávané výhradne sekvenčne na jednom a tom istom zdielanom vlákne na pozadí.

==== Operátor subsribe() ====

Operátor, ktorý spája observera spolu s Observable tak, že sprostredkováva observerovi výsledky generované Observable objetkom. Aby observer mohol vidieť jednotlivé objekty generované Observable, alebo dostať informáciu o tom, či operácia skončila úspešne alebo chybou, musí byť najskôr na Observable pripojený práve použitím metódy subscribe(). Operátor subscribe() prijíma ako parameter objekt (nazývaný Observer alebo Subscriber), ktorý implementuje rozhranie obsahujúce niektorú z týchto metód :

* onNext() - Observable volá túto metódu vždy, ak publikuje nový objekt. Parameter metódy je práve publikovaný objekt.
* onError() - Observable zavolá túto metódu, ak dôjde k chybe pri generovaní objektov očakávaných metódou onNext(). Pri zavolaní metódy onError(), je Observable zastavený a nepríde k ďalším volaniam metód onNext() a onComplete().
* onCompleted() - Observable zavolá túto metódu, ak je metóda onNext() zavolaná poslednýkrát a nenastala žiadna chyba.

==== Operátor observeOn() ====

Ak použijeme operátor subsribeOn(), práca Observable je presmerovaná na v ňom definované pracovné vlákno. Použitím operátora observeOn() špecifikujeme iné vlákno, v ktorom má byť po dokončení práce notifikovaný observer.

Operátor observeOn() určuje vlákno, na ktoré má Observable prostredníctvom operátora subscribe() publikovať výsledky. Zabezpečuje presmerovanie výsledku prúdu z pracovného vlákna definovaného v operátore subscribeOn() na vlákno definované v operátore observeOn(). Ako parameter observeOn() operátora môžeme špecifikovať napríklad hlavné vlákno použitím triedy AndroidSchedulers a jej metódy mainThread() . Príklad použitia operátorov RxJava priamo v aplikácii demonštruje [[#listing:rx_operators|[listing:rx_operators]]].