ZADÁNÍ BAKALÁŘSKÉ PRÁCE

ČESKÉ VYSOKÉ UČENÍ TECHNICKÉ V PRAZE FAKULTA INFORMAČNÍCH TECHNOLOGIÍ ZADÁNÍ BAKALÁŘSKÉ PRÁCE Název: Mobilní nástroj pro správu skupin lidí Student: Petr Panský Vedoucí: Ing. Jan Baier 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 2017/18 Pokyny pro vypracování Proveďte analýzu požadavků a posléze navrhněte a implementujte mobilní aplikaci řešící problém rozdělování lidí do skupin. Nutnou podmínkou je funkčnost aplikace na OS Android. Celé řešení řádně otestujte a sepište uživatelskou příručku. Aplikace musí umožňovat následující: uložit/editovat pojmenované skupiny lidí, rozdělit skupinu lidí do týmů, zobrazit pro každého člověka seznam lidí, se kterými již byl v týmu a kolikrát, vizualizovat rozdělení pro potřeby tisku, navrhnout takové rozdělení do týmů, které zohledňuje zadaná integritní omezení, při nemožnosti splnění všech omezení navrhnout možnost, která porušuje nejmenší počet omezení. Možná omezení: minimální/maximální počet lidí v týmu, minimální/maximální počet lidí, kteří již byli ve stejném týmu, vynucení/zákaz konkrétních dvojic. Seznam odborné literatury Dodá vedoucí práce. Ing. Michal Valenta, Ph.D. vedoucí katedry prof. Ing. Pavel Tvrdík, CSc. děkan V Praze dne 11. ledna 2017

Bakalářská práce Mobilní nástroj pro správu skupin lidí Petr Panský Katedra softwarového inženýrství Vedoucí práce: Ing. Jan Baier 13. května 2018

Poděkování Rád bych poděkoval mému vedoucímu bakalářské práce Ing. Janu Baierovi za vedení mé bakalářské práce a cenné rady. Dále bych rád poděkoval mé rodině a přátelům, kteří mě během studia podporovali.

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ě, teritoriá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 alespoň srovnatelným způsobem a ve srovnatelném rozsahu, jako je zpřístupněn zdrojový kód Díla. V Praze dne 13. května 2018.....................

České vysoké učení technické v Praze Fakulta informačních technologií c 2018 Petr Panský. 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ředpisy 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 licencí 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 Panský, Petr. Mobilní nástroj pro správu skupin lidí. Bakalářská práce. Praha: České vysoké učení technické v Praze, Fakulta informačních technologií, 2018.

Abstrakt Tato práce se zabývá tvorbou mobilní aplikace pro platformu Android. Aplikace slouží ke správě skupin a jejich osob. Práce obsahuje analýzu požadavků, návrh, implementaci a testování aplikace. Součástí práce je i návrh a implementace algoritmu, který rozděluje skupinu osob na základě omezení a historie do týmů. Cílenou skupinou uživatelů jsou především pracovníci seznamovacích a teambuildingových agentur. Výsledná aplikace umožňuje přinést do procesu rozdělování přehlednost, jednoduchost a jistý řád. Klíčová slova algoritmus výběru z množin, mobilní aplikace, Android, teambuilding, týmy vii

Abstract The thesis is dealing with the creation of a mobile application for the Android framework. The application shall be used to manage groups and their members. The thesis contains requirements analysis, design, implementation and testing of the application. The thesis also contains a design and the implementation of the algorithm which divides a group of people into teams by defined restrictions and member s history. The target group of users are employees of teambuilding agencies. The final application makes the process of division well-arranged and simple. set selection algorithm, mobile application, Android, teambuil- Keywords ding, teams ix

Obsah Úvod 1 1 Analýza 3 1.1 Požadavky.............................. 3 1.2 Současná řešení........................... 5 2 Návrh 9 2.1 Technologie............................. 9 2.2 Databázový model......................... 12 2.3 Obrazovky aplikace......................... 14 2.4 Problematika rozdělování..................... 21 3 Implementace 25 3.1 Android framework......................... 25 3.2 Architektura aplikace....................... 28 3.3 RecyclerView............................ 33 3.4 DialogFragment........................... 36 3.5 Vytváření rozdělení......................... 37 4 Testování 41 4.1 Unit testy.............................. 41 4.2 Instrumentační testy........................ 42 4.3 Testy uživatelského rozhraní.................... 42 4.4 Testování doby běhu algoritmu.................. 43 Závěr 47 Literatura 49 A Seznam použitých zkratek 51 xi

B Obsah přiloženého CD 53 xii

Seznam obrázků 2.1 Databázový model........................... 13 2.2 Wireframe Seznam skupin...................... 15 2.3 Wireframe Přidání a editace skupiny................ 15 2.4 Wireframe Detail skupiny...................... 17 2.5 Wireframe Přidání a editace osoby................. 18 2.6 Wireframe Detail osoby....................... 18 2.7 Wireframe Vytvoření rozdělení................... 20 2.8 Wireframe Detail rozdělení..................... 21 3.1 Životní cyklus aktivity......................... 26 3.2 Životní cyklus fragmentu....................... 27 3.3 MVP model............................... 30 3.4 RecyclerView model.......................... 36 4.1 Doba běhu hledání rozdělení bez minimalizace opakování týmů.. 44 4.2 Doba běhu hledání rozdělení s minimalizací opakování týmů.... 45 xiii

Seznam tabulek 2.1 Jednotlivé verze Androidu....................... 10 xv

Úvod V internetových obchodech s aplikacemi pro mobilní chytrá zařízení je ke stažení velké množství aplikací různých kategorií. Od zábavných her, multimediálních přehrávačů, po aplikace, které se snaží lidem usnadnit jejich každodenní život. V této mase mobilních aplikací jsem ale nenašel aplikaci, která by pomáhala s organizací teambuildingovým agenturám. Teambuildingové agentury jsou v dnešní době velice populární. Pomáhají firmám utužit kolektiv a zlepšit vztahy uvnitř firmy. Nemusí se ale vždy jednat jenom o firmu. Při poznávání kolektivu mohou agentury často řešit problém, jak danou skupinu lidí rozdělit pro potřeby her do jednotlivých týmů. Při rozdělování v režii účastníků se často stává, že lidé, kteří se už znají, chtějí být spolu v týmu. Je ale lepší, když se rozdělí nahodile. Tímto způsobem nebudou vznikat izolované skupinky a lidé se mezi sebou lépe poznají. [1] Cíl práce Cílem práce je vyvinout mobilní aplikaci pro systém Android, která umožní rozdělovat lidi do týmů na základě zadaných parametrů. Aplikace je určena hlavně pro komunitu lidí, kteří často pořádají seznamovací, teambuildingové a jiné podobné akce. Mohou ji ale například využít i lidé, kteří pořádají různé hry a chtějí se rozdělit do týmů podle daných kritérií. Všem těmto lidem by měla aplikace přinést do rozdělování přehlednost, ale hlavně jednoduchost. Práce se nejdříve věnuje analýze funkčních a nefunkčnich požadavků. Po a- nalýze požadavků se zaměří na již existující aplikace, které jsou té mé podobné. Poté se práce přesouvá k návrhu aplikace, kde jsou popsány technologie, které budou použity, a je představen celkový návrh aplikace včetně problematiky rozdělování lidí do týmů. Poté se práce věnuje implementaci aplikace a jejímu otestování. 1

Kapitola 1 Analýza V této kapitole se věnuji analýze dat pro potřebu návrhu a implementace aplikace. Jako první krok před každým vývojem softwarového projektu, a vlastně před začátkem jakéhokoliv projektu, ať už se jedná o softwarový nebo třeba ekonomický projekt, je potřeba sesbírat data, která pomohou v dalších krocích realizace. Na základě těchto dat je možné posoudit, jak projekt uchopit a vyvíjet ho. Právě tato část je ve většině projektů klíčová a špatně zpracovaná analýza může celý projekt předurčit k neúspěchu. V oblasti vývoje softwaru jsou již několik let zavedeny doporučené postupy, jak při jeho vývoji postupovat. Prvním krokem je právě analýza dat. Do analýzy dat patří sběr funkčních a nefunkčních požadavků, modelování diagramu případů užití (anglicky use case diagram) a diagram aktivit. V práci jsem se zaměřil na funkční a nefunkční požadavky. Případy užití a diagram aktivit jsem pro tento projekt nevyužil. Použil bych ho u složitějších programů, kde by bylo potřeba namodelovat business procesy a byl by potřeba výsledný model toku řízení aktivit. 1.1 Požadavky Z konzultací s klientem se seberou data a na základě jejich analýzy je možné analyzovat požadavky na software. Poté se požadavky zanášějí do dokumentace. Zapisovat se mohou textově nebo v grafické podobě. Analýza požadavků pomáhá vymezit hranice, co všechno bude systém muset umět a jaké požadavky má klient na daný software. Také je důležité identifikovat všechny zúčastněné strany (stakeholdery), které se zapojují do procesů. Z požadavků lze částečně odhadnout náročnost projektu. Požadavky se dělí na 2 typy funkční a nefunkční. 3

1. Analýza 1.1.1 Funkční požadavky Funkční požadavky definují všechny hlavní nároky na funkcionalitu, které jsou kladeny na software, neboli specifikují, co má software umět. Jedná se o základní stavební kamen funkcionality softwaru. Tyto požadavky jsou měřitelné konkrétními prostředky, např. zda software uložil do databáze určitá data a následně je zobrazuje uživateli. Analýzou požadavků jsem dospěl k těmto funkčním požadavkům. 1.1.1.1 Přidání, editace a pojmenování skupin lidí Aplikaci bude obsahovat seznam skupin. Do tohoto seznamu bude možné přidávat nové skupiny. Skupina je uskupení, které obsahuje osoby. Zároveň by měla jít skupina editovat a případně smazat ze seznamu, aby se uživateli již nezobrazovala. Při přidávání a editaci skupiny se mění vždy pouze název a popisek skupiny, který není povinný a slouží uživateli k uložení poznámky o skupině. 1.1.1.2 Přidání, editace a odebrání osoby ve skupině Každá skupina bude obsahovat seznam osob, které budou v této skupině. Do tohoto seznamu půjde přidávat nové osoby, se kterými se poté bude dále pracovat. Počet osob ve skupině není nijak omezen. Když už je osoba v seznamu, musí být možná editace jejích osobních údajů (jméno, příjmení, přezdívka). Stačí vyplnit alespoň jeden z těchto údajů. Osobu lze ze skupiny odstranit, pokud ještě nezačal proces rozdělování nebo nebyla součástí vytvořených rozdělení. 1.1.1.3 Rozdělení do týmů na základě vybraných omezení Nad každou skupinou bude možné provádět rozdělení osob podle zadaných omezení. Bude možné některé osoby do rozdělení nezahrnout. Po rozdělení vznikne vždy několik týmů, ve kterých budou vybrané osoby ze skupiny. Každá osoba může být maximálně v jednom týmu na jedno rozdělení. Omezení, která půjdou při rozdělení vybrat, jsou tato následující: 4 Počet osob v týmu / počet týmů Minimální počet osob v týmu Maximální počet osob v týmu Počet týmů Vynucení / Zákaz konkrétních dvojic zda spolu dané dvojice můžou nebo nemůžout být v jednom týmu Minimální počet osob, které již byly ve stejném týmu

1.2. Současná řešení 1.1.1.4 Histori rozdělení Každá skupina má seznam rozdělení, která byla vytvořena. Pro každé rozdělení z tohoto seznamu půjde zobrazit informace o něm. V detailu si uživatel bude moci zobrazit týmy, které jsou v tomto rozdělení, a osoby, které jsou v těchto jednotlivých týmech. 1.1.1.5 Možnost zobrazit si o dané osobě s kým byla v týmu a kolikrát Pro každou osobu ve skupině si bude možné na základě historie rozdělení zobrazit, s kým byla v týmu a kolikrát. 1.1.1.6 Vyobrazení rozdělení vhodné k tisku Pro každé rozdělení bude možné vytvořit tisknutelný PDF soubor. Zároveň bude možné vytvořit PDF soubor i pro všechna rozdělení, která v dané skupině proběhla. S těmito soubory bude možné dále nakládat dle uživatele. Například poslat přes email nebo nasdílet aplikaci pro tisk. 1.1.2 Nefunkční požadavky Nefunkční požadavky se od funkčních liší tím, že místo specifických funkcionalit softwaru definují jeho vlastnosti a omezení. Požadavky na vlastnosti musí být zadané tak, aby bylo možné jejich ověření. Na základě analýzy požadavků jsem specifikoval tyto nefunkční požadavky. 1.1.2.1 Platforma Android Aplikace musí být možné nainstalovat a spustit na mobilním zařízení s operačním systémem Android. 1.2 Současná řešení V rámci analýzy aplikace jsem se rozhodl prozkoumat pole již existujících mobilních aplikací, které jsou na trhu. Hledal jsem v obchodě s aplikacemi Google Play. Z vybraných 10 aplikací, které měly podobnou funkcionalitu, jsem vybral 3 příklady, které se nejvíce podobaly mému zadání, byly uživatelsky přivětivé a měly alespoň 1000 instalací na zařízení. V následující části bych rád tyto aplikace otestoval a porovnal po stránce jejich funkčnosti. 1.2.1 Team Maker[2] Hodnocení: 5,0 a 5 recenzí Počet instalací: více než 1 000 5

1. Analýza Vyžaduje Android: 5.0 a vyšší Tato aplikace mi přišla velice podobná. Uživatel může přidávat do seznamu osoby (jméno, pohlaví a skóre v jednotlivých činnostech, které se nadefinuje formou vztahu klíč hodnota). Pro generování týmů je několik možností, jak tým vygenerovat. Buď se použije seznamu osob a z něj si uživatel vybere ty, které chce do rozdělení zahrnout. Zadá počet týmů a vybere si, jestli generovat týmy náhodně, s vyrovnaným skórem, nebo s vyrovnaným počtem stejného pohlaví v každém týmu. Nebo vybere jenom počet osob a počet týmů. Vygenerované rozdělení se poté přidá do historie. Rozdělení je možné sdílet ve formě formátovaného textu. Postrádal jsem zde skupiny, abych mohl mít více skupin uživatelů od sebe oddělených. Aplikace působila intuitivně, při prvním otevření bylo jasné, kde co hledat. Jediné, co mi trochu vadilo, byla reklama, která se zobrazovala po dokončení před jeho zobrazením. 1.2.2 Random Team Generator[3] Hodnocení: 4,0 a 9 recenzí Počet instalací: více než 1 000 Vyžaduje Android: 4.2 a vyšší Uživatel si v aplikaci může přidat osoby (jména) do jednotlivých listů (skupin) a listy pojmenovat a upravovat. Při generování rozdělení si vybere skupinu, počet členů na tým a rozdělení se vygeneruje. Je možné také generovat rozdělení na základě celkového počtu osob (bez listu) a počtu členů týmu. Všechna rozdělení jsou prováděna náhodně. Oproti předešlé aplikaci je zde sice možnost vytváření skupin, ale chybí ukládání historie a sdílení vytvořených rozdělení. 1.2.3 Random Team Generator[4] Hodnocení: 4,3 a 64 recenzí Počet instalací: více než 10 000 Vyžaduje Android: 4.0 a vyšší Poslední vybraná aplikace má stejné jméno jako předešlá. Uživatel zde může přidávat uživatele v textové podobě do presetů (skupin). Před generováním rozdělení si jen vybere preset s uživateli, zadá počet týmů a následně je vygenerováno rozdělení, které je založeno na náhodném rozdělení uživatelů do týmů. Výsledek rozdělení se ale nikam neukládá a nelze ho tak zpětně dohledat. Výsledné rozdělení není možné sdílet, lze ho pouze prohlížet. Aplikace obsahuje reklamu v dolní části obrazovky ve formě proužku. Díky reklamě je tak obrazovka zmenšená. 6

1.2. Současná řešení 1.2.4 Závěr současných řešení Z vybraných aplikací se mi nejvíce zamlouval Team Maker, který mi připadal funkčností až na pár bodů nejvíce podobný mé aplikaci. Aplikace působila na uživatele přívětivě, navíc uměla rozdělení ukládat a sdílet. Naopak zbývající dvě aplikace mi přišly vhodné spíše na rychlé rozdělování osob na místě akce kvůli absenci uložení historie rozdělení. Vedoucí osoba by si před každou hrou vygenerovala nové rozdělení a osoby hned na místě rozdělila do příslušných týmů. 7

Kapitola 2 Návrh Kapitola se věnuje návrhu implementace aplikace. Nejdříve jsou popsány technologie a knihovny, které byly zvoleny jako vhodné pro použití při implementaci. Dále je zde popsán databázový model a jednotlivé návrhy obrazovek aplikace. 2.1 Technologie V této části jsou popsány jednotlivé technologie a knihovny. Technologie jsem volil na základě osobních zkušeností a recenzí od ostatních vývojářů. 2.1.1 Android framework Aplikace musí být spustitelná na zařízeních se systémem Android. Nabízí se proto dvě možná řešení. Jako první možnost se nabízelo použití frameworku pro mobilní vývoj, který umožňuje vytvořit mobilní aplikaci, která je spustitelná na více operačních systémech. Jedním z takovýchto frameworků je open-source projekt s názvem Xamarin. Tento nástroj umožňuje vývojářům vyvíjet aplikace pro 3 mobilní platformy najednou a tím zkrátit čas, který by potřebovali při vývoji aplikací pro každou z nich. Mezi podporované platformy patří Android, ios a Windows.[5] Při použití tohoto řešení by aplikace mohla být multiplatformní a oslovila by tak více uživatelů. Druhou možností je vývoj přímo pro platformu Android. Aplikace je vyvíjena v programovacím jazyce Java za použití Android Application Frameworku, který poskytuje speciální funkcionalitu, která je nutná pro běh v systému Android.[6] Tímto způsobem je napsána většina současných aplikací pro Android. Při rozhodování se, které řešení je lepší, jsem první možnost zamítl. Pro tuto práci jsem si vybral druhou možnost nativní aplikaci pro Android. Z nastudování dokumentace projektu Xamarin vyplynulo několik negativ. Prvním pro- 9

2. Návrh Tabulka 2.1: Jednotlivé verze Androidu[7] Verze Označení API Rozdělní 2.3.3-2.3.7 Gingerbread 10 0,3% 4.0.3-4.0.4 Ice Cream Sandwich 15 0,4% 4.1.x Jelly Bean 16 1,7% 4.2.x Jelly Bean 17 2,6% 4.3 Jelly Bean 18 0,7% 4.4 KitKat 19 12,0% 5.0 Lollipop 21 5,4% 5.1 Lollipop 22 19,2% 6.0 Marshmallow 23 28,1% 7.0 Nougat 24 22,3% 7.1 Nougat 25 6,2% 8.0 Oreo 26 0,8% 8.1 Oreo 27 0,3% blémem bylo omezení systémů, na kterých lze aplikaci vyvíjet a následně kompilovat. Pokud vývojář nepoužívá Mac OS, nelze vyvíjet pro mobilní zařízení ios, a pokud nepoužívá program Microsoft Visual Studio, nelze vyvíjet ani pro Windows zařízení. Další komplikací byl požadavek pro používání Xamarin Studia, jelikož toto vývojové prostředí funguje oficiálně pouze na systémech Windows a Mac OS.[5] 2.1.2 Minimální verze Android systém od svého vzniku prošel mnoha změnami. Všechny větší změny byly vždy publikovány vydáním nové nebo upgradem starší verze Androidu. Každá takováto verze Androidu měla i své označení levelem API. Čím vyšší verzi API má dané zařízení, tím víc má funkcionalit oproti předchozí verzi. Před začátkem jakéhokoliv projektu je nutné se rozhodnout, jakou minimální verzi API bude aplikace podporovat, neboli určit, od které verze Android systému bude možné aplikaci na zařízení nainstalovat. Při rozhodování jsem vycházel z analýzy četnosti 2.1 jednotlivých verzí Android OS od vývojářského týmu Androidu. Na základě této analýzy jsem se rozhodl nastavit minimální API level na hodnotu 19. Aplikaci tak podle průzkumu bude moci využít 94,3% potencionálních uživatelů a budu moci použít více funkcionalit, které by mi například API level 16 neumožňoval. 2.1.3 Android Studio Pro implementaci aplikace jsem vybral vývojové prostředí (IDE) Android Studio[8] vyvinuté firmou JetBrains ve spolupráci s Google. IDE vychází z vývojového prostředí IntelliJ IDEA, od kterého dědí všechny jeho funkcionality. 10

2.1. Technologie Oproti prostředí IDEA je ale připraveno k vývoji aplikací pro mobilní zařízení. Je v něm integrován emulátor zařízení, designér pro navrhování XML layoutů, zabudovaný Gradle pro kompilaci kódu a správu závislostí nebo prohlížeč jednotlivých logů (Logcat) aplikací a spousta dalších funkcionalit usnaďnující debugování běhu aplikace. 2.1.4 greendao V aplikaci je potřeba ukládat data lokálně v zařízení. Rozhodl jsem se data ukládat do lokální SQLite databáze na zařízení. K usnadnění práce s databází jsem vybral knihovnu greendao. GreenDAO je open source databázová knihovna.[9] K přístupu k databázi používá objektově relační mapování (ORM). ORM zajišťuje synchronizaci mezi objekty a jejich prezentaci v databázi, v případě greendao mezi objektem třídy v Javě a entitou v SQLite databázi. Knihovna umožňuje provádění základních CRUD operací nad každou tabulkou, modelování vztahů mezi jednotlivými objekty a zachovaní persistence dat. 2.1.5 ButterKnife ButterKnife[10] je knihovna, která v Androidu slouží k nalezení widgetů ve view a přiřazení jejich referencí do proměnných. Pomáhá tak kód zjednodušit a ušetřit řádky kódu. class ExampleActivity extends Activity { TextView name; Button button; } @Override public void oncreate(bundle savedinstancestate) { super.oncreate(savedinstancestate); setcontentview({r.layout.example_activity}); this.name = (TextView) findviewbyid(r.id.name); this.button = (Button) findviewbyid(r.id.button); } Listing 1: Aktivita bez použití ButterKnife Jak je vidět v ukázce 1 bez použití knihovny, v metodě aktivity oncreate se musí všechny widgety před jejich použitím namapovat na proměnné objektu třídy ExampleActivity. Toho docílíme tak, že je v této metodě najdeme přes metodu findviewbyid, nalezené objekty typu View přetypujeme na požadované a přiřadíme je příslušným proměnným. Proměnné tedy mají reference na nalezené widgety. 11

2. Návrh class ExampleActivity extends Activity { @BindView(R.id.name) TextView name; @BindView(R.id.button) Button button; } @Override public void oncreate(bundle savedinstancestate) { super.oncreate(savedinstancestate); setcontentview(r.layout.example_activity); ButterKnife.bind(this); } Listing 2: Aktivita s použití ButterKnife Naproti tomu v ukázce 2 s použitím knihovny se v metodě oncreate zavolá pouze ButterKnife.bind(this). Toto volání zařídí, že se jednotlivé widgety najdou a jejich reference se přiřadí do proměnných. Aby tohoto kroku bylo možné docílit, je potřeba u každé proměnné, do které se má přiřadit reference widgetu, udělat dvě věci: Definovat správný typ proměnné TextView, Button, ImageView,... Přidat anotaci @BindView(ID), kde ID je identifikační číslo widgetu ve view. 2.1.6 itext Pro potřebu vyobrazení rozdělení vhodné k tisku jsem se rozhodl použít knihovnu itext[11]. Konkrétně její Android verzi, která využívá starší knihovnu verze 5.0. Knihovna umožňuje vytvořit dokument a přidávat do něj jednotlivé elementy jako jsou nadpisy, texty, tabulky, obrázky, aj. a upravovat jejich parametry (velikost, font, padding, margin,... ). Knihovna je dostupná pro Android, Java projekty (pomocí Maven dependencies nebo.jar archiv) a.net. 2.2 Databázový model Na obrázku 2.1 je vidět návrh databázového modelu. Android zařízení používají databáze SQLite a při návrhu databáze bylo potřeba s touto informací počítat. SQLite databáze totiž umožňuje použít pouze 5 datových typů[12]: 12 NULL nulová hodnota INTEGER celé číslo REAL desetinné číslo

2.2. Databázový model id name description groups integer text text id name surname nickname group_id users integer text text text integer divisions id integer group_id integer created_at integer type_division integer user_pairs user_divisions id integer id integer user1_id integer userid integer user2_id integer divisionid integer division_id integer same_team integer id division_id name teams integer integer text id user_id team_id user_teams integer integer integer Obrázek 2.1: Databázový model TEXT textový řetězec BLOB obecná data v binárním tvaru Navržený databázový model obsahuje celkem 7 entit: Groups Jedna z hlavních entit. Reprezentuje jednotlivé skupiny a obsahuje vždy název skupiny a případně nějakou poznámku (popis) o skupině. Na tuto entitu jsou napojené další entity pomocí cizích klíčů. Users Entita Users reprezentuje jednotlivé osoby ve skupině. Obsahuje alespoň jeden z údajů jméno, příjmení a přezdívka. Dále musí vždy obsahovat ID skupiny, do které osoba patří, aby bylo možné skupinu identifikovat. Divisions Tato entita reprezentuje rozdělení skupiny. Obsahuje ID skupiny, ke které rozdělení patří, čas vytvoření rozdělení a typ rozdělení (počet týmů, minimální nebo maximální počet osob v týmu). Teams Entita reprezentuje týmy jednotlivých rozdělení. Obsahuje ID rozdělení a název týmu. 13

2. Návrh UserTeams Entita umožňující vztah M:N mezi Teams a Users. Na základě této pomocné entity je rozdělen vztah na 1:N a 1:M. Obsahuje ID uživatele a ID týmu. UserDivisions Tato entita slouží k reprezentaci konfigurace rozdělení, přesněji k záznamu vybraných uživatelů do rozdělení. Pro každého uživatele v rozdělení se zde vytvoří záznam s ID uživatele a ID rozdělení. UserPairs Tato entita umožňuje zapamatovat si pro každé rozdělení nakonfigurované páry. Každý pár je reprezentován ID číslem obou osob, ID rozdělením a informací, zda mají být osoby z páru ve stejném nebo rozdílném týmu. Každá z těchto tabulek má samozřejmě vlastní identifikátor typu integer s autoinkrementem. Tzn. že při vkládání záznamu bez ID se záznamu přiřadí hodnota z autoinkrementu. Po vložení takovéhoto záznamu se hodnota autoinkrementu zvětší o 1 a pro další vkládání do stejné tabulky bude identifikátor nového záznamu o 1 větší. 2.3 Obrazovky aplikace V rámci návrhu jsem se zaměřil i na jednotlivé obrazovky aplikace. Na základě analýzy jsem identifikoval obrazovky, které bude potřeba v aplikaci vytvořit. Pro každou identifikovanou obrazovku jsem vymezil její funkcionalitu a detailně ji popsal níže. 2.3.1 Seznam skupin Seznam skupin 2.2 bude defaultní obrazovka, která se zobrazí po spuštění aplikace. Uživatel v ní uvidí seznam existujících skupin řazený abecedně. Pro každou skupinu (položku seznamu) bude možné přejít do obrazovky s detaily skupiny. Z této obrazovky půjde také přejít na přidávání nové skupiny. 2.3.2 Přidání a editace skupiny V této obrazovce 2.3 bude možné přidávat novou skupinu nebo editovat již existující. Upravovat půjde název skupiny a případně její popis, ten ale na rozdíl od názvu skupiny nebude nutné vyplnit. Po vyplnění potřebných údajů bude možné skupinu vytvořit (uložit změny existující). Po tomto kroku bude uživatel přesměrován do seznamu skupin (detailu existující skupiny). Vytváření skupiny (editaci existující skupiny) bude možné kdykoliv přerušit a vrátit se na předešlou obrazovku. 14

2.3. Obrazovky aplikace 12:00 Rozdělovač skupin Skupina 1 Skupina 2 Skupina 3 Skupina 4 Skupina 5 Skupina 6 Skupina 6 Obrázek 2.2: Wireframe Seznam skupin 12:00 12:00 Přidat skupinu ULOŽIT Upravit skupinu ULOŽIT Název skupiny Název skupiny Skupina 1 Popis skupiny Popis skupiny q w e r t y u i o p a s d f g h j k l z x c v b n m?123,. q w e r t y u i o p a s d f g h j k l z x c v b n m?123,. Obrázek 2.3: Wireframe Přidání a editace skupiny 15

2. Návrh 2.3.3 Detail skupiny Obrazovka detail skupiny 2.4 bude jedna z nejvíce používaných obrazovek, půjde z ní totiž spravovat nejvíce údajů. Z menu bude možné přejít na úpravu skupiny, sdílet generovaný soubor se všemi rozděleními nebo odstranit celou skupinu a vrátit se na seznam skupin. Bude obsahovat celkem tři záložky (taby), mezi kterými bude bude možné přepínat. Záložky jsou následující: Popis V tomto tabu bude možné zobrazit název a popis skupiny. Rozdělení V záložce rozdělení půjde zobrazit seznam již vygenerovaných rozdělení a přejít do detailu jednotlivých rozdělení. Půjde zde ale i přejít na generování nového rozdělení. Osoby V této části bude možné zobrazit seznam osob ze skupiny, v jejímž detailu právě uživatel je. Půjde přejít do detailu konkrétní osoby nebo na vytvoření nové osoby. 2.3.4 Přidání a editace osoby V této obrazovce 2.5 bude možné přidávat novou osobu do skupiny nebo editovat již existující. Upravovat půjde jméno, příjmení a přezdívka. Vždy musí být vyplněný minimálně jeden z těchto údajů. Po vyplnění údajů půjde osobu vytvořit (upravené změny uložit existující osobě). Po tomto kroku bude uživatel přesměrován do detailu skupiny, konkrétně zpět do záložky osob. Přidávání nové osoby (editaci existující osoby) půjde kdykoliv přerušit a vrátit se na detail skupiny. 2.3.5 Detail osoby Pro zobrazení detailu osoby ze skupiny slouží právě tato obrazovka 2.6. Zde se zobrazí název prohlížené osoby a seznam ostatních osob ze skupiny s číslem informujícím uživatele o tom, kolikrát byla osoba s danou osobou ze skupiny v týmu. Z této obrazovky půjde přejít do editace osoby. Bude možné ji i odstranit za určitých podmínek. Pokud tak nepůjde učinit, bude uživatel informován. Po dokončení prohlížení se uživatel vrátí zpět na detail skupiny, do záložky osoby. 2.3.6 Vytvoření rozdělení Pro konfiguraci a vytvoření rozdělení bude sloužit tato obrazovka 2.7. Výběr konfigurace rozdělení jsem se v této obrazovce rozhodl rozdělit do tří kroků, aby ovládání bylo více přehledné. 16

2.3. Obrazovky aplikace 12:00 12:00 Skupina 1 Skupina 1 POPIS ROZDĚLENÍ OSOBY Název skupiny Skupina 1 Popis skupiny Toto je skupina s číslem 1 lorem ipsum lorem ipsum lorem ipsum lorem ipsum lorem ipsum lorem ipsum lorem ipsum POPIS ROZDĚLENÍ OSOBY před 1 hodinou včera 13:45 10. února 2018 17:45 10. února 2018 17:45 10. února 2018 17:45 10. února 2018 17:45 10. února 2018 17:45 10. února 2018 17:45 10. února 2018 17:45 10. února 2018 17:45 10. února 2018 17:45 10. února 2018 17:45 10. února 2018 17:45 10. února 2018 17:45 12:00 12:00 Skupina 1 Skupina 1 Upravit POPIS ROZDĚLENÍ OSOBY Petr Lukáš J. Honza Lumček Bořivoj Javorský Sandra Stehlíková Smazat POPIS ROZDĚLENÍ OSOBY Název skupiny Skupina 1 Vytisknout / Sdílet rozdělení Popis skupiny Toto je skupina s číslem 1 lorem ipsum lorem ipsum lorem ipsum lorem ipsum lorem ipsum lorem ipsum lorem ipsum Justýna Hasalová Teodor Lukyč Metoděj Václavek Daniela Tylová Milan Šrubař Zoe Smolová Zikmund Kročil 10. února 2018 17:45 Obrázek 2.4: Wireframe Detail skupiny 17

2. Návrh 12:00 12:00 Přidat osobu ULOŽIT Upravit osobu ULOŽIT Jméno Jméno Teodor Příjmení Příjmení Přezdívka Přezdívka q w e r t y u i o p a s d f g h j k l z x c v b n m?123,. q w e r t y u i o p a s d f g h j k l z x c v b n m?123,. Obrázek 2.5: Wireframe Přidání a editace osoby 12:00 12:00 Teodor Teodor Upravit Petr 4x Petr Smazat 4x Lukáš J. 3x Lukáš J. 3x Honza Lumček 5x Honza Lumček 5x Bořivoj Javorský 5x Bořivoj Javorský 5x Sandra Stehlíková 2x Sandra Stehlíková 2x Justýna Hasalová 1x Justýna Hasalová 1x Lukyč 0x Lukyč 0x Metoděj Václavek 6x Metoděj Václavek 6x Daniela Tylová 2x Daniela Tylová 2x Milan Šrubař 3x Milan Šrubař 3x Zoe Smolová 4x Zoe Smolová 4x Zikmund Kročil 4x Zikmund Kročil 4x 10. února 2018 17:45 10. února 2018 17:45 Obrázek 2.6: Wireframe Detail osoby 18

2.3. Obrazovky aplikace 1. Výběr osob V této části půjde vybrat osoby ze skupiny, které chceme do rozdělení zahrnout. Musí být vybrané alespoň nějaké osoby. Poté přejde uživatel na další krok. Pokud výběr nesplňuje podmínky, bude uživatel při přechodu na další krok upozorněn a zůstane na aktuálním kroku. Při návratu zpět se vrátíme do detailu skupiny, konkrétně do záložky rozdělení. 2. Přidání párů Zde můžeme vidět seznam párů z osob, které spolu mají či nemají být. Můžeme zde také pár přidat. Otevřeme si dialogové okno, zvolíme osoby do páru, vybereme, zda mají být ve stejném nebo rozdílném týmu, a přidáme je. Pokud pár může být přidán, přidá se do seznamu a seznam se aktualizuje. V opačném případě se uživateli zobrazí upozornění s instrukcemi. Páry ze seznamu je také možné odstranit. Můžeme přejít na další krok. Při kroku zpět se dostaneme na předchozí krok. 3. Vlastnosti V posledním kroku vybereme omezení rozdělení. Na výběr máme mezi počtem týmů, minimálním a maximálním počtem osob v týmu. Po výběru vyplníme hodnotu, která přísluší vybranému typu omezení. Také můžeme vybrat, zda chceme minimalizovat opakování podobných týmů na základě historie. Můžeme přejít k samotnému generování rozdělení. Pokud jsme vyplnili všechny vlastnosti správně, aby mohlo být rozdělení uskutečněno, rozdělení se vygeneruje, aplikace informuje uživatele a přejde zpět do detailu skupiny, do záložky rozdělení. Při nemožnosti vytvořit tým kvůli špatné konfiguraci uživatele informuje, proč nemohlo k rozdělení dojít. Při návratu zpět z tohoto kroku se dostaneme do kroku přidání párů. 2.3.7 Detail rozdělení Pro zobrazení detailu rozdělení skupiny využijeme tuto obrazovku 2.8. Zobrazí se seznam týmů se zanořenými členy jednotlivých týmů. Můžeme zde rozdělení odstranit nebo sdílet vygenerovaný soubor s rozdělením ostatním aplikacím. Po skončení prohlížení se vrátíme zpět do detailu skupiny, do záložky rozdělení. 19

2. Návrh 12:00 12:00 Vyberte osoby DALŠÍ Přidejte páry DALŠÍ Petr Lukáš J. Honza Lumček Bořivoj Javorský Sandra Stehlíková Teodor Lukáš J. Honza Lumček Rozdílný tým Stejný tým x x Sandra Stehlíková Justýna Hasalová Teodor Lukyč Metoděj Václavek Daniela Tylová Milan Šrubař Zoe Smolová Zikmund Kročil 12:00 12:00 Přidejte páry DALŠÍ Vyberte vlastnosti GENEROVAT Sandra Stehlíková Teodor Lukáš J. Honza Lumček Rozdílný tým Stejný tým Přidat pár Metoděj Václavek x x Vyberte omezení Počet týmů Minimální počet v týmu Maximální počet v týmu Zoe Smolová Počet týmů 5 Tým Stejný PŘIDAT Rozdílný Minimalizovat opakování podobných týmů na základě historie Obrázek 2.7: Wireframe Vytvoření rozdělení 20

2.4. Problematika rozdělování 12:00 12:00 Detail rozdělení Smazat Detail rozdělení Tým 1 Petr Lukáš J. Honza Lumček Tým 2 Bořivoj Javorský Sandra Stehlíková Justýna Hasalová Teodor Tým 3 Lukyč Metoděj Václavek Tým 1 Petr Lukáš J. Honza Lumček Tým 2 Bořivoj Javorský Sandra Stehlíková Justýna Hasalová Teodor Tým 3 Lukyč Metoděj Václavek Vytisknout / Sdílet rozdělení Daniela Tylová Milan Šrubař 10. února 2018 17:45 Daniela Tylová Milan Šrubař 10. února 2018 17:45 Obrázek 2.8: Wireframe Detail rozdělení 2.4 Problematika rozdělování Jednou z hlavních částí této práce je i návrh a implementace algoritmu pro rozdělování osob do týmů. Tento algoritmus dle zadaných omezení najde vhodné rozdělení osob, které porušuje co nejméně zadaných omezení. 2.4.1 Omezení 2.4.1.1 Počet a velikost týmů Pro rozdělení půjde vybrat vždy jedno z těchto omezení. Při procesu vytváření týmů pak toto omezení nebude možné porušit. Všechna tato omezení se týkají počtu týmů a počtu osob v týmu. Na jejich základě se určuje počet týmů a přibližný počet osob v týmech tak, aby týmy byly početně vyrovnané. Omezení jsou následující: Počet týmů Tímto omezením se definuje počet týmů v rozdělení. Na základě počtu týmů se vypočítávají velikosti jednotlivých týmů. Minimální počet osob v týmu Pokud má být v každém týmu definovaný minimální počet osob, použije se právě toto omezení. Na základě minimálního počtu osob v týmu se dopočítávají velikosti týmu a jejich počet. Maximální počet osob v týmu Toto omezení slouží k definování maximálního počtu osob v každém týmu. Z tohoto maxima se dopočítají počty týmů a jejich velikosti. 21

2. Návrh 2.4.1.2 Osoby v páru Toto omezení slouží k vynucení nebo zakázání konkrétních dvojic v rozdělení. Pokud uživatel chce, aby Osoba1 a Osoba2 byly ve stejném týmu, při hledání ideálního rozdělení se algoritmus bude snažit, aby tyto osoby byly spolu v jednom týmu. Naopak, pokud nechce, aby tyto osoby spolu nebyly, algoritmus se bude snažit, aby každá osoba z páru byla v jiném týmu. 2.4.1.3 Minimalizace opakování týmů Tímto omezením lze vynutit, aby se algoritmus pokusil přidávat osoby do týmu s těmi, se kterými ještě ve stejném týmu nebyly nebo se kterými byly dosud nejméněkrát. 2.4.2 Algoritmus hledání rozdělení Při návrhu vhodného algoritmu vyšlo najevo, že problematika rozdělení osob do skupin podle určitých omezení je mnohem složitější, než se na první pohled zdálo. Pokusil jsem se problém rozdělení na základě historie namapovat na nějaký známý grafový problém, který se zabývá podobnou problematikou. Před dalším postupem je nejprve potřeba zadefinovat některé pojmy z oblasti grafů. Neorientovaný graf s ohodnocenými hranami je uspořádaná dvojice (V, E), kde V je neprázdná konečná množina vrcholů, E je množina hran a w R je váhová funkce, která přiřazuje hranám čísla jejich váhy. [13] Problém rozdělení lze převést do grafu, kde jednotlivé osoby jsou vrcholy. Mezi každými dvěma osobami je hrana s touto vahou: Osoby v páru stejný tým, hrana má hodnotu 20. Osoby v páru rozdílný tým, hrana má hodnotu 20. Pokud osoby nejsou definované jako pár: Minimalizace opakování ano hrana má hodnotu takovou, kolikrát osoba byla s druhou ve stejném týmu, ale zápornou Minimalizace opakování ne hrana má hodnotu 0. Vznikne tedy graf G, kde každý vrchol má hranu do všech ostatních. Nyní chceme graf rozdělit tak, aby platilo následující: V = N 1 N 2 N 3 N i, a kde N a = V b V c V e. Zároveň pro každé N a a N b platí N a N b =. Graf je třeba nyní rozdělit tak, aby všechny části N splňovaly podmínku, že budou mít stejný nebo podobný počet vrcholů a zároveň součet hran mezi vrcholy ve skupině bude vyrovnaný ostaním součtům skupin. 22

2.4. Problematika rozdělování Při těchto podmínkách lze problém namapovat na Graph Partition Problem. Jedná se o téměř totožný problém rozdělení vrcholů s hranami do skupin, které budou mít součet hran vyvážený vůči ostatním skupinám. Bohužel tento problém patří do skupiny NP-úplných problémů[14]. Tyto problémy nemájí řešení v polynomiálním čase. 2.4.2.1 Navržený algoritmus Kvůli absenci řešení v polynomiálním čase a s co nejoptimálnějším rozdělením jsem se rozhodl navrhnout vlastní algoritmus. Nesplní vždy podmínku, že dané rozdělení porušuje nejméně omezení, vždy se ale tomuto řešení alespoň částečně přiblíží. Běh algoritmu lze rozdělit celkem do čtyř částí: 1. Vytvoří týmy podle omezení počtu týmů/osob. 2. Vytvoří skupiny z osob, které chtějí být spolu ve stejném týmu na základě definovaných párů. Všechny tyto skupiny seřadí od největší po nejmenší a přidá je do fronty. Dokud není fronta prázdná, vždy odebere první skupinu z fronty a pokusí se pro ni na základě volných míst, počtu porušených omezení (příp. historie, pokud je nastavena minimalizace) najít nejvíce vyhovující tým/y. Pokud najde vyhovující tým/y, vybere jeden z nich a do něho přidá skupinu osob. V situaci, kdy nelze přidat celou skupinu do žádného týmu kvůli velikosti, rozdělí skupinu na dvě části a obě části přidá na konec fronty. 3. Přidá všechny osoby, které ještě nejsou v týmech do fronty. Dokud není fronta prázdná, vždy odebere první osobu z fronty a na základě volných míst, počtu porušených omezení (příp. historie, pokud je nastavena minimalizace) najde nejvíce vyhovující tým/y. Z vyhovujících týmů vybere jeden a do něho přidá osobu. 4. Když jsou všechny osoby rozděleny v týmech, provede maximálně 10 následující operaci: Pro každou osobu z každého týmu otestuje, zda je možné ji vyměnit s jinými osobami z ostaních týmů. Pokud bude součet porušených omezení v obou týmech nižší, vymění osoby mezi týmy. V situaci, kdy je nastavená minimalizace, kontroluje v případě shodného součtu porušených omezení, zda výměnou uživatelů nedosáhne lepší minimalizace opakování týmu a popřípadě uživatele vymění. Pokud se během tohoto opakování nevymění žádný uživatel, o další opakování se již nepokouší. 23

Kapitola 3 Implementace 3.1 Android framework Framework umožňuje vývoj mobilních aplikací pro systém Android. Poskytuje přístup k funkcionalitám systému a umožňuje jejich použití v kódu. Spolu s jazykem Java lze tak vyvíjet aplikace. Každá aplikace se skládá z některých základních komponent, které tvoří její základ[15]. Existují celkem čtyři takovéto komponenty: Activities Každá aktivita reprezentuje jednu obrazovku, kterou lze zobrazit na zařízení a umožňuje interakci s uživatelem. Např. vyplnění formuláře nebo prohlížení seznamu. Services Služba, která nemá UI a běží na pozadí aplikace. Je určena pro operace, které běží delší dobu. Např. stahování souborů. Broadcast Receivers Komponenta, která umožňuje poslouchat zprávy z aplikace, z ostatních aplikací a zprávy přímo od systému. Např. systémová zpráva o stavu nízké baterie. Content Providers Manager, který umožňuje uchovávat data v paměti telefonu, v databázi, na webu nebo na jiném uložišti, ke kterému má zařízení přístup. Všechny komponenty zmíněné výše se musejí deklarovat v souboru AndroidManifest.xml. Dále se rozepíši pouze o komponentě Activities, ostatní komponenty v aplikaci nebylo potřeba použít. 3.1.1 Aktivity Jak již bylo zmíněno, aktivita je jeden z hlavních stavebních kamenů aplikace. Aktivita je v Androidu jedna obrazovka, kterou zařízení uživateli zobrazí. Aplikace musí mít minimálně jednu aktivitu, většinou jich má ale několik. 25

3. Implementace Obrázek 3.1: Životní cyklus aktivity[16] Aplikace pomocí těchto aktivit reaguje s uživatelem a zobrazuje mu data pomocí jejího uživatelského rozhraní. Každá aktivita má svůj životní cyklus, kterým si projde od doby vzniku po její konec. Životní cyklus aktivity můžeme vidět na obrázku 3.1. 3.1.2 Fragmenty Kromě aktivit je tu další komponenta, kterou je možné použít pro komunikaci s uživatelem přes uživatelské rozhraní. Jedná se o fragment. Fragment má za úkol starat se o celky menší než aktivita. Většinou se jedná o určitý funkční celek, který chce vývojář odstínit od konkrétní aktivity a případně ho použít ve více aktivitách. Díky fragmentům se tak kód nebude duplikovat. Vývojář 26

3.1. Android framework Obrázek 3.2: Životní cyklus fragmentu[17] implementovaný fragment poté přidá do aktivity, do které bude chtít. Aktivita může obsahovat i více fragmentů najednou. Využití fragmentů je vidět na příkladu s emailovou aplikací. Uživatel má jedno zařízení s malým displejem (např. telefon) a jedno zařízení s velkým displejem (např. tablet). Na telefonu se mu zobrazí aktivita MainActivity a v ní bude fragment MailListFragment se seznamem emailů. Po kliknutí na položku seznamu se spustí druhá aktivita MailDetailActivity a v té bude fragment MailDetailFragment s detaily emailu. Oproti tomu na tabletu se mu zobrazí aktivita MainActivity. V kódu aktivity se detekuje široký displej a v aktivitě se zobrazí dva fragmenty. Vlevo na třetině displeje bude seznam emailů ve fragmentu MailListFragment a na zbylé pravé části displeje bude detail vybraného emailu ve fragmentu MailDetailFragment. Také fragmenty mají životní cykly jako aktivita, viz obrázek 3.2. Fragment je ale s aktivitou, ve které se momentálně nachází, svázán, a tak jeho životní cyklus závísí i na aktuálním stavu aktivity. Toto jde pozorovat třeba na metodě onactivitycreated z cyklu fragmentu. 3.1.3 Widgety Aby aktivity a fragmenty mohly uživateli zobrazovat data, potřebují k tomu základní komponenty k zobrazení neboli widgety. (Ty jsou často chybně zaměňovány za App Widgety, což jsou widgety, které je možné umístit na domovskou plochu zařízení a umožnit tak uživateli rychlou interakci s aplikací přímo z plochy.) Tyto widgety jsou komponenty, které rozšiřují defaultního wi- 27

3. Implementace dget View. Jedná se o základní stavební komponenty, které jsou umisťovány do aktivit a fragmentů. Patří sem například: TextView jednoduchý text k zobrazení EditText zadávání textu, podobnost s input z html ImageView zobrazení obrázku Button tlačítko LinearLayout widget, do kterého je možné umísťovat další widgety K tomu, aby byly widgety do aktivit a fragmentů umístěny, slouží XML soubory s layouty. Každý takovýto XML soubor musí mít hlavní widget, např. LinearLayout, RelativeLayout, FrameLayout,... Do hlavních widgetů lze vkládat jednotlivé widgety s jejich parametry (velikost, umíštění, margin, padding, barvy,... ). Tento XML soubor se poté nastaví aktivitě nebo fragmentu jako její vzhled. Struktura XML souboru je vidět na ukázce 3. V ukázce je nejprve LinearLayout. Do tohoto widgetu lze přidávat potomky, které se v něm zobrazí. V LinearLayoutu jsou dále dva TextView widgety. Tyto widgety slouží k zobrazení textu. Na obrazovce se tak zobrazí texty obou TextView pod sebou, a to díky atributu android:orientation="vertical" v LinearLayoutu. <LinearLayout xmlns:android="http://schemas.android.com/apk/res/android" android:layout_width="match_parent" android:layout_height="wrap_content" android:orientation="vertical"> <TextView android:layout_width="match_parent" android:layout_height="wrap_content" android:text="hello" /> <TextView android:layout_width="match_parent" android:layout_height="wrap_content" android:text="world!" /> </LinearLayout> Listing 3: Ukázka XML layoutu 3.2 Architektura aplikace Před začátkem implementace se objevila otázka, jakou architekturu pro implementaci zvolit. Bylo na výběr z několika možností. 28

3.2. Architektura aplikace Jako nejjednodušší architektura na implementaci se nabízela defaultní achitektura Android aplikace. V jejím případě použití uživatel reaguje s aktivitou či fragmentem. Veškerá logika aplikace je tak implementována právě ve třídách aktivit a fragmentů. Třídy těchto komponent mají hodně řádků, všechnu aplikační logiku v třídě aktivity nebo fragmentu a pro nového programátora v projektu jsou složité k orientaci a pochopení. Zároveň je třeba ošetřit kritické situace. Mezi takovéto situace patří asynchronní načítání dat z internetu a následné zobrazení v aktivitě. Pokud se během načítání otočí obrazovka, aktivita se pozastaví a následně spustí. Nebo se může celá aktivita restartovat. A přesně takovéto situace je potřeba vždy ošetřit. Tímto směrem jsem se vydat nechtěl. Rozdhodl jsem proto využít architekturu MVP. 3.2.1 MVP Model-View-Presenter je architektonický vzor, který vychází ze vzoru Model- View-Controller. Tento vzor pomáhá s implementací uživatelského rozhraní. A přestože vychází z MVC, v některých funkcionalitách se od MVC liší. V MVP vzoru jsou tři komponenty: Model Model reprezentuje data a práci s nimi (databáze, API,... ). View Komponenta, která umožňuje interakci s uživatelem. Zobrazuje data, která mu předá Presenter. Zároveň reaguje na všechny uživatelské akce a předává je do Presenteru. Presenter Presenter je zprostředkovatel mezi Model a View. Zpracovává data z Modelu a posílá je do View k zobrazení. Zároveň zpracovává delegované uživatelské akce z View. Akci přijme, data z ní zpracuje a v případě požadavku opět pošle data do View pro úpravu pohledu. Celý model MVP je k vidění na obrázku 3.3, kde jsou znázorněné jednotlivé vazby mezi komponentami. 3.2.1.1 Řešení MVP pro Android Po zvolení MVP architektury je nutné ji implementovat přímo pro Android zařízení. Myšlenka zůstává stejná jako u obecného vzoru. Jako View komponenta vystupuje Aktivita nebo Fragment. Tyto komponenty implementují interface pro vlastní View. Toto rozhraní má definované metody, které pomáhájí se zobrazováním dat a posíláním eventů do Presenteru. View obsahuje referenci na svůj Presenter, do které posílá eventy. Tento Presenter má v sobě referenci na View, ale pouze ve formě rozhraní, aby nemohl přistupovat k dalším metodám, které aktivita nebo fragment nabízejí. Může tak používat pouze veřejně vystavené metody přes toto rozhraní. Pomocí těchto metod zobrazuje data 29

3. Implementace Presenter Model changed User actions Update model Update UI Model View Obrázek 3.3: MVP model uživateli a reaguje na dané eventy. Při zániku aktivity či fragmentu zaniká i Presenter, který se o dané View stará. Do této chvíle se většina implementací MVP pro Android příliš neliší. Problém nastává při změně konfigurace aktivity (otočení displeje, změna jazyka na telefonu,... ). Aktivita se při změně konfigurace restartuje a to by znamenalo, že starý Presenter zanikne a vytvoří se nový s defaultními daty. Nebyla by tedy zachována persistence uložených dat v Presenteru. První možností by bylo použít při každém restartu aktivity metodu on- SaveInstanceState a v té data z Presenteru uložit. Poté je po restartu z uložené instance získat a poslat novému Presenteru. Bohužel ukládání dat v této metodě funguje pouze pro základní objekty Javy jako jsou Integer, Long, String, pole String hodnot, apod. Pro objekty vlastních tříd by bylo třeba, aby třídy implementovaly rozhraní Parcelable. Zároveň by bylo složité řešit ukládání referencí na běžící asynchronní procesy na pozadí. Toto řešení bylo proto zavrhnuto. Dalším možným řešením bylo ukládat referenci na Presenter někde v aplikaci a při změně konfigurace aktivity ji uložit a poté ji opět načíst. Řešením by bylo udělat referenci na Presenter jako statickou proměnnou. Problém ale nastává, pokud aplikace poběží na pozadí a zařízení bude mít málo paměti RAM. Aktivita bude odsunuta na pozadí a při této akci se nastaví statické proměnné do jejich defaultních hodnot. V tomto případě to znamená, že bude reference na Presenter ztracena a nebude možné ji získat zpět. Rozhodl jsem se proto pro podobné řešení, ale s jiným typem ukládání referencí. Toto řešení využívá k ukládání referencí na Presenter Loaders. Loaders jsou nástroje, které poskytuje Android framework, a dokážou přežít změnu konfigurace. Jejich životní cyklus je řízen systémem a jsou automaticky odstraněny, když je jejich aktivita nebo fragment na trvalo zničen [18][Překlad 30

3.2. Architektura aplikace vlastní]. Loaders jsou defaultně určeny k načítání dat asynchronně ve vlastním vlákně pro aktivitu nebo fragment. Například k načítání seznamu položek z databáze. V tomto případě jsou Loaders využity pro ukládání reference na Presenter z aktivity nebo fragmentu. Toto řešení je převzaté od autora tohoto článku[18] a je nepatrně upraveno. 3.2.1.2 Implementace MVP pro Android Jednou ze základních tříd pro užití MVP je třída Presenter. Jedná se o abstraktní třídu. Třída obsahuje referenci na View mview a metody onviewattached a onviewdetached. Reference na View je generického typu. Díky tomu lze nadefinovat defaultní Presenter třídu a konkrétní Presentery budou od tohoto Presenteru pouze dědit. Zbylé dvě metody slouží pro uložení a zrušení reference na View. Protože Presenter žije i při změně konfigurace, je třeba mu odebrat referenci na View. V době konfigurace aktivity nebo fragmentu není View dostupné a nelze na něm provádět změny v UI. Došlo by totiž k pádu aplikace. Metoda onviewattached slouží k uložení reference na View a metoda onviewdetached slouží k zničení reference. Implementaci Presenteru lze vidět na ukázce 4. public abstract class Presenter<V> { protected V~mView; public void onviewattached(@nonnull V~view){ mview = view; }; public void onviewdetached(){ mview = null; } } Listing 4: Abstraktní třída Presenteru Další důležitou třídou je PresenterLoader. Díky této tříde je možné Presenter aktivity nebo fragmentu uložit při změně konfigurace a následně ho obnovit. V konstruktoru se uloží PresenterFactory, která umí vytvořit konkrétní Presenter. V metodě onstartloading se ověří, zda Presenter existuje. Pokud ano, pošle se Presenter aktivitě nebo fragmentu. V opačném případě se vynutí metodou forceload jeho vytvoření. Toto zavolání odchytí systém a zavolá metodu onforceload, která vytvoří Presenter a pošle ho dál. Více v ukázce 5. Posledními třídami pro správné fungování MVP jsou třídy BasePresenter- Activity pro aktivity a BasePresenterFragment pro fragmenty. V těchto třídách je implementováno vytvoření Presenteru pomocí třídy PresenterLoader. 31