Ing. Michal Valenta, Ph.D.
vedoucí katedry doc. RNDr. Ing. Marcel Jiřina, Ph.D.
děkan
ZADÁNÍ BAKALÁŘSKÉ PRÁCE
Název: Android aplikace DayWork.cz: základní modul
Student: Michal Mroček
Vedoucí: Ing. Robert Pergl, Ph.D.
Studijní program: Informatika
Studijní obor: Webové a softwarové inženýrství Katedra: Katedra softwarového inženýrství Platnost zadání: Do konce letního semestru 2018/19
Pokyny pro vypracování
Portál DayWork.cz slouží pro párování nabídek a poptávek brigád. Práce je součástí projektu vytvoření Android (AN) aplikace pro pracovníky a Android aplikace pro firmy. Cílem této práce je převevším analýza, návrh architektury a vývoj základního modulu obou aplikací.
1) Proveďte analýzu funkčních a nefunkčních požadavků pro obě aplikace, zejména:
- analýzu technologií a vhodných knihoven pro vývoj, - bezpečnost při přihlašování.
2) Dále proveďte návrh:
- základní architektury a rozdělení zodpovědnosti v rámci tříd (jmenná konvence),
- základních stavebních kamenů perzistenční vrstvy aplikace (ukládání dat z API pro offline režim), - základních stavebních kamenů komunikace s API (definice interface),
- cloud messaging - řešení příchozí push zprávy a rozeslání do aplikace.
3) Proveďte implementaci a otestování základního modulu, který bude dále sloužit pro vývoj aplikace pro pracovníky a aplikace pro firmy řešené v paraleleně běžících bakalářských pracích.
Seznam odborné literatury
Dodá vedoucí práce.
Bakalářská práce
Android aplikace DayWork.cz: základní modul
Michal Mroček
Katedra softwarového inženýrství Vedoucí práce: Ing. Robert Pergl, Ph.D.
Poděkování
Děkuji Ing. Robertu Perglovi, Ph.D. za cenné rady a pomoc při vytváření této
Prohlášení
Prohlašuji, že jsem předloženou práci vypracoval(a) samostatně a že jsem uvedl(a) veškeré použité informační zdroje v souladu s Metodickým pokynem o etické přípravě vysokoškolských závěrečných prací.
Beru na vědomí, že se na moji práci vztahují práva a povinnosti vyplývající ze zákona č. 121/2000 Sb., autorského zákona, ve znění pozdějších předpisů.
V souladu s ust. § 46 odst. 6 tohoto zákona tímto uděluji nevýhradní oprávnění (licenci) k užití této mojí práce, a to včetně všech počítačových programů, jež jsou její součástí či přílohou, a veškeré jejich dokumentace (dále souhrnně jen
„Dílo“), a to všem osobám, které si přejí Dílo užít. Tyto osoby jsou oprávněny Dílo užít jakýmkoli způsobem, který nesnižuje hodnotu Díla, a za jakýmkoli účelem (včetně užití k výdělečným účelům). Toto oprávnění je časově, teri- toriálně i množstevně neomezené. Každá osoba, která využije výše uvedenou licenci, se však zavazuje udělit ke každému dílu, které vznikne (byť jen zčásti) na základě Díla, úpravou Díla, spojením Díla s jiným dílem, zařazením Díla do díla souborného či zpracováním Díla (včetně překladu), licenci alespoň ve výše uvedeném rozsahu a zároveň zpřístupnit zdrojový kód takového díla ale- spoň srovnatelným způsobem a ve srovnatelném rozsahu, jako je zpřístupněn zdrojový kód Díla.
České vysoké učení technické v Praze Fakulta informačních technologií
© 2018 Michal Mroček. Všechna práva vyhrazena.
Tato práce vznikla jako školní dílo na Českém vysokém učení technickém v Praze, Fakultě informačních technologií. Práce je chráněna právními před- pisy a mezinárodními úmluvami o právu autorském a právech souvisejících s právem autorským. K jejímu užití, s výjimkou bezúplatných zákonných li- cencí a nad rámec oprávnění uvedených v Prohlášení na předchozí straně, je nezbytný souhlas autora.
Odkaz na tuto práci
Mroček, Michal. Android aplikace DayWork.cz: základní modul. Bakalářská práce. Praha: České vysoké učení technické v Praze, Fakulta informačních technologií, 2018.
Abstrakt
Bakalářská práce se zabývá analýzou dostupných technologií a architektonic- kých stylů, které lze využít při vývoji aplikace pro operační systém Android.
Součástí je i analýza požadavků a návrh jádra mobilní aplikace pro portál Daywork.cz. Práce dále obsahuje definici nutných bezpečnostních standardů pro zajištění bezpečné komunikace mezi aplikací a serverem. V implementační části je poté kladen důraz na realizaci komponent stanovené architektury, pří- jem push zpráv a otestování.
Klíčová slova architektonický styl, MVVM, push notifikace, bezpečnost aplikace, Android Architecture Components
Abstract
Thesis analyses available technologies and architectonic styles which can be used whilst developing mobile application for operating system Android. Ana- lysis of functional and non-functional requirements and mobile application’s design of core for portal Daywork.cz is also included. Thesis also contains de- finition of required security standards which must be taken into account to ensure secure connection between application and server. In the implemen- tation part an emphasis is placed on architecture components, push messages and testability.
Keywords architecture, MVVM, push notifications, security of an appli- cation, Android Architecture Components
viii
Obsah
Úvod 1
1 Cíl práce a metodika 3
1.1 Metodika . . . 3
2 Rešerše 5 2.1 Technologie pro vývoj . . . 5
2.2 Architektonický styl . . . 7
2.3 Minimální verze systému . . . 12
3 Analýza 15 3.1 Funkční požadavky . . . 15
3.2 Nefunkční požadavky . . . 17
3.3 Případy užití . . . 18
3.4 Technologie pro vývoj . . . 21
3.5 Minimální verze systému . . . 21
3.6 Architektonický styl . . . 21
4 Návrh 23 4.1 Jmenná konvence a anotace . . . 23
4.2 Spolupráce v týmu . . . 26
4.3 Android Architecture Components . . . 28
4.4 Perzistenční vrstva . . . 30
4.5 Push zprávy . . . 33
4.6 Zabezpečení . . . 33
4.7 Komunikace se serverem . . . 35
4.8 Architektura . . . 37
5 Realizace 41 5.1 Oprávnění . . . 41
5.2 Knihovny a frameworky . . . 41
5.3 Asynchronní operace . . . 44
5.4 Nasazení . . . 45
5.5 Výsledná aplikace . . . 46
6 Testování 49
Závěr 53
Literatura 55
A Seznam použitých zkratek 59
B Obsah přiloženého CD 61
x
Seznam obrázků
2.1 Plán uvolňování beta verzí OS Android 8.0 . . . 5
2.2 Diagram tříd – MVC architektura . . . 9
2.3 Diagram tříd – MVP architektura . . . 10
2.4 Diagram tříd – MVVM architektura . . . 11
2.5 Status bar . . . 13
2.6 Navigation bar . . . 13
3.1 Přehled případů užití . . . 20
4.1 Relační schéma databáze jádra . . . 31
4.2 Diagram tříd databáze . . . 32
4.3 Stavový diagram aplikace . . . 36
4.4 Inicializace a aktualizace modelu . . . 39
5.1 Diagram nasazení . . . 45
5.2 Obrazovka přihlášení . . . 46
5.3 Obrazovky registrace . . . 47
Seznam ukázek kódu
4.1 Aplikace jmenné konvence . . . 25
4.2 Využití anotací . . . 26
4.3 Propojení view s viewmodelem . . . 29
4.4 Přístup do databáze přes DAO . . . 30
5.1 Využití knihovny dagger při inicializaci tříd . . . 42
5.2 Návrhový vzor „interceptor“ v OkHttp3 . . . 43
6.1 Test deserializace dat z JSON formátu . . . 50
6.2 Test propisování chyb do UI . . . 51
Seznam tabulek
2.1 Verze jazyka Java a návaznost na Android . . . 6
2.2 Verze OS Android a jejich rozšířenost . . . 12
3.1 Výsledek analýzy architektur . . . 21
4.1 Správná a nesprávná transformace akronymů . . . 24
4.2 Požadavky na přítomnost hlaviček dle rozhraní . . . 36
Úvod
Portál Daywork.cz byl spuštěn v roce 2017 s cílem zjednodušit hledání brigád v Praze a jejím blízkém okolí. Potencionální brigádníci po registraci a vyplnění profilu jsou vyzvání k nastavení filtru, kde si mohou zvolit preferovanou lokaci nebo pracovní pozici. Portál jim poté nabídne relevantní výsledky a uživatelé mohou projevit zájem o brigádu. Samotná účast musí být schválena firemním administrátorem, který zároveň nabídky do systému vkládá. Obě strany si mohou mezi sebou vyměňovat zprávy. Tato funkcionalita je dostupná neustále, primárně ale určena pro snadnější dohodu mezi oběma stranami. Po dokončení schvalovacího procesu práce portálu končí – pouze je potřeba, aby se brigádník dostavil do práce.
Po úspěšném nasazení webového portálu přichází na řadu mobilní aplikace pro operační systém Android. Tato bakalářská práce je jednou ze tří, které se zabývají kompletním procesem vývoje aplikace. Členové vývojářského týmu (seřazeni dle příjmení) a jejich primární úkoly jsou:
• Mroček, Michal – analýza požadavků, návrh architektury, vývoj a otes- tování jádra;
• Novotný, Kryštof – návrh uživatelského rozhraní, vývoj a otestování části pro firmy;
• Sousedík, Michal – návrh push zpráv, vývoj a otestování části pro bri- gádníky.
Kapitola 1
Cíl práce a metodika
Primárním cílem této práce je vytvořit robustní jádro aplikace, které bude sloužit ostatním kolegům při vývoji mobilní aplikace Daywork. Jádro by mělo řešit přihlášení do aplikace, stažení nejnutnějších dat pro běh aplikace a po- skytovat třídy, které urychlí vývoj dalších funkcionalit.
1.1 Metodika
Tato kapitola obsahuje stručný rozbor zadání bakalářské práce včetně krát- kého popisu jednotlivých požadavků. Pro modelování jednotlivých komponent a interakce mezi nimi využiji standard UML verze 2.5.1.
Budu-li v textu odkazovat na zdrojový kód, pak vždy ve formátu, který se používá v JavaDoc komentářích. Ukázky kódu z kapitol 5 a 6 jsou vyňaty ze zdrojových souborů aplikace. Jsou taktéž mírně upraveny – zejména zkráceny pro zachování přehlednosti.
1.1.1 Analýza
Funkční a nefunkční požadavky Prozkoumám aktuální webový portál a identifikuji jednotlivé uživatelské role v rámci systému. Na jejich základě vymezím požadavky pro každou skupinu uživatelů. Dále vydefinuji nutné ne- funkční požadavky na aplikaci.
Technologie Provedu analýzu dostupných technologií, které lze využít pro vyvinutí mobilní aplikace pro operační systém Android. Porovnám jejich klady a zápory, nakonec určím finální technologii, jež bude použita pro vývoj s ohle- dem na náš tým.
1. Cíl práce a metodika
Architektura Identifikuji různá architektonická paradigmata, která jsou využívána ve spojitosti s vybranou technologií. Stanovím kritéria jejich hodno- cení s ohledem na testovatelnost a rozšiřitelnost kódu, následně vyberu jeden styl.
Podpora systému Analyzuji jednotlivé verze systému Android a zmíním nejdůležitější změny, které přišly s některými verzemi. Na základě aktuálního podílu jednotlivých verzí na trhu určím minimální verzi systému, která bude aplikací podporována. Poté vyberu sadu stěžejních knihoven, které budou po- užity při implementaci a zohledněny v návrhové části.
1.1.2 Návrh
Jmenná konvence Určím jmennou konvenci. Tu budou muset ostatní spo- lupracovníci dodržovat při implementaci funkcionalit a popíši sadu doporu- čení, která je vhodné dodržovat při rozšiřování aplikace.
Persistence Navrhnu strukturu databáze pro jádro a určím pravidla pro přidávání nových entit do relační databáze.
Push zprávy Popíši princip vytváření zpráv na severu a jejich přijímání v cílovém zařízení. Vyspecifikuji chování aplikace při příjmu různých typů zpráv.
Komunikace s API Vymezím pravidla pro komunikaci se serverem s ohle- dem na bezpečnost a v návaznosti na ně navrhnu jednotlivé třídy zajišťující komunikaci.
Architektura Použiji zvolený architektonický styl z analytické části a roz- šířím jej, aby byl plně použitelný pro potřeby aplikace. Vydefinuji jednotlivé třídy zodpovědnosti v rámci stanovené architektury.
1.1.3 Implementace
Naimplementuji jádro aplikace ve jazyce, který zvolím. Zároveň vyjmenuji všechny knihovny, které použiji a krátce popíši, k čemu slouží. Nakonec uvedu diagram nasazení jádra.
1.1.4 Testování
Otestuji vytvořený kód – konkrétně vytvořím sadu jednotkových, instrumen- ted a UI testů.
4
Kapitola 2
Rešerše
2.1 Technologie pro vývoj
Před počátkem vývoje je třeba zvolit technologii pro vývoj. Chceme-li vyvíjet pro OS Android, tak máme na výběr hned z několika programovacích jazyků.
Následující kapitola popisuje možné přístupy k docílení úspěchu – tedy sesta- vení výsledné aplikace.
2.1.1 Nativní vývoj
Nativní vývoj probíhá s přímým využitím Android SDK. Ještě před samotným vydáním nové verze systému Google uvolňuje alpha a beta verze nástrojů pro vývoj a samotné SDK. Vývojáři tedy mohou ještě s předstihem připravit své aplikace – přidat nové funkce nebo upravit stávající, aby aplikace byla plně kompatibilní s novou verzi systému.
Například první testovací verze systému Android O včetně SDK byla k dispo- zici 21. března 2017 [1], během následujících měsíců vyšly ještě další tři verze a 21. srpna 2017 [2] konečně finální, která nese název Android 8.0 Oreo.
březen duben květen červen červenec Q3
DP 1 DP 2 DP 3 DP 4
Vydání verze
Finální API
Obrázek 2.1: Plán uvolňování beta verzí OS Android 8.0 [3]
2. Rešerše
2.1.1.1 Java
Každý, kdo stal u počátku vývoje mobilních aplikací pro Android, používal Javu. V době zrodu systému byla právě Java SE 6 jediným jazykem, který mohl být použit. Podpora novějších verzí Javy je problematická, protože nové funkcionality musí být příslušně promítnuty do systému. Stává se tak, že i pár let po uvolnění nové verze Javy, ji Android ještě nepodporuje.
Java verze Vydání Minimální verze AN Vydání verze AN
6 11. 12. 2006 [4] 1.0 23. 9. 2008 [5]
7 7. 6. 2011 [6] 4.4 KitKat 31. 11. 2013 [7]
8 18. 3. 2014 [6] 7.0 Nougat 22. 8. 2016 [8]
Tabulka 2.1: Přehled verzí jazyka Java a návaznost na Android Google tento problém aktuálně řeší na úrovni kompilace do bytekódu. Zmíněný proces se nazývá „desugaring“ [9] a umožňuje využívání některých funkcionalit z novějších verzí Javy na starších verzích systému. Desugaring je zapnut v Android Studiu od verze 3.1 ve výchozím nastavení. V předchozích verzích jej bylo nutné manuálně povolit.
2.1.1.2 Kotlin
Jazyk vyvíjí společnost Jetbrains, verze 1.0 byla vydána 15. února 2016 [10].
Kotlin je další možnou variantou, pokud se programátor rozhodne jít nativní cestou vývoje. Oproti Javě přináší řadu výhod – například podporuje lambda výrazy na všech úrovních jazyka. Další výhodou je, že pro Kotlin vychází častěji aktualizace a jazyk dává programátorům větší volnost – dovoluje třeba přetěžovat operátory.
Největší výhodou je, že se kompilátor dokáže ze zdrojových kódů psaných v Kotlinu vytvořit Java 6 nebo Java 8 kompatibilní bytekód. Kotlin taktéž do- káže pracovat s Java knihovnami, není tedy třeba provádět dodatečné úpravy nově vydaného Android SDK.
Oficiální podporu Kotlinu vyjádřil i Google v 2017 na Google I/O. S verzí 3.0 Android Studia přišla i přímá integrace s Kotlinem [11].
2.1.2 Flutter
Flutter je open source SDK pro vývoj mobilních aplikací [12]. Projekt se v době psaní této bakalářské práce nacházel v beta verzi a podporoval vývoj pro Android a iOS. Primárně cílí na přenositelnost kódu mezi platformami a rychlost vykreslování UI. Flutter SDK nevyužívá nativní systémové kom- ponenty, ale samo řeší jejich implementaci. Pro Android tak přináší značnou 6
2.2. Architektonický styl optimalizaci u animací. Díky Flutteru lze provádět složitější animace, které by byly při nativním vývoji téměř nemyslitelné.
Pro vývoj je využíván programovací jazyk Dart a minimální verze Android OS je 4.1 Jelly Bean. Ze strany Flutteru je taktéž kladen požadavek na architek- turu procesoru zařízení – podporován je pouze ARM.
2.1.3 Xamarin
Od roku 2013 lze vyvíjet Android aplikace i v jazyce C# s pomocí platformy Xamarin. Je potřeba mít nainstalováno Visual Studio s integrací Xamarin.
Mezi hlavní výhody Xamarinu patří znovupoužitelnost kódu v případě mul- tiplatformního vývoje. Kompilace probíhá do nativního kódu a je zde možnost využití nativních UI komponent u všech podporovaných platforem [13].
V případě Androidu je zde malé omezení týkající se knihoven. Například tzv.
support knihovny, které Google vydává pro usnadnění vývoje, musí být pa- třičně přetransformovány, aby mohly být použity. Tato komplikace zhoršuje možnost integrace nových funkcionalit. Xamarin ke 4. březnu 2018 podporuje support-v4 knihovnu ze září 2017 (verze 26.1.0) [14]. Aktuálně je k dispozici již verze z února 2018 (27.1.0).
2.1.4 HTML5
Jako další možnost se nabízí vyvinutí webové stránky, která bude simulovat mobilní aplikaci. V tomto případě je potřeba vytvořit pouze aplikaci, která po spuštění načte příslušný web, který si bude vše řídit sám. Vykreslování obsahu zajišťuje WebView komponenta. Od Androidu 5.0 se automaticky aktualizuje přes obchod Google Play [15]. Starší verze systému se v tomto případě mohou potýkat ať už bezpečnostními problémy [16] nebo nekompatibilitou s novými verzemi JavaScriptu. Diskutabilní v tomto případě je výkon takové aplikace.
VyužíváníWebViewje zpravidla náročnější na procesorový čas a zvyšuje využití baterie. Přístup k úložišti zařízení nebo lokaci musí být řešen mnohem složitěji.
2.2 Architektonický styl
Při programování aplikací lze využít různé architektonické styly. Součástí této kapitoly je analýza nejvíce užívaných architektonických stylů v rámci vývoje pro platformu Android.
Při analýze jsme kladli důraz na čtyři klíčové vlastnosti jednotlivých řešení – rozšiřitelnost, testovatelnost, složitost základní implementace a schopnost reagovat na konfigurační změny.
2. Rešerše
2.2.1 Bez architektury
Aplikace lze vyvíjet bez předem předepsané architektury. Vstupní bod do kaž- dého procesu aplikace je třídaApplication. První obrazovka, která se zobrazí, vždy dědí od třídyActivity.
Následující styl nezaručuje plnou testovatelnost, protože nedefinuje třídy zod- povědnosti. Každý nový vývojář na projektu může nové funkce implementovat dle vlastní libosti. Ucelenost kódu může utrpět újmy, a tím pádem nelze zaru- čit jednoduchou rozšiřitelnost. Na druhou stranu pro vytvoření programu je potřeba znát pouze Android framework.
2.2.2 MVC
Tento architektonický styl definuje tři základní třídy zodpovědnosti, které mezi sebou vzájemně interagují. Užitá zkratka vznikla z počátečních písmen násle- dujících tří slov –model,view a controller [17].
Model v tomto případě obsahuje sadu informací, které reprezentují stav da- ného celku. Běžně se v modelu taktéž vyskytuje business logika aplikace.
View slouží jako vizuální reprezentace modelu. Zodpovědností této třídy je vykreslení všech potřebných dat v závislosti na stavu modelu. Vytváří tak tzv. user interface (UI). V případě systému Android tuto roli plní třídy dědící od třídyView.
Controller následně slouží jako prostředník mezi view a modelem. Obdržuje informace, které vznikají v rámci interakce uživatele s view (například vepsání textu, klepnutí na tlačítko). Na jejich základě poté změní stav v modelu.
U nativních Android aplikací se jedná zejména o potomky tříd Activity či Fragment. Ty dokáží totiž zachytávat uživatelský vstup [18].
V rámci jmenné konvence je zvykem, že třída, která vykonává view nebo controller roli má toto slovo jako součást svého názvu. Ve většině případů pak právě tímto slovem její název končí.
Tento zvyk ale neplatí pro systém Android, jelikož controllererem se stává třída, která dědí od jiné ze systémového frameworku. Z toho důvodu se upřed- nostňuje jmenná konvence systému – potomek Activity je MainActivity, nikoliv MainController. V případě view platí stejné pravidlo. Android fra- mework poskytuje na desítky nativních view komponent, a pokud progra- mátor nevyvíjí vlastní, tak ani není potřeba je nějak rozšiřovat. Pokud je LinearLayout kořenem layoutu, zůstane to tak i nadále. Controller jej bude pouze referencovat – nevytváří se speciální potomek.
8
2.2. Architektonický styl Rozdělení tříd zodpovědnosti po vzoru MVC přináší lepší rozpad zodpověd- nosti než nepoužití žádného stylu. Svázanost view a controlleru omezuje jed- notkové testování a způsobuje, že v rámci změny view musí dojít k promítnutí změn i do controlleru. Jelikož view a controller dědí od systémových tříd, tak jakékoliv testy musí být prováděny pouze na Android zařízení. Použití MVC je velmi jednoduché – programátor musí pouze vytvořit příslušný model. View a controller už systém poskytuje.
Obrázek 2.2 popisuje závislost jednotlivých komponent na sobě, controller je držitel životního cyklu.
View Controller Model
1 1 1 1
Obrázek 2.2: Diagram tříd – MVC architektura
2.2.3 MVP
Styl „model view presenter“ částečně vychází z MVC. Alespoň co se týče defi- nice modelu, jehož primární zodpovědnost zůstává stejná – udržuje informaci o stavu a řeší business logiku.
Presenter poté slouží jako obdoba controlleru. V případě Androidu presenter nedědí od některé z frameworkových komponent. Ideálně ani na žádnou přímo neodkazuje. Povolené jsou pouze rozhraní (interfaces), což zajišťuje lepší tes- tovatelnost presenteru.
View opět plní stejnou roli jako v případě MVC. Zde se ale jedná o potomka jedné z těchto tříd: Activity,Fragment nebo dokonceService.
V spojitosti s MVP se hojně využívají rozhraní, která definují chování view.
Presenter tak klasicky odkazuje na rozhraní, které poté view implementuje. To zajišťuje lepší přenositelnost kódu. Jednou napsaný kód (presenter a model) lze následně zrecyklovat na jiných systémech a pouze vytvořit nové view, které bude obsah vykreslovat.
Z hlediska jmenné konvence nejsou kladeny žádné požadavky na model. V pří- padě presenteru je zvykem používat příponu „Presetner“ – třída se tedy jmenuje například MainPresenter. Definice view (interface) používá příponu
„View“ – může se tedy nazývat MainView. Implementační třída se v Java EE nazývá MainViewImpl – přidává se pouze přípona „Impl“. Pokud jde o Android framework, tak zde je implementace view spíše pojmenována jako MainActivityneboMainFragment. Dodržuje se stejná zvyklost jako v případě MVC – třídy se jmenují dle svých rodičů.
2. Rešerše
Nasazení MVP je v případě Android OS komplikovanější než MVC. V tomto případě je programátor nucen presenteru předávat informace o stavu view a zároveň počítat s možností, že presenter nebude mít přístup k view.
Každá komponenta je nezávislá na ostatních, což plyne i z diagramu tříd pro MVP na obrázku 2.3.
Vi ew P resenter Model
1
1 1 1
Obrázek 2.3: Diagram tříd – MVP architektura
2.2.4 MVVM
Architektonický styl, který se na první pohled skládá ze čtyř komponent, se ve skutečnosti skládá pouze ze tří. Jména těchto komponent jsouview,model aviewmodel.
Koncepty view a model zůstávají stejné jako v případě MVP. Největší změna přichází v kardinalitě mezi view a viewmodelem. MVVM totiž umožňuje view komunikovat s vícero viewmodely. Ve všech předchozích případech se jednalo vždy o vztah jedna ku jedné. Tato malá změna umožňuje větší dekompozici problémů a přináší snazší sdílení kódů mezi různými částmi aplikace (views).
Samotný viewmodel obaluje model a zajišťuje dvě hlavní funkce. První z nich je možnost sledovat model. Kdokoliv, kdo má přístup k viewmodelu, má mož- nost sledovat změny modelu. Logiku, která tuto funkcionalitu zajišťuje, musí řešit právě viewmodel.
Druhou funkcionalitou je možnost měnit model. Platforma Android neposky- tuje žádné vlastní nástroje pro zajištění těchto funkcí a MVVM lze tak napří- klad implementovat pomocíObservabletřídy z Javy nebo RxJava knihoven.
Novinkou roku 2018 je knihovna Android Architecture Components, která se zaměřuje na zjednodušení implementace MVVM.
Architektura MVVM je z hlediska implementace značně složitější než všechny předchozí. Musí se vyrovnat se stejnými problémy jako MVP.
V rámci jmenné konvence platí pravidla jako pro styl MVP. Jméno třídy, která reprezentuje viewmodel končí právě tímto slovem. Diagram na obrázku 2.4 popisuje vztah jednotlivých komponent.
10
2.2. Architektonický styl
View ViewModel Model
1 1..* 1
1
Obrázek 2.4: Diagram tříd – MVVM architektura
2.2.5 Životní cyklus a konfigurační změny
V případě mobilních aplikací, a zejména těch pro OS Android, je potřeba počítat s životním cyklem jednotlivých komponent. Otočení zařízení o 90◦ vyvolá změnu orientace obrazu. Z pohledu systému je tato akce vnímána jako konfigurační změna – konkrétně jde o změnu rozlišení plochy, která je využita pro vykreslení UI komponent.
Pokud vývojář nedeklaruje jinak, tak systém v reakci na tuto změnu kom- pletně zničí aktuální aktivitu či fragment a vytvoří ji resp. jej znovu. Vý- vojář před samotným zničením musí zaručit, že stav komponenty bude ob- noven i po jejím znovuvytvoření. Systém v tomto případě zavolá metodu onSaveInstaceState(Bundle)a vývojář má možnost do Bundleuložit aktu- ální stav obrazovky a následně jej obnovit po znovuvytvoření.
Tato skutečnost má přímý dopad na každou ze tří zmíněných architektur a v rámci implementace se musíme v každé potýkat s řadou problémů.
MVC Controller je zároveň Android komponentou, obdržuje tedy informace o konfiguračních změnách. Zároveň si drží referenci na model, může tedy velmi pružně na tyto změny reagovat.
MVP V případě MVP je view UI komponenta. Sama ale informace o stavu nedrží – od toho tu je presenter. Je tedy nutné, aby veškeré informace o stavu view byly přeposílány do presenteru a ten na ně může příslušně reagovat. Uklá- dání stavu probíhá na žádost view, požadavek zpracovává presenter. Samotné uložení ale musí provést view.
MVP architektura zde už naráží na své limity, protože pro zachování testo- vatelnosti je třeba, aby proces ukládání řešilo view, interaguje totiž s kompo- nentami Android frameworku.
Podobná situace nastává v případě změny views. Spuštění aktivity nebo při- dání fragmentu do zásobníku může provést pouze systémová komponenta.
Z hlediska architektury by tento proces měl ale vykonávat presenter. Danou situaci lze řešit porušením pravidel – tedy delegací odpovědnosti na view – nebo například skloubením MVP a MVC, vytvořením MVPC.
2. Rešerše
MVVM Centrálním mozkem je zde view, které přijímá informace o změnách modelů pomocí viewmodelu. Konfigurační změny lze řešit jednoduše, modely je třeba pouze z viewmodelů dostat a následně patřičně zpracovat.
Viewmodel ani model nemusí nic vědět o stavu view. View jen při svém zničení musí viewmodelu říct, že zaniká. Viewmodel mu následně přestane doručovat informace. Samotné neoznámení by potom mohlo vést k úniku paměti (me- mory leaku).
2.3 Minimální verze systému
Před počátkem vývoje aplikace bývá zvykem, že je určena minimální verze systému, kterou aplikace podporuje. Toto rozhodnutí je klíčové zejména pro vývojáře, protože některé funkcionality jsou dostupné až od určitě verze sys- tému. Cílení na nejaktuálnější verzi vede k nejsnadnějšímu vývoji, ale naopak k nejhorší dostupnosti.
2.3.1 Podíl verzí na trhu
Tabulka 2.3 popisuje podíl jednotlivých verzí Androidu k 5. únoru 2018. Verze, které mají tržní podíl nižší než 1 % nejsou ve statistice zahrnuty. Sloupec
„trend“ obsahuje znak↑, pokud se podíl zvýšil v porovnání s lednovou statis- tikou. V opačném případě je použit symbol↓.
Verze Kódové označení API Procentuální podíl Trend
2.3.3 - 2.3.7 Gingerbread 10 0.3 % ↓
4.0.3 - 4.0.4 Ice Cream Sandwich 15 0.4 % ↓
4.1 Jelly Bean 16 1.7 % ↓
4.2 17 2.6 % ↓
4.3 18 0.7 % ↓
4.4 KitKat 19 12 % ↓
5.0 Lollipop 21 5.4 % ↓
5.1 22 19.2 % ↓
6.0 Marshmallow 23 28.1 % ↓
7.0 Nougat 24 22.3 % ↑
7.1 25 6.2 % ↑
8.0 Oreo 26 0.8 % ↑
8.1 27 0.3 % ↑
Tabulka 2.2: Verze OS Android a jejich rozšířenost 2.3.2 Zásadní změny
S každou verzí systému dochází ke změnám. Přibývají nové možnosti pro vývo- jáře v podobě rozšíření stávajícího API nebo k omezení některých funkciona- 12
2.3. Minimální verze systému lit. Tato podsekce se věnuje vybraným verzím, ve kterých došlo k zásadnějším změnám.
Honeycomb 3.0 Verze Honeycomb [19] není ani uvedena v tabulce 2.3, protože byla původně určena pouze pro tablety. Do té doby Android plně tato zařízení nepodporoval a Google problém vyřešil konstruktem zvaným Fragment. Ten v závislosti na své viditelnosti přejímá životní cyklus svého rodiče Activity. Hlavní výhodou je, že aktivních fragmentů může být více, což napomáhá rozpadu kódu. Fragmenty jsou dnes již zažitým konstruktem při budování funkční aplikace.
Došlo taktéž ke standardizaci velkého množství UI prvků – světlo světa spatřil ActionBar [20], který byl později nahrazen komponentou s názvemToolbar.
Tato komponenta je zpravidla umístěna v horní části UI aplikace a umož- ňuje uživateli otevírat kontextové menu nebo se v hierarchii obrazovek vrátit o úroveň výše.
Ice Cream Sandwich 4.0 Tato verze již počítala s tablety a mobily [21].
Společně s ní byl uveden holo design, který unifikoval UI pro mobily a tablety.
Zpětnou kompatibilitu nových prvků se staršími verzemi systému zaručovaly dodatečné knihovny a téma AppCompat, které existuje dodnes.
Lollipop 5.0 Poslední důležitá verze nese název Lollipop [22]. S ní přišla nová designová konvence, která platí dodnes. Jmenuje se material design a na rozdíl od svého předka je mnohem striktnější – například pevně definuje me- zery mezi jednotlivými vizuálními prvky a popisuje sadu přístupů, které lze aplikovat při vývoji designu aplikace. Na druhou stranu dává designérům vol- nější ruku v úpravách aplikací – systém společně s material designem přináší i možnost obarvovat status a navigation bar.
12:30
Obrázek 2.5: Status bar
Byly taktéž vydány knihovny, které částečně přinášejí podporu material de- signu na starší verze systému, podpora je ale dodnes značně omezena.
Obrázek 2.6: Navigation bar
2. Rešerše
Dále dochází ke značným změnám v jádře systému. Přechází se na virtuální stroj Android RunTime (ART). To má za následek delší dobu instalace apli- kací na cílovém zařízení. Na druhou stranu ale rychlejší kompilaci aplikace.
Pro vývojáře přináší ART více možností při debugování. Systém nově pro vykreslování dedikuje speciální vlákno s názvem RenderThread. Přímým dů- sledkem této změny je ve spojitosti s ART rychlejší načtení UI komponent a plynulejší animace.
Marshmallow 6.0 a novější Od verze Marshamallow systém podporuje in- dividuální udělování oprávnění aplikacím. Uživatel získává větší kontrolu nad svými daty. Další verze se spíše zaměřují na omezení práce aplikací na pozadí – byl představen režim Doze, který plánuje periodické probouzení zařízení, když je vypnutý displej. Aplikacím dává krátký časový úsek, který mohou využít pro vlastní potřebu. Plánování úloh na přesně stanovený čas je stále možné, ale s ohledem na výdrž baterie se nedoporučuje využívat. Google tak- též v novějších verzích systému omezil aplikacím možnost přijímat informace o změnách v úložišti – opět s cílem zvýšit výdrž zařízení.
14
Kapitola 3
Analýza
3.1 Funkční požadavky
Funkční požadavky kladené na aplikaci vycházejí z již stávajícího webového portálu Daywork.cz. Aplikace by dle specifikace od zadavatele měla plnit všechny stěžejní funkcionality. Výjimka je udělena pro notifikace, pro které má webový portál vlastní sekci. V případě mobilních zařízení lze tyto zprávy nahradit nativními notifikacemi.
3.1.1 Uživatelské role
Aktuálně webový portál pracuje se čtyřmi rolemi – host, pracovník, firma a ad- min. Na mobilní aplikaci je kladen požadavek, aby plně podporovala funkci- onality pro pracovníky a firemní zákazníky. Role host nabývá každý uživatel portálu, pokud není přihlášen. Rozhraní pro administrátora aplikace podpo- rovat nebude.
3.1.2 Funkční požadavky - host
Registrace Aplikace bude uživatelovi umožňovat provést kompletní proces registrace, který zahrnuje vyplnění e-mailové adresy a hesla. Tyto údaje musí být na server přenášeny v šifrované formě. Registraci pracovníka lze taktéž provést přihlášením k účtu třetí strany. Konkrétně jsou podporovány uživa- telské účty od firem Google a Facebook.
Přihlášení Uživatel, který je zaregistrován, se může do aplikace přihlásit až třemi cestami. Pokud se jedná o uživatele role brigádník, tak tento proces může dokončit zadáním své e-mailové adresy a hesla, nebo s využitím autori- začních serverů třetích stran – Googlu a Facebooku. Uživatel, který je správce firemního účtu, se může přihlásit pouze s pomocí e-mailu a hesla.
3. Analýza
Rozpoznání role uživatele Jelikož uživatel může nabývat jedné role z pře- dem definované množiny, tak aplikace musí být po přihlášení schopna rozeznat typ uživatele, aby mu dle jeho role mohla zobrazit relevantní obsah.
Číselníky Pro omezení zbytečného přenosu dat server vystaví přístupový bod, kde bude seznam všech číselníků. Jedná se o strukturu s klíčem, který bude použit v ostatních odpovědích serveru, a hodnotou. Ta odpovídá textu, který má být uživateli zobrazen. Do číselníků patří například seznam zemí, jazyků, pohlaví, velikostí oblečení, ...
3.1.3 Funkční požadavky - přihlášený uživatel
Posílání zpráv Pro komunikaci brigádníka a firmy bude aplikace poskyto- vat rozhraní, které bude umožňovat zasílání zpráv.
Zobrazení vlastního profilu Ke všem uživatelským účtům se váže i jejich osobní profil. Nezávisle na roli v systému bude mít každý přihlášený uživatel možnost si prohlédnout svůj vlastní profil.
Push zprávy Každý přihlášený uživatel bude mít možnost přijímat push zprávy relevantní vůči jeho účtu. Mezi hlavní funkcionality bude patřit změna stavu brigády nebo informace o nové soukromé zprávě.
Odhlášení Uživatel bude mít možnost se z aplikace odhlásit.
3.1.4 Funkční požadavky - pracovník
Základní nastavení účtu Po přihlášení aplikace nabídne brigádníkovi do- vyplnění povinných polí v profilu, pokud nejsou vyplněny. Součástí základního nastavení účtu je také volba filtrů pro nabídky brigád.
Práce s profilem Brigádník bude mít možnost si přes mobilní aplikaci upravit svůj profil.
Filtrování brigád Aplikace bude brigádníkovi nabízet možnost upravit si své filtry pro nabídky. Uživatel bude moci seznam brigád filtrovat dle přibližné lokace nebo nabízené pracovní pozice.
Detail brigády Ke každé nabízené brigádě bude k dispozici možnost zob- razit její plný detail.
Proces přihlášení k brigádě V případě zájmu bude uživatel moci po- dat žádost o nabízenou brigádu. Aplikace dále bude rozeznávat aktuální stav přihlášky a bude uživateli umožňovat celý proces úspěšně dokončit.
16
3.2. Nefunkční požadavky Oblíbené brigády Součástí funkcionalit aplikace bude i práce s oblíbenými brigádami. Uživatel si může zvolit libovolný počet oblíbených brigád, prochá- zet jimi a upravovat je.
3.1.5 Funkční požadavky - firma
Práce s profilem Firemní uživatel bude moci kompletně upravovat svůj profil.
Vytvoření brigády Aplikace bude nabízet rozhraní pro vytvoření brigády.
Vrácení se k neodeslané brigádě Aplikace bude automaticky ukládat vyplněná data v rámci procesu vytváření brigády. Pokud uživatel celý proces vytváření nedokončí, tak při dalším vstupu na příslušnou obrazovku uživateli nabídne možnost vrátit se zpět k rozpracované brigádě.
Zobrazení brigád Uživatel v aplikaci uvidí všechny brigády, které vytvořil.
Součástí výpisu budou základní informace o každé položce.
Detail brigády Ke každé nabízené brigádě bude k dispozici možnost zob- razit její plný detail.
Úprava brigády Uživatel bude moci přes aplikaci upravovat povolená pole již existující brigády.
Správa brigádníků Uživatel, který bude v roli firma, bude mít k dispozici rozhraní pro schvalování brigádníků, kteří projevili zájem o pracovní pozici.
Oblíbení brigádnici Podobně jako brigádník má oblíbené brigády, tak pod firemním účtem lze vést seznam oblíbených brigádníků a upravovat jej.
Detail profilu brigádníka V případě, že byl dokončen proces schvalování brigádníka, tak firemní uživatel bude mít přístup k profilu brigádníků, kteří pro firmu pracují.
3.2 Nefunkční požadavky
Zabezpečení Data přenášená mezi aplikací a webovým serverem musí být šifrována. Využívání nezabezpečených protokolů (jako je například HTTP) je striktně zakázáno. Citlivé údaje (hesla) musí být ještě navíc vlastnoručně zašifrována před samotným odesláním.
3. Analýza
Dostupnost Aplikace musí být dostupná zdarma na Google Play Store. Po nainstalování musí fungovat na všech zařízeních, která mají minimálně verzi systému ze sekce 3.5 nebo novější.
Spotřeba baterie V době, kdy aplikace poběží na pozadí, tak omezí veškeré své činnosti. Nebude zařízení automaticky probouzet, ani provádět časově či výkonově náročné operace.
Rozšiřitelnost Jádro aplikace musí být navrhnuto s důrazem na další rozši- řitelnost. Musí být stanovena jednotná architektura, která bude využita v mo- dulech pro brigádníky a firemní uživatele.
Modularita Do aplikace musí být jednoduché zahrnout nové uživatelské role. Jednotlivé části aplikace musí záviset pouze na jádře. Přímá závislost mezi moduly by neměla nastat.
Rychlá odezva Aplikace bude schopna přijímat i zpracovávat vstup uživa- tele během celé doby svého běhu. Není povoleno vykonávat časově náročné operace na vlákně, které bude mít tyto operace na starosti.
3.3 Případy užití
Případy užití vycházejí z definice funkčních požadavků ze sekce 3.1. V případě jádra se zabýváme primárně těmi, které se týkají nepřihlášeného uživatele.
Pokrytí ostatních požadavků je předmětem dalších prací.
Proces registrace může být dokončen dvěma způsoby. S využitím SSO exter- ních služeb nebo manuálním vyplněním požadovaných údajů. Každý z nich probíhá odlišně.
Registrace – manuální
1. Uživatel klepne na tlačítko „zaregistrovat“ na přihlašovací obrazovce.
2. Uživatel si zvolí svou roli. Může se zaregistrovat jako firma nebo brigád- ník.
3. Aplikace zobrazí obrazovku s textovými poli, které je nutné vyplnit pro zaregistrování. U každého z nich bude signalizováno, jestli je nutné jej vyplnit nebo ne. Dále je taktéž zobrazeno tlačítko pro odeslání poža- davku. Formulář se mění dle předvybrané role.
4. Uživatel vyplní všechna povinná pole a potvrdí svůj záměr provést re- gistraci.
18
3.3. Případy užití 5. Aplikace zkontroluje správnost dat a odešle je na server. V případě chyb-
ných dat je uživatel vyzván k opravě.
6. Server požadavek zpracuje a vytvoří účet nebo vrátí chybu, ve které je popsáno, které z polí nebylo vyplněno korektně.
7. Po registraci je uživateli výsledek procesu oznámen skrze nativní UI prvek. Následně je uživatel přesměrován na obrazovku přihlášení.
Registrace – externí účet
1. Uživatel si na přihlašovací obrazovce zvolí, pomocí jakého účtu externí služby se chce přihlásit.
2. Aplikace v závislosti na zvolené službě obdrží přístupové údaje k účtu a odešle je na server.
3. Server zjistí nutné informace o uživateli, založí mu účet a automaticky přiřadí roli pracovníka.
4. Po registraci je uživateli výsledek procesu oznámen skrze nativní UI prvek. Následně je uživatel přihlášen do aplikace a přesměrován na pří- slušnou obrazovku dle své role.
Přihlášení
1. Aplikace nepřihlášenému uživateli nabídne ze tří možností přihlášení – pomocí Daywork, Facebook nebo Google účtu.
2. Uživatel zvolí typ přihlášení.
3. V případě Daywork účtu je uživatel vyzván k vyplnění e-mailu a hesla.
Následně klepne na tlačítko „přihlásit“.
4. Aplikace v závislosti na typu přihlášení odešle data na server.
5. Server dohledá uživatele a vystaví mu přístupové údaje, společně s nimi v odpovědi vrátí i roli uživatele. V případě externího účtu vytvoří účet, pokud neexistuje.
6. Aplikace si údaje uloží.
7. Aplikace stáhne nejnovější číselníky. V případě chyby v tomto kroku dojde k selhání celého procesu přihlášení.
8. Aplikace přesměruje uživatele na příslušnou obrazovku dle jeho role.
3. Analýza
Odhlášení
1. Uživatel klepne na tlačítko „odhlásit se“.
2. Aplikace odešle na server požadavek, nezávisle na jeho výsledku uživatele odhlásí a přesměruje na obrazovku, kde se může znovu přihlásit.
3. Server zneplatní přístupové údaje uživatele.
B rigádník Nepřihlášený
uživ atel
Firma Registrace —
manuální
Registrace — externí účet Přihlášení — externí účet
Odhlášení
Přihlášený uživ atel Přihlášení —
Dayw ork účet
Stažení číselníků Přihlášení
«include»
«extend»
«extend»
«extend»
Obrázek 3.1: Přehled případů užití
20
3.4. Technologie pro vývoj
3.4 Technologie pro vývoj
Tato sekce navazuje na rešeršní část práce – konkrétně sekci 2.1.
Jelikož je cílem vyvinout aplikaci pro Android, tak multiplatformní frameworky nám nepřinášejí žádnou přidanou hodnotu. V rámci našeho týmu jsme se proto spíše přiklonili k nativní cestě vývoje. S ohledem na náš cíl naučit se více o platformě proto taktéž zavrhujeme možnost HTML5 webu.
Zbývá tedy vybrat mezi Javou a Kotlinem. Oba tyto jazyky nabízí takřka to samé, přičemž Kotlin v mnohém usnadňuje programování. V týmu jsme se ale rozhodli využít Javu, jelikož s tímto jazykem máme všichni větší zkušenosti.
Tuto volbu taktéž činíme s vědomím, že na projektu nás bude více – striktnost Javy například v určování typu proměnných nám pomůže se lépe zorientovat v kódu.
3.5 Minimální verze systému
Kdybychom chtěli pokrýt největší uživatelskou základnu, tak samozřejmě zvo- líme minimální podporované API verze 10. Je třeba ale brát v potaz podporu ze strany knihoven třetích stran. V našem případě je mandatorní podpora tzv.
support knihoven, které vydává Google periodicky každý měsíc.
Vyvíjet lze i bez těchto knihoven, ale doba vývoje se v tomto případě zvýší a zároveň nelze použít některé funkce zpětně. Support knihovny tento problém v mnoha případech řeší. Jako konkrétní příklad lze například uvést přidání podpory material designu pro Androidem 4.4 a starší. Tyto zmíněné knihovny aktuálně podporují všechny verze systému od API 15. Aplikace Daywork tedy může korektně fungovat na Android 4.0.3 a novějším.
S ohledem na klesající podíl verzí počínající cifrou 4 (viz sekce 2.3) jsme se rozhodli, že aplikace bude plně funkční od verze Android 5.0 Lollipop.
3.6 Architektonický styl
Tabulka 3.1 shrnuje výsledek analýzy pro každý ze stylů z kapitoly 2.2.
Bez architektury MVC MVP MVVM
Rozšiřitelnost Diskutabilní OK OK OK
Testovatelnost NE NE OK OK
Složitost implementace Diskutabilní OK Složitější Složitější
Reakce na konfig. změny OK OK Složitější OK
Tabulka 3.1: Výsledek analýzy architektur
3. Analýza
Z výsledků analýzy plyne, že nepoužití předem definované architektury nemusí vést k uspokojení všech 4 požadavků. Nejlépe si vede architektura MVVM, která se dokáže vypořádat skoro se všemi požadavky – pouze plně funkční implementace může zabrat více času než v případě konkurentů.
Na základě této analýzy jsme se rozhodli, že pro mobilní aplikaci Daywork použijeme MVVM architekturu.
22
Kapitola 4
Návrh
4.1 Jmenná konvence a anotace
Dalším z cílů této bakalářské práce je stanovení jednotné jmenné konvence.
Tento požadavek vznikl hlavně, aby byla zajištěna lepší kvalita a přehlednost kódu.
V rámci definování pravidel pro pojmenovávání různých objektů a jejich sou- částí bude použita sada pravidel, které již dnes mají své oficiální pojmenování.
Předpokládejme, že pro každou z následujících třech konvencí je vstupem ře- tězec „Hello world“.
Camel case Výstupem bude „HelloWorld“. Dojde tedy k odstranění mezer, výstup může začínat malým písmenem, každé další slovo velkým. Camel case se využívá zejména ve světě Java nebo C#.
Snake case V tomto případě nahrazujeme mezery znakem potrhovací čáry a všechny verzálky nahradíme mínuskami. Zapisujeme „hello_world“. Tento styl se dnes hojně využívá ve zdrojových kódech PHP nebo jazyka Python.
Kebab case Funguje podobně jako snake case, pouze místo symbolu „_“
je použita pomlčka, výsledek je tedy „hello-world“. Kebab case je aplikován v Lispu.
4.1.1 Stanovení pravidel
Jelikož aplikaci budeme programovat v jazyce Java, tak budeme dodržovat zažitou konvenci pro tento jazyk. Obohatíme ji o sadu pravidel, která jsou specifická pro Android [23].
4. Návrh
Camel case použijeme pro pojmenování:
• tříd,
• enumerací,
• rozhraní,
• metod,
• proměnných, které nejsou konstantami – tzn. neobsahují modifikátory staticafinal zároveň.
V případě jmen prvních tří položek platí, že první písmeno názvu musí být velké. U ostatních případů naopak malé.
Snake case s verzálkami bude využit u:
• konstant a
• prvků enumerací.
V případě nefinálních a nestatických proměnných dále přidáváme znak „m“
jakožto předponu názvu k proměnné. Z hello se tedy stane mHello. Pokud je proměnná pouze statická, tak dodáváme předponu „s“, výsledkem je tedy sHello. Číselné proměnné automaticky formátujeme a tisícové řády oddělu- jeme podtržítkem.
Všechna zmíněná pravidla stručně shrnuje ukázka kódu 4.1.
4.1.2 Akronymy
V případě výskytu akronymů ve jménech tříd, metod nebo proměnných platí pravidla definovaná v tabulce 4.1. Pro zajištění lepší čitelnosti musí všechny znaky (kromě počátečního) být sázeny mínuskami.
Nesprávný název Správný název JSONConverter JsonConverter HTTSRequest HttpsRequest HTMLCSSPullParser HtmlCssPullParser
Tabulka 4.1: Správná a nesprávná transformace akronymů 24
4.1. Jmenná konvence a anotace public class SampleClass {
public static final int CONSTANT_NUMBER = 42_000;
private static Object sInstance;
public String firstName = "Jan"
private String mLastName = "Novak";
public static Object getInstance() { return sInstance;
}
public String getLastName() { return mLastName;
} }
public enum SampleEnum { HELLO_WORLD, HELLO_MARS;
}
Kód 4.1: Ukázka aplikace jmenné konvence
4.1.3 Anotace
Jazyk Java podporuje využití takzvaných anotací. Jedná se o speciální příkazy, které mohou být přiřazeny k definicím typů, metod nebo proměnných [24].
Důsledkem pak může být například vygenerování dalšího kódu při kompilaci nebo pouze ověření konzistence kódu. Rozeznat se dají podle znaku zavináče, který náleží vždy před jejich deklarací.
Mezi snad nejhojněji využívanou anotaci patří@Override. Vyskytuje se pouze u metod a značí, že daná metoda je přetížená, tedy že předek aktuální třídy ji již definoval a implementoval. Odebrání anotace může mít za následek zobra- zení varování během kompilace kódu nebo kompletní selhání tohoto procesu – vše záleží na nastavení kompilátoru.
Pro označení dostupnosti hodnoty, která je skryta za referencí, využijeme tyto dvě anotace.
@Nullable Anotace aplikovatelná na metody a proměnné. Indikuje, že ná- vratová hodnota, resp. cíl reference, může býtnull. Pokud proměnná má tuto anotaci, tak v kódu musíme provést ověření validity hodnoty.
4. Návrh
@NonNull Používá se taktéž pouze u proměnných a metod. Návratová hod- nota nesmí nikdy býtnull.
Dále pro rozlišení, na jakém vlákně můžeme danou metodu volat, využíváme tyto tři anotace.
@MainThread Potřebujeme-li zdůraznit, že metoda musí běžet na hlav- ním vlákně, aplikujeme tuto anotaci. Využíváme ji zejména v metodách, které pracují s UI prvky.
@WorkerThread Pokud daná metoda nesmí běžet na hlavním vlákně, je třeba aplikovat tuto anotaci. Vynecháváme ji, pokud je z kódu zřejmé, že pracujeme na asynchronním vlákně – například pokud přetěžujeme metodu doInBackground(Params...)v potomku třídy AsyncTask.
@AnyThread Tuto anotaci využíváme u metod jejichž název evokuje, že by mohly běžet pouze na hlavním, nebo asynchronním vlákně. Příkladem může být metoda s názvemrunIfNotRunning()– spuštění operace může být časově náročné, ale díky anotaci víme, že ji lze volat z hlavního vlákna.
Pokud v kódu dále pracujeme s referencemi na zdroje mimo Java kód, kon- krétně s třídouR, tak využíváme anotace@StringRes,@ColorRes,@ColorInt či@DimenRespro lepší orientaci v kódu. Datový typ v těchto případech je ne- měnný –int, respektiveInteger.
A konečně, pokud metoda je určena pouze pro testy, musí obsahovat anotaci
@VisibleForTesting. Následující ukázka kódu demonstruje možné využití části anotací. V parametru přijímá referenci na přeloží ji na reálnou barvu.
@ColorInt
@NonNull
@AnyThread
public Integer get(@Nullable @ColorRes Integer colorResource) { return ContextCompat.getColor(this, colorResource == null ?
R.color.black : colorResource);
}
Kód 4.2: Využití anotací
4.2 Spolupráce v týmu
Pro vylepšení spolupráce využijeme systém git, který nám umožní paralelně pracovat na různých funkcionalitách aplikace. Po jejich dokončení budou ná- 26
4.2. Spolupráce v týmu sledně spojovány dohromady do jedné z takzvaných větví (branches). Zdrojové kódy budeme společně ukládat na server gitlab.com.
4.2.1 GitFlow
V našem git repozitáři budou existovat 3 typy větví a slučování jedné do druhé nebude vždy možné.
master Tato větev odkazuje vždy na commit z něhož je vytvořena verze aplikace, která je dostupná v obchodu Google Play. Dokud aplikace není do- stupná pro veřejnost, tak tato větev neexistuje.
X.Y.Z-DEV Hlavní vývojová větev, kde X.Y.Zslouží jako aktuální číselné označení. Tato větev zaniká vždy s uvolněním nové verze aplikace pro veřej- nost. Sloučení (merge) pak proběhne do větve master. Jednotlivé proměnné, které tvoří název větve, mohou nabývat pouze číselných hodnot. Při vydání nové verze aplikace musí dojít k inkrementaci jedné z nich dle těchto pravidel:
• X - majoritní verze, mění se v případě, kdy je aplikace kompletně pře- psána, nebo když přibude nová funkcionalita, která má dopad na všechny typy uživatelů.
• Y - minoritní verze, zvyšuje se pokud dojde k přidání nové funkcionality.
• Z - bugfix verze, dochází k inkrementaci při každém vydání nové verze.
Každé zvýšení hodnoty způsobí vynulování všech hodnot s nižší prioritou.
Pokud bude například aktuální verze 2.4.5 a přidáme novou funkci, tak nová verze aplikace bude 2.5.0 a větev se bude nazývat 2.5.0-DEV.
feature/X Větev určená pro jednu funkcionalitu, která by měla být ato- mická. Vychází vždy z větve, do které bude následně zahrnuta. Od jednotli- vých feature větví může být zahrnuta jakákoliv jiná větev.
Díky stanovení jednoznačného procesu a jmenné konvence větví se budeme lépe orientovat v repozitáři. Zároveň nutné vytváření feature větví pro každou funkci zajistí, že následné zahrnutí do vývojové větve nebude tak komplexní, než kdyby kdybychom všichni pracovali ve své jedné větvi.
4.2.2 Nastavení prostředí
Každý z nás během vývoje má k dispozici vlastní instanci webového serveru Daywork.cz, který je připojen na lokální PostgreSQL databázi. Jelikož aplikace
4. Návrh
musí znát ať už URL nebo IP adresu serveru, tak musíme měnit toto nastavení pro každého vývojáře.
Nástroj pro vytváření instalačních balíčků (gradle) dovoluje samotný proces upravovat. Zde proto využijeme možnost vytvoření tzv.buildType, který bude pro každého z nás jiný. Nazývat se bude dle našeho ČVUT přihlašovacího jména a při procesu vytváření balíčku aplikace musí být zvolen ten správný.
Hlavní výhodoubuildType je, že umožňuje měnit cesty ke zdrojovým soubo- rům, které budou použity při kompilaci. Konstanty spojené s naším lokálním prostředím uložíme právě do souborů, jenž budou závislé na aktuální konfigu- raci. Konkrétně se jedná o již dříve zmíněnou adresu webového serveru nebo například sadu přihlašovacích údajů, které jsou platné pro naše instance.
Do produkčního instalačního balíčku není možno přidávat textace obsahující přihlašovací údaje. Jejich přítomnost v tomto případě představuje významné bezpečnostní riziko.
4.2.3 Struktura projektu
Zdrojové kódy obsahují základní balík cz.daywork, jeho součástí jsou:
• company- balík pro zdrojové soubory firemní části,
• core- složka, která obsahuje jádro aplikace,
• shared- zdrojové soubory, které mohou využívat všichni,
• worker- kořenový adresář části pro pracovníky.
Pro zajištění modularity aplikace platí navíc následující pravidlo – části com- pany a worker nesmí importovat typy z druhého balíku. Pokud existuje nějaká sdílená funkce, tak se musí nacházet v balíkucz.daywork.shared.
4.3 Android Architecture Components
Android Architecture Components je balík knihoven, které vydává společnost Google, přičemž některé z nich jsou stále ještě v alpha nebo beta verzi. V apli- kaci využíváme tři z nich.
4.3.1 Lifecycle
První stabilní verze této knihovny spatřila světlo světa 6. listopadu 2017 [25].
Obsahuje zejména nástroje, které odstiňují problémy s životním cyklem ně- kterých komponent.
28
4.3. Android Architecture Components LiveData Třída LiveData by se dala popsat jako tradiční Observable, které umí reagovat na životní cyklus komponenty, k níž je připojeno. Pro sledování dat je potřeba tomuto objektu poskytnout takzvaného držitele ži- votního cyklu. Toho lze implementovat individuálně neboLiveDatajednoduše navázat na již existující. V případě Androidu se jedná třeba oActivitynebo Fragment.LiveDatapoté doručuje změny pouze, když je jeho držitel ve stavu, ve kterém je schopen data zpracovávat. V případě jeho zničení zaniká auto- maticky i propojení.
ViewModel Slouží pro identifikaci viewmodelu, který je instantizován tří- dou ViewModelProviders. Naše viewmodely od něj musí dědit.
public class UsernameViewModel extends ViewModel { public MutableLiveData<String> username =
new MutableLiveData<String>();
}
public class UsernameActivity extends Activity {
public void onCreate(@Nullable Bundle instanceState) { super.onCreate(instanceState);
ViewModelProviders.of(this).get(UsernameViewModel.class) .username.observe(this, this::onUsernameChanged);
}
public void onUsernameChanged(@Nullable String username){
System.out.println("New username is: " + username);
} }
Kód 4.3: Propojení view s viewmodelem
Ukázka kódu 4.3 obsahuje dvě třídy:
• UsernameViewModel - viewmodel, který obsahuje uživatelské jméno, je- hož změny lze sledovat a
• UsernameActivity - view, které pomocíViewModelProviderszíská in- stanci viewmodelu a následně jej začne sledovat. Změna dat způsobí zavolání metodyonUsernameChanged(String).
4. Návrh
4.3.2 Room
Další knihovna se jmenuje „Room“ a přináší vylepšený přístup k SQLite da- tabázi aplikace. V kombinaci sLiveDataumožňuje sledovat změny.
@Dao
public interface EnumerationDao extends BaseDao<Enumeration> {
@Query("SELECT * FROM enumeration") LiveData<List<Enumeration>> getAll();
}
Kód 4.4: Přístup do databáze přes DAO
Pokud získáme přístup ke tříděEnumerationDao z ukázky kódu 4.4, tak mů- žeme pomocí metody getAll() načíst obsah databáze. Room poté zajistí asynchronní načtení dat a předá je cílovému posluchači. Změna množiny dat, která je definována pomocí SQL dotazu v anotaci, způsobí aktualizaci dat u všech posluchačů.
4.3.3 Paging
Poslední z využitých knihoven se nazývá „Paging“ a zefektivňuje práci s daty, která musí být donačítána postupně ze serveru. Dokud jsou data dostupná lokálně – tedy v databázi – tak zajišťuje, že pouze potřebná podmnožina z nich bude načtena v paměti zařízení. Eliminuje tak spotřebu RAM.
Jakmile je dosažena poslední poslední položka, tak pomocí rozhraní upozorní příslušné třídy. Jejich úkolem je poté stáhnout další část dat.
4.4 Perzistenční vrstva
Jádro aplikace musí taktéž poskytovat základ perzistenční vrstvy pro uklá- dání dat. Na výběr jsou dvě možnosti, které jsou rozvedeny v následujících podkapitolách. Konečný výběr je na programátorech.
4.4.1 Lokální soubor
TřídaSharedPreferences je součástí Android SDK a umožňuje ukládání li- bovolných dat do externího souboru na úložišti zařízení. Využíván je formát XML a s uloženou hodnotou je vždy spojen jedinečný klíč, který si aplikace musí pamatovat.
30
4.4. Perzistenční vrstva Tento způsob ukládání dat se hodí zejména pro zaznamenávání uživatelského nastavení. Rozhodně by neměla být využívána pro ukládání komplexnějších entit nebo objektů, jenž mají vazby na jiné.
V rámci aplikace bude vytvořena nová třída PreferenceHelper, která bude řešit přístup k té systémové. Samotné ukládání do souboru totiž probíhá asyn- chronně a pracování s vícero instancemi třídy SharedPreferences by mohlo způsobit ztrátu dat. V tomto případě bude využit návrhový vzor singleton.
4.4.2 Relační databáze
Relační databáze poskytovaná jádrem slouží pro ukládání komplexnějších en- tit. Jádro aplikace bude obsahovat základní sadu tabulek, které budou do- stupné pro další programátory.
Jelikož jádro řeší pouze přihlašování uživatele, tak databázové schéma 4.1 není tak komplexní. Obsahuje pouze tabulku pro aktuálního uživatele a základní in- formace o něm (jeho role v systému, přístupový token a e-mail). Dále všechny číselníky ze serveru, které jádro nijak nevyužívá, slouží pro pozdější užití v čás- tech pro pracovníky a firmy. A konečně poslední tabulka Credentialsslouží pro jednoznačnou identifikaci uživatele na straně serveru a také obsahuje de- finici veřejného klíče pro danou instanci aplikace.
Enumeration
«column»
*PK id: INTEGER
* dw_id: INTEGER
* value: TEXT
* type: TEXT
«PK»
+ PK_Enumeration(INTEGER)
User
«column»
*PK id: INTEGER
* email: TEXT
* access_token: TEXT
* kind: TEXT
«PK»
+ PK_User(INTEGER)
Credentials
«column»
*PK id: TEXT
* m: TEXT
* e: TEXT
«PK»
+ PK_Credentials(TEXT)
Obrázek 4.1: Relační schéma databáze jádra
Ke každé tabulce poté náleží příslušný model, který představuje její reprezen- taci v Java světě. Pro přístup k datům slouží třídaDwDatabase. Její instanci lze získat pomocí statické metodyDwDatabase#get()– je zde využit návrhový vzor singleton pro zajištění sekvenčního přístupu k objektu, resp. databázi. Po získání instance je třeba ještě zvolit korektní DAO, které obsluhuje požadova- nou tabulku. Základní operace jsou vydefinovány v typu BaseDao, konkrétní implementace poté může provádět nad tabulkou všechny podporované SQLite operace. V příkladu v sekci 4.3.2 třeba DAO přidává možnost načíst všechna data v tabulce.
4. Návrh
Počet obslužných tříd odpovídá počtu tabulek – tuto skutečnost znázorňuje diagram tříd na obrázku 4.2.
Dw Databse - sInstance: DwDatabse + get(): DwDatabse + user(): UserDao
+ enumerations(): EnumerationsDao + credentials(): CredentialsDao
«interface»
T : T
B aseDao + insert(T...)
+ update(T...) + delete(T...)
«interface»
UserDao + get(): LiveData<User>
+ insert(User...) + getSync(): User + update(User...) + delete(User...) + nuke()
«interface»
EnumerationDao + getAll(): LiveData<List<Enumeration>>
+ insert(Enumeration...)
+ findByDwI d(int, EnumerationType): Enumeration + update(Enumeration...)
+ delete(Enumeration...) + findById(int): Enumeration + nuke()
«interface»
Credentials
+ get(): LiveData<Credentials>
+ insert(Credentials...) + getSync(): Credentials + update(Credentials...) + delete(Credentials...)
< T->User > < T->Credentials >
< T->Enumeration >
Obrázek 4.2: Diagram tříd databáze
32
4.5. Push zprávy
4.5 Push zprávy
Push zpráva je objekt, který je odeslán ze serveru do zařízení s cílem informo- vat klienta o změně dat.
Aplikace Daywork bude podporovat příjem těchto zpráv s využitím služby Firebase Cloud Messaging (dále FCM). Ta umožňuje pomocí jednoduchého HTTPS POST požadavku na předem definovanou URL adresu serveru odeslat zprávu až o velikosti 4 kB [26] do množiny zařízení. Každé z nich má vlastní instanceId – jedinečný identifikátor, které generuje SDK od FCM.
Doručená zpráva je mapována na třídu Map<String,String>, jádro ji poté převede na příslušný model a pošle dalším třídám. Rozhodování, kam objekt zamíří, určuje typ zprávy, přičemž aktuálně rozlišujeme dva druhy.
Hlasitá zpráva Po doručení a zpracování této zprávy dojde k upozornění uživatele. Pokud bude aktivní obrazovka, která dokáže zprávu zpracovat, tak ji bude zpráva předána. V opačném případě bude vytvořena systémová noti- fikace.
Tichá zpráva Zpracování nikdy neřeší aktivní obrazovka, probíhá vždy na pozadí. Výsledkem je například invalidace aktuálních dat a následné pře- načtení. Uživatel v tomto případě uvidí například indikátor načítání na obra- zovce, což je přímý důsledek počátku načítání dat.
Po převedení zprávy do objektu ji dále zpracuje PushRouter. Ten je v apli- kaci hned ve dvou verzích – LoudPushRouter zpracovává hlasité zprávy a SilentPushRoutertiché. Následně dle jedinečného identifikátoru, který každá zpráva obsahuje, ji přepošle do některého z potomků třídy PushHandler.
Každý typ zprávy má svůj PushHandler.
Jádro push zprávy využívá pro detekci změn číselníků. Identifikátor zprávy je ENUMERATIONS_CHANGED a EnumerationChangedHandler po přijetí zneplatní všechny číselníky. Automaticky dojde k aktualizaci dat. V případě neúspěchu jsou zachována původní. Při spuštění nové obrazovky dochází v aplikaci k opakování požadavku do doby, než se podaří číselníky aktualizovat.
4.6 Zabezpečení
Aby uživatel aplikace (ať už brigádník nebo firma) mohl přistupovat k je- jím funkcím, tak se musí nejprve přihlásit. Pro zvýšení bezpečnosti dochází k šifrování přihlašovacích údajů pomocí asymetrické šifry.
