%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%% I, the copyright holder of this work, release this work into the
%% public domain. This applies worldwide. In some countries this may
%% not be legally possible; if so: i~grant anyone the right to use
%% this work for any purpose, without any conditions, unless such
%% conditions are required by law.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\documentclass[
  digital,    
  color,
  oneside,
  nosansbold,
  nocolorbold,
  lof,        
  nolot,      
]{fithesis4}

\usepackage[main=czech]{babel} %% foreign texts to be typeset as follows:
\usepackage{paratype}

%% The following section sets up the metadata of the thesis.
\thesissetup{
    date        = \the\year/\the\month/\the\day,
    university  = mu,
    faculty     = fi,
    type        = mgr,
    author      = Matěj Novotný,
    gender      = m,
    advisor     = {RNDr. Vít Rusňák, Ph.D.},
    department  = {Katedra vizuální informatiky},
    title       = {Vývoj multiplatformních mobilních aplikací v~React Native},
    TeXtitle    = {Vývoj multiplatformních mobilních aplikací v~React Native},
    keywords    = {
      Multiplatformní mobilní vývoj, Mobilní aplikace, React Native, Expo, CI/CD, Kontinuální integrace, Kontinuální doručování, iOS, Android OS, skautIS
    },
    TeXkeywords = {
      Multiplatformní mobilní vývoj, Mobilní aplikace, React Native, Expo, CI/CD, iOS, Kontinuální integrace, Kontinuální doručování, iOS, Android OS, skautIS
    },
    abstract    = {%
      Tato diplomová práce se zaměřuje na vývoj druhé verze mobilní aplikace Kapesní skautIS, která slouží jako mobilní rozhraní informačního systému pro skautskou organizaci Junák -- český skaut z. s. Hlavním cílem práce je reimplementovat významnou část původní aplikace pomocí frameworku React Native a~zavést strategie kontinuální integrace a~doručování (CI/CD). Tím se usiluje o~vytvoření přehledného a~efektivního vývojového procesu, který umožní snadné budoucí rozšíření a~úpravy aplikace. 

      
      % This diploma thesis focuses on the development of the second version of the mobile application Kapesní skautIS, which serves as the mobile interface of the information system for the scouting organization Junák - český skaut z. s. The main objective of this work is to reimplement a~significant part of the original application using the React Native framework and introduce continuous integration and delivery (CI/CD) strategies. The aim is to create a~clear and efficient development process that enables easy future expansion and modifications of the application.
    },
    thanks      = {%
      Na tomto místě bych v~první řadě rád poděkoval RNDr. Vítu Rusňákovi, Ph.D. za cenné rady, kritické připomínky a~hlavně trpělivost. 
      Dále bych chtěl poděkovat Iloně Kirchnerové a~otci Jaromírovi Novotnému, kteří mi pomohli s~korekturou práce.
    },
    bib         = literature.bib,
    facultyLogo = fithesis-fi
}

\usepackage{makeidx}      %% The `makeidx` package contains
\makeindex                %% helper commands for index typesetting.
%% These additional packages are used within the document:
\usepackage{paralist} %% Compact list environments
\usepackage{amsmath}  %% Mathematics
\usepackage{amsthm}
\usepackage{amsfonts}
\usepackage{url}      %% Hyperlinks
\usepackage{markdown} %% Lightweight markup
\usepackage[babel]{csquotes}
\usepackage{textcomp}                 
\usepackage{enumitem}
\usepackage{listings} %% Source code highlighting
\lstset{
  basicstyle      = \ttfamily\footnotesize,
  identifierstyle = \color{black},
  keywordstyle    = \color{blue},
  keywordstyle    = {[2]\color{cyan}},
  keywordstyle    = {[3]\color{olive}},
  stringstyle     = \color{teal},
  commentstyle    = \itshape\color{magenta},
  breaklines      = true,
}
\renewcommand{\lstlistingname}{Kód}
\renewcommand*\ttdefault{txtt}       

\usepackage{enumitem}
\setlist{itemsep=0pt,topsep=3pt,leftmargin=20pt}

\emergencystretch 1em\relax

\clubpenalty=10000
\widowpenalty=10000
\displaywidowpenalty=1000

\begin{document}

\chapter{Úvod}

Mobilní telefony se staly nedílnou součástí každodenního života a~převládají na nich dvě platformy, Android a~iOS, které ovládají téměř celý trh\footnote{Statistiky mobilního trhu: \url{https://gs.statcounter.com/os-market-share/mobile/worldwide}}. Přestože obě platformy nabízejí podobné služby pro uživatele, vývojářský přístup se liší. Pro vývoj aplikace pro obě platformy je nutné využít buď odděleného vývoje pro každou z~nich, nebo multiplatformního přístupu, který umožňuje využít jednu kódovou bázi pro obě platformy.

Cílem této diplomové práce je reimplementace aplikace Kapesní skautIS pro organizaci Junák -- český skaut z.s., která je největší skautskou organizací v~České republice s~více než 75 000 registrovanými členy. Organizace má hierarchickou strukturu, kde základními jednotkami jsou skautské oddíly, které jsou součástí skautských středisek a~ty pak tvoří skautské okresy nebo kraje. V~současné době má organizace silnou mezinárodní působnost a~spolupracuje s~mnoha dalšími skautskými organizacemi po celém světě.

Současná verze aplikace Kapesní skautIS obsahuje chyby a~nezahrnuje automatizované nasazování nebo kontrolu kvality kódu, což způsobuje problémy s~její udržitelností. Z~těchto důvodu je potřeba aplikaci reimplementovat a~nastavit vývojové prostředí tak, aby byl budoucí vývoj co nejjednodušší.

Tato diplomová práce se skládá z~sedmy kapitol, které se věnují různým aspektům mobilního vývoje. V~kapitole~\ref{c:mobile-app} jsou prezentovány široké možnosti, které dnešní mobilní vývoj nabízí, spolu s~principy a~strategiemi automatizace vývoje aplikací. Kapitola~\ref{c:revision} se věnuje popisu všech dosavadních aplikací skautIS a~analýzou poslední verze aplikace Kapesního skautIS. V~kapitole~\ref{c:implementation} je popsána reimplementaci aplikace. Kapitola~\ref{c:cdid-implementace} se věnuje implementaci CI/CD a~kapitola~\ref{c:test} popisuje průběh a~výsledky uzavřeného testování. Závěrečná kapitola~(\ref{c:zaver}) shrnuje výsledky práce a~nabízí náhled na možnosti budoucího rozšíření aplikace.

\chapter{Moderní způsoby vývoje mobilních aplikací}
\label{c:mobile-app}

Kapitola nejprve srovnává výhody a~nevýhody různých přístupů k~vývoji mobilních aplikací. Následuje představení principů kontinuální integrace a~doručování, které se využívají pro usnadnění rutinních činností při vývoji.

\section{Přístupy~k vývoji mobilních aplikací}

V~tato sekce se bude zabývat různými přístupy k~vývoji mobilních aplikací, konkrétně se zaměříme na nativní, webový, hybridní a~multiplatformní přístupy. Každý z~těchto přístupů přináší své výhody a~omezení, a~rozhodnutí o~volbě správného přístupu závisí na konkrétních požadavcích a~cílech projektu~\cite{netsolutions-native}.

\subsection{Nativní vývoj}

Největší výhodou nativního vývoje je to, že neexistuje žádná nadstavba mezi aplikaci a~nativními funkcemi (práce s~kamerou, soubory atd.), aplikace tedy komunikuje přímo s~celým SDK (Software Development Kit). Aplikace pro iOS jsou vyvíjené v~jazycích Objective-C nebo Swift na druhou stranu aplikace pro Android jsou vyvíjené v~jazycích Java nebo Kotlin. Výhodou vývoje iOS aplikací je znalost specifikace hardwaru zařízení Apple. To umožňuje zkompilovaný kód v~binárním formátu spustit přímo na procesoru. Android, na druhou stranu, je využíván řadou výrobců jako operační systém pro jejich přístroje a~aplikace potřebují k~běhu virtuální stroj. Důsledkem je nižší výkon a~větší abstrakce hardwaru.

Vzhledem k~tomu, že aplikace mohou využívat celý výkon zařízení, jsou zpravidla rychlejší než aplikace vyvíjené jinými způsoby. Nepotřebují také žádný nadstandardní aplikační rámec k~sestavení na danou platformu, což znamená, že sestavené nativní aplikace zabírají méně místa v~porovnání s~ostatními přístupy. Nativní vývoj má však jednu velkou a~podstatnou nevýhodu, kterou je nutnost vyvíjet dvě aplikace, pro každou platformu zvlášť. Vývoj se tak stává dražší a~časově náročnější. 

Tento přístup bývá populární u~velkých aplikací, které jsou vyvíjeny korporátními společnostmi, jako je například aplikace Waze\footnote{Waze: \url{https://www.waze.com/}}. Na druhou stranu pro startupy je tento přístup jen stěží použitelný, jelikož jejich cílem je doručit na trh funkční verzi služby či produktu co nejrychleji a~s~co nejnižším náklady. Právě tyto potřeby vedly ke vzniku dalších přístupů k~mobilnímu vývoji.

\subsection{Webový vývoj}

Při vývoji mobilních aplikací bývá mnohdy překážkou následná publikace do obchodů Google Play a~Apple App Store. Jelikož pravidla obchodů i~způsob schvalování aplikací se liší, může být celý proces zbytečně zdlouhavý, nebo se dokonce může stát, že po aktualizaci pravidel bude aplikace z~obchodu stažena. Z~tohoto důvodu se někteří vývojáři rozhodli vytvořit pouze webovou aplikaci, která jim umožňuje zveřejnit aplikace i~mimo obchody a~nabízet je jak pro mobilní zařízení, tak i~na počítače. Jedná se pouze o~tradiční webové aplikace napsané v~jazycích HTML, CSS a~JavaScript, pro které lze využít širokou škálu rámců a~knihoven. Mezi v~současnosti nejpopulárnější patří Angular, React či Vue. V~dnešní době je již běžnou praxí, že se při návrhu webové aplikace využívá tzv. \emph{mobile-first aproach}, tj. design aplikace je navržen primárně na mobilní zařízení a~až poté na ostatní.

Webový vývoj ale ze všech přístupů nejvíce trpí absencí nativních funkcí, jelikož aplikace jsou omezeny pouze na možnosti webového prohlížeče v~zařízení uživatele. Ačkoliv je v~současnosti možné využívat i~funkce, jako je GPS a~fotoaparát, webový vývoj má stále své limity, např. nutnost být online.

V~roce 2017 Google představil koncept progresivních webových aplikací (PWA\footnote{PWA: \url{https://web.dev/progressive-web-apps/}}), které těmto typům aplikací umožňují přijmout více nativních funkcí, jako jsou standardní ikony aplikací, push notifikace, možnosti práce v~offline režimu a~další. Společnost Microsoft také nedávno přijala toto řešení a~učinila z~těchto typů aplikací plnohodnotné položky jejich obchodě s~aplikacemi.

Největší výhodou a~tedy i~důvodem proč si vývojové týmy tento přístup volí je, že mohou snadno vytvořit aplikaci z~jediné kódové základny, kterou pak lze použít na různých platformách a~snadno ji dále rozšiřovat o~nové funkce. Pro některé vývojové týmy je toto řešení přitažlivé, neboť pro řadu aplikací nenáročných na výkon je tento přístup mnohdy dostačující.

\subsection{Hybridní vývoj}

Hybridní přístup je kombinací nativních a~webových řešení. Kód je napsán pouze jednou a~aplikace je opět vyvíjena pomocí moderních webových technologií. Důležité ale je, že tento kód je poté obalen nativním kódem (např. pomocí Ionic's Capacitor či Apache Cordova), což umožňuje získání přístupu k~nativním funkcím.

Díky nativnímu obalu se svým výkonem blíží nativním aplikacím. Nicméně tyto aplikace stále běží v~nativním webovém prohlížeči zařízení a~i zde jsou proto specifika, např. související s~odlišným chováním prohlížeče na různých platformách nebo verzích operačního systému~\cite{ionic-hybrid}.

\subsection{Multiplatformní vývoj}

Hybridní a~multiplatformní vývoj jsou dva přístupy k~vývoji aplikací, které mohou být často zaměňovány. Avšak, jedinou významnou shodou mezi těmito přístupy je možnost sdílet kód mezi různými platformami, což umožňuje vývojářům psát kód pouze jednou a~následně ho opakovaně používat na různých platformách.

Multiplatformní přístup je založen na podobném principu sdílené kódové báze, jako vývoj hybridní. Nejedná se však o~synonyma, neboť přístupy se zásadně liší. Multiplatformní vývoj je založen na existenci aplikačních rámců, které umožňují přeložení kódu ze společné báze do zcela nativního kódu dané platformy. Vzhledem ke vzrůstající popularitě multiplatformního vývoje roste i~vývojářská komunita. Oproti hybridnímu vývoji je vytváření aplikace v~mnohém přímočařejší a~výkon výsledné aplikace je srovnatelný s~aplikací nativní. 
V~dnešní době převládají multiplatformní aplikace. Veškerá zásluha patří frameworkům React Native, Native Script, Xamarin či Flutter.

\subsection{Porovnání vývojových přístupů}

Po seznámení se s~hlavními přístupy k~mobilnímu vývoji můžeme nyní v~tabulce (viz Tab.~\ref{tab:mobileDev}) porovnat tyto přístupy na základě jejich klíčových vlastností.

\begin{table}[!ht]
\scriptsize
\centering
\begin{tabularx}{\textwidth}{X|XXXX}
\toprule
Vlastnost & Nativní & Webový & Hybridní & Multiplatformní \\
\midrule
Nativní přístup & Úplný & Omezený & S~pluginy & Úplný \\
Znovupoužití & Ne & Ano & Ano & Ano       \\
Podpora napříč platformami & Ne & Ano & Ano & Ano \\               
Výkon & Vysoký & Střední/  vysoký & Střední/ vysoký & Střední/ vysoký \\
Programovací jazyk & Podle platformy & HTML, CSS, Javascript & HTML, CSS, Javascript & React Native, Xamarin a~Flutter \\ 

\bottomrule
\end{tabularx}
\caption{Klíčové vlastnosti: nativní, webový, hybridní a~multiplatformní vývoj.}
\label{tab:mobileDev}
\end{table}

\section{Automatizace vývoje aplikace}
\label{s:cicd}

V~této části se zaměřujeme na dva klíčové přístupy ve vývoji softwaru, a~to kontinuální integraci ({\it continuous integration} -- CI) a~kontinuální doručování ({\it continuous delivery} -- CD). Tyto postupy slouží k~automatizaci procesů ve vývoji softwaru s~cílem zlepšit jeho kvalitu a~efektivitu. Kontinuální integrace umožňuje vývojářům integrovat svůj kód do společného repozitáře a~následně ho automaticky otestovat. Kontinuální doručování pak umožňuje automatizovat proces nasazení softwaru do produkčního prostředí. Tímto způsobem lze dosáhnout rychlejšího vývoje, častějších a~spolehlivějších dodávek softwaru~\cite{ci-cd}. 

\subsection{Kontinuální integrace -- CI}

Jedná se o~postup při vývoji softwaru, při kterém vývojáři pravidelně slučují své změny kódu do centrálního úložiště, kde probíhá automatizované sestavení aplikace, testy, kontrola kódu a~v~neposlední řadě jeho verzování.

CI se nejčastěji vztahuje na proces sestavení aplikace, respektive poté na celou integrační fázi procesu vydání softwaru. Primárními cíli CI je automatizovat a~zrychlit proces hledání chyb a~celkově dohlížet na kvalitu softwaru, to vede ke zkrácení času, který je nutný pro validaci a~vydání nových aktualizací.

Mezi základní výzvy implementace CI patří společný zdrojový kód a~udržování jediného úložiště, dále pak automatizace sestavení a~automatické testovaní. Velkou výhodou zde pro vývojářské týmy je viditelnost všech verzí aplikace, včetně její kompletní historie. 

Vývojář posílá kód do centrálního úložiště v~pravidelných intervalech, minimálně jednou za den. Nastaveni CI umožňuje vývojářům přesně specifikovat kdy a~v~jakém pořadí se mají spustit jaké akce. Toto nastavení v~ideálním případě zajistí, že se do produkčního kódu dostane vždy pouze kód, který prošel všemi definovanými akcemi. Běžnou praxí je i~lokální syntaktická kontrola kódu před odesláním do centrálního úložiště, aby se zamezilo případným konfliktům a~problémům s~nefunkčním kódem na serveru. Jednotkové a~integrační testy se také provádí zpravidla bezprostředně před produkčním nasazením~\cite{ci-cd-guide}.

\subsubsection*{Výhody kontinuální integrace}

CI přináší mnoho výhod pro týmy vývojářů softwaru. Především jde o~zvýšení kvality kódu, zvýšení produktivity vývojářů, zkrácení doby trvání vývoje a~rychlé detekce chyb~\cite{ibm-ci}.

\begin{itemize}
\item\textit{Zvýšení kvality kódu:} Pomocí CI jsou všechny změny v~kódu okamžitě testovány a~kompilovány. To umožňuje odhalit chyby dříve a~zabránit tak vzniku velkých problémů v~kódu později. Díky tomu jsou týmy schopné doručovat kvalitnější kód, což může vést k~větší spokojenosti zákazníků.
\item\textit{Zvýšení produktivity vývojářů:} CI umožňuje rychle a~snadno testovat a~přidávat změny do kódu. Tím se snižuje doba, kterou vývojáři tráví manuálním testováním a~zvyšuje se produktivita celého týmu.
\item\textit{Zkrácení vývoje:} Díky CI mohou týmy dodávat nové funkce a~opravy rychleji a~efektivněji. Vývojáři se nemusí zabývat složitými procesy ručního testování a~nasazování. To může vést k~rychlejšímu zavedení nových funkcí na trh a~tím k~rychlejšímu návratu investic.
\item\textit{Rychlá detekce a~řešení problémů:} Pokud se při testování kódu objeví problém, CI okamžitě upozorní vývojáře. Díky tomu mohou rychle zareagovat a~odstranit problémy dříve, než se dostanou do produkčního prostředí. To umožňuje zvýšit stabilitu a~spolehlivost celého systému.
\item\textit{Snadné zpětné hledání a~opravování chyb:} Použití CI umožňuje snadno zjistit, kdy a~kde se vyskytly problémy. Týmy mohou rychle identifikovat chyby, zpětně hledat, jak se dostaly do kódu a~co je způsobilo. To umožňuje snadnější opravy a~vyloučení opakování chyb v~budoucnu.
\end{itemize}

\subsection{Kontinuální doručování -- CD}

Jedná se o~postup při vývoji softwaru, kde jsou změny softwaru automaticky sestavovány, testovány a~připravovány pro vydání produkční verze. Funguje jako rozšíření CI o~nasazování softwaru na testovací prostředí, produkční prostředí, anebo oboje. Nasazování přichází na řadu poté co je sestavovací fáze úspěšně dokončena. CD může být plně automatizovaným procesem nebo částečně automatizované s~manuálními kroky v~kritických bodech. Příkladem částečné automatizace může být mobilní vývoj, kdy jsme schopní dostat sestavenou aplikaci automaticky do administrační konzole aplikačního obchodu. Nicméně finální krok, tedy zveřejnění aplikace nebo její nové verze vyžaduje manuální zásah.

Jedním z~nedorozumění týkajících se CD je, že každá změna, která je nahrána a~projde automatizovanými testy, je ihned aplikována v~produkčním prostředí. Cílem CD však není aplikovat každou změnu do produkce ihned, ale zajistit, že změna neovlivní produkční nasazení.

Před nasazením změny do produkce lze implementovat proces rozhodování, aby bylo zajištěno, že nasazení do produkce je autorizováno a~auditováno. Toto rozhodnutí může být učiněno osobou a~poté provedeno nástroji.

Nasazení změny do produkce není rušivou událostí. Nasazení nevyžaduje zastavení práce technického týmu na dalším souboru změn a~nevyžaduje projektový plán, dokumentaci předání nebo okno údržby. Nasazení se stává opakovatelným procesem, který byl prověřen mnohokrát v~testovacím prostředí.

\subsubsection{Výhody kontinuálního doručování}

Mezi hlavní výhody CD patří automatizace procesů, zlepšení produktivity vývojářů, zvyšování kvality kódu a~rychlejšího dodávání aktualizací zákazníkům.
\begin{itemize}
\item\textit{Automatizace procesu vydání softwaru:} CD poskytuje týmům způsob, jak nahrávat kód, který je automaticky sestaven, otestován a~připraven k~vydání do produkce, aby dodávání softwaru bylo efektivní, bezpečné a~bez zbytečných chyb.
\item\textit{Zlepšení produktivity vývojářů:} Postupy CD pomáhají zlepšovat produktivitu týmu tím, že vývojářům uvolňují ruce od rutinních úkolů, usnadňují složité závislosti a~vrací prioritu k~dodávání nových funkcí softwaru. Namísto toho, aby vývojáři ztráceli čas integrací jejich kódu s~ostatními částmi vývoje a~jeho následným nasazením, mohou se zaměřit na programování logiky, která dodává požadované funkce.
\item\textit{Zlepšení kvality kódu:} CD může pomoci identifikovat chyby v~rané fázi vývoje. Rozšíření o~nové typy testů je snadné, protože celý proces je automatizovaný. S~cílem {\it více testů častěji}, tedy raději více malých testů s~tím, že jsou spouštěny opakovaně, než-li méně spouštěných jen zřídka, mohou týmy rychleji získávat okamžitou zpětnou vazbu o~vlivu změn. To umožňuje produkovat kvalitní kód s~vysokou zárukou stability a~bezpečnosti. 
\item\textit{Rychlejší dodávání aktualizací:} CD pomáhá zrychlit a~zkrátit dobu pro dodávání aktualizací softwaru, včetně vydávání nových funkcí a~oprav chyb. Lze tak rychleji reagovat na změny trhu, bezpečnostní výzvy, či akutní potřeby zákazníků.
\end{itemize}

\subsection{Git flow}
\label{s:gitflow}

Git Flow\cite{git-flow-doc} je úspěšný a~oblíbený metodický přístup ke správě verzí zdrojového kódu pomocí verzovacího systému Git\footnote{Git: \url{https://git-scm.com/}}. Umožňuje organizovat a~řídit proces vývoje softwaru, aby byl co nejefektivnější a~měl minimální rizika. Git Flow umožňuje definovat pravidla a~postupy pro použití větví (branches) repozitáře kódu. Tím lze zajistit oddělení různých verzí kódu, jako jsou vývoj, testování a~nasazení, do samostatných fází vývoje. 

Typicky se využívá dvou hlavních větví: hlavní (main) a~vývojové (develop). Hlavní větev obsahuje všechny schválené změny a~používá se k~vytvoření nových verzí produktu. Vývojová větev obsahuje kód, na kterém vývojáři aktuálně pracují a~testují jej. Jakmile jsou změny schváleny, dochází ke včlenění kódu vývojové větve do hlavní větve a~nová verze produktu je vytvořena.

Git Flow a~CI/CD jsou úzce propojeny, protože Git Flow pomáhá organizovat vývojový proces a~oddělit fáze vývoje, zatímco CI/CD pomáhá automatizovat proces integrace, testování a~nasazení kódu. Použití Git Flow může pomoci týmu vývojářů implementovat úspěšný a~efektivní proces CI/CD pro správu kódu a~vývoj softwaru~\cite{git-flow}. 

\chapter{Revize návrhu aplikace Kapesní skautIS}
\label{c:revision}

Cílem této kapitoly je podrobně analyzovat proces návrhu nové verze aplikace Kapesní skautIS. První část se zaměřuje na představení existujících aplikací skautIS a~jejich vlastnosti. Druhá část se věnuje analýze předchozí verze aplikace a~identifikaci případných problémů spojených s~jejím používáním. Třetí část se zabývá návrhem nové architektury aplikace, včetně výběru vhodných technologií a~postupů pro implementaci.

\section{Existující řešení aplikací skautIS}

SkautIS je informační systém vyvinutý pro efektivní správu skautských oddílů a~akcí. Klíčovou součástí systému je programové rozhraní (API), které umožňuje integraci služeb skautIS do jiných aplikací nebo přístup k~uloženým datům. Hlavní aplikací skautIS je Informační systém skautIS, který je realizován jako webová aplikace. Vedle toho bylo v~minulosti vytvořeno několik verzí mobilní aplikace Kapesní skautIS, přičemž nejnovější verze bude detailně analyzována v~rámci této práce (viz sekce~\ref{s:problemy}).

\subsection{Informační systém skautIS}
S~rozrůstající se členskou základnou, rozmanitostí aktivit, a~narůstající byrokracií, vyvstala potřeba centrálního informačního systému, který usnadní řízení orgaizace. Ten vznikl v~roce 2010 a~od té doby je neustále rozvíjen a~postupně rozšiřován o~další funkce. V~současnosti tak např. umožňuje správu členské základny, evidenci účasti na pořádaných akcích, plánování a~organizaci táborů a~výprav, různé formy výkaznictví či agendu skautských vyznamenání.

SkautIS\footnote{\url{https://is.skaut.cz}} je webová aplikace napsaná pomocí frameworku .NET\footnote{.NET: https://dotnet.microsoft.com/en-us/} a~je vyvíjena firmou Skeleton Software s.r.o\footnote{Skeleton Software s.r.o: https://skeleton.cz/}. Kromě Junáka je skautIS využíván i~v~sesterské organizaci Slovenský skauting.

V~systému skautIS mají uživatelé možnost zastávat více rolí, které odpovídají jejich funkci v~organizaci. Každá role poskytuje přístup pouze k~určitým agendám a~funkcím, které jsou přidělovány na základě oprávnění vázaných na tyto role. Například, vedoucí oddílu má přístup k~údajům o~členech svého oddílu, ale není schopen si ani zobrazit seznam členů jiného oddílu. Základní role, člen oddílu, umožňuje uživateli pouze editaci svých osobních dat. Každý uživatel má v~danou chvíli přidělenou pouze jednu roli, což zajišťuje přístup pouze k~relevantním informacím. V~případě, kdy zastává více rolí (je např. běžné, že jeden člověk je zároveň vedoucím oddílu a~zastává i~další funkci na středisku či v~jiné jednotce), musí mezi rolemi přepínat. 

SkautIS obsahuje řadu agend, které uožňují správu členů, financí, registraci členské základny, evidenci táborů, akcí aj. Hlavními funkcemi aplikace skautIS jsou\cite{Domkar2019thesis}:

\begin{itemize}
    \item Zpřístupňování informací o~přihlášeném členovi, jeho kontaktech, funkcích v~organizaci a~absolvovaných akcích.
    \item Zpřístupňování informací o~členech, evidenci hospodaření či majetku jednotky.
    \item Poskytování administrativních funkcí pro vedoucí jednotek (registrace, nábory, atd.).
    \item Vyhledávání kontaktů na vedoucí a~činovníky organizace.

    \item Služby skautských benefitů jako je Skautská telefonní síť (STS).
    \item Správa nemovitostí, dotací, hodnocení kvality a~v~neposlední řadě také export dat.
\end{itemize}

Vedle produkční instance existuje i~testovací verze této aplikace, jež se nachází na adrese \url{https://test-is.skaut.cz}. Ta má shodnou funkcionalitu jako ta produkční, obsahuje však fiktivní data a~slouží pro testování nových funkcí a~školení uživatelů. Vizuálně se liší žlutým pozadím (viz Obr.~\ref{fig:skautis-test}) na rozdíl od bílého pozadí produkční verze (viz Obr.~\ref{fig:skautis-prod}).

\begin{figure}[!ht]
  \begin{center}
    \includegraphics[width=\textwidth]{fithesis/images/prod.png}
  \end{center}
  \caption{Produkční verze informačního systému skautIS.}
  \label{fig:skautis-prod}
\end{figure}

\begin{figure}[!ht]
  \begin{center}
    \includegraphics[width=\textwidth]{fithesis/images/test.png}
  \end{center}
  \caption{Testovací verze informačního systému skautIS.}
  \label{fig:skautis-test}
\end{figure}

\subsubsection{Rozhraní webových služeb}
\label{s:API}
Rozhraní webových služeb se nachází na adrese \url{https://is.skaut.cz/JunakWebservice/} a~umožňuje komunikaci s~databází skautIS.

Rozhraní webových služeb používá protokol SOAP (\textit{Simple Object Access Protocol}), který slouží k~výměně zpráv mezi klientem a~serverem. Všechny požadavky na data a~odpovědi na ně jsou přenášeny v~podobě XML zpráv.

Díky rozhraní webových služeb je možné snadno integrovat skautIS s~dalšími aplikacemi a~využívat jeho funkce i~v~jiných systémech. Architektura skautIS je navržena tak, aby aplikace pracovaly pouze s~daty ke kterým mají explicitně povolen přístup a~která potřebují. Pro získání kompletní sady informací o~uživateli, včetně osobních údajů, zdravotních informací, funkcí a~rolí a~informací o~registraci, je tak třeba provést až osm dotazů, neboť různé uživatelské role mají přístup k~různé části těchto dat. Řízení oprávnění je na úrovni jednotlivých volání, což znamená, že je nutné mít explicitně povoleny vybrané SOAP zprávy, aby bylo možné získat nějaká data.

Kromě autentizace je dalším typickým využitím API možnost propojení skautIS s~dalšími službami a~weby, např. CMS WordPress\footnote{WordPress: \url{https://wordpress.com/}}, který je využíván jednotkami pro správu svých webových stránek. Kromě původního SOAP rozhraní se v~posledních letech se s~revizí  agendách skautISu zavádí REST API, což umožňuje snadnější a~modernější integraci s~dalšími aplikacemi a~webovými službami.

\subsection{Mobilní aplikace Kapesní skautIS}

Cílem mobilní aplikace bylo od počátku zpřístupnit vybrané agendy a~upravit jejich rozsah s~ohledem na formát zařízení a~odlišné způsoby využití funkcí skautISu (např. na telefonu nedává smysl řešit administrativu spojenou s~registrací osob). Postupně vznikly dvě verze, první pro Android OS a~Microsoft Windows Mobile, druhá pak pro platformy Android OS a~Apple iOS.

\subsubsection{Kapesní skautIS -- verze Xamarin}
První verze byla vyvíjena jako dodatek k~webové aplikaci a~za jejím vývojem opět stála firma Skeleton Software s.r.o. Implementována byla v~aplikačním rámci Xamarin\footnote{Xamarin: \url{https://learn.microsoft.com/cs-cz/xamarin/get-started/what-is-xamarin}}, který byl svého času jeden z~prvních pro vývoj mobilních aplikací. Xamarin je založen na programovacím jazyku C\#. 

Aplikace zpřístupňovala základní agendy jako správu uživatelů, jednotek a~telefonních čísel v~STS. Bohužel aplikace nebyla příliš rozvíjena a~obsahovala řadu chyb. Poslední dostupná verze je z~roku 2016 a~přinášela pouze drobné opravy chyb. S~ohledem na nákladnost vývoje a~nízký přínos pro uživatele bylo od dalšího vývoje upuštěno.

\subsubsection{Kapesní skautIS -- verze NativeScript}
\label{s:kapesni-verze-dva}
Vývoj druhé verze aplikace začal v~roce 2018 díky studentům Fakulty informatiky Masarykovy univerzity. Ti, v~rámci svých závěrečných prací, začali postupně implementovat aplikaci znovu. Hlavní motivací bylo použití programovacího rámce, který bude stárnout lépe než Xamarin, jež byl tehdy na ústupu a~aktuálně je naplánován konec jeho podpory v~letošním roce.

V~rámci první závěrečné práce\cite{Domkar2019thesis} napsané Mgr. Petrem Domkařem došlo nejdříve k~prozkoumání a~porovnání dostupných technologických rámců s~tím, že byl nakonec vybrán framework NativeScript, který využívá moderních webových technologií. Vzniklá implementace funkčně odpovídala původní aplikaci. Další agendy pak postupně vznikaly v~navazujících pracích:
\begin{itemize}
    \item agenda správy majetku~\cite{Ostruszkova2020thesis},
    \item agendy akcí (tábory, všeobecné akce a~sněmy)~\cite{Zeman2021thesis},
    \item agendy pro vedoucí oddílu (nábory, e-přihlášky a~exporty)~\cite{Treskon2021thesis},
    \item a~nakonec agenda hodnocení kvality~\cite{Bradac2021thesis}.
\end{itemize}

Poslední práce, která se věnovala primárně redesignu uživatelského rozhraní vznikla v~roce 2022~\cite{Koutek2022thesis}. V~rámci ní byla částečně upravena informační struktura aplikace a~vznikl také grafický manuál, který pokrývá barevné schéma, typografii, ikony a~grafické prvky. Srovnání původního a~nového vzhledu je na Obr.~\ref{fig:redesign}. 

\begin{figure}[!ht]
  \begin{center}
    \includegraphics[width=\textwidth]{fithesis/images/redesign.png}
  \end{center}
  \caption{Ukázka uživatelské rozhraní před redesignem (vlevo) a~po něm (vpravo)\cite{Koutek2022thesis}}
  \label{fig:redesign}
\end{figure}

Při vývoji softwaru je důležité neustále sledovat, zda aplikace splňuje požadavky uživatelů a~zda vyhovuje současným technickým standardům. V~roce 2022 bylo rozhodnuto o~nutnosti aplikaci reimplementovat. Důvodů bylo několik. Jedním byla složitá a~náročná údržba kódu, neboť kvůli neexistenci doporučení pro vývoj se kód jednotlivých agend často velmi lišil. Zároveň byl již delší dobu pozorován úpadek aplikačního rámce NativesSript. Na konci roku 2022 tak byla z~aplikačních obchodů stažena i~druhá verze Kapesního skautISu. V~té době však již započala implementace nové verze pomocí perspektivního rámce \textit{React Native}.

\section{Problémy aplikace Kapesní skautIS}
\label{s:problemy}

Následující kapitola popisuje nedostatky aplikace kapesní skautIS a~to nejprve z~hlediska jejího kódu, poté z~hlediska funkčních nedostatků a~nakonec z~hlediska designových nedostatků.

\subsection{Problémy zdrojového kódu aplikace}
Vývoj druhé verze aplikace probíhal spíše organicky a~nebylo tak přesně jasné jakým stylem bude aplikace vyvíjena. To vedlo k~tomu, že při prvotním přepisování aplikace nebyl kladen dostatečný důraz na nastavení programovacího prostředí a~doporučení pro vývoj pozdějších rozšíření. Použijeme-li terminologii agilního vývoje, byla každá závěrečná práce autonomním \textit{sprintem} na jehož konci byl do aplikace přidán nový inkrement bez zásadního vlivu.

\subsubsection{Nekonzistence kódu}

Jak bylo uvedeno výše (viz podsekce~\ref{s:kapesni-verze-dva}) na tvorbě aplikace se podílelo sedm programátorů. V~repozitáři ale chybí nastavení základních programovacích nástrojů jako je \textit{linter} který umožňuje kontrolu pravidel stylu kódu. Kvůli jeho absenci tak každý nový programátor přirozeně využíval svůj zažitý styl psaní kódu. Aplikace proto obsahovala soubory z~nichž je patrné, že na nich pracovalo více lidí a~stejně tak i~soubory, u~kterých je jen stěží poznat, že se jedná o~tutéž aplikaci~\cite{inproceedings}.

Nejvíce je tento problém vidět v~pojmenování proměnných. Zatímco agendy implementované ze začátku se řídí pravidlem, kdy název proměnné odpovídá volání API, později vyvíjené agendy již názvy zkracují, viz ukázka~\ref{lst:code-inconsistent}.

\begin{lstlisting}[caption={List akcí pro řešení problémů pro cílovébody \it LoadPersonPhoto a~EventGeneralInsert},label={lst:code-inconsistent}]]
export const erroredActions = [
    {
        name: 'LoadPersonPhoto',
        action: LoadPersonPhoto,
        message: 'Nepodarilo se nacist foto profilu',
    },
    {
        name: 'NewGenEventInvalid',
        action: NewGenEvent,
        message: 'Nepodarilo se vytvorit vseobecnou akci. (validace hodnot)',
    },
];
\end{lstlisting}

\subsubsection{Souborová struktura}
\label{ss:souborova-struktura}


Aplikace má běžnou strukturu~\cite{file-structure}, s~tím, že soubory různých konfigurací a~závislostí se nachází v~kořenovém adresáři aplikace. Mimo to se zde nachází i~adresář {\it app} s~zdrojovým kódem aplikace, v~němž jsou dále adresáře {\it constants}, {\it core}, {\it fonts} a~{\it pages}. Na první pohled logické členění však skrývá problém v~podobě adresáře {\it pages}.

Ten obsahuje stromovou strukturu s~adresářem pro každou hlavní obrazovku aplikace. Adresář hlavní obrazovky může obsahovat adresáře {\it components} a~{\it containers}. Problémem je to, že oba tyto adresáře neobsahují adresáře pouze pro danou obrazovku ale i~pro všechny jí podřízené obrazovky. To v~některých případech vede až k~zanoření do hloubky pěti pod obrazovek a~ke ztrátě orientace v~souvislostech kódu.

Příkladem může být obrazovka profilu, a~její pod obrazovky: Detail profilu, Formulář na vytvoření nového uživatele a~Formulář na úpravu uživatele. Podle aplikované souborové struktury pak výsledná struktura vypadá následovně:

\begin{lstlisting}[caption={Stávající souborová strukturu použitá na příkladu.},label={lst:structure-old}]]
- pages
  - profile
    - components
      - profile-contacts
          - source
      - profile-form
           - source
    - containers
      - profile
          - source
      - profile-detail
          - source
      - profile-new
          - source
      - profile-edit
        - source
\end{lstlisting}

Tato struktura trpí nedostatkem přehlednosti, protože při prvním pohledu není zcela zřejmé, jak jsou obrazovky propojeny, což je způsobeno jejich umístěním na stejné úrovni. Tento nedostatek vede k~obtížnému identifikování vztahů mezi jednotlivými obrazovkami a~způsobuje špatnou orientaci v~kódu.

\subsubsection{Absence CI/CD}
Absence CI/CD (viz sekce~\ref{s:cicd}) se týká chybějících procesů kontinuální integrace a~doručování. To může mít negativní dopad na kvalitu kódu a~stabilitu aplikace, její nasazení a~výkon. Bez těchto procesů může být obtížné identifikovat a~opravit chyby v~kódu či neschopnost pružně reagovat na změny a~aktualizace vývojového prostředí. Pro řešení této problematiky je nutné implementovat procesy CI/CD tak, aby bylo dosaženo kontinuálního testování a~integrace kódu. Sníží se tím riziko chyb z~nepozornosti a~neefektivní nasazování nových funkcí. Důsledkem bude kvalitnější aplikace a~lepší uživatelský zážitek.

\subsection{Funkční problémy}
\label{s:function-problems}
Vedle problému zdrojového kódu v~aplikaci lze najít i~řadu funkčních problémů. Vzhledem k~tomu, že aplikace nebyla masivně používána, je to pochopitelné.
Některé z~těchto problémů vznikly v~průběhu redesignu aplikace, jednalo se o~rozsáhlý zásah do aplikace, který nebyl opřen o~dostatečně velké uživatelské testování. Níže jsou představeny tři nejzávažnější problémy, které mají výrazný vliv na uživatelský zážitek a~plynulost práce s~aplikací.

\paragraph{Načítání obrazovky}
Načítání obrazovky je řešeno pomocí globálního stavu a~není vázáno přímo na akci ke které patří. Když se uživatel pohybuje aplikací jinak než programátor zamýšlel může se stát, že identifikátor načítání zůstane {\it viset} na obrazovce, jelikož aplikace neposlala signál, že už je vše načteno.

\paragraph{Volba role uživatele}
Role uživatele je uchovávána v~úložišti telefonu, aby uživatel při opětovném přihlášení pracoval se stejnou rolí jako posledně. Na základě zvolené role aplikace určuje zda má uživatel přístup k~dané agendě nebo nikoliv. Přístupová práva se, na rozdíl od role samotné, nezmění ve chvíli kdy uživatel změní roli ale nastaví se jen a~pouze při zapnutí aplikace. Tedy spustí-li uživatel aplikaci a~nastavena je role s~nižšími oprávněními, tak i~po změně role práva zůstávají nezměněná, a~to až do chvíle než je aplikace restartována.

\paragraph{Správa stavů aplikace}
Nejzásadnější problém se však vyskytuje při práci s~agendami akcí a~exportů. Poté co uživatel zobrazí detail nějaké akce, vše funguje jak má. Pokud však chce posléze zobrazit detail jiné, aplikace se vypne. Důvodem je špatná správa stavů, tedy stav se nejspíš nevymaže a~architektura není navrhnuta tak, aby podporovala přepis starého stavu na nový.

\subsection{Designové problémy}
\label{s:design-problems}

Kromě funkčních problémů trpí aplikace také řadou designových problémů~\cite{interactiondesign}, které jsou nekonzistentní a~mohou negativně ovlivnit uživatelský zážitek. Přestože nový design aplikaci pomohl vylepšit a~zpřehlednit, jeho implementace způsobila některé logické nedostatky. Aplikace např. nepodporuje dnes již běžné umístění kamery ve výřezu nebo v~průstřelu displeje. To lze však řešit relativně snadno. Nelogické je tlačítko \textit{Zpět} na hlavní obrazovce, které se zobrazuje i~když se už není kam vracet.
Podobně jako u~funkčních problémů jsou níže popsány  tři nejzávažnější problémy v~designu uživatelského rozhraní, které ovlivňují uživatelský zážitek. 

\subsubsection{Nekonzistentní použití navigační lišty}
\label{ss:navbar}
Aplikace obsahuje čtyři hlavní obrazovky {\it Profil}, {\it Hledat}, {\it Jednotka} a~{\it Více}. (viz Obr.~\ref{fig:navbar}). Pouze profilová obrazovka však má navigační lištu, která odpovídá hlavní stránce. Obsahuje očekávanou funkcionalitu, tedy detail profilu, dialog na změnu rolí a~možnost odhlášení. Obrazovky {\it Jednotka}, {\it Hledat} a~{\it Více} pro jistotu nemají žádnou navigační lištu a~působí tak spíše jako modální okno aplikace. Největší problém je potom u~obrazovky {\it Jednotka}, která má stejnou lištu jako jakákoli jiná pod obrazovka v~této aplikaci. 

\begin{figure}[h]
  \begin{center}
    \begin{minipage}{.24\textwidth}
      \includegraphics[width=\textwidth]{fithesis/images/navbar/screen-3.jpg}
    \end{minipage}
    \hfill  % Fill the horizontal space between the images
    \begin{minipage}{.24\textwidth}
      \includegraphics[width=\textwidth]{fithesis/images/navbar/screen-2.jpg}
    \end{minipage}
    \hfill 
    \begin{minipage}{.24\textwidth}
      \includegraphics[width=\textwidth]{fithesis/images/navbar/screen-1.jpg}
    \end{minipage}
    \hfill 
    \begin{minipage}{.24\textwidth}
      \includegraphics[width=\textwidth]{fithesis/images/navbar/screen-4.jpg}
    \end{minipage}
  \end{center}
\caption{Navigační lišta v~primárních obrazovkách aplikace.}
  \label{fig:navbar}
\end{figure}

\subsubsection{Nesourodost chybových hlášek}
\label{ss:errors}
Dalším problémem je nesourodost zobrazení chybových hlášek. V~aplikaci jsou hned tři způsoby: dialog s~hláškou, červený text pod chybným textovým polem a~modál umožňující poslat zpětnou vazbu (viz Obr.~\ref{fig:error-msg}). Pochopitelné by bylo, pokud by aplikace měla odlišné způsoby zobrazení systémových chyb a~chyb ve formulářích. Problém ale je, že v~aplikaci jsou všechny tři tyto varianty využity při práci s~formulářem.

\begin{figure}[!ht]
  \begin{center}
    \includegraphics[width=.5\textwidth]{fithesis/images/error-msg.png}
  \end{center}
  \caption{Typy chybových hlášek v~aplikaci.}
  \label{fig:error-msg}
\end{figure}

\subsubsection{Uživatelská oprávnění}
\label{ss:prava}
API skautISu nenabízí cílový bod, který by uživateli vrátil jeho oprávnění nebo poskytl obecný přehled o~tom, co uživatel s~danou rolí může dělat. Místo toho, pokud uživatel zavolá cílový bod API, na který nemá oprávnění, API tento požadavek zamítne.

Po návrhové stránce je tento problém řešen tak, že pokud uživatel navštíví stránku, která využívá nějaký cílový bod, který byl zamítnut, zobrazí se okno s~chybovou hláškou a~neúplný obsah stránky, jelikož očekávaná data nebyla získána. Tento přístup je velmi frustrující, neboť téměř všechny stránky jsou přístupné (aplikace povolí jejich zobrazení), i~když uživatel nemá potřebná oprávnění na zobrazení jejich obsahu. To je jednak zbytečné, jednak matoucí.

\section{Požadavky na aplikaci}

Vzhledem k~tomu, že cílem reimplementace mobilní verze aplikace Kapesní skautIS je vytvořit novou, moderní a~efektivní verzi aplikace, bylo nutné stanovit funkční a~nefunkční požadavky aplikace. Ty jsou dále diskutovány níže~\cite{requirements}.

Jelikož bylo nutné zachovat pokud možno kompletní stávající funkcionalitu a~opravit případné chyby a~nedostatky, bylo nutné implementovat funkcionalitu existujících agend. Ty zahrnují detail uživatele, agendu zpráv, detail jednotky vč. registrace, seznamu členů a~e-přihlášek. Dále pak agendu akcí, která zahrnuje kurzy, sněmy, tábory a~obecné akce. V~neposlední řadě pak také vyhledávání uživatelů, jednotek a~akcí, hodnocení kvality a~exporty. Všechny tyto agendy již byly definovány v~předchozích pracích (viz \cite{Domkar2019thesis, Ostruszkova2020thesis, Zeman2021thesis, Treskon2021thesis, Bradac2021thesis, Koutek2022thesis}) a~proto je nebudu popisovat detailně. 

\subsection{Nefunkční požadavky}
Nefunkční požadavky určují vlastnosti a~charakteristiky aplikace, které jsou nezbytné pro její správnou funkčnost a~úspěšné nasazení. Pro aplikaci Kapesní skautIS byly původní požadavky revidovány do následující podoby:

\begin{compactitem}
  \item Aplikace bude napsána pomocí programovacího rámce React Native.
  \item Aplikace bude používat programovací jazyk Typescript.
  \item Pro práci s~daty bude používat rozhraní webových služeb pro aplikace skautIS (viz podsekce~\ref{s:API}).
  \item Pro přihlášení uživatele bude využita webová aplikace skautIS skrze WebView.
  \item Uživatel bude přihlášen dokud nevyprší platnost jeho tokenu. Tj. uživatel zůstává přihlášen i~po restartu aplikace, je-li token platný.
  \item Projekt bude mít nastavené CI ({\it Continuous Integration}) pro kontrolu kvality kódu.
  \item Projekt bude mít nastavené CD ({\it Continuous Delivery}) pro snadné nasazení nových verzí aplikace na obchody s~aplikacemi.
  \item Pro přihlášení uživatele bude využita webová aplikace skautIS skrze WebView.
\end{compactitem}


\chapter{Reimplementace aplikace Kapesní skautIS}
\label{c:implementation}

V~této kapitole se nejprve zaměříme na technologie, které byly použity pro implementaci. Poté se budou analyzovat vybrané části implementace, které jsou zajímavé z~technického, výkonnostního nebo uživatelského hlediska. V~neposlední řadě se budeme věnovat implementaci uživatelského rozhraní a~popíšeme, jaké agendy byly v~rámci této práce na implementovány.

\section{Použité technologie a~knihovny}

Při výběru technologií a~knihoven pro vývoj aplikace bylo klíčové zvolit takové, které mají stabilní zázemí vlastního vývoje a~širokou základnu komunity vývojářů, kteří je využívají. Smyslem je minimalizace pravděpodobnosti, že v~budoucnu přestanou být podporovány, jak se to stalo v~případě Xamarin a~NativeScript. Dále byl kladen důraz na to, aby zvolené knihovny umožnily psát čistý a~srozumitelný kód, což přispěje ke snadnému rozšiřování a~údržbě aplikace v~budoucnu.

\subsection{React Native}
React Native~\cite{ReactNative} je mobilním protějškem webového rámce React, který byl vytvořen společností Meta. Jde o~software s~otevřeným zdrojovým kódem ({\it open-source}. Tento framework používá deklarativní zápis pro popis uživatelského rozhraní pomocí komponent, které jsou složeny z~vlastností a~stavů, ovlivňujících vzhled a~chování uživatelského rozhraní. Kromě toho React Native obsahuje mnoho nativních komponent pro mobilní platformy, které jsou optimalizovány pro dosažení vysoké výkonnosti.

Volba tohoto rámce byla založena na závěrečná práci~Michala Zoppa~\cite{Zopp2021thesis} z~roku 2021, která měla za cíl porovnat programovací rámce Native Script a~React Native. Výsledkem práce mj. bylo zjištění, že React Native má lepší nástroje pro ladění, srozumitelnější syntaxi kódu a~je přístupnější pro začínající vývojáře, zejména pro ty s~předchozí zkušeností v~webovém vývoji. Kromě toho React Native nabízí schopnost vykreslování prvků v~nativním stylu, což zajišťuje podobnou výkonnost jako u~nativních aplikací.

\subsubsection{Expo}
Při vývoji mobilních aplikací pomocí React Native se často využívá i~jeho nadstavba Expo~\cite{adhithiravi-building}. Expo nabízí mnoho užitečných funkcí. Mimo jiní i~{\it hot reload} či {\it hot module replacement}, jež umožňují okamžité aktualizace kódu, resp. vybraných modulů kódu bez nutnosti načítat celou aplikaci znovu. Obě funkce vývojářům umožňují zrychlit vývoj a~testování aplikace.I Expo však má svá omezení. Pokud např. programátor potřebuje využít funkce, které nejsou v~Expo dostupné, je nutné vytvořit vlastní moduly a~přidat je do aplikace. Omezením může být i~vlastní systém balíčkování, který může omezit využití vlastních balíčků, které v~systému nejsou.

Během analýzy aplikace byly identifikovány potřebné nativní funkce systému v~aplikaci (např. zasílání SMS, emailů, sdílení a~ukládání kontaktů do adresáře v~telefonu, propojení s~mapovou aplikací či stahování souborů). Všechny potřebné balíčky byly nalezeny i~v~Expo, což později výrazně usnadnilo vývoj aplikace. Ačkoli existuje potencionální riziko, že s~růstem aplikace narazíme na nativní funkci, která nebude podporována, je toto riziko poměrně malé. 

\subsubsection{Typescript}
TypeScript~\cite{TypeScript} je typovaná nadstavba jazyka JavaScript\footnote{JavaScript: \url{https://developer.mozilla.org/en-US/docs/Web/JavaScript}}. Statické typování umožňuje vývojářům deklarovat typ proměnných a~funkcí, což umožňuje odhalit mnoho chyb a~nedostatků v~kódu již během vývoje. To může ušetřit spoustu času a~úsilí při ladění kódu později. Navíc TypeScript je navržen a~podporuje vývojáře v~tom, aby kód byl čistý a~přehledný, což usnadňuje jeho čtení a~úpravu i~pro ostatní členy týmu. S~rozvojem webového vývoje v~posledních letech tak stoupá jeho popularita. Dřívější absence podpory některých knihoven je již překonána a~možnosti jazyka se neustále zlepšují. Ačkoliv předchozí verze aplikace Kapesní skautIS využívala TypeScript, typová kontrola nebyla vynucena a~část kódu byla i~v~jazyce JavaScript. Nová verze aplikace oba tyto nedostatky odstraňuje.

\subsection{Tailwind}
V~React Native aplikacích se obvykle pro stylování obrazovek používají tzv {\it Styled Components}\footnote{{\it Styled Components}: \url{https://styled-components.com/}.}. Výhodou rámce Tailwind CSS\footnote{Tailwind CSS: \url{https://tailwindcss.com/}} je možnost psát kaskádové skripty pomocí předdefinovaných tříd, což usnadňuje úpravy designu. Dále je Tailwind CSS snadno přizpůsobitelný pomocí konfigurace barev, velikostí písma a~dalších vlastností, čímž je možné snadno vytvořit unikátní vzhled aplikace. Používání předdefinovaných tříd zajišťuje konzistenci a~jednoznačnost kódu i~údržbu projektu. Výsledný CSS soubor je zpravidla velmi kompaktní, díky čemuž se stránky (v~našem případě obrazovky aplikace) načítají rychleji. Integraci a~použití Tailwind CSS v~React Native usnadňuje knihovna NativeWind\footnote{NativeWind: \url{https://www.nativewind.dev/}.}.

\subsection{React Query}
S~ohledem na složitou strukturu skautIS API je klíčové využívat účinné nástroje, které usnadní správu stavů, jako například načítání dat a~zpracování chybových hlášek. To umožní dosáhnout nejlepšího výkonu aplikace a~snížit potřebu manuální správy těchto stavů v~kódu. K~tomuto účelu je využita knihovna React Query\footnote{React Query: \url{https://tanstack.com/query/v3/}}. Ta se v~roce 2023 stala velmi populární knihovnou pro správu dat v~React aplikacích díky své rychlosti a~efektivnosti. Jednou z~nejvýraznějších výhod této knihovny je automatické načítání dat z~různých zdrojů a~možnost {\it cachování dat}. To vede ke snížení počtu požadavků na server a~zvyšuje vnímanou rychlost aplikace. Další výhodou jsou snadné aktualizace či odstranění dat z~aplikace, což zvyšuje produktivitu vývojářů. React Query má také aktivní komunitu, která se stále snaží tuto knihovnu vylepšovat~\cite{react-query}. 

\section{Implementované agendy}
S~ohledem na skutečnost, že finální aplikace obsahuje více než padesát unikátních obrazovek, včetně domovských obrazovek, formulářů a~detailů, není smysluplné detailně popisovat každou z~nich. Avšak u~každé implementované agendy budou popsány funkce a~uživatelský průchod, společně s~ilustrativními snímky základních obrazovek.

Základní struktura aplikace se skládá ze čtyř hlavních obrazovek, konkrétně {\it Profil}, {\it Hledat}, {\it Jednotka} a~{\it Více}, které slouží jako navigační panel pro různé agendy specifické pro danou obrazovku. Tyto obrazovky poskytují uživatelům rychlý a~jednoduchý přístup k~potřebným funkcionalitám aplikace.

\subsection{Profil}
Agenda Profil slouží ke správě agend, které jsou přímo spojeny s~účtem přihlášeného uživatele. Hlavní stránka pak slouží jako navigační panel k~dílčím agendám (Moje kurzy a~Sněmy), zobrazení emailů a~detailů uživatele (viz Obr.~\ref{fig:profile}). 

Na hlavní stránce jsou vždy zobrazeny tři nejnovější nepřečtené zprávy. V~případě, že žádné takové nejsou k~dispozici, je uživateli sdělena tato informace. Po kliknutí na zprávu se zobrazí její detail, kde má uživatel možnost ji smazat. Pro aktualizaci tří nejrelevantnějších zpráv, nebo pro zobrazení kompletní historie jsou nad seznamem zpráv umístěny dvě ikony.

\begin{figure}[!h]
  \begin{center}
    \includegraphics[width=\textwidth]{fithesis/images/implementace/profil.png}
  \end{center}
  \caption{Základní obrazovky agendy Profil zleva: Hlavní stránka, detail osoby, list emailů a~detail emailu.}
  \label{fig:profile}
\end{figure}

\subsection{Sněmy}
Agenda Sněmy umožňuje uživatelům zobrazit seznam sněmů dle zadaných filtrů a~řazení. Každý sněm následně nabízí možnost zobrazit informace o~jednotce, která daný sněm pořádá, nebo detaily k~samotném sněmu.

Detaily sněmu obsahují základní informace, například datum a~místo konání, a~díky ikoně mapy umožňují uživatelům zobrazit místo konání v~nativní aplikaci map v~daném zařízení. V~sekci podstránek pak uživatelé mohou nalézt seznam kandidátů, jejich profily. Po skončení sněmu je zde k~dispozici také přehled výsledků voleb a~v~neposlední řadě také předložená a~přijatá ustanovení (viz Obr.~\ref{fig:cong}).

\begin{figure}[!h]
  \begin{center}
    \includegraphics[width=\textwidth]{fithesis/images/implementace/snemy.png}
  \end{center}
  \caption{Základní obrazovky agendy Sněmy. Zleva: seznam sněmů, detail sněmu, volby a~kandidáti.}
  \label{fig:cong}
\end{figure}

\subsection{Moje kurzy}
Agenda Moje kurzy funguje obdobně jako agenda Sněmy, ale zaměřuje se na vzdělávací kurzy Junáka. Ty lze dále filtrovat a~řadit podle jejich parametrů, jako je typ kurzu, doba konání, aj. Každý kurz nabízí možnost zobrazit detaily kurzu, informace o~pořádající jednotce a~detail přihlášky (pokud je registrace spravována ve skautISu).

Detail kurzu obsahuje základní informace o~dané akci a~seznam všech kurzů, které jsou součástí této akce (často se konají dva typy kurzů ve stejný čas na stejném místě). Uživatel má také možnost se na kurz přihlásit, nastavit si upozornění na jeho začátek a~zobrazit další informace, včetně ilustračních fotografií. Dále je  možné procházet stav svých přihlášek a~odevzdání (viz Obr.~\ref{fig:actions}).

\begin{figure}[!h]
  \begin{center}
    \includegraphics[width=\textwidth]{fithesis/images/implementace/kurzy.png}
  \end{center}
  \caption{Základní obrazovky agendy Moje kurzy. Zleva: seznam kurzů, detail kurzu, stav a~odevzdání a~přihláška.}
  \label{fig:actions}
\end{figure}

\subsection{Jednotka}
Agenda Jednotka slouží k~řízení agend přímo spojených s~jednotkou relevantní pro aktuální uživatelskou roli. Na hlavní stránce je umístěn navigační panel pro dílčí agendy (Obecné akce, Tábory, Nábory a~Exporty), ale také zde uživatel najde detailní informace o~jednotce, seznam členů a~statistiky registrace (viz Obr.~\ref{fig:unit}). 

Detail jednotky zobrazuje nejen základní informace o~dané jednotce, ale také umožňuje procházet nadřazené a~podřazené jednotky. Dále poskytuje seznam obsazených funkcí v~rámci této jednotky.

\begin{figure}[!h]
  \begin{center}
    \includegraphics[width=\textwidth]{fithesis/images/implementace/jednotka.png}
  \end{center}
  \caption{Základní obrazovky agendy Jednotka. Zleva: hlavní stránka, detail jednotky, statistika registrace a~členové jednotky.}
  \label{fig:unit}
\end{figure}

\subsection{Nábory}
Agenda Náborů slouží pro správu náborů jednotky a~skládá se ze dvou hlavních obrazovek. První obrazovka zobrazuje informace o~náboru, umožňuje nastavit poznámku a~vytvořit termíny schůzek. Ty lze dále přiřazovat novým nebo existujícím náborovým kategoriím (benjamínci, vlčata, světlušky, skautky, skauti, ...). Druhá obrazovka je pak formulář umožňující rozeslání elektronické verze přihlášky (tzv. e-přihlášky) rodičům nováčků (viz Obr.~\ref{fig:nabor}).

\begin{figure}[!h]
  \begin{center}
    \includegraphics[width=\textwidth]{fithesis/images/implementace/nabory.png}
  \end{center}
  \caption{Základní obrazovky agendy Nábory Zleva: přehled náborů, odeslání e-přihlášky a~formuláře na editaci termínu schůzku a~kategorie.}
  \label{fig:nabor}
\end{figure}

\subsection{Tábory}
Agenda Tábory slouží pro správu letních, zimních a~putovních táborů a~vícedenních akcí o~délce alespoň pěti dní. Uživatelé mohou prohlížet seznam táborů jichž se účastní, případně je editovat, mají-li dostatečná oprávnění. 

V~detailu tábora jsou opět k~dispozici základní informace o~akci, místo konání, tým, účastníci a~stav odevzdávání (viz Obr.~\ref{fig:camp}).
Každý tábor nabízí také možnost zobrazit detail jednotky a~samotného tábora, a~kontaktovat vedoucího pomocí telefonního čísla skrze nativní aplikace mobilního zařízení.

\begin{figure}[!h]
  \begin{center}
    \includegraphics[width=\textwidth]{fithesis/images/implementace/akce.png}
  \end{center}
  \caption{Základní obrazovky agendy Tábory. Zleva: seznam táborů, detail tábora, formulář pro tvorbu tábora a~statistika účastníků.}
  \label{fig:camp}
\end{figure}

\subsection{Obecné akce}
Agenda Obecné akce umožňuje získat přehled o~dalších typech akcí, jako jsou víkendové výpravy či setkání, která nespadají do předchozích kategorií akcí. Uživatel zde může opět procházet a~vyhledávat akce, jichž se účastní, zobrazovat detaily a~akce spravovat za předpokladu, že má dostatečná oprávnění.

V~detailu akce jsou k~dispozici základní informace o~akci a~místě konání. Z~detailu je také možné prohlížet a~upravovat tým akce, který může zahrnovat například hlavního vedoucího nebo lékaře. Dále je zde k~dispozici statistika účastníků, které lze přidávat, editovat nebo mazat. Nakonec je zde k~dispozici zobrazení a~úprava zprávy z~akce a~stavu odevzdávání (viz Obr.~\ref{fig:actions}).

\begin{figure}[!h]
  \begin{center}
    \includegraphics[width=\textwidth]{fithesis/images/implementace/akce.png}
  \end{center}
  \caption{Základní obrazovky agendy Obecné akce. Zleva: seznam akcí, detail akce, seznam účastníků akce a~pořádající tým.}
  \label{fig:actions}
\end{figure}

\newpage
\subsection{Exporty}
Agenda Exporty slouží k~poskytnutí přehledu dostupných tiskových sestav a~detailů o~nich. V~případě, že jsou uvedeny e-mailové adresy nebo telefonní čísla, lze uživatelům posílat hromadné emaily a~SMS zprávy pomocí nativních funkcí zařízení. Kromě toho poskytuje možnost stažení vybrané tiskové sestavy ve formátech PDF nebo XLSX (viz Obr.~\ref{fig:exports}).

\begin{figure}[!h]
  \begin{center}
    \includegraphics[width=\textwidth]{fithesis/images/implementace/exporty.png}
  \end{center}
  \caption{Základní obrazovky agendy Exporty. Seznam tiskových sestav (vlevo) a~detail tiskové sestavy (vpravo).}
  \label{fig:exports}
\end{figure}

\subsection{Hledat}
Agenda Hledat poskytuje uživatelům snadné a~přehledné vyhledávání uživatelů, jednotek a~akcí a~zobrazování detailů odpovídajících návrhu příslušných agend. Tento nástroj umožňuje uživatelům efektivně a~rychle najít potřebné informace a~usnadňuje tak práci s~aplikací (viz Obr.~\ref{fig:find}).

\begin{figure}[!h]
  \begin{center}
    \includegraphics[width=\textwidth]{fithesis/images/implementace/hledat.png}
  \end{center}
  \caption{Základní obrazovky agendy Hledat. Zleva: hlavní stránka agendy, seznam akcí, seznam jednotek a~seznam uživatelů.}
  \label{fig:find}
\end{figure}

\subsection{Více}
Agenda Více poskytuje uživatelům podrobnější informace o~aplikaci, včetně historie změn a~licenčních práv na aplikaci (viz Obr.~\ref{fig:more}).

\begin{figure}[!h]
  \begin{center}
    \includegraphics[width=\textwidth]{fithesis/images/implementace/more.png}
  \end{center}
  \caption{Stránka agendy Více obsahující informace o~aplikaci.}
  \label{fig:more}
\end{figure}

\subsection{Majetek a~Hodnocení kvality}
U~všech zmíněných agend nebyla pouze provedena reimplementace, ale také opravy všech chyb a~úpravy návrhu aplikace s~cílem zjednodušit ovládání a~zvýšit uživatelskou přívětivost. Tím, že na aplikaci pracovalo postupně více lidí, některé části aplikace ani po redesignu nebyly kompatibilní a~nebo nefungovaly správně. Nejrozsáhlejší potenciální zásah by byl nutný především u~agend Majetek a~Hodnocení. U~agendy Majetku navíc v~průběhu času došlo k~významným změnám na straně serverové implementace a~hodnocení kvality není plošně v~Junáku příliš využíváno. Po domluvě s~vedoucím tak bylo rozhodnuto, že tyto agendy budou implementovány později, neboť jejich implementace by neúměrně navýšila rozsah této diplomové práce.


\section{Vybrané aspekty implementace}

Klíčovým faktorem implementace byl přehledný a~srozumitelný kód, který by měl umožnit snadné rozšíření aplikace. Vysokou kvalitu kódu pak podpořila implementace CI/CD (viz kapitola~\ref{c:cdid-implementace}). V~nové verzi aplikace tak byly integrovány návrhy na zlepšení a~opravy chyb, které byly identifikovány během analýzy předchozí verze (viz podsekce~\ref{s:function-problems},~\ref{s:design-problems}) a~bylo zapracováno i~několik nedostatků, které identifikovali uživatelé předchozích verzí a~nachází se v~seznamu požadavků v~repozitáři projektu na platformě Github. Ve zbytku kapitoly jsou představeny vybrané aspekty implementace, zahrnující použité koncepty i~řešení problémů s~nimiž jsme se při vývoji potýkali~\cite{UI}.

\subsection{Souborová struktura}

Souborová struktura původní aplikace byla příliš složitá a~nejasná, což vedlo k~problémům s~orientací v~kódu. Adresář pro každou hlavní obrazovku obsahoval adresáře {\it components} a~{\it containers}, které někdy obsahovaly pod-adresáře nejen pro danou obrazovku, ale i~pro všechny jí podřízené obrazovky. To mělo za následek složité zanořování a~ztrátu souvislostí kódu, například při zanoření do více než pěti pod-obrazovek. (viz podsekce~\ref{ss:souborova-struktura} a~ukázka~\ref{lst:structure-old}).

Pro zjednodušení a~zpřehlednění struktury nám potom stačily dva kroky. Za prvé bychom měli do každého kontejneru, který má nějakou podstránku, přidat další adresář s~názvem {\it containers} a~jeho podadresáři. Za druhé bychom měli složku {\it containers} umístit co nejníže podle její abstrakce. Například komponenta obsahující kontakty může být umístěna přímo v~kontejneru s~kontakty, jelikož se nikde jinde nepoužívá. Na druhé straně by komponenta s~formulářem již měla být umístěna dostatečně vysoko, aby ji viděly oba kontejnery. Jako příklad aplikace této struktury opět využijme obrazovku profilu, a~její pod-obrazovky detail profilu, formulář na vytvoření nového uživatele a~formulář na úpravu uživatele. (viz ukázka~\ref{lst:structure-new}).

\begin{lstlisting}[caption={Üpravená souborová strukturu použitá na příkladu.},label={lst:structure-new}]]
- pages
  - profile
    - containers
      - profile
          - source
          - components
            - profile-form
              - source
          - containers
            - profile-detail
              - source
              - containers
                - profile-edit
                  - source
            - profile-new
              - source
          - components
            - profile-contacts
              - source
\end{lstlisting}

Tato změna oproti původnímu přístupu jasněji zobrazuje, jaké jsou vztahy mezi obrazovkami a~tedy je i~snazší zorientovat se v~kódu. To je o~to důležitější vzhledem k~časté změně programátorů co na vývoji pracují.

\subsection{Optimalizace vykreslování dlouhých seznamů}

Aplikace Kapesní skautIS používá mnoho různých seznamů, což může být pro mobilní zařízení s~omezenými zdroji a~výkonem problematické. Vykreslování dlouhých seznamů v~React Native může způsobovat zpomalení aplikace a~snižovat její stabilitu~\cite{betterprogramming_render_large_lists}. Komponenty \texttt{FlatList}~\cite{reactnativeflatlist} a~\texttt{FlashList}~\cite{ShopifyFlashList} řeší tento problém tak, že vykreslují pouze ty položky seznamu, které jsou viditelné na obrazovce, což snižuje spotřebu paměti a~procesoru a~zlepšuje výkon aplikace.

\texttt{FlashList} je v~React Native lepší volbou pro vykreslování dlouhých seznamů než FlatList, neboť je rychlejší a~efektivnější než \texttt{FlatList}, protože nevyužívá výpočetně náročnou komponentu \texttt{VirtualizedList}. \texttt{FlashList} je také jednodušší na použití a~konfiguraci a~poskytuje pokročilé funkce, jako animace při rolování seznamu a~snadnou manipulaci s~jeho položkami (např. přesouvání nebo mazání)~\cite{shopify2021instant, flashlist}.

V~aplikaci Kapesní skautIS jsou použity oba přístupy na základě složitosti seznamu. Pokud seznam obsahuje složitější prvky, jako jsou obrázky nebo animace, je vhodnější použít \texttt{FlashList} pro lepší výkon a~uživatelskou zkušenost. Pokud však seznam obsahuje pouze jednoduché prvky, jako jsou nadpisy a~podnadpisy, je \texttt{FlatList} efektivnější a~rychlejší.

\subsection{Návrhový vzor Adaptér}

Návrhový vzor \textit{Adaptér}~\cite{adapterRefactoringGuru} se používá k~přizpůsobení rozhraní jedné třídy tak, aby vyhovovalo očekávání třídy jiné. Tento vzor umožňuje, aby spolu mohly spolupracovat i~třídy, které mají rozdílná rozhraní~\cite{sendgrid-adapter-pattern-react}.

V~aplikaci Kapesní skautIS jsou principy tohoto návrhového vzoru použity zejména na dvou místech. Za prvé v~extrahování nativních funkcí, což umožňuje snadnější změnu jejich funkcionality pro případné nové komponenty. Adaptér se používá k~přizpůsobení rozhraní nativních funkcí tak, aby odpovídaly požadavkům nových komponent. Za druhé, adaptér se používá v~práci s~API. API je strukturované podle různých zaměření, jako jsou {\it events}, {\it exports} atd. Každé zaměření obsahuje sadu cílových bodů. Tuto strukturu přesně kopíruje třída API v~aplikaci. Pro API cílový bod {\it CampAll} v~balíku {\it events} používá aplikace funkci \texttt{api.events.CampAllGet}. Tento přístup počítá s~budoucími změnami v~rámci API a~umožňuje pomocí návrhového vzoru adaptér měnit pouze některé části kódu tak, aby to neovlivnilo další fungování aplikace. Adaptér umožňuje snadno přizpůsobit API různým potřebám a~zároveň zachovat konzistentní rozhraní pro celou aplikaci.

\subsection{Načítání aplikace}

Aplikace sleduje stav načítání dat pro každé volání API zvlášť a~umožňuje okamžité zpracování určité části, jakmile jsou k~dispozici všechna potřebná data. Tento stav není uchováván globálně a~neovlivňuje tedy jiné obrazovky, což eliminuje problémy s~přetrvávajícím stavem, které se vyskytly v~předchozí verzi aplikace.

Při startu aplikace v~případě, kdy má uživatel platný přihlašovací token a~přeskočí fázi přihlášení, se vyskytuje problém s~nesprávně vykreslenou navigační lištou. Tento problém trvá až do doby, než jsou načteny všechny dotazy na databázi, které jsou potřebné pro správné zobrazení navigační lišty, jako je například profilový obrázek a~uživatelské role. Toto chování může uživateli působit dojmem, že je s~aplikací něco v~nepořádku.

Tento problém byl vyřešen pomocí načítací obrazovky. Aplikace si ukládá stav všech načítání probíhajících v~navigační liště a~načítací obrazovka zůstává zobrazena, dokud nejsou všechny potřebné dotazy načteny úspěšně. V~případě, že se některý dotaz nezdaří, zobrazí se patřičná chybová hláška. Tímto způsobem se zajišťuje správné zobrazení navigační lišty a~zabrání se bezpečnostním rizikům spojeným s~přístupem uživatele k~nedokončené aplikaci.



\subsection{Uživatelská oprávnění}

Problém s~původní verzí aplikace spočíval v~tom, že uživatel byl informován o~tom, že nemá dostatečná oprávnění ke provedení dané akce až po provedení samotné akce. Toto vedlo k~neúplným nebo rozbitým verzím aplikace (viz podsekce~\ref{ss:prava}). Pro řešení tohoto problému byl zvolen jiný přístup, kterým je preemptivní volání cílových bodů API předtím, než uživatel s~daty potřebuje reálně pracovat. Cílem je zjistit, zda požadavek proběhl bez problémů nebo s~chybovou hláškou. Tímto způsobem je možné zpřístupnit uživateli zobrazení dané stránky pouze tehdy, pokud má potřebná oprávnění a~naopak. Navíc se také díky přednačítání dat zlepšuje responzivnost aplikace, i~když za cenu zvýšeného počtu dotazů. Tímto způsobem bude uživatelům poskytnuta jasná a~srozumitelná informace o~jejich oprávněních a~zároveň se zvýší bezpečnost aplikace.

\subsection{Navigační lišta}

Původní aplikace měla problém s~nekonzistencí navigační lišty na domovských obrazovkách (viz podsekce~\ref{ss:navbar}). Aby se tento problém vyřešil, byla použita hlavní navigační lišta, která se doposud objevovala pouze v~profilové obrazovce, pro všechny čtyři obrazovky. Tímto způsobem je možné upravovat role napříč všemi obrazovkami (viz Obr.~\ref{fig:new-navbar}). V~budoucnu mohou být tlačítka pro odhlášení a~zobrazení detailů profilu nahrazena jinými tlačítky v~závislosti na obrazovce, se kterou uživatel pracuje.

\begin{figure}[!ht]
  \begin{center}
    \begin{minipage}{.24\textwidth}
      \includegraphics[width=\textwidth]{fithesis/images/navbar/new-screen-4.jpg}
    \end{minipage}
    \hfill  % Fill the horizontal space between the images
    \begin{minipage}{.24\textwidth}
      \includegraphics[width=\textwidth]{fithesis/images/navbar/new-screen-2.jpg}
    \end{minipage}
    \hfill 
    \begin{minipage}{.24\textwidth}
      \includegraphics[width=\textwidth]{fithesis/images/navbar/new-screen-1.jpg}
    \end{minipage}
    \hfill 
    \begin{minipage}{.24\textwidth}
      \includegraphics[width=\textwidth]{fithesis/images/navbar/new-screen-3.jpg}
    \end{minipage}
  \end{center}
\caption{Navigační lišta v~primárních obrazovkách aplikace.}
  \label{fig:new-navbar}
\end{figure}

\subsection{Chybové hlášky}

Cílem bylo zajistit jednotný způsob práce s~chybovými hláškami v~aplikaci a~vyvarovat se tak problému, který trápil původní verzi, v~níž byly použity hned tři typy hlášek (viz podsekce~\ref{ss:errors}). Pro aktuální verzi aplikace byla zvolena {\it Feedback} zpráva. Tento typ zprávy umožňuje uživateli okamžitou zpětnou vazbu o~akci, kterou právě provedl, a~zároveň zobrazuje případné chybové hlášky. Použitím jednotného typu hlášek se zvyšuje srozumitelnost aplikace pro uživatele a~zlepšuje se také její celková uživatelská přívětivost.

\chapter{Implementace CI/CD}
\label{c:cdid-implementace}

V~této kapitole se budeme věnovat realizaci průběžné integrace a~nasazování (CI/CD) pro aplikaci Kapesní skautIS. Nejprve jsou podrobněji představeny nástroje Husky hooks~\cite{husky} a~Github akce~\cite{githubactions}, které jsme použili pro implementaci CI/CD procesů, následně je vysvětleno jejich použití pro implementaci průběžné integrace a~nasazení v~kontextu aplikace Kapesní skautIS.

\section{Husky hooks}
V~moderním vývoji softwaru je automatizace procesů klíčová pro efektivitu a~úspěšnost projektů. Jedním z~nástrojů, které pomáhají vytvořit automatizované postupy integrace a~nasazení, jsou {\it git hooks}. Tyto skripty umožňují spouštění určitých akcí v~repozitáři při určitých událostech, například před vložením nového kódu (tzv. \textit{commit}) nebo před sloučením větve. V~průběžné integraci a~nasazení (CI/CD) jsou git hooks klíčové pro zajištění kvality kódu a~standardizaci vývojového procesu. Jedním z~nástrojů pro správu git hooks v~JavaScriptu jsou Husky hooks, které umožňují spouštění různých testů a~kontrol před odesláním změn do hlavní větve. V~tomto kontextu jsou Husky hooks nedílnou součástí celého procesu CI/CD. V~této kapitole se budeme věnovat implementaci Husky hooks pro aplikaci Kapesní skautIS.

\subsection{Implementace Husky hooks}
V~aplikaci Kapesní skautIS jsou používány dva typy Husky hooks pro Git -- {\it pre-commit hook}, který kontroluje kvalitu kódu a~zabrání možným chybám, a~{\it commit-msg hook}, který ověřuje správnost zprávy commitu.

\subsubsection{Ověřování kvality kódu}
Při provádění commitu v~Gitu je spuštěn {\it pre-commit hook}, který umožňuje spustit různé testy a~skripty, které ověřují správnost a~kvalitu kódu. V~případě úspěšného dokončení těchto testů se commit provede a~změny jsou odeslány do repozitáře. Pokud testy selžou, commit je zastaven a~vývojář musí opravit chyby v~kódu.

V~aplikaci Kapesní skautIS jsou v~rámci \textit{pre-commit} fáze spouštěny dva skripty. První z~nich je \texttt{npx lint-staged}, což je nástroj pro spouštění {\it linterů} a~dalších statických analýz nad změněnými soubory v~repozitáři. Jako linter je použitý nástroj ESLint\footnote{ESLint: \url{https://eslint.org/}.} a~pro formátování kódu Prettier\footnote{Prettier: \url{https://prettier.io/}.}. Při provádění commitu jsou vybrány změněné soubory, které jsou odeslány na vstup linterů a~dalších nástrojů. Pokud {\it lint-staged} nalezne chyby nebo nekonzistence, proces commitu je ukončen s~chybovým kódem. Tímto způsobem může {\it lint-staged} zabránit odeslání chybného kódu do repozitáře a~zvýšit tak kvalitu kódu.

Druhým skriptem spuštěným v~rámci hooku {\it pre-commit} je \texttt{npx tsc --noEmit}, který kontroluje syntaxi a~typy v~souborech s~kódem TypeScriptu. Pokud byly nalezeny chyby, commit je zastaven a~vývojář musí chyby opravit.

\subsubsection{Ověřování validity zprávy commitu v~Gitu}
Při provádění commitu v~Gitu se spouští další hook s~názvem {\it commit-msg}. Ten umožňuje definovat pravidla pro zprávy commitů, která musí být dodržena v~celém týmu vývojářů, aby byla zajištěna konzistence a~kvalita zpráv v~commitu.

V~implementaci aplikace Kapesní skautIS v~rámci tohoto hooku je použit nástroj {\it commitlint}\footnote{Commitlint: \url{https://commitlint.js.org/}.}, který umožňuje definovat pravidla pro formátování zpráv commitů a~ověřovat, zda jsou tato pravidla dodržena. V~této aplikaci jsou použita tato pravidla:

\begin{compactitem}
  \item Zpráva commitu musí začínat názvem zmenšeného nástroje, například \texttt{feat}, \texttt{fix}, \texttt{docs}, \texttt{test} nebo \texttt{chore}.
  \item Za názvem nástroje musí následovat dvojtečka a~mezera.
  \item Následuje stručný popis změny, který začíná velkým písmenem a~končí bez tečky.
  \item Pokud je to nutné, následuje podrobný popis změny na novém řádku, který také musí začínat velkým písmenem a~končit bez tečky.
\end{compactitem}

V~případě, že zpráva commitu neodpovídá těmto pravidlům, {\it commit-msg} hook zastaví proces commitu a~vývojáři musí upravit zprávu tak, aby odpovídala stanoveným pravidlům.

Díky použití {\it commit-msg} hooku s~nástrojem {\it commitlint} je zajištěna konzistence zpráv commitů v~týmu vývojářů a~usnadněna správa historie změn v~repozitáři.

\section{Github akce}

Github akce jsou automatizované skripty, které se spouštějí v~závislosti na určitých událostech v~repozitáři. V~porovnání s~Husky hooks se spouštějí až po vložení kódu do repozitáře. Tyto akce mohou být využity k~mnoha účelům, například ke spouštění testů, kompilaci a~publikaci balíčků, nasazování aplikací a~dalším.

Při vývoji aplikace se řídíme Git flow workflow (viz podsekce~\ref{s:gitflow}), který zahrnuje tři hlavní větve: \texttt{master}, \texttt{release} a~\texttt{feature}. \texttt{Master} větev slouží k~vývoji testovací verze aplikace, zatímco \texttt{release} větev se používá k~nasazování aplikace do produkčního prostředí. Pro vývoj nových funkcí jsou vytvářeny \texttt{feature} větve, které se odvozují z~\texttt{master} větev a~po dokončení se slévají zpět do \texttt{master} větev. Do \texttt{release} větve lze nahrát pouze otestovanou \texttt{master} větev (viz Obr.~\ref{fig:gitflow}).

\begin{figure}[!ht]github-actions-book
  \begin{center}
    \includegraphics[width=\textwidth]{fithesis/images/gitflow.png}
  \end{center}
  \caption{Diagram aplikované Git flow.}
  \label{fig:gitflow}
\end{figure}

V~rámci Git flow workflow využíváme právě Github akce pro automatizaci tří akcí. První dvě jsou zaměřeny na nasazování nových verzí aplikace. První akce ověřuje kvalitu kódu a~funkčnost aplikace a~druhá slouží k~nasazení nových verzí do testovacího prostředí. Třetí akce se zaměřuje na nasazení nových verzí do produkčního prostředí.

Všechny tři akce mají společný soubor {\it action.yml}, který definuje akci {\it setup-frontend-job} s~popisem, vstupy a~kroky, které musí být vykonány. Tento soubor obsahuje kroky pro instalaci a~správu závislostí, jako je instalace Node.js verze 16.x\footnote{Node.js: \url{https://nodejs.org/en}.}, cachování {\it node modules}\footnote{{\it node modules}: složka v~Node.js projektu, kde jsou uloženy závislosti projektu v~podobě balíčků.} a~instalace balíčků spolu se všemi závislostmi. Dále, každá akce vyžaduje povinný vstup {\it gh access key}, který se používá pro ověření přístupu k~repozitáři. Tyto kroky jsou společné pro všechny tři akce.

\subsection{Syntaktická analýza kódu a~spouštění testů}

V~souboru s~názvem {\it pull-request.yml} je definována akce, která se spouští na Pull requesty na větvi \texttt{master}. Tato akce obsahuje tři oddělené úlohy ({\it jobs}) -- Test, Lint a~Typescript, přičemž každá úloha má své vlastní kroky. Definovány jsou i~společné kroky, jako například ověření kódu ze správné větve pomocí akce {\it checkout@v2} a~nastavení a~instalace balíčků pro následující skripty pomocí akce {\it setup-frontend-job}. První úloha, 
\textit{Test}, spouští testovací skript příkazem \texttt{npm test}. Úloha \textit{Lint} spouští skript pro ověření syntaktické správnosti kódu příkazem \texttt{npm run lint}, a~úloha \textit{Typescript} spouští skript pro ověření syntaxe TypeScriptu pomocí příkazu \texttt{npm run tscheck}. Tyto skripty se spouštějí na celou aplikaci, na rozdíl od Husky hooks, které se spouštějí pouze na změny v~kódu.

\subsection{Expo Release Channels}
\label{s:expo-chanels}

Expo Release Channels~\cite{expo-release-channels} je nástroj, který umožňuje vývojářům aktualizovat své aplikace na Expo platformě bez nutnosti aktualizovat celou aplikaci přes App Store nebo Google Play. Expo Channels fungují tím, že umožňují vývojářům distribuovat a~nasazovat různé verze své aplikace různým skupinám uživatelů.

Každý kanál má svoje vlastní URL, které umožňuje uživatelům stáhnout novou verzi aplikace přímo z~Expo serveru. Uživatelé si pak mohou stáhnout aplikaci přímo z~kanálu, aniž by museli procházet App Store nebo Google Play a~to za pomocí Expo aplikace Expo Go\footnote{Expo Go: \url{https://expo.dev/client}.}. Největší výhodou tohoto přístupu je, že pro vydání nové verze nemusí být provedena žádná dodatečná akce, jak tomu je při práci s~testovacími verzemi přímo skrze obchody.

Aplikace Kapesní skautIS disponuje dvěma kanály, konkrétně {\it test} a~{\it prod}. Kanál {\it test} se aktivuje při spuštění akce {\it Deploy to Test}, která má za úkol aktualizovat tento kanál po nahrání kódu do větve {\it master}. Tento kanál je určen k~testování aplikace, jak již napovídá jeho název.

Pro budoucí vývoj plánujeme využívat správnou instanci skautIS API podle toho, zda se jedná o~produkční nebo testovací kanál. V~současné době však pro oba kanály používáme testovací instanci API. Pokud bychom chtěli využívat produkční instanci API, museli bychom provést patřičné úpravy v~konfiguračních souborech na straně API. Bohužel, kvůli tomu, že skautIS API spravuje třetí strana, je to pro nás v~této fázi vývoje překážkou.

Kanál {\it prod} je začleněn do posledního procesu s~názvem {\it production.yml}. Jeho funkce je podobná jako u~kanálu test, s~jediným rozdílem -- reaguje na nahrání kódu do větve {\it release}. Účelem kanálu {\it prod} je poskytnout jednoduchý způsob kontroly produkční verze aplikace před jejím nasazením do obchodu.

\subsection{Nasazení aplikace do obchodů}

Zatímco testovací akce se zaměřuje pouze na nasazení aplikace pomocí Expo Release Channel, produkční akce obsahuje další kroky. Ty zahrnují sestavení a~nasazení aplikace na obchody s~aplikacemi. K~tomuto účelu se využívá nástroj EAS~\cite{eas} ({\it Expo Application Services}). EAS umožňuje snadné a~efektivní sestavení aplikace pro všechny platformy a~následné nasazení na obchody s~aplikacemi jako jsou Google Play nebo App Store. 

Aby tato akce fungovala, je nejprve nutné aplikaci nasadit manuálně a~patřičně ji nakonfigurovat. Jakmile je tento proces dokončen, akce funguje automaticky pro všechny nové verze aplikace, které jsou posílány do vývojářských konzolí obchodů. Zde pak čekají na zveřejnění, které musí proběhnout manuálně.

\subsubsection{Prvotní s~nasazení aplikace Kapesní skautIS}

Při práci s~platformou Expo a~nástrojem EAS je nutné mít certifikát a~privátní klíč pro podepsání aplikace pro obě platformy (iOS a~Android). Pro iOS je nutné vytvořit certifikát a~privátní klíč pomocí Apple Developer účtu a~nahrát je do EAS a~Expo CLI\footnote{Expo CLI: \url{https://docs.expo.io/workflow/expo-cli/}.} pro sestavení a~podepsání aplikace pro iOS~\cite{deploy-ios}. Pro Android se používá Keystore, který lze vygenerovat pomocí Expo CLI a~poté je nutné tento soubor nahrát do EAS a~Expo CLI pro sestavení a~podepsání aplikace pro Android~\cite{deploy-android}.

Během procesu nasazování aplikace Kapesní skautIS se objevil problém spojený s~Keystore, který je často běžný při aktualizaci aplikace, zejména pokud předchozí verze aplikace v~Google Play využívala Keystore s~jiným kódovým základem. Při pokusech o~nahrání nové verze aplikace nebo extrahování původního Keystore souboru se nedosáhlo úspěchu, protože by to znamenalo obejít ochranu Keystore, která slouží k~zajištění, že všechny verze aplikace pocházejí ze stejného zdroje. V~této konkrétní situaci bylo nutné stáhnout aplikaci z~veřejné části obchodu\footnote{V současnosti není možné aplikace z~obchodů zcela smazat. Jejich správce je může pouze zneplatnit, čímž znemožní jejich vyhledání a~instalaci uživateli.} a~vytvořit novou verzi s~korektně nakonfigurovaným Keystore.

Po vytvoření konfigurace k~sestavení je možné sledovat průběh a~výsledky na stránce s~výsledky. Ty jsou k~dispozici v~Expo konzoli\footnote{Expo konzole: \url{https://expo.dev/}.}, jež slouží pro správu verzí aplikací. Poté již stačí stáhnout aplikaci z~konzole a~nahrát ji manuálně do obchodů, kde je třeba nastavit všechny potřebné konfigurace (mj. popis aplikace, fotky, cílová skupina). 


\chapter{Uživatelské testování}
\label{c:test}

Pro ověření funkčnosti aplikace Kapesní skautIS bylo vhodné aplikaci podrobit uživatelskému testování. Testování probíhalo ve spolupráci s~vybranými členy organizace Junák, kteří představují cílovou skupinu uživatelů aplikace. Cílem testování bylo odhalit co nejvíce chyb a~nedostatků v~aplikaci a~zlepšit tak uživatelskou přívětivost a~stabilitu aplikace. Testování proběhlo ve dvou kolech v~lednu a~březnu 2023 a~celkem jsme získali pět odpovědí.

Testování probíhalo pomocí aplikace Expo Go\footnote{Expo Go: \url{https://expo.dev/client}.}, která umožňuje testování mobilních aplikací na reálných zařízeních. K~tomu bylo nutné stáhnout Expo Go z~obchodu s~aplikacemi a~přihlásit se pomocí testovacího účtu. Pro zajištění kvality byly testy prováděny přes kanál {\it test} (viz podsekce~\ref{s:expo-chanels}), který je součástí nastavených strategií {\it Continuous Integration/Continuous Deployment} (CI/CD).

Testování aplikace bylo prováděno ve dvou kolech s~cílem získat co nejkomplexnější zpětnou vazbu od různých uživatelů. Každé kolo se skládalo z~řady testovacích úkolů a~otázek, které byly navrženy tak, aby ověřily funkčnost nově implementované funkcionality a~poskytly co nejpodrobnější informace o~aplikaci. Otázky byly strukturovány a~distribuovány pomocí online formuláře v~Google Forms a~byly zaměřeny na testované agendy, uživatelskou přívětivost a~stabilitu aplikace. Testovací úkoly byly rozděleny na dva typy -- konkrétní úkoly a~obecné poznatky. Konkrétní úkoly měly za úkol otestovat funkčnost konkrétních agend, zatímco obecné poznatky se zaměřovaly na celkový dojem z~aplikace a~uživatelskou přívětivost. Po dokončení testování byly výsledky pečlivě sbírány a~analyzovány s~cílem získat užitečné zpětné vazby a~identifikovat případné nedostatky v~aplikaci.

\section{První testovací kolo}

V~lednu 2023 bylo provedeno první testovací kolo. Cílem testování bylo otestovat agendy Jednotka, Profil, Moje kurzy a~Sněmy. Testování probíhalo pomocí formuláře dostupného na adrese \url{https://forms.gle/qZ8fdHpJwBG85jjP8}. Běžným nedostatkem byly překliky, a~to jak na straně aplikace (např. špatně popsaná položka), tak i~na straně kódu, kde například neshodovaly klíče pro řazení seznamu a~to pak nefungovalo správně.

Během prvního testovacího kola se objevil významný problém s~přetékáním seznamů na menších displejích (úhlopříčka menší než 5"). Původní řešení spočívalo v~zadávání počtu pixelů pro stylování seznamu, avšak tento přístup způsoboval problémy. Proto byla tato funkce upravena s~využitím kontejneru Flex-Box pro nastavení rozmístění prvků na webové stránce. To zajistilo, že se seznamy vykreslují správně bez ohledu na velikost displeje.

\section{Druhé testovací kolo}
V~březnu poté proběhlo i~druhé testovací kolo. Cílem testování bylo otestovat agendy Tábory, Obecné akce a~Exporty. Testování probíhalo pomocí formuláře dostupného na adrese \url{https://forms.gle/58RcJUCGbsAkrDnKA}.

Během tohoto kola testování se objevily minimální problémy a~jedinou významnou chybou byla neschopnost stáhnout tiskové soubory na zařízeních s~operačním systémem iOS. Tato chyba byla způsobena použitím knihovny, která není kompatibilní s~platformou iOS. Jakmile byla chyba identifikována, stačilo doplnit dodatečnou implementaci specifickou pro iOS, čímž se podařilo dosáhnout plné funkčnosti pro obě platformy.

Ačkoliv je zjevným omezením nízký počet respondentů (dáno překvapivě malým zájmem ze strany oslovených členů Junáka), považujeme tento způsob testování jako vhodný i~do budoucna, neboť využití Google Formuláře jako návodu a~průvodce testováním umožňuje snadnou administraci i~zpracování získaných dat.

\chapter{Závěr}
\label{c:zaver}

Tato diplomová práce se věnovala problematice vývoje mobilních aplikací a~způsobům umožňujícím zlepšit kvalitu aplikací pomocí automatizace a~testování. Hlavní motivací práce však byla analýza stávající podoby mobilní aplikace Kapesní skautIS, revize funkcionality a~její následná implementace.

Na základě získaných poznatků byla v~praktické části práce vytvořena nová verze mobilní aplikace Kapesní skautIS, která využívá programovacího rámce React Native. Vznikly tak mobilní aplikace pro oba hlavní operační systémy (iOS a~Android) pomocí jednoho kódu.
Nová verze aplikace Kapesní skautIS, která umožňuje práci s~agendami Profilu, Směrů, Kurzů, Jednotek, Náborů, Táborů, Obecných akcí, Hledání a~Více. Cílem bylo zachovat původní funkcionalitu, ale opravit funkční a~logické problémy tak, aby výsledná aplikace zlepšila uživatelský zážitek z~jejího používání. Uzavřené testování pak pomohlo odhalit nedostatky implementace, které byly následně opraveny.

Implementace nové verze aplikace zahrnovala také implementaci strategií pro kontinuální integraci a~doručování (CI/CD). Tyto strategie umožnily efektivnější a~průběžnou integraci nových funkcí a~
zefektivnění procesu jejich sestavení a~nasazení do obchodů s~aplikacemi Google Play a~Apple App Store. Tím se zkrátil čas mezi vývojem a~uvedením nových verzí aplikace do provozu, což přináší výhody pro uživatele. 

Tato diplomová práce ukázala možnosti využít moderních přístupů při vývoji mobilních aplikací a~demonstrovala je na nové verzi aplikace Kapesní skautIS. Jako jeden z~dalších kroků by mělo proběhnout širší testování. Navázat lze i~s~implementací dalších agend, ať už Majetku, hodnocení kvality či např. seznamu základen. Díky nastaveným postupům a~doporučením pro vývoj by další rozvoj aplikace již měl být také snáze udržitelný.

\appendix
\chapter{Obsah přílohy v~IS MU}
Přiložený {\it zip} soubor, který je nahrán v~Informačním systému Masarykovy univerzity, obsahuje následující přílohy:

\begin{itemize}
  \item Zdrojové soubory textu práce.
  \item Zdrojové kódy aplikace.
  \item Instalační soubor aplikace pro Android ve formátu \texttt{apk}.
  \item Textový soubor s~přihlašovacími údaji testovacích účtů do aplikace.
  \item PDF se snímky obrazovek.
\end{itemize}

\printbibliography[heading=bibintoc] %% Print the bibliography.


\end{document}
