%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%% 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[
  printed, 
  twoside, 
  table,  
  nolof,   
  nolot,    
]{fithesis3}

\usepackage[resetfonts]{cmap} %% We need to load the T2A font encoding
\usepackage[T1,T2A]{fontenc}  %% to use the Cyrillic fonts with Russian texts.
\usepackage[main=czech,english]{babel} %% foreign texts to be typeset as follows:
\usepackage{paratype}
\def\textrussian#1{{\usefont{T2A}{PTSerif-TLF}{m}{rm}#1}}

%% The following section sets up the metadata of the thesis.
\thesissetup{
    date          = \the\year/\the\month/\the\day,
    university    = mu,
    faculty       = fi,
    type          = bc,
    author        = Jan Crha,
    gender        = m,
    advisor       = {RNDr. Vít Rusňák, Ph.D.},
    title         = {Mobilní aplikace \\pro správu majetku},
    TeXtitle      = {Mobilní aplikace \\pro správu majetku},
    keywords      = {skaut, Junák, inventarizace, skautIS, mobilní apliakce, iOS, Android, NativeScript},
    TeXkeywords   = {skaut, Junák, inventarizace, skautIS, mobilní aplikace, iOS, Android, NativeScript},
    abstract      = {Práce se zabývá analýzou, návrhem a implementací mobilní multiplatformní aplikace pro inventarizaci a správu majetku skautské organizace Junák -- český skaut, z.s. V~současnosti se pro tyto účely používá webový informační systém skautIS, který není optimalizován pro mobilní zařízení. V~toretické části jsou nejprve představeny technologie umožňující multiplatformní vývoj pro mobilní zařízení, následně je analyzováno stávající řešení systému skautIS a nakonec je rozebrán návrh aplikace. V~praktické části jsou představeny použité technologie, komunikace s~webovými službami systému skautIS a implementační detaily. Výstupem práce je mobilní aplikace poskytující popisovanou funkcionalitu.
    				},
    thanks        = {Rád bych na tomto místě poděkoval svému vedoucímu RNDr. Vítu Rusňákovi, Ph.D., za odborné vedení, rady, konzultace a pomoc při řešení problémů.
    				},
    bib           = example.bib,
}
\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[hyphens]{url}      %% Hyperlinks
\usepackage{markdown} %% Lightweight markup
\usepackage{listings} %% Source code highlighting
\lstset{
  basicstyle      = \ttfamily,%
  identifierstyle = \color{black},%
  keywordstyle    = \color{blue},%
  keywordstyle    = {[2]\color{cyan}},%
  keywordstyle    = {[3]\color{olive}},%
  stringstyle     = \color{teal},%
  commentstyle    = \itshape\color{magenta}}
\usepackage{floatrow} %% Putting captions above tables
\usepackage{todonotes}
\usepackage{textcomp}

\begin{document}

\hypertarget{uxfavod}{%
\chapter{Úvod}\label{uxfavod}}

Junák je v~současné době na území České republiky největší organizací
hlásící se ke skautským myšlenkám. Jedná se o~dobrovolný, nezávislý a
nepolitický spolek, jehož posláním a účelem je podporovat rozvoj
osobnosti mladých lidí \hyperlink{1}{{[}1{]}}. Celosvětově má skautské hnutí více než
50 milionů registrovaných členů ve 216 zemích a teritoriích. Junák
v~České republice\footnote{Junák je členem světových organizací WOSM --
  World Organization of the Scout Movement a WAGGGS -- World Association
  of Girl Guides and Girl Scouts} momentálně sdružuje přes 60 000 členů
ve více než 2000 oddílech \hyperlink{2}{{[}2{]}}. Od roku 2006 Junák zdvojnásobil svoji
členskou základnu \hyperlink{3}{{[}3{]}}.

Základní výchovnou jednotkou Junáka jsou oddíly. Ty jsou zpravidla
tvořeny 20--50 osobami a dále se dělí na menší celky tzv. družiny.
Oddíly a družiny ale nejsou jednotkami v~právním smyslu, protože nejsou
právnickými osobami. Základní právní jednotkou Junáka jsou tzv.
Střediska (podle občanského zákoníku se jedná o~pobočné spolky).
Střediskům jsou nadřazeny vyšší organizační jednotky, kterými jsou
skautské okresy a kraje. Statutárním orgánem je Starosta Junáka, který
řídí Výkonnou radu. Strategické směřování organizace je pak v~kompetenci
Náčelnictva Junáka a kontrolním orgánem je Ústřední revizní komise. Tyto
subjekty jsou pak sdruženy v~tzv. Ústředí. S~výjimkou Starosty a
některých členů Výkonné rady se jedná o~dobrovolnické pozice.
O~administrativní podporu na nejvyšší úrovni se stará Kancelář ústředí
Junáka.

Střediska Junáka zpravidla disponují nějakým majetkem. Ten jsou podle
zákona č. 563/1991 Sb. o~účetnictví povinna inventarizovat a zároveň
musí být schopna prokázat provedení inventarizace u~veškerého majetku a
závazků po dobu 5 let po jejím provedení \hyperlink{4}{{[}4{]}}.

Tento zákon popisuje dva typy inventarizace, fyzickou a dokladovou.
Fyzická inventarizace se týká majetku, u~kterého lze vizuálně zjistit
jeho existenci. Dokladová inventarizace probíhá u~závazků a majetku,
u~kterých nelze vizuálně zjistit jejich existenci, a to včetně jiných
aktiv, jiných pasiv a skutečností účtovaných v~knize podrozvahových účtů
\hyperlink{4}{{[}4{]}}. Tato práce se dále zabývá pouze fyzickou inventarizací.

Podle vnitřních směrnic Junáka provádí inventarizaci tzv. Inventarizační
komise. Ta má povinnost zkontrolovat stav všech položek skladu \hyperlink{5}{{[}5{]}}.
V~současnosti probíhá inventarizace ručně za pomoci zapisování
aktuálního stavu každé položky. Takto inventarizované položky je poté
nutno dohledat v~systému skautIS (viz kapitola~\ref{informaux10dnuxed-systuxe9m-skautis}) a manuálně vložit
inventuru do systému.

Cílem této práce je navrhnout mobilní multiplatformní aplikaci
podporující systémy iOS a Android, která usnadní práci správcům majetku
Junáka tím, že umožní kontrolovat stav majetku z~mobilního zařízení a
provádět elektronickou inventarizaci přímo na místě skladu, a to včetně
režimu inventarizace skenováním QR a čárových kódů. Aplikace bude
podporovat možnost inventarizovat majetek bez připojení k~internetu a
označené předměty následně manuálně synchronizovat se serverem. Mimo
těchto funkcí umožní aplikace doplnit chybějící fotografii u~předmětu a
prohlížet a rezervovat veřejně dostupný majetek Junáka.

Předkládaná práce se skládá ze šesti kapitol. Ve druhé kapitole jsou popsány
dostupné technologie pro vývoj multiplatformních mobilních aplikací.
Třetí kapitola se zaměřuje na představení systému skautIS, analýzu agend
majetku jednotky a rezervace majetku a v~jejím závěru je identifikována
klíčová funkcionalita těchto agend, kterou bude poskytovat vyvíjená
aplikace. Ve čtvrté kapitole je představen návrh vyvíjené mobilní
aplikace. Pátá kapitola popisuje samotný proces implementace. Na začátku
kapitoly je představen způsob komunikace se službami systému skautIS a
následně jsou popsány zvolené technologie a uživatelské rozhraní.
Závěrečná kapitola shrnuje získané poznatky a výsledky práce.


\hypertarget{multiplatformnuxed-vuxfdvoj-mobilnuxedch-aplikacuxed}{%
\chapter{Multiplatformní vývoj mobilních
aplikací}\label{multiplatformnuxed-vuxfdvoj-mobilnuxedch-aplikacuxed}}


Vývoj softwaru je proces časově i finančně náročný. V~současnosti
existují dvě dominantní mobilní platformy, které jsou vzájemně naprosto
nekompatibilní -- iOS a Android. To znamená, že v~případě požadavku na
vývoj čistě nativní aplikace, podporující obě výše zmíněné platformy,
musejí být vyvíjeny dvě kompletně oddělené aplikace s~co nejpodobnějším
uživatelským rozhraním. Tento přístup je velmi náročný z~hlediska
lidských zdrojů a času. Vývoj zaměřený na konkrétní platformu vyžaduje
tým vývojářů s~konkrétními znalostmi daného operačního systému. Je to
způsobeno tím, že nativní vývoj pro platformu iOS lze uskutečnit
výhradně v~jazycích Objective-C a Swift \hyperlink{6}{{[}6{]}}. Android vývojáři se
zase musí spokojit s~jazykem Java, případně některým z~moderních jazyků,
které se do Javy kompilují\footnote{Například Kotlin nebo Groovy.}.

Právě kvůli výše zmíněným problémům vznikla v~posledních letech celá
řada nástrojů, které umožňují sdílení kódu mezi oběma platformami a tím
značně snižují čas i finance potřebné pro vývoj. Ty se dají rozdělit na
skupinu hybridních aplikací a skupinu nativních multiplatformních
řešení.


\hypertarget{hybridnuxed-aplikace}{%
\section{Hybridní aplikace}\label{hybridnuxed-aplikace}}


Hybridní mobilní aplikace je taková aplikace, která je napsána za
použití webových technologií\footnote{Typicky HTML5 + JavaScript.} a
následně je spouštěna v~nativním kontejneru na mobilním zařízení. Tímto
kontejnerem je komponenta WebView (UIWebVIew pro platformu iOS a WebView
pro Android). Hybridní aplikace umožňují využívat nativních
API\footnote{API (Application Programming Interface -- aplikační
  programové rozhraní) je sbírka funkcí, tříd, či celých knihoven, které
  programátor používá, aby dosáhl žádané funkcionality.} dané platformy
díky implementaci abstraktní vrstvy. Při kompilaci je pak skrze tuto
vrstvu JavaScriptový kód namapován na část nativního API zařízení.

K~výhodám takto psaných aplikací patří jednoduchost vývoje. Vývojář
nepotřebuje žádné specifické znalosti vývoje pro danou platformu a
vystačí si se zkušenostmi z~webového prostředí. Nespornou výhodou je
také téměř úplná možnost sdílení kódu mezi platformami. Toto sdílení
kódu může ale přinést i problémy, pokud zadavatel očekává nativní vzhled
a~chování aplikace. To se typicky pro jednotlivé platformy liší a
v~některých případech může způsobit stejný vzhled a~chování na platformách
iOS a Android špatnou uživatelskou zkušenost.

Mezi nevýhody hybridních aplikací patří například neúplnost přístupných
nativních API. Hlavní nevýhodou tohoto typu aplikací je ale výkon.
Aplikace běžící ve WebView kontejneru může nativní pocit poskytovat
pouze pokud není příliš složitá. Pokud od aplikace očekáváme práci
s~grafikou, případně operace nad velkým množstvím dat, bude výkonnostní
deficit oproti nativní aplikaci znatelný.


\hypertarget{nativnuxed-aplikace}{%
\section{Nativní aplikace}\label{nativnuxed-aplikace}}


V~posledních letech se objevila řada aplikačních rámců (frameworků)
umožňujících nový způsob vývoje multiplatformních mobilních aplikací.
Tyto technologie typicky samy generují část nativního kódu nutnou pro
sestavení aplikace na dané platformě. Takto vygenerovaný kód už
v~základních případech použití nevyžaduje od vývojáře žádnou modifikaci.
Výjimku tvoří situace, kdy aplikace potřebuje využít některé nativní
knihovny, které nejsou z~frameworku dostupné (může se jednat například
o~knihovny připojených zařízení jako jsou čtečky platebních karet apod.) a
situace, kdy aplikace k~provozu potřebuje uživatelem speciálně potvrdit
některá práva, jako například přístup k~lokaci zařízení. V~případě
potvrzení práv bývá nicméně zásah do vygenerovaného kódu velmi malý a
v~drtivé většině případů existují velmi podrobné návody, jak výsledku
dosáhnout.

Mimo takto vygenerovaný kód už vývojář může používat jednu kódovou
základnu pro celý projekt a nemusí se starat o~kompatibilitu
jednotlivých platforem. Co tento přístup odlišuje od hybridních aplikací
je fakt, že kód aplikace neběží v~žádném kontejneru, ale je překládán
přímo do nativních komponent pomocí volání API dané platformy. To
umožňuje získat z~jednou napsaného kódu skutečně nativní vzhled a
chování pro jednotlivé platformy. V~ideálním případě tak uživatel vůbec
nepozná, že nepoužívá aplikaci napsanou výlučně pro danou platformu.

Mimo nativní vzhled a chování takto napsané aplikace, patří mezi výhody
multiplatformního vývoje zejména výkon, který by se ve většině případů
měl blížit nativním aplikacím. Stejně jako u~hybridních aplikací i
u~multiplatformních nativních technologií jsou podstatně nižší nároky na
vývojový tým. Aplikace je psána v~jednom jazyce nezávisle na platformě.
Další výhodou je, že většina těchto frameworků podporuje nějakou
variantu flexboxu\footnote{Flexbox (Flexbox Layout) -- umožňuje
  kontejneru měnit velikost prvků v~něm umístěných takovým způsobem, aby
  co nejlépe vyplnily dostupné místo.}, který funguje stejně jako
v~CSS\footnote{CSS (Cascading Style Sheets -- kaskádové styly) je jazyk
  umožňující popsat způsob zobrazení elementů na stránce.}. S~využitím
flexboxu je možné bez nutnosti speciálních optimalizací dosáhnout
stejného vzhledu aplikace na různých velikostech obrazovek, což
u~nativních aplikací nemusí být vždy jednoduché. Jednou z~důležitých výhod
tohoto typu vývoje je, že většina nativních multiplatformních frameworků
zpřístupňuje vývojářům celé nativní API. To znamená, že i v~případě, kdy
daný framework přímo neposkytuje požadovanou funkcionalitu
multiplatformně, vývojář je stejně schopen cíle dosáhnout voláním
nativních funkcí pro konkrétní platformy.

Hlavní nevýhodou tohoto typu vývoje je, že dostupné multiplatformní
technologie jsou poměrně nové (v~reálném vývoji se začaly více používat
před 3--4 roky) a všechny problémy ještě nemusí být objeveny, případně
odladěny. Zároveň to znamená, že dostupná dokumentace je ne vždy
vyčerpávající a často je potřeba ověřit hledanou informaci z~více
zdrojů. Nicméně s~tím, jak se tyto moderní technologie vyvíjejí, přibývá
i jejich uživatelů a získávají na důvěře.


\hypertarget{srovnuxe1nuxed-technologiuxed-pro-multiplatformnuxed-vuxfdvoj}{%
\section{Srovnání technologií pro multiplatformní
vývoj}\label{srovnuxe1nuxed-technologiuxed-pro-multiplatformnuxed-vuxfdvoj}}

\hypertarget{react-native}{%
\subsection{React Native}\label{react-native}}

React Native je jedním z~frameworků umožňujících multiplatformní vývoj.
Jedná se o~framework jazyka JavaScript. Za jeho správou a vývojem stojí
společnost Facebook a na trh byl uveden v~roce 2015. Vychází
z~frameworku React, který je používán pro webový vývoj. Stejně jako React
používá i React Native jednosměrný tok informací. Udržuje si hierarchii
komponent, ve které každá komponenta závisí jen na rodičovské komponentě
a svém vlastním stavu. Data tedy proudí pouze od rodiče k~dětem. Pokud
závisí rodičovská komponenta na stavu svého potomka, musí mu předat tzv.
callback\footnote{Callback funkce je funkce, kterou přijímá nějaká další
  funkce jako argument. Ta je potom zavolána zevnitř funkce, která ji
  přijala, aby vykonala žádanou akci.} funkci \hyperlink{7}{{[}7{]}}. Tento koncept
funguje do té doby, dokud vyvíjíme výhradně za použití tohoto
frameworku. React Native oproti většině ostatních multiplatformních
technologií neposkytuje celé nativní API. Pokud chceme v~aplikaci
kombinovat React Native a nativní API, které není React Nativem
zpřístupněno, musíme použít speciální propojovací mechanismus, který
umožní výměnu informací mezi těmito dvěma částmi \hyperlink{7}{{[}{7, 8}{]}}.

Za jednu z~hlavních výhod frameworku React Native lze považovat funkci
Hot Reload, která okamžitě promítne změny v~javascriptových souborech do
připojeného zařízení (případně simulátoru) a umožňuje vývojáři ihned
vizuálně ověřit výsledek jeho práce. Tato funkce šetří obrovské množství
času a umožní již během vývoje odhalit mnoho chyb. Mezi další výhody
patří například malá velikost aplikace, silně deklarativní základy
frameworku a rozsáhlá uživatelská komunita.

Pravděpodobně největším problémem tohoto frameworku je fakt, že
neposkytuje přístup k~celému nativnímu API. Kvůli tomuto nedostatku
můžou často nastat situace, kdy se vývojář neobejde bez základních
(případně pokročilých) znalostí programování pro jednotlivé platformy.
Dalším nedostatkem technologie React Native je chybějící uživatelsky i
vývojářsky přívětivá možnost navigace mezi obrazovkami aplikace.
Vzhledem k~rychlému vývoji frameworku už existují různé možnosti
navigace, ale každá má nějaké problémy a~zatím žádná nedosahuje kvality
nativní navigace.

\begin{figure}
  \begin{center}
    \includegraphics[width=\linewidth]{rn}
  \end{center}
  \caption{Znázornění architektury React Native\protect\footnotemark}
  \label{fig:react-native}
\end{figure}
\footnotetext{Převzato z \url{https://medium.com/@tsupreet/scripting-native-app-with-react-native-7702fd538a3d}}

\hypertarget{nativescript}{%
\subsection{NativeScript}\label{nativescript}}


NativeScript je dalším frameworkem z~rodiny multiplatformních řešení. Je
vyvíjen společností Telerik, která jej představila v~roce 2014. Nabízí
několik možností způsobu vývoje -- v~jazyce JavaScript nebo jazyce
TypeScript a k~těmto dvěma variantám ještě možnost usnadnit vývoj
využitím jednoho ze dvou podporovaných javascriptových frameworků
Angular nebo Vue.js. NativeScript samotný se skládá ze čtyř hlavních
částí. První částí jsou tzv. Runtimes, které umožňují volání nativních
API iOS a Androidu z~javascriptového kódu. Další částí jsou základní
moduly (NativeScript Core Modules). Ty poskytují potřebnou abstrakci
k~jednotnému použití vlastních nativních API. Další věcí, kterou tyto
základní moduly umožňují, je jednoduché definování uživatelského
rozhraní pomocí XML\footnote{XML (Extensible Markup Language) je obecný
  značkovací jazyk, který definuje řadu pravidel pro takové formátování
  dokumentu, aby byl lidsky i strojově čitelný.}. Dalším ze stavebních
kamenů tohoto frameworku je NativeScript CLI\footnote{CLI (Command Line
  Interface) je uživatelské rozhraní, ve kterém uživatel komunikuje
s~programy zapisováním příkazů do příkazového řádku.}, které umožňuje
skrze definované příkazy například vytvoření projektu, sestavení
aplikace nebo její spuštění na zařízení. NativeScript CLI podporuje
systémy Windows, macOS i Linux. Poslední částí, ze které se framework
skládá, jsou NativeScript Plugins (zásuvné moduly). Tyto zásuvné moduly
slouží k~poskytnutí jednotného obalu k~nějakým nativním funkcím nebo
knihovnám \hyperlink{9}{{[}9{]}}. Většinu dostupných zásuvných modulů lze dohledat
v~oficiálním obchodu NativeScript pluginů provozovaného vývojářským týmem
frameworku. Naprostá většina pluginů je nabízena zdarma (případně zdarma
poskytuje alespoň částečnou funkcionalitu)\footnote{Dostupné na
 \url{https://market.nativescript.org/}.}.

Stejně jako React Native i NativeScript poskytuje funkci Hot Reload.
Z~vlastní zkušenosti musím bohužel poznamenat, že Hot Reload u~tohoto
frameworku nefunguje vždy spolehlivě. Velkou výhodou je, že NativeScript
umožňuje pro vývoj použít několik různých technologií. Je tedy velká
šance, že vývojář, který se NativeScript chystá použít poprvé, bude mít
příležitost využít technologií, které už zná z~jiných projektů. Co ale
považuji za největší výhodu tohoto frameworku je definování
uživatelského rozhraní skrze samostatné XML soubory. Díky tomu vede
vývojáře k~oddělení aplikační logiky od uživatelského rozhraní, což může
zejména začínajícím vývojářům pomoct udržet čitelný kód a vyvarovat se
zbytečných chyb.

Mezi hlavní nevýhody frameworku patří nutnost mnoha optimalizací na
konci vývoje. Bez nich má jednoduchá mobilní aplikace velikost kolem 100
MB a neoslní ani rychlostí. Naštěstí ale existují dobře zdokumentované
postupy, jak aplikaci zrychlit a zredukovat její velikost. Další
závažnou nevýhodou NativeScriptu je poměrně malá uživatelská komunita.
Na druhou stranu je nutno podotknout, že přes svou velikost je tato
komunita velmi aktivní.

\begin{figure}
  \begin{center}
    \includegraphics[width=5in]{native-script}
  \end{center}
  \caption{Znázornění architektury frameworku NativeScript\protect\footnotemark}
  \label{fig:nativescript}
\end{figure}
\footnotetext{Převzato z \url{https://docs.nativescript.org/start/how-it-works}}

\hypertarget{xamarin}{%
\subsection{Xamarin}\label{xamarin}}


Xamarin je multiplatformní řešení, v~současné době vlastněné a vyvíjené
společností Microsoft. Xamarin vznikl v~roce 2013, ale veřejnosti byl
zpřístupněn až na konci roku 2014. Jedná se o~framework jazyka C\# a
multiplatformnost je zajištěna tím, že je založen na technologii Mono.
Mono je open-source verze .NET frameworku, která si klade za cíl
zpřístupnit jeho funkcionalitu na všech používaných platformách
\hyperlink{10}{{[}10{]}}. Stejně jako React Native a NativeScript i Xamarin umožňuje
sdílet kód mezi platformami. Je toho dosaženo abstraktní vrstvou kódu,
která obaluje nativní API jednotlivých platforem.

Díky jazyku C\# získává Xamarin oproti konkurenci jednu zásadní výhodu
-- automaticky podporuje i platformu Windows Mobile\footnote{C\# je
  jazyk vytvořený společnosti Microsoft a je oficiálním jazykem pro
  vývoj na jejích platformách.}. Další velkou výhodou, kterou přináší
jazyk C\# je možnost využití jednoho jazyka pro celou aplikaci včetně
back-endu. To umožní vývojářům v~týmu jednoduše pracovat na všech
částech aplikace bez nutnosti znalosti syntaxe dalšího jazyka. Možnost
využít stejný jazyk pro back-end sice nabízí i javascriptové
technologie, ale zdaleka nejsou tak rozšířené a většina vývojářských
týmů se nakonec rozhodne pro některou z~používanějších technologií jako
je Java nebo právě C\#. Xamarin je z~multiplatformních řešení, zmíněných
v~této práci, technologií nejstarší. Díky době, po kterou je framework
dostupný, existuje velmi kvalitní dokumentace.

Oproti konkurenci bylo při využití Xamarinu dlouhou dobu nutné vytvořit
uživatelské rozhraní pro každou platformu zvlášť. To se změnilo
s~příchodem technologie Xamarin.Forms, která podporuje tvorbu jednoho
sdíleného uživatelského rozhraní definovaného v~souboru XML. Bohužel,
v~současnosti Xamarin.Forms nedosahují v~provozu nativního výkonu a z~mé 
zkušenosti je zejména na Androidu rychlostní problém znatelný. Dalším
nedostatkem Xamarinu je chybějící oficiální Hot Reload funkce. Existují
komunitní řešení, ale ty nefungují vždy spolehlivě. K~využití plné síly
Xamarinu je zapotřebí vývojové prostředí Microsoft Visual Studio. To
není problém pro jednotlivé vývojáře nebo v~případě vývoje open-source
aplikací. Pokud je ale vyvíjena komerční aplikace, znamená pro
vývojářský tým značné náklady, protože je nutné zakoupit profesionální
edici tohoto SW.

\begin{figure}
  \begin{center}
    \includegraphics[width=5in]{xamarin}
  \end{center}
  \caption{Znázornění typické architektury aplikace psané v~Xamarinu\protect\footnotemark}
  \label{fig:xamarin}
\end{figure}
\footnotetext{Převzato z \url{https://docs.microsoft.com/en-us/xamarin/cross-platform/app-fundamentals/building-cross-platform-applications/setting-up-a-xamarin-cross-platform-solution}}

\hypertarget{flutter}{%
\subsection{Flutter}\label{flutter}}

Flutter je z~frameworků zmíněných v~této kapitole nejmladší (beta verze
byla představena na začátku roku 2018). Jedná se o~open--source
framework vyvíjený společností Google za přispění uživatelské komunity.
Pro vývoj ve Flutteru zvolil Google programovací jazyk Dart, kterého je
společnost také autorem. Dart je objektově orientovaný jazyk, který je
silně ovlivněn jazyky C, C\#, Java a JavaScript. Flutter, stejně jako
ostatní v~této kapitole zmíněné technologie, umožňuje sdílet jeden kód
pro vývoj nad platformami iOS a Android. Navíc půjde do budoucna využít
stejný kód i pro nový operační systém Google Fuchsia\footnote{Společnost
 Google zatím oficiálně neoznámila na jaká zařízení Fuchsia cílí.}, 
 který by podle spekulací mohl nahradit systém Android.
Základní myšlenkou Flutteru je, že všechno je tzv. widget. Může se
jednat o~vizuální prvky jako jsou tlačítka nebo například o~typ písma.
Dokonce samotná aplikace je brána jako widget. Komplexní funkcionality
je pak docíleno kompozicí jednotlivých widgetů, kde každý widget dědí
vlastnosti rodiče \hyperlink{11}{{[}11{]}}. Flutter pro definici uživatelských rozhraní
nepoužívá XML soubory, místo toho je uživatelské rozhraní vytvořeno
skládáním widgetů přímo v~kódu.

Stejně jako React Native a NativeScript má i Flutter oficiální funkci
Hot Reload. Výhodou oproti konkurenci je velmi bohatá knihovna komponent
pro uživatelské rozhraní. Existují vestavěné vizuální komponenty pro
situace, které ostatní technologie zmíněné v~této kapitole neřeší
(například animované kruhové menu nebo velké množství grafových
komponent). Tím Flutter umožňuje ještě více zrychlit proces vývoje. Za
zmínku stojí také velmi jednoduchá možnost rozdílného zobrazení
komponent na různých platformách. Je toho docíleno využitím tzv. themes,
které umožňují pro každý widget zobrazit určitou vizuální část jinak pro
jednu platformu, než pro ostatní (například odsazení).

Bohužel, Flutter je skutečně v~rané fázi vývoje a nemá stabilní verzi
1.0. Díky této skutečnosti nemá zatím důvěru velkých společností a~zpravidla není první volbou vývojářským týmů. Dalším závažným
nedostatkem Flutteru je fakt, že v~současnosti nenabízí oficiální
komponentu WebView. Existuje komunitní řešení tohoto problému, ale také
nefunguje bez problémů. Za zmínku stojí také fakt, že princip tvorby
uživatelských rozhraní ve Flutteru se liší od většiny ostatních
multiplatformních řešení (nepoužívá soubory XML) a vývojářům může tento
fakt ze začátku dělat problémy.

\begin{figure}
  \begin{center}
    \includegraphics[width=5in]{flutter}
  \end{center}
  \caption{Znázornění architektury frameworku Flutter\protect\footnotemark}
  \label{fig:flutter}
\end{figure}
\footnotetext{Převzato z \url{https://hackernoon.com/whats-revolutionary-about-flutter-946915b09514}}


\hypertarget{analuxfdza-agendy-majetku-v-informaux10dnuxedm-systuxe9mu-skautis}{%
\chapter{Analýza agendy majetku v~informačním systému skautIS}
\label{analuxfdza-agendy-majetku-v-informaux10dnuxedm-systuxe9mu-skautis}}

Na začátku této kapitoly je představen systém skautIS, přičemž zvláštní
pozornost je věnována uživatelským rolím a testovací verzi systému.
Následně je rozebrán vzhled úvodní stránky a navigace mezi jednotlivými
agendami. Ve třetí části kapitoly je podrobně rozebrána agenda správy
majetku jednotky, ve čtvrté pak agenda rezervace majetku. Kapitola je
zakončena identifikací klíčových funkcí agend správy majetku, které má vyvíjená aplikace poskytovat.


\hypertarget{informaux10dnuxed-systuxe9m-skautis}{%
\section{Informační systém skautIS}
\label{informaux10dnuxed-systuxe9m-skautis}}


Junák používá pro správu jednotek, osob a informací informační systém
skautIS\footnote{Sytém je dostupný na adrese \url{https://is.skaut.cz/}.}. Ten
byl spuštěn v~roce 2009 a v~současnosti je nasazena verze 11.6. Systém
poskytuje veškeré potřebné funkce pro vedení jednotek, např. evidenci
členů a jejich správu, organizaci akcí, vedení evidence skladů a majetku
apod.

SkautIS navíc poskytuje prostřednictvím webových služeb funckionalitu
jednotného přihlášení do dalších externích aplikací a webů. Tímto
způsobem je zajištěna rozšiřitelnost systému pro potřeby dalšího vývoje.
Jednotlivé aplikace tedy nemusí řešit vlastní registraci a~následnou
synchronizaci se systémem skautIS, protože je používána centrální
databáze členů. Na webových stránkách\footnote{Dostupné na
  \url{https://is.skaut.cz/Login/}.} se může zaregistrovat každý nicméně
většina agend není pro takovéhoto uživatele dostupná. Pro otevření plné
funkcionality je nutné zažádat o~propojení účtu s~osobou v~databázi
u~vedoucího konkrétní jednotky.


\hypertarget{uux17eivatelskuxe9-role-a-opruxe1vnux11bnuxed}{%
\subsection{Uživatelské role a
oprávnění}\label{uux17eivatelskuxe9-role-a-opruxe1vnux11bnuxed}}


Pro přístup k~jednotlivým agendám systém využívá uživatelské role. Ty
definují práva uživatele a omezují přístup k~agendám, např. uživatel
s~rolí \emph{vedoucí/admin} bude mít přístup k~agendě správy majetku,
uživatel s~rolí člen ne. Každý uživatel může mít více rolí jak v~jedné
jednotce (například role \emph{skladník} a \emph{člen} v~rámci stejné
jednotky), tak vůči jednotkám různým (například role \emph{člen}
v~jednotce středisko a~role \emph{vedoucí/admin} v~jednotce oddíl).
Uživatel může mít však v~každém okamžiku v~systému aktivní pouze jednu
roli. Pro správu různých jednotek je v~systému nutné nejprve změnit
uživatelskou roli.

\hypertarget{testovacuxed-skautis}{%
\subsection{Testovací skautIS}\label{testovacuxed-skautis}}

K~produkčnímu systému skautIS existuje i jeho testovací verze\footnote{Dostupná
  na \url{https://test-is.skaut.cz/}.}. Ta poskytuje možnost otestovat chování
a funkcí aplikace bez hrozby poškození reálných dat. Zároveň tuto verzi
systému využívají veškeré nově vyvíjené aplikace, které jsou na skautIS
napojeny. Až poté, co je nová aplikace připravena na produkční využití a
proběhne její testování vůči této testovací verzi systému skautIS, získá
potřebná data k~napojení na verzi produkční. Testovací skautIS je mj.
používán i při interních školeních Junáka.

\hypertarget{uxfavodnuxed-struxe1nka-a-navigace-mezi-agendami}{%
\section{Úvodní stránka a navigace mezi
agendami}\label{uxfavodnuxed-struxe1nka-a-navigace-mezi-agendami}}

Po přihlášení do systému skautIS se uživatel ocitne na stránce \emph{Můj
skautIS}. Zde je mu k~dispozici seznam zpráv a úkolů, oblíbené odkazy,
historie přihlášení a tabulka s~přístupnými agendami dle aktuální role
(obrázek~\ref{fig:skautIS-initial-page}). Celkový design stránek na mě působí zastarale a z~mého
pohledu není uživatelsky přívětivý. K~navigaci mezi jednotlivými
agendami slouží vysouvací panel menu umístěný na levém okraji stránek.
V~horní části menu je zobrazen detail přihlášeného uživatele včetně
aktuální role. Pro její změnu musí uživatel kliknutím na název role
rozbalit menu s~ostatními dostupnými rolemi a výběr potvrdit. Samotné
navigační menu se skládá z~výběru hlavních agend, které se po kliknutí
rozbalí a umožní přesnější výběr operace.

Správa majetku v~systému skautIS je rozdělena do dvou agend -- agendy
majetku jednotky a agendy rezervovatelného majetku Junáka, které budou
podrobně rozebrány v~podkapitolách ~\ref{uxfavodnuxed-struxe1nka-a-navigace-mezi-agendami} a~\ref{agenda-majetku-jednotky}.

\begin{figure}
  \begin{center}
    \includegraphics[width=\linewidth]{skautIS-initial-page}
  \end{center}
  \caption{Úvodní stránka systému skautIS}
  \label{fig:skautIS-initial-page}
\end{figure}

\hypertarget{agenda-majetku-jednotky}{%
\section{Agenda majetku jednotky}\label{agenda-majetku-jednotky}}


V~agendě majetku jednotky skautIS umožňuje vytvářet sklady a v~nich mít
majetek. Tento majetek lze inventarizovat -- skautIS je nápomocný tím,
že je možné jednotlivé položky během fyzické inventury „odklikat“ a že
umí generovat předpřipravené formuláře. Dále se zde řeší zpracování
rezervací z~pohledu vlastníka majetku.

Pro zobrazení majetku jednotky musí uživatel nejdříve v~menu aplikace
zvolit možnost \emph{Jednotky\textrightarrow{}Moje jednotka} (alternativně pak \emph{Moje\textrightarrow{}\\Moje
jednotka}). Následně se mu zobrazí stránka s~detailem jednotky. Pro
další navigaci v~agendě detailu jednotky se používá záložek umístěných
v~horní části obrazovky. Uživateli se zobrazují pouze dostupné záložky
podle přidělených práv role, ve které je v~dané chvíli přihlášen.
Záložka \emph{Majetek} pak uživateli zobrazí samotnou agendu pro správu
majetku jednotky.

Nejvýše umístěnými prvky v~zobrazené agendě jsou tři tlačítka umožňující
přejít do agend správy skladů, přehledu vydaných a půjčených položek a
agendy inventarizace. Tyto tlačítka podle mého názoru nejsou dostatečně
vizuálně výrazná. Vzhledem k~tomu, že systém do těchto agend neposkytuje
možnost navigace přímo z~hlavního menu, očekával bych alespoň výrazné
zobrazení. V~případě kliknutí na tlačítko inventarizace je uživatel
přesměrován na stránku, kde je zobrazen seznam všech existujících
inventur v~systému a je zde umožněno založit novou inventuru, případně
uzavřít existující inventuru.

Pokud se vrátíme zpět na hlavní stránku agendy \emph{Majetek}, tak je
dalším zobrazeným prvkem na stránce blok filtrů seznamu předmětů. Je
umístěn přímo pod výše zmíněnými tlačítky. Nachází se v~něm několik
filtrů umožňující zobrazit specifický seznam předmětů. Mimo jiné lze
filtrovat například podle skladu, do kterého předmět patří, podle názvu
předmětu nebo podle kategorie, do které předmět patří (např. Sportovní
potřeby). Jednotlivé filtry lze kombinovat a tím docílit velmi
specifického výběru. Problémem tohoto bloku je, že podle mého názoru
není uživatelsky přívětivě zarovnán a poskládán. V~prvním řádku má
uživatel možnost zvolit 4 různé filtry, ve druhém 3 a posledním třetím
řádku jsou umístěny 2 filtry a tlačítko pro potvrzení vyhledávání.
Celkově pak na mě takto organizované filtry působí nepřehledně (viz
obrázek~\ref{fig:skautIS-majetek}).

Pod tímto blokem následuje tlačítko pro upravení zobrazených sloupců
v~seznamu předmětů. Kliknutím na toto tlačítko se zobrazí seznam
dostupných informací o~předmětu a možnost jednotlivé sloupce zobrazit.
Na obrázku~\ref{fig:skautIS-majetek-seznam} můžete vidět, že ani tento 
seznam sloupců není zobrazen velmi přehledně.

Dalšími prvky zobrazenými pod tlačítkem pro upravení zobrazených sloupců
jsou tlačítka pro přidání nového předmětu, upravení existujících
předmětů a exportování seznamu předmětů do excelového souboru. Pokud
uživatel klikne na tlačítko přidání nového předmětu, je přesměrován na
jednoduchou formulářovou stránku, kde jsou pole pro vyplnění údajů
o~přidávaném předmětu. Po uložení předmětu nebo stornování akce je
uživatel přesměrován opět na hlavní stránku agendy majetku jednotky.

Posledním zobrazeným prvkem nad samotným seznamem předmětů je pole pro
volbu akce, která se má provést nad vybranými předměty z~níže
zobrazeného seznamu. Možnými akcemi jsou například vydání ze skladu,
inventarizace položky nebo vyřazení položky z~evidence. Tlačítkem
umístěným vpravo od tohoto pole je pak akce nad vybranými předměty
potvrzena a provedena.

Nejníže zobrazeným prvkem na stránce je pak samotný seznam předmětů. Ten
je organizován do tabulky. Jednotlivými sloupci tabulky jsou například
fotografie nebo název. Prvním zobrazeným sloupcem je vždy sloupec pro
výběr položky. V~tomto sloupci má každá položka jednoduché pole
s~možností zařazení do seznamu vybraných položek. Co považuji za zvláštní
je fakt, že zobrazený název tohoto sloupce je \emph{Ne}. Za lepší
variantu považuji název vynechat, případně sloupec pojmenovat
\emph{Výběr}.

\begin{figure}
  \begin{center}
    \includegraphics[width=\linewidth]{skautIS-majetek}
  \end{center}
  \caption{Část agendy majetku zobrazená nad seznamem položek}
  \label{fig:skautIS-majetek}
\end{figure}

\begin{figure}
  \begin{center}
    \includegraphics[width=\linewidth]{skautIS-majetek-zobrazene-sloupce}
  \end{center}
  \caption{Výřez nastavení zobrazovaných sloupců v~seznamu majetku}
  \label{fig:skautIS-majetek-sloupce}
\end{figure}

\begin{figure}
  \begin{center}
    \includegraphics[width=\linewidth]{skautIS-majetek-seznam}
  \end{center}
  \caption{Část zobrazeného seznamu majetku jednotky}
  \label{fig:skautIS-majetek-seznam}
\end{figure}


\hypertarget{agenda-rezervace-majetku}{%
\section{Agenda rezervace
majetku}\label{agenda-rezervace-majetku}}


Agenda rezervace majetku umožňuje členům organizace prohlížet majetek
jednotek, který jednotlivé pobočné spolky nabízí k~zapůjčení v~rámci
Junáka. Lze v~ní také podat žádost o~rezervaci vybraných předmětů.
Agenda rezervací je v~navigačním menu umístěna jinde, což je mírně
matoucí.

K~této agendě se uživatel dostane rozbalením položky
\emph{Služby\textrightarrow{}\\Majetek} dostupné z~hlavního menu aplikace. Agenda je
poměrně jednoduchá, nevyžaduje zobrazení lišty záložek pro sekundární
navigaci jako například agenda správy jednotky.

Nejvýše umístěným prvkem na této stránce je tabulka s~různými možnostmi
pro konkrétní vyhledávání předmětů. Tabulka opět není ideálně zarovnaná,
nicméně oproti tabulce v~agendě majetku jednotky je, podle mého názoru,
přehlednější. Za její hlavní nedostatek považuji to, že pole pro zadání
maximální ceny za vypůjčení předmětu je na samostatném řádku, přičemž
samotný popis pole je na řádku předchozím (lze vidět na obrázku~\ref{fig:skautIS-rezervace-filtry}).

Pod tabulkou je umístěn samotný seznam předmětů dostupných k~zapůjčení.
Zobrazené sloupce jsou oproti seznamu v~agendě majetku jednotky pevně
dané a nelze měnit jejich pořadí ani zobrazit další informace. V~prvním
sloupci je umístěna zmenšená fotografie předmětu (pokud je dostupná).
Když na tuto zmenšenou fotografii uživatel klikne, zobrazí se přes
zbytek stránky fotografie v~plné velikosti. Dalšími zobrazenými sloupci
jsou postupně: \emph{Název, Umístění, Jednotka, Orientační cena,
Poznámka k~ceně} a sloupec s~názvem \emph{Skladem}. V~jednotlivých
polích daného předmětu jsou pak vyplněny odpovídající údaje. V~posledním
zobrazeném sloupci se u~každého předmětu zobrazuje tlačítko, které
umožňuje předmět rezervovat.

Po kliknutí na tlačítko rezervovat je uživatel přesměrován na
jednoduchou stránku s~formulářem pro rezervaci předmětu. Mezi povinné
informace k~vypůjčení předmětu patří sklad, do kterého bude předmět
zapůjčen, den začátku rezervace, den konce rezervace a kontaktní osoba.

V~současnosti je v~této agendě na webu chyba validace pole pro výběr
skladu a rezervaci tak nelze dokončit. V~aplikaci vyvíjené v~rámci této
práce však rezervace předmětu funguje.


\begin{figure}
  \begin{center}
    \includegraphics[width=\linewidth]{skautIS-rezervace-filtry}
  \end{center}
  \caption{Filtry v~agendě rezervovatelného majetku}
  \label{fig:skautIS-rezervace-filtry}
\end{figure}

\begin{figure}
  \begin{center}
    \includegraphics[width=\linewidth]{skautIS-rezervace-seznam}
  \end{center}
  \caption{Část zobrazeného seznamu vypůjčitelných předmětů}
  \label{fig:skautIS-rezervace-seznam}
\end{figure}

\hypertarget{shrnutuxed}{%
\section{Shrnutí}\label{shrnutuxed}}


Vzhledem k~omezenému zaměření vyvíjené aplikace a zachování její
přehlednosti bylo nutné z~agend zmíněných v~této kapitole vybrat pouze
část funkcionality, která bude implementována.

Z~agendy majetku jednotky byla převzata možnost zobrazit jednotlivé
sklady jednotky a jejich majetek. Dále je uživateli umožněno nahrát
fotku k~předmětům, u~kterých fotografie chybí a jednotlivé předměty
inventarizovat. Samotnou inventarizaci je nutné založit i uzavřít ve
webové části systému skautIS. Hlavním důvodem je, že se jedná o~jinou
logickou část procesu inventarizace, jejíž zpracování nebylo v~zadání
vyžadováno. Při zakládání a uzavírání inventury musí uživatel vytisknout
a zpracovat inventarizační protokoly a tato část není přímo časově
propojena se samotnou fyzickou inventarizací skladu. Dalším důvodem je,
že vynechání těchto kroků umožní zjednodušit a~zpřehlednit uživatelské
rozhraní.

Z~funkcí agendy rezervace majetku Junáka byla implementována možnost
procházet majetek dostupný k~vypůjčení a zadat žádost o~rezervaci
předmětu. Dále je možné mezi předměty vyhledávat podle jejich názvu.

\hypertarget{nuxe1vrh-aplikace}{%
\chapter{Návrh aplikace}\label{nuxe1vrh-aplikace}}

V~této kapitole se zaměřuji na celkový návrh aplikace. V~první části
rozebírám systémové požadavky (funkční a nefunkční) včetně konkrétních
výsledků analýzy. Následuje identifikace případů užití systému a~sestavení jejich diagramu. V~poslední části kapitoly je rozebrán návrh
databáze a její struktura.

Hlavním pravidlem, kterého jsem se držel během návrhu aplikace je
jednoduchost a uživatelská přívětivost. Jedním z~pravidel pro dosažení
této přívětivosti je vyvarovat se složitých vizuálních prvků. Pokud
aplikace vyžaduje uživatelsky náročné interakce je důležité je rozdělit
na menší jednodušší prvky.

Pro vizuální styl byly vybrány barvy ze skautského grafického
manuálu\footnote{Dostupné na
  \href{https://logo.skaut.cz/doc/SKAUT_manual_26_1_2018.pdf}{{https://logo.skaut.cz/doc/SKAUT\_manual\_26\_1\_2018.pdf}}}. Hlavní kombinací barev aplikace je bílá s~variantou
modré. Popis jednotlivých stránek aplikace včetně obrázků je dostupný v~podkapitole~\ref{uux17eivatelskuxe9-rozhranuxed}.


\hypertarget{systuxe9movuxe9-poux17eadavky}{%
\section{Systémové
požadavky}\label{systuxe9movuxe9-poux17eadavky}}

\hypertarget{funkux10dnuxed-poux17eadavky}{%
\subsection{Funkční
požadavky}\label{funkux10dnuxed-poux17eadavky}}


Funkční požadavky jsou souhrnem služeb, které má systém poskytovat. Dále
popisují, jakým způsobem má systém reagovat na konkrétní vstupy a
situace. V~některých případech mohou funkční požadavky explicitně
stanovit, jak se systém chovat nemá \hyperlink{12}{{[}12{]}}.

Zadáním práce bylo vytvořit mobilní multiplatformní aplikaci, která bude
poskytovat část funkcionality agendy správy majetku dostupné
v~informačním systému skautIS. Konkrétně se jedná o~možnost inventarizovat
a rezervovat majetek. Důvodem je přílišná komplexita stávajícího
webového řešení a nedostatečná optimalizace pro mobilní zařízení. Jedním
z~hlavních cílů mé práce je navrhnout uživatelsky přívětivé řešení.
Další požadavky na aplikaci plynou z~povahy inventarizační činnosti.

V~aplikaci je vyžadována následující funkcionalita vycházející ze
současného zpracování agendy správy majetku a dalších požadavků
zadavatele:
\begin{itemize}
\itemsep 0pt
\item Autentizace probíhá pomocí přihlašovacích údajů do systému skautIS.
\item Aplikace komunikuje s~webovými službami systému skautIS.
\item Aplikace umožňuje prohlížet a rezervovat majetek Junáka dostupný
k~rezervaci.
\item Aplikace umožňuje prohlížet majetek konkrétní jednotky a v~případě
  založené inventury v~systému skautIS majetek inventarizovat.
\item Uživatelé bez potřebných práv pro správu majetku jednotky mají přístup
  pouze k~agendě rezervace půjčitelných předmětů.
\item U~jednotlivých položek skladu je možné zobrazit jejich popis,
  inventarizační číslo, datum poslední inventury, datum pořízení,
  pořizovací cenu a fotografii.
\item Aplikace umožňuje doplnit chybějící fotografii uskladněného předmětu.
\item Invetarizace probíhá buď manuálně označením jednotlivých položek nebo
  skenováním příslušných QR nebo čárových kódů.
\item Označení předmětů k~inventarizaci nevyžaduje internetové připojení.
\item Po dokončení inventarizace uživatel připojený k~internetu manuálně
  potvrdí synchronizaci dat.
  
\end{itemize}

\hypertarget{nefunkux10dnuxed-poux17eadavky}{%
\subsection{Nefunkční
požadavky}\label{nefunkux10dnuxed-poux17eadavky}}


Nefunkční požadavky jsou požadavky, které se přímo netýkají konkrétních
funkcí poskytovaných systémem uživateli. Mohou se týkat například
spolehlivosti systému nebo reakčního času. Mohou také definovat určitá
omezení systému, například strukturu dat používanou při komunikaci
s~jinými systémy \hyperlink{12}{{[}12{]}}.

Ve spolupráci se zadavatelem byly stanoveny následující nefunkční
požadavky:

\begin{itemize}
\itemsep 0pt
\item Aplikace je napsána za využití některé z~nativních multiplatformních
  technologií.
\item Podporovanými platformami jsou systémy iOS a Android.
\item Zdrojový kód je řádně zdokumentovaný.
\item Aplikace je rozšiřitelná a do budoucna se počítá s~její integrací do
  souběžně vyvíjené mobilní verze systému skautIS.
  
\end{itemize}

\hypertarget{pux159uxedpady-uux17eituxed}{%
\section{Případy užití a stavový diagram}\label{pux159uxedpady-uux17eituxed}}

Na základě funkčních a nefunkčních požadavků a charakteristiky uživatelů
aplikace jsem vytvořil diagram případů užití (obrázek~\ref{fig:use-case}). Diagram
případů užití znázorňuje pouze očekávané chování programu. Nestará se
tedy o~to, jak daného chování dosáhnout. Hlavním účelem diagramu je
modelování systému z~pohledu koncového uživatele \hyperlink{13}{{[}13{]}}.

Pro detailnější popis chování aplikace a identifikaci interakcí mezi jednotlivými agendami byl sestrojen stavový diagram\footnote{Stavový diagram zobrazuje model chování aplikace pomocí jejích stavů a přechodů mezi nimi.} (obrázek~\ref{fig:state-diagram}), na kterém lze vidět potřebné kroky k dosažení různých funkcí programu.

\hypertarget{nuxe1vrh-databuxe1ze}{%
\section{Návrh databáze}\label{nuxe1vrh-databuxe1ze}}

Na základě diagramu případu užití a systémových požadavků můžeme
sestrojit model databáze. Jak lze vidět na obrázku~\ref{fig:erd}, pro účely této
aplikace stačí velmi jednoduchý databázový model se třemi entitami – \texttt{warehouse}, \texttt{item} a \texttt{inventory}.

Entita \texttt{warehouse} může mít přiřazen jeden nebo žádný nadřazený sklad. Vzhledem k~tomuto faktu má v~databázi rekurzivní vztah sama se sebou.

Každý sklad může obsahovat 0--n položek skladu, které jsou reprezentovány tabulkou \texttt{item}. Mimo atributů popisujících samotný předmět má entita navíc atribut \texttt{synced}, který reprezentuje synchronizaci se serverem (pokud je hodnota 0, nejsou provedené změny propagované na server). Tato tabulka je propojena s~tabulkou \texttt{inventory} vazbou many-to-one, protože v~jedné inventuře může být zahrnuto více předmětů.

Kromě popisných atributů má tabulka \texttt{inventory} navíc atribut \texttt{warehouses}, který je textovou reprezentací pole identifikátorů skladů, kterých se daná inventura týká.

\begin{figure}[ht!]
  \begin{center}
    \includegraphics[width=0.8\linewidth]{ERD}
  \end{center}
  \caption{Schéma databáze znázorněné pomocí ER diagramu}
  \label{fig:erd}
\end{figure}

\begin{figure}[ht!]
  \begin{center}
    \includegraphics[width=\linewidth]{use-case}
  \end{center}
  \caption{Diagram případů užití}
  \label{fig:use-case}
\end{figure}

\begin{figure}[ht!]
  \begin{center}
    \includegraphics[width=\linewidth]{state-diagram}
  \end{center}
  \caption{Stavový diagram aplikace}
  \label{fig:state-diagram}
\end{figure}
\hypertarget{implementace-aplikace}{%
\chapter{Implementace aplikace}\label{implementace-aplikace}}

V~této kapitole je rozebrána samotná implementace aplikace. Nejprve jsou blíže představeny 
použité technologie. Následuje popis komunikace s~API systému skautIS. V~závěru
kapitoly je rozebráno uživatelské rozhraní jednotlivých obrazovek aplikace.

\hypertarget{volba-technologiuxed}{%
\section{Volba technologií}\label{volba-technologiuxed}}

K~vývoji aplikace bylo použito prostředí IntelliJ IDEA, jedná se o~jedno
z~nejrozšířenějších vývojových prostředí. Podporuje mnoho programovacích
jazyků a vývojářům usnadňuje práci řadou funkcí jako například
inteligentním vyhledáváním výrazů v~celém projektu včetně možnosti
jednoduchého přejmenování funkcí či objektů napříč projektem.

Pro rychlý vývoj mobilních aplikací je nezbytné využít simulátoru
mobilního zařízení jinak by bylo nutné po každé větší změně v~kódu
nahrát novou verzi aplikace na zařízení fyzické. Vzhledem k~nutnosti
multiplatformního vývoje bylo pro simulátor platformy Android využito
prostředí Android Studia, které obsahuje řadu vestavěných obrazů systému
této platformy. Pro systém iOS bylo využito vestavěného simulátoru
vývojového prostředí Xcode\footnote{Xcode je oficiální vývojové
  prostředí pro vývoj iOS aplikací, které je dostupné na systémech macOS.}.

Během implementace bylo použito následujících technologií, z~nichž
některé budou popsány v~dalších kapitolách:

\begin{itemize}
\itemsep 0pt
\item NativeScript + Angular
\item TypeScript
\item NativeScript BarcodeScanner
\item NativeScript Camera
\item NativeScript RadListView
\item NativeScript SQLite
\item NativeScript XML Objects
\item RxJS
\end{itemize}

\hypertarget{nativescript-angular}{%
\subsection{NativeScript + Angular}\label{nativescript-angular}}

Aplikace je postavena s~využitím multiplatformní technologie
NativeScript ve variantě s~frameworkem Angular. K~tomuto výběru vedlo
několik faktorů.

Hlavním důvodem bylo do budoucna zjednodušit skautským vývojářům možnost
aplikaci rozšířit. Většina těchto vývojářů má zkušenosti s~frameworkem
Angular, které může díky zvolené kombinaci technologií jednoduše využít.
Z~multiplatformních technologií popsaných v~kapitole~\ref{agenda-majetku-jednotky} se jedná
o~jediné řešení umožňující využít znalostí práce s~frameworkem Angular.
Dalším důvodem pro volbu tohoto frameworku je velmi intuitivní struktura
aplikace. NativeScript uživatele vede k~přehlednému a čitelnému dělení
souborů. Jednotlivé stránky aplikace by se podle konvencí měly nacházet
v~adresáři \texttt{Pages}, kde má každá stránka vlastní podadresář.
Samotný podadresář se pak typicky skládá z~XML souboru popisujícího
uživatelské rozhraní dané stránky a z~javascriptového nebo
typescriptového souboru obsahujícího logiku této stránky. Volitelně se
mohou v~tomto adresáři nacházet ještě CSS soubory pro stylování
uživatelského rozhraní. Tyto soubory by měly být pojmenovány podle
zavedených konvencí například \texttt{název.ios.css}, \texttt{název.android.css}
nebo \texttt{název.common.css}, aby umožnily NativeScriptu aplikovat dané styly
pouze na specifickou platformu.


\hypertarget{typescript}{%
\subsection{TypeScript}\label{typescript}}

Za programovací jazyk aplikace byl zvolen TypeScript. Je to programovací
jazyk vyvíjený společností Microsoft. V~podstatě se jedná o~nadmnožinu
jazyka JavaScript. V~porovnání s~ostatními jazyky\footnote{Například
  Scala, Elm nebo Dart.}, které se do JavaScriptu kompilují, má
TypeScript unikátní filozofii. Jakýkoliv javascriptový kód je validním
typescriptovým kódem. V~podstatě je možné změnit příponu javascriptových
souborů z~\texttt{.js} na \texttt{.ts} a začít v~projektu používat
TypeScript bez větších úprav. TypeScript se kompiluje do dobře čitelného
JavaScriptu, takže v~případě problémů není složité provést zpětnou
migraci \hyperlink{14}{{[}14{]}}.

Mezi největší výhody, které TypeScript přináší oproti JavaScriptu, patří 
volitelné statické typování. JavaScript je dynamicky typovaný jazyk.
To znamená, že u~proměnných není znám jejich typ, dokud nejsou za běhu
použity. V~případě, že typ proměnné neodpovídá očekávanému typu, mohou
v~programu nastat fatální chyby. Díky volitelné možnosti otypovat proměnné
přímo v~kódu přináší TypeScript programátorům možnost vyvarovat se výše
zmíněných chyb. Mimo statického typování umožňuje TypeScript využít
například striktní kontroly nenulových proměnných.

\hypertarget{nativescript-sqlite}{%
\subsection{NativeScript SQLite}\label{nativescript-sqlite}}

V~současné době existují pro NativeScript dvě hlavní databázová řešení,
která nevyužívají cloudových služeb\footnote{Cloudové služby neběží na
  samotném zařízení, nýbrž v~jsou dodávány online některým
z~poskytovatelů.}, NativeScript SQLite a Couchbase. Hlavním rozdílem
mezi těmito databázemi je pohled na uložená data.

SQLite je typickým představitelem relačních databází. Data jsou ukládána
do jednotlivých tabulek databáze a pro práci s~nimi je používán jazyk
SQL\footnote{SQL (Structured Query Language) je standardizovaný
  strukturovaný dotazovací jazyk, používaný pro práci s~daty v~relačních
  databázích.}. Pro vyjádření vztahu mezi jednotlivými tabulkami se
používají tzv. cizí klíče\footnote{Cizí klíč (foreign key) se používá
v~relačních databázích pro vyjádření vztahu mezi tabulkami. Hodnota
  cizího klíče musí existovat v~primárním klíči jiné tabulky.}. Výhodou
menších relačních databází je jejich jednoduchá struktura.

Narozdíl od SQLite nepatří Couchbase mezi relační databáze. Jedná se
o~tzv. NoSQL úložiště, což znamená, že k~práci s~databází není využíváno
dotazového jazyka SQL. Místo tabulek jsou v~případě Couchbase data
ukládána do tzv. dokumentů. Tyto dokumenty jsou tvořeny klíči a jejich
hodnotami.

Po důkladném zvážení jsem pro účely programované aplikace vybral
úložiště SQLite. Hlavním důvodem je moje předchozí zkušenost s~relačními
databázemi.


\hypertarget{nativescript-xml-objects}{%
\subsection{NativeScript XML
Objects}\label{nativescript-xml-objects}}


Vzhledem k~SOAP API systému skautIS bylo nutné zvolit vhodnou
technologii pro práci s~daty v~XML formátu. Typickým formátem dat
typescriptové aplikace je JSON\footnote{JSON (JavaScript Object
  Notation) je textovým formátem složeným z~atributů a jejich hodnot.}.
Bohužel, TypeScript nemá vestavěnou kvalitní podporu pro práci
s~formátem XML. Pro usnadnění vývoje bylo proto nutné vybrat některou
z~open-source knihoven podporovanou frameworkem NativeScript. Po analýze
možností jsem našel dvě použitelné knihovny: \emph{NativeScript-xml2js} a
\emph{NativeScript XML Objects}.

Principem práce s~XML daty v~knihovně \emph{NativeScript-xml2js}~\footnote{\url{https://www.npmjs.com/package/nativescript-xml2js}.} je jejich
konverze do formátu JSON, se kterým lze následně jednoduše pracovat
pomocí funkcí poskytovaných v~jazyce TypeScript.

Knihovna \emph{NativeScript XML Objects}~\footnote{\url{https://github.com/mkloubert/nativescript-xmlobjects}.} používá značně odlišný pohled na XML
data. Jak název napovídá, pracuje s~textem ve formátu XML jako
s~objektem, což je umožněno jeho pevně danou strukturou. Jednotlivé
parametry zprávy tvoří hierarchický systém objektů, ve kterém se dá
jednoduše pohybovat pomocí dostupných metod knihovny.

Vzhledem k~jednoduchosti řešení a mně blízkému objektovému pohledu na
data byla pro implementaci aplikace vybrána knihovna \emph{NativeScript XML
Objects}.

\hypertarget{rxjs}{%
\subsection{RxJS}\label{rxjs}}


RxJS (The Reactive Extensions for JavaScript) je knihovna používaná pro
tvorbu asynchronních programů za využití tzv. \emph{observables} a \emph{operátorů}
pro práci s~nimi. Základní výhodou, kterou knihovna přináší je možnost
zpracovat několik asynchronních událostí podobným způsobem, jako kdyby
vývojář pracoval s~kolekcemi. Observable si můžeme představit jako pole,
jehož prvky přicházejí asynchronně.

Knihovna samotná je hojně používaná uvnitř frameworku Angular. V~této
práci je jí využito zejména skrze třídu \emph{HttpClient}, kterou
Angular používá pro komunikaci s~webovými službami \hyperlink{15}{{[}15{]}}. Volání
metod této třídy vrací objekt třídy \emph{Observable}, jehož hodnotu
získáme zavoláním metody \emph{subscribe}.


\hypertarget{komunikace-s-api-sluux17eby-skautis}{%
\section{Komunikace s~API služby
skautIS}\label{komunikace-s-api-sluux17eby-skautis}}


Komunikace externích aplikací se webovými službami systému skautIS
probíhá pomocí protokolu SOAP (Simple Object Access Protocol). Definuje
obálkovou strukturu zpráv, kde je tělo posílané zprávy v~jedné části
obálky a kontrolní informace v~jiné. Formát těla posílané zprávy je XML
\hyperlink{16}{{[}16{]}}.

Komunikace se skautISem probíhá tak, že klientská aplikace posílá na
server HTTP\footnote{HTTP (Hypertext Transfer Protocol) slouží
k~uskutečnění webové komunikace.} dotazy metodou POST\footnote{POST je
  jednou z~metod dotazu v~rámci protokolu HTTP. Očekává, že server
  přijme data v~těle zprávy metodou zaslané (pokud jsou validní) a dále
  je zpracuje.}. Server následně zašle klientovi odpověď, z~jejíhož těla
získá klient potřebná data, případně zprávu o~chybě.


\hypertarget{autentizace}{%
\subsection{Autentizace}\label{autentizace}}


Autentizace do systému skautIS se poněkud liší od ostatních žádostí na
server. Systém z~bezpečnostních důvodů neposkytuje API pro přihlášení
pomocí zpráv protokolu SOAP. Autentizace pro externí aplikace probíhá
přes integrovaný přihlašovací formulář skautISu. Ten v~případě úspěšného
příhlášení přesměruje uživatele zpět na stránku externího programu.

Pro integraci webového přihlašovacího formuláře by bylo nutné použít
komponentu \emph{WebView}, která zobrazí úvodní stránku skautISu stejně,
jako by ji zobrazil webový prohlížeč. Tento přístup není pro mobilní
aplikace vhodný z~následujících důvodů:


\begin{itemize}
\itemsep 0pt
\item O~komponentě \emph{WebView} je známo, že neposkytuje stejnou rychlost
  jako nativní ovládací prvky.
\item Přihlašování přes externí webovou stránku naruší jednotný vizuální
  styl.
\item V~mobilní aplikaci je přihlašování přes webovou aplikaci velmi
  neobvyklé a působí rušivě.
\end{itemize}

Lepším řešením autentizace je použití klasické přihlašovací stránky
poskládané z~nativních komponent dané platformy (obrázek~\ref{fig:login}). Po
vyplnění přihlašovacích údajů uživatele je pak požadavek na autentizaci
odeslán protokolem HTTP přímo z~aplikace. Ve stránce, kterou server
vrátí v~odpovědi se nacházejí pro další žádosti na server nezbytné
parametry:


\begin{itemize}
\itemsep 0pt
\item \texttt{skautIS\_Token} -- vygenerovaný jedinečný token přihlášeného uživatele.
  Ten je povinnou součástí všech dalších požadavků na server, které
  vyžadují oprávnění přihlášeného uživatele;
\item \texttt{skautIS\_IDRole} -- identifikátor role, za kterou je uživatel
  přihlášený;
\item \texttt{skautIS\_IDUnit} -- identifikátor jednotky, ke které se váže role, za
  kterou je uživatel právě přihlášen.
\end{itemize}

\hypertarget{generickuxe1-struktura-zpruxe1v}{%
\subsection{Generická struktura
zpráv}\label{generickuxe1-struktura-zpruxe1v}}

Systém skautIS předepisuje jednotnou strukturu pro všechny dotazové
zprávy a odpovědi. Pod obálkovým parametrem posílané zprávy
\texttt{\textless{}soap:Body\textgreater{}} vždy následuje parametr s~názvem
volané služby. V~další vnořené úrovni je pak parametr s~názvem služby
začínající malým písmenem a s~na konci připojeným slovem \texttt{Input}.
V~poslední vnořené úrovni jsou pak jednotlivé atributy nutné pro volání
dané služby. Celé volání pak vypadá například následovně:

\begin{lstlisting}[basicstyle=\small\tt,language={XML},morekeywords={soap:Body,WarehouseDetail,warehouseDetailInput,ID_Login},backgroundcolor=\color{yellow!10}]
<soap:Body>
  <WarehouseDetail>
    <warehouseDetailInput>
      <ID_Login>guid</ID_Login>
      <ID>int</ID>
    </warehouseDetailInput>
  </WarehouseDetail>
</soap:Body>
\end{lstlisting}

Odpověď skautISu na dotaz má podobnou generickou strukturu. Pod
obálkovým parametrem \texttt{\textless{}soap:Body\textgreater{}} následuje
parametr s~názvem volané služby a na konci připojeným textem \texttt{Response}.
Dalším vnořeným parametrem je opět název volané služby tentokrát
s~připojeným slovem \texttt{Result}. Následně mohou nastat dva případy. Pokud
volání služby vrací vždy pouze jeden objekt, jsou v~další úrovni již
samotné atributy odpovědi. Odpověď pak může vypadat například takto (pro
demonstraci struktury je zobrazeno pouze několik přijatých atributů):

\begin{lstlisting}[basicstyle=\small\tt,language={XML},morekeywords={soap:Body,WarehouseDetailResponse,WarehouseDetailResult,ID_Login,DisplayName,ID_WarehouseMain},backgroundcolor=\color{yellow!10}]
<soap:Body>
  <WarehouseDetailResponse>
    <WarehouseDetailResult>
      <ID_Login>guid</ID_Login>
      <ID>int</ID>
      <DisplayName>string</DisplayName>
      <ID_WarehouseMain>int</ID_WarehouseMain>
    </WarehouseDetailResult>
  </WarehouseDetailResponse>
</soap:Body>
\end{lstlisting}

Druhý případ nastane pro služby, které v~odpovědi vracejí \emph{0-n}
objektů. V~této situaci bude v~další úrovni pro každý objekt obálkový
parametr pojmenovaný opět stejně jako název volané služby s~připojeným
slovem \texttt{Output}. Pod tímto parametrem jsou už samotné atributy
jednotlivých vrácených objektů a celá struktura odpovědi může vypadat
například takto:

\begin{lstlisting}[basicstyle=\small\tt,language={XML},morekeywords={soap:Body,WarehouseAllBorrowableResponse,WarehouseAllBorrowableResult,WarehouseAllBorrowableOutput,DisplayName},backgroundcolor=\color{yellow!10}]
<soap:Body>
  <WarehouseAllBorrowableResponse>
    <WarehouseAllBorrowableResult>
      <WarehouseAllBorrowableOutput>
        <ID>int</ID>
        <DisplayName>string</DisplayName>
      </WarehouseAllBorrowableOutput>
      <WarehouseAllBorrowableOutput>
        <ID>int</ID>
        <DisplayName>string</DisplayName>
      </WarehouseAllBorrowableOutput>
    </WarehouseAllBorrowableResult>
  </WarehouseAllBorrowableResponse>
</soap:Body>
\end{lstlisting}

Díky této generické struktuře zpráv není nutné psát pro volání
jednotlivých webových služeb speciální funkce, ale lze opakovaně využít
jednu parametrizovanou. Podobně je generické struktury využito i
u~zpracování odpovědí skautISu, kde je pouze potřeba rozlišit případy
jednoho a více obdržených objektů.


\hypertarget{offline-funkcionalita}{%
\subsection{Offline
funkcionalita}\label{offline-funkcionalita}}


Vzhledem k~požadavku na možnost provést inventarizaci skladu bez
internetového připojení bylo potřeba při implementaci analyzovat
možnosti synchronizace dat se serverem. Vzhledem k~typickému případu
užití bylo po konzultaci se zadavatelem rozhodnuto, že aplikace bude
poskytovat offline funkcionalitu až po výběru konkrétního skladu.

Této funkcionality je docíleno načtením potřebných dat ze serveru ještě
před vstupem do samotné agendy skladu. Označení předmětů
k~inventarizaci probíhá na úrovni lokálně uložených dat. Samotná
žádost o~inventarizaci se na server odesílá až po stisknutí tlačítka
\emph{Potvrdit} a to jen v~případě, že je uživatel připojen k~internetu,
v~opačném případě se objeví zpráva popisující situaci.

Typickým problémem u~aplikací umožňujících použití bez internetového
připojení je řešení konfliktů mezi daty klienta a serveru. V~tomto
případě je však situace poměrně jednoduchá, protože server funguje na
principu FCFS\footnote{FCFS (First come, first served) je metoda
  plánování, kdy je vždy obsloužen první příchozí požadavek ve frontě.}.
Vzhledem k~této implementaci nedovolí server vícenásobné inventarizování
jednoho předmětu. V~případě pokusu o~další inventarizaci stejného
předmětu zareaguje server chybovou hláškou vysvětlující, že předmět byl
již inventarizován. Na tuto situaci pak klient reaguje nastavením
inventarizovaného příznaku předmětu v~lokálních datech.


\hypertarget{uux17eivatelskuxe9-rozhranuxed}{%
\section{Uživatelské
rozhraní}\label{uux17eivatelskuxe9-rozhranuxed}}

Nejvýše umístěným elementem každé stránky aplikace je skrytý panel
obsahující chybovou, případně potvrzující zprávu (obrázek~\ref{fig:message-pane}). Ten se objeví v~reakci
na vzniklou situaci. Například v~případě selhání komunikace se serverem
nebo pro potvrzení úspěšného provedení akce jako je rezervace nebo
inventarizace předmětu. Vzhledem k~podobné funkcionalitě na všech
stránkách tento prvek v~dalších kapitolách vynechám.

\begin{figure}[ht!]
  \begin{center}
    \frame{\includegraphics[width=1.65in]{ios-message-panel}}
    \frame{\includegraphics[width=1.65in]{Screenshot-message-panel}}
  \end{center}
  \caption{Panel s~chybovou zprávou}
  \label{fig:message-pane}
\end{figure}

\begin{figure}[hb!]
  \begin{center}
    \frame{\includegraphics[width=1.65in]{ios-login}}
    \frame{\includegraphics[width=1.65in]{Screenshot-login}}
  \end{center}
  \caption{Přihlašovací stránka aplikace}
  \label{fig:login}
\end{figure}

\hypertarget{pux159ihluxe1ux161enuxed}{%
\subsection{Přihlášení}\label{pux159ihluxe1ux161enuxed}}

První stránkou aplikace je jednoduchá přihlašovací stránka (obrázek~\ref{fig:login}). Nejvýše
umístěným vizuálním prvkem této stránky je oficiální logo Junáka. Pod
ním následují dva textové vstupy pro uživatelské jméno a heslo. Nejníže
umístěným prvkem stránky je tlačítko pro potvrzení přihlášení.

\hypertarget{volba-jednotky}{%
\subsection{Volba jednotky}\label{volba-jednotky}}

Po úspěšném přihlášení je uživatel přesměrován na stránku pro výběr
jednotky (obrázek~\ref{fig:select-role}). Nejvýše umístěným prvkem této stránky je navigační panel. Ten
se skládá z~tlačítka umožňujícího přejít zpět na přihlašovací stránku
(provede ohlášení uživatele) a z~uprostřed umístěného názvu stránky. Pod
tímto panelem se nachází komponenta pro výběr z~dostupných jednotek
následovaná tlačítkem pro potvrzení výběru a navigaci na stránku
s~volbou skladu. Na spodním okraji stránky se nachází panel s~tlačítkem
pro navigaci na stránku rezervace dostupného majetku Junáka.

\begin{figure}[ht!]
  \begin{center}
    \frame{\includegraphics[width=1.8in]{ios-select-role}}
    \frame{\includegraphics[width=1.8in]{Screenshot-select-role}}
  \end{center}
  \caption{Stránka pro výběr jednotky}
  \label{fig:select-role}
\end{figure}

\hypertarget{rezervace-majetku}{%
\subsection{Rezervace majetku}\label{rezervace-majetku}}

Další komponentou aplikace je stránka umožňující procházet a následně
rezervovat dostupný majetek pobočných spolků Junáka, který je nabízen
k~zapůjčení v~rámci celé organizace (obrázek~\ref{fig:rezervation}). Ve vrchní části stránky se nachází
panel s~tlačítkem pro návrat na předchozí stránku a tlačítkem pro
odhlášení uživatele. Mezi těmito tlačítky se nachází textová komponenta
s~názvem stránky. Pod výše zmíněným panelem je umístěno pole pro
vyhledávání mezi dostupnými předměty. Zbytek stránky je vyčleněn seznamu
dostupných předmětů. Ten se zobrazí pouze v~případě, že jsou nějaké
předměty dostupné. V~opačném případě se zobrazí jen textová komponenta
s~popisem situace. Jednotlivé řádky seznamu reprezentují načtené předměty.
Každý řádek se skládá z~fotky předmětu (pokud je v~systému dostupná),
názvu předmětu a dvou ikon. První ikonou je symbol fajfky, který slouží
k~otevření vyskakovacího okna pro rezervaci předmětu. Klepnutím řádek se
rozbalí další informace o~předmětu. Druhá ikona slouží k~reprezentaci a
vizuálnímu odlišení toho, jestli je daný řádek v~zabaleném nebo
rozbaleném stavu.

Jak bylo zmíněno v~předchozím odstavci, stránka skrývá vyskakovací okno
pro zadání rezervace předmětu. To se skládá zejména ze dvou komponent
pro výběr data začátku a konce vypůjčení předmětu. Kromě těchto
komponent obsahuje okno ještě dvě tlačítka. První slouží ke zrušení okna
a druhé k~potvrzení rezervace (obázek~\ref{fig:rezervation-popover}).

V~případě, že uživatel klikne na fotku předmětu, zobrazí se vyskakovací
okno s~fotkou v~plné velikosti.

\begin{figure}[ht!]
  \begin{center}
    \frame{\includegraphics[width=1.65in]{ios-rezervation}}
    \frame{\includegraphics[width=1.65in]{Screenshot-rezervation}}
  \end{center}
  \caption{Stránka rezervace majetku}
  \label{fig:rezervation}
\end{figure}

\begin{figure}[ht!]
  \begin{center}
    \frame{\includegraphics[width=1.65in]{ios-rezervation-popover}}
    \frame{\includegraphics[width=1.65in]{Screenshot-rezervation-popover}}
  \end{center}
  \caption{Rezervace majetku -- vyskakovací okno}
  \label{fig:rezervation-popover}
\end{figure}

\hypertarget{volba-skladu}{%
\subsection{Volba skladu}\label{volba-skladu}}

Po vybrání jednotky je uživatel přesměrován na stránku sloužící k~výběru
skladu (obrázek~\ref{fig:warehouses}). Ve vrchní části stránky se opět nachází panel s~tlačítky pro
návrat na předchozí stránku a pro odhlášení. Mezi těmito tlačítky je
umístěna textová komponenta s~názvem stránky. Jediným dalším prvkem
stránky je 0-n tlačítek reprezentujících jednotlivé sklady jednotky.
V~případě, že jednotka nemá přiřazen žádný sklad, zobrazí se místo tlačítek
textová komponenta popisující situaci.

\begin{figure}[ht!]
  \begin{center}
    \frame{\includegraphics[width=1.8in]{ios-warehouses}}
    \frame{\includegraphics[width=1.8in]{Screenshot-warehouses}}
  \end{center}
  \caption{Stránka se seznamem skladů}
  \label{fig:warehouses}
\end{figure}

\hypertarget{detail-skladu-s-moux17enostuxed-inventarizace}{%
\subsection{Detail skladu s~možností
inventarizace}\label{detail-skladu-s-moux17enostuxed-inventarizace}}

Poslední stránkou aplikace je detail skladu. Nejvýše umístěným prvkem je
opět panel s~tlačítky \emph{Zpět} a \emph{Odhlásit}. Mezi těmito
tlačítky se nachází název daného skladu. Hlavní komponentou této stránky
je komponenta obsahující dvě záložky \emph{K~Výběru} a
\emph{Inventarizováno}. První jmenovaná záložka obsahuje seznam předmětů
dostupných ve skladu, které zatím nebyly označeny k~inventarizaci (obrázek~\ref{fig:inventory-select}). Druhá
záložka obsahuje seznam předmětů k~inventarizaci označených (obrázek~\ref{fig:inventory-selected}). Seznamy
mají stejnou strukturu jako seznam na stránce rezervace majetku Junáka
s~několika rozdíly.

Prvním rozdílem je možnost pořídit fotografii pro předmět bez
fotografie. Tato funkcionalita se zpřístupní kliknutím na zástupný
symbol fotografie, které otevře fotoaparát zařízení. Dalším rozdílem je
textová komponenta umístěná pod názvem předmětu, která nese informaci
o~tom, jestli se předmět v~současnosti nachází ve skladu. Třetím rozdílem
je funkcionalita symbolu fajfky, která v~seznamu záložky \emph{K~Výběru}
místo rezervace předmětu označí předmět k~inventarizaci\footnote{Tato
  funkcionalita je přístupná pouze pokud v~systému skautIS existuje pro
  daný sklad otevřená inventura.}.

První dva zmíněné rozdíly se vztahují na oba seznamy. Vzhledem k~povaze
seznamu v~záložce \emph{Inventarizováno} bylo nutné částečně změnit jeho
vzhled i chování. Prvním rozdílem je chybějící symbol fajfky, ten je
nahrazen ikonou křížku pro odstranění příznaku inventarizace daného
předmětu. Seznam rozlišuje mezi dvěma stavy zobrazených předmětů. Prvním
typem zobrazených předmětů jsou takové předměty, které byly již označeny
jako inventarizované v~systému skautIS. Ty jsou odlišeny zeleným pozadím
řádku a není možné zrušit jejich příznak inventarizace. Druhý stav
zobrazených předmětů je určen pro předměty, které byly v~současném běhu
aplikace označeny k~inventarizaci, ale inventarizace ještě nebyla
potvrzena.

Pod seznamem předmětů se nachází horizontální čarou oddělená textová
komponenta vysvětlující funkcionalitu ikony fajfky.

Nejníže umístěným prvkem stránka je panel obsahující tlačítka pro
inventarizaci pomocí skenování QR kódů a pro potvrzení inventarizace.

\begin{figure}[ht!]
  \begin{center}
    \frame{\includegraphics[width=1.8in]{ios-inventory}}
    \frame{\includegraphics[width=1.8in]{Screenshot-inventory-select}}
  \end{center}
  \caption{Záložka \emph{K~Výběru} na stránce detailu skladu}
  \label{fig:inventory-select}
\end{figure}

\begin{figure}[ht!]
  \begin{center}
    \frame{\includegraphics[width=1.8in]{ios-inventorized}}
    \frame{\includegraphics[width=1.8in]{Screenshot-inventory-selected}}
  \end{center}
  \caption{Záložka se seznamem inventarizovaných předmětů}
  \label{fig:inventory-selected}
\end{figure}

\hypertarget{zuxe1vux11br}{%
\chapter{Závěr}\label{zuxe1vux11br}}

Cílem této bakalářské práce bylo seznámit se s~agendami správy a~půjčování majetku v~systému skautIS a následně vytvořit multiplatformní
mobilní aplikaci, která bude poskytovat funkcionalitu pro inventarizaci
a rezervaci majetku. Výsledkem práce je popis celého vývoje aplikace, od
představení skautské organizace Junák a analýzy stávajícího řešení
správy majetku v~systému skautIS až po návrh a~implementaci samotné
aplikace.

Výstupem práce je funkční aplikace pro platformy iOS a Android, která
zjednodušuje proces inventarizace, včetně možnosti inventarizovat
majetek bez internetového připojení. Aplikace dále umožňuje kontrolovat
aktuální stav skladu a rezervovat vypůjčitelný majetek Junáka.
Jednotlivé instalační soubory jsou dostupné v~elektronické příloze.

Zdrojové kódy aplikace jsou řádně zdokumentovány a zařazeny mezi již
existující skautské projekty na portálu GitHub\footnote{Dostupné na
\url{https://github.com/skaut/Warehouse\_mobile}.}. Do budoucna se očekává
její rozšíření a případná integrace do mobilní verze systému skautIS.
Mezi možná rozšíření patří přidání funkcionality správy rezervací
z~pohledu vlastníka majetku. Během léta se očekává akceptační testování
aplikace a ve druhé polovině roku připojení aplikace na produkční verzi
systému skautIS s~následným vydáním aplikace do obchodů App Store a
Google Play.

\renewcommand\bibname{Literatura}
\begin{thebibliography}{999}
\addcontentsline{toc}{chapter}{Literatura}
\bibitem{1}
\hypertarget{1}{}
  Junák český -- skaut, z. s. \emph{Stanovy spolku schválené XIV.
Valným sněmem Junáka v~Litomyšli dne 29. 3. 2014} {[}online{]}.
Litomyšl, 2014 {[}cit. 9. 5. 2018{]}. Dostupné z:
\textless{}\url{https://www.skaut.cz/sites/default/files/stanovy_junaka_0.pdf}\textgreater{}.

\bibitem{2}
\hypertarget{2}{}
  Junák -- český skaut, z. s. \emph{Zajímavá fakta a čísla}
{[}online{]}. {[}cit. 9. 5. 2018{]}. Dostupné z:
\textless{}\url{https://www.skaut.cz/skauting/o-skautingu/fakta-cisla}\textgreater{}.

\bibitem{3}
\hypertarget{3}{}
  Junák -- český skaut, z. s. \emph{Dobrodružný rok 2017 shrnuje
nová skautská výroční zpráva!} {[}online{]}. {[}cit. 9. 5. 2018{]}.
Dostupné z: \textless{}\url{https://skaut.cz/vyrocnizprava/}\textgreater{}.

\bibitem{4}
\hypertarget{4}{}
  ČESKO. \emph{Zákon č. 563/1991 Sb. Zákon o~účetnictví}. 1991.
Sbírka zákonů České republiky.

\bibitem{5}
\hypertarget{5}{}
  Junák -- český skaut, z. s. \emph{Majetek a Inventarizace}
{[}online{]}. {[}cit. 10. 5. 2018{]}. Dostupné z:
\textless{}\url{https://krizovatka.skaut.cz/stredisko/majetek-a-hospodareni/predpisy-a-metodiky/majetek-a-inventarizace}\textgreater{}.

\bibitem{6}
\hypertarget{6}{}
  Apple Inc. \emph{Apple Developer Documentation: App Frameworks}
{[}online{]}. {[}cit. 11. 5. 2018{]}. Dostupné z:
\textless{}\url{https://developer.apple.com/documentation/}\textgreater{}.

\bibitem{7}
\hypertarget{7}{}
  Facebook Inc. \emph{Communicating between native and React
Native: Introduction} {[}online{]}. {[}cit. 11. 5. 2018{]}. Dostupné z:
\textless{}\url{https://facebook.github.io/react-native/docs/communication-ios.html\#introduction}\textgreater{}.

\bibitem{8}
\hypertarget{8}{}
  Facebook Inc. \emph{Communicating between native and React
Native: Other ways of cross-language interaction (events and native
modules)} {[}online{]}. {[}cit. 11. 5. 2018{]}. Dostupné z:
\textless{}\url{https://facebook.github.io/react-native/docs/communication-ios.html\#other-ways-of-cross-language-interaction-events-and-native-modules}\textgreater{}.

\bibitem{9}
\hypertarget{9}{}
  Progress Software Corporation. \emph{Documentation: How
NativeScript Works} {[}online{]}. {[}cit. 11. 5. 2018{]}. Dostupné z:
\textless{}\url{https://docs.nativescript.org/start/how-it-works\#how-nativescript-works}\textgreater{}..

\bibitem{10}
\hypertarget{10}{}
  Microsoft Corporation. \emph{Xamarin: Part 1 -- Understanding
the Xamarin Mobile Platform} {[}online{]}. {[}cit. 12. 5. 2018{]}.
Dostupné z:
\textless{}\url{https://docs.microsoft.com/en-us/xamarin/cross-platform/app-fundamentals/building-cross-platform-applications/understanding-the-xamarin-mobile-platform}\textgreater{}.

\bibitem{11}
\hypertarget{11}{}
  Google LLC. \emph{Technical Overview: Core principles}
{[}online{]}. {[}cit. 14. 5. 2018{]}. Dostupné z:
\textless{}\url{https://flutter.io/technical-overview/}\textgreater{}.

\bibitem{12}
\hypertarget{12}{}
  SOMMERVILLE, Ian. \emph{Software Engineering (9th Edition)}.
London: Pearson, 2011. ISBN 0137035152.

\bibitem{13}
\hypertarget{13}{}
  Visual Paradigm. \emph{What is Use Case Diagram?} {[}online{]}.
{[}cit. 16. 5. 2018{]}. Dostupné
z~\textless{}\url{https://www.visual-paradigm.com/guide/uml-unified-modeling-language/what-is-use-case-diagram/}\textgreater{}.

\bibitem{14}
\hypertarget{14}{}
  Progress Software Corporation. \emph{What is TypeScript?}
{[}online{]}. {[}cit. 18. 5. 2018{]}. Dostupné
z~\textless{}\url{https://developer.telerik.com/topics/web-development/what-is-typescript/}\textgreater{}.

\bibitem{15}
\hypertarget{15}{}
  Progress Software Corporation. \emph{An Introduction to
Observables for Angular Developers} {[}online{]}. {[}cit. 18. 5.
2018{]}. Dostupné
z~\textless{}\url{https://developer.telerik.com/topics/web-development/introduction-observables-angular-developers/}\textgreater{}.

\bibitem{16}
\hypertarget{16}{}
  HIRSCH, Frederick, KEMP John, ILKKA, Jani. \emph{Mobile Web
Services: Architecture and Implementation}. John Wiley \& Sons, Ltd,
2006. ISBN 0470015969.

\end{thebibliography}

\chapter*{A Testovací uživatelské účty}
\addcontentsline{toc}{chapter}{A Testovací uživatelské účty}

Pro účely vývoje aplikace v~prostředí testovacího skautISu byla použita 
sada uživatelských účtů, které jsou veřejně přístupné pro testování.
Údaje k~těmto a dalším dvěma účtům jsou dostupné rovněž na stránce
nápovědy pro testovací skautIS
\url{https://napoveda.skaut.cz/skautis/testovaci}.

\begin{table}[ht!]
\centering
\begin{tabular}{ll}
\textbf{Uživatelské jméno} & \textbf{Heslo} \\
\hline
kraj.vary & vary.Web \\
kraj.tgm & tgm.Web3\\
okres.blansko & blansko.Web1\\
stredisko.koprivnice & koprivnice.Web5\\
\end{tabular}
\end{table}

\chapter*{B Elektronické přílohy}
\addcontentsline{toc}{chapter}{B Elektronické přílohy}

Zdrojový kód práce: \url{https://github.com/skaut/Warehouse_mobile}\\\\
Archív závěrečné práce: \url{https://is.muni.cz/th/ibkmp/}, který obsahuje:
\begin{itemize}
\itemsep 0pt
\item Diagram případů užití, stavový diagram a ER diagram ve formátech XML a SVG.
\item Zdrojový kód práce psané v programu LaTex, včetně použitých obrázků.
\end{itemize}

\end{document}

