Skip to content

Commit

Permalink
FINAL
Browse files Browse the repository at this point in the history
petrnymsa committed May 27, 2020
1 parent 89134ad commit f9ea0dc
Showing 9 changed files with 118 additions and 123 deletions.
2 changes: 1 addition & 1 deletion FITthesis.cls
Original file line number Diff line number Diff line change
@@ -236,7 +236,7 @@ a~z\'arove\v n sa zav\"azuje spr\'\i stupni\v t zdrojov\'y k\'od tak\'eho diela
}\else{%
I hereby declare that the presented thesis is my own work and that I have cited all sources of information in accordance with the Guideline for adhering to ethical principles when elaborating an academic final thesis.

I acknowledge that my thesis is subject to the rights and obligations stipulated by the Act No.\,121/2000~Coll., the Copyright Act, as amended. In accordance with Article~46~(6) of the Act, I hereby grant a nonexclusive authorization (license) to utilize this thesis, including any and all computer programs incorporated therein or attached thereto and all corresponding documentation (hereinafter collectively referred to as the ``Work''), to any and all persons that wish to utilize the Work. Such persons are entitled to use the Work in any way (including for-profit purposes) that does not detract from its value. This authorization is not limited in terms of time, location and quantity. However, all persons that makes use of the above license shall be obliged to grant a license at least in the same scope as defined above with respect to each and every work that is created (wholly or in part) based on the Work, by modifying the Work, by combining the Work with another work, by including the Work in a collection of works or by adapting the Work (including translation), and at the same time make available the source code of such work at least in a way and scope that are comparable to the way and scope in which the source code of the Work is made available.
I acknowledge that my thesis is subject to the rights and obligations stipulated by the Act No.\,121/2000~Coll., the Copyright Act, as amended. In accordance with Article~46~(6) of the Act, I hereby grant a nonexclusive authorization (license) to utilize this thesis, including any and all computer programs incorporated therein or attached thereto and all corresponding documentation (hereinafter collectively referred to as the ``Work''), to any and all persons that wish to utilize the Work. Such persons are entitled to use the Work in any way (including for-profit purposes) that does not detract from its value. This authorization is not limited in terms of time, location and quantity. However, all persons that makes use of the above license shall be obliged to grant a~license at least in the same scope as defined above with respect to each and every work that is created (wholly or in part) based on the Work, by modifying the Work, by combining the Work with another work, by including the Work in a collection of works or by adapting the Work (including translation), and at the same time make available the source code of such work at least in a~way and scope that are comparable to the way and scope in which the source code of the Work is made available.
}\fi\fi
}\@declarationOptionSelectedtrue\fi
\ifx5#1 \DeclareRobustCommand{\thedeclarationofauthenticity}{\if\@lang1{%
8 changes: 4 additions & 4 deletions chapters/00_introduction.tex
Original file line number Diff line number Diff line change
@@ -5,14 +5,14 @@

\begin{figure}[htp]
\centering
\includegraphics[width=0.9\linewidth]{img/introduction/so-flutter-trend.pdf}
\includegraphics[width=0.88\linewidth]{img/introduction/so-flutter-trend.pdf}
\caption{Flutter Trend Against Other Popular Frameworks~\cite{so-flutter-trend}.}
\label{fig:so-flutter-trend}
\end{figure}

During~2017, the~concept of another approach was proposed, where the~application uses low-level platform API to draw over the whole screen with keeping high performance and access to native features. Later on, from this concept open-source framework Flutter, made by Google, was created~\cite{flutter}.

The Flutter for the last three years until now (first half of 2020) started to gain developers attention, and it was highly promoted by Google. One indication of its growing popularity is \textit{Stack~Overflow Developer Survey~2019}~\cite{so-2019-survey} where it took third place of ``Most Loved'' framework directly after \textit{.NET Core} and \textit{Torch/PyTorch} and highly growing trend among questions created during the last years (\Cref{fig:so-flutter-trend}). However, like with every new technology, the Flutter can become well-known and well used or will be left as a dead-end.
Flutter for the last three years until now (first half of 2020) started to gain developers attention, and it was highly promoted by Google. One indication of its growing popularity is \textit{Stack~Overflow Developer Survey~2019}~\cite{so-2019-survey} where it took third place of ``Most Loved'' framework directly after \textit{.NET Core} and \textit{Torch/PyTorch} and highly growing trend among questions created during the last years (\Cref{fig:so-flutter-trend}). However, like with every new technology, the Flutter can become well-known and well used or will be left as a dead-end.

\section{Motivation}
There are many reasons why the author chose this topic for the thesis. First of all, his bachelor thesis~\cite{nymsap-bp} already focused on mobile application development, although it used different cross-platform technology -- Xamarin. During his ongoing studies, the author discovered and started to use new, by his opinion, promising framework Flutter. So his first goal and motivation was to study Flutter more in-depth and bring comprehensive study material of this framework for others. The second reason was to conclude if Flutter can become a framework which can be used to create production-ready applications or if it is still an experimental framework. Last reason was motivation to create complex, and yet, simple to use mobile application for everyone who seeks to find new cafes to visit.
@@ -21,8 +21,8 @@ \section{Structure}
The thesis is divided to four chapters:
\begin{itemize}
\item \Cref{ch:flutter} deals with introduction to Flutter framework, its concept~and internal functionality.
\item \Cref{ch:analysis} introduce proposed Coffee Time application. Describes the~created prototype and its user testing. The~analysis of back-end services is described.
\item \Cref{ch:implementation} describes process of back-end implementation as well of Coffee Time application. In the chapter, details how its implemented, which approaches was taken and how development process was done.
\item \Cref{ch:analysis} introduces proposed Coffee Time application. It describes the~created prototype and its user testing. The~analysis of back-end services is also described.
\item \Cref{ch:implementation} describes a~process of back-end implementation as well as of Coffee Time application implementation. In the~chapter, details how its implemented, which approaches was taken and how development process was done.
\item \Cref{ch:testing} describes final application release and its testing.
\end{itemize}
In conclusion, the results are compared with the goals of this thesis.
15 changes: 7 additions & 8 deletions chapters/01_flutter.tex
Original file line number Diff line number Diff line change
@@ -66,7 +66,7 @@ \subsection{Reactive Programming}
\subsubsection{The Notion of Streams}
A Stream can be described as ``A pipe with two ends, only one allowing to insert something into it. When something is inserted into the pipe, it flows inside the pipe and goes out by the other end''~\cite{reactive-didier}. The~Stream can convey any~data type, from simple values to~events, complex object or even another stream. The~data can come to the~Stream, for example, from an external data source such as server connection or from events such as user interactions. In~Dart, the Streams support manipulating them, filtering, re-grouping, modify data before they are send and~much more. This functionality can be used to build reactive \gls{ui}. Flutter has several widgets supporting streams to rebuild part of the~\gls{ui} whenever new data arrived into the~Stream.

The answer to the question ``What is reactive programming$?$'' could be ``Reactive programming is programming with asynchronous data streams``~\cite{reactive-didier}\cite{reactive-red-hat}. Within Flutter framework, anything from an~interaction event (a~tap, a~gesture), changes of a~variable, messages, everything that may change is conveyed and triggered by streams.
The answer to the question ``What is reactive programming$?$'' could be ``Reactive programming is programming with asynchronous data streams`` \cite{reactive-didier}\cite{reactive-red-hat}. Within Flutter framework, anything from an~interaction event (a~tap, a~gesture), changes of a~variable, messages, everything that may change is conveyed and triggered by streams.
It means that with reactive programming, according to~\cite{reactive-didier}, the~application:
@@ -263,14 +263,14 @@ \subsection{Case Study Note}
Following lines in this section introduce some used patterns and solutions for state management. Every solution will use the same case study but with appropriate implementation. Each solution's full code is available as an~appendix. The design and functionality remain the same as introduced before.
% --- # --- # --- # --- # --- # --- # --- # --- # --- # --- # --- # --- # --- # --- # --- # --- # --- # --- #
\subsection{Inherited Widget}
One solution offered by \textit{Flutter} framework is the concept of \textit{InheritedWidget}~\cite{flutter-inherited-widget}~\cite{notion-widget-didier}. This concept is used across the framework -- for example, obtaining current \textit{Theme} or screen device information through \textit{MediaQuery} object. Both can be accessed through convention ``of'' method -- \verb|Theme.of(context)| returns \textit{Theme} object. Internally these objects makes usage of InheritedWidget. InheritedWidget has two features:
One solution offered by \textit{Flutter} framework is the concept of \textit{InheritedWidget}~\cite{flutter-inherited-widget}~\cite{notion-widget-didier}. This concept is used across the framework -- for example, obtaining current \textit{Theme} or screen device information through \textit{MediaQuery} object. Both can be accessed through convention ``of'' method -- \verb|Theme.of(context)| returns \textit{Theme} object. Internally these objects makes usage of an~\textit{InheritedWidget}. The~\textit{InheritedWidget} has two features:
\begin{itemize}
\item It can be accessed from any widget directly.
\item Whenever the widget changes, the accessing widget is automatically rebuilt.
\end{itemize}
The second implies that, for example, whenever widget access the~\textit{MediaQuery} and it is changed (the device is rotated, resolution changed,\ldots ), the~widget is rebuilt to handle these changes.
The~second implies that, for example, whenever widget access the~\textit{MediaQuery} and it is changed (the device is rotated, resolution changed,\ldots ), the~widget is rebuilt to handle these changes.
\begin{listing}[ht]
\begin{minted}{dart}
@@ -645,9 +645,7 @@ \subsection{Notion of Keys}
\label{listing:keys_page_stateless}
\end{listing}
The~problem can occur when some widget uses a~collection of widgets of the~same type that holds some state. Consider a~concrete example where \verb|SquarePage| holds a~list of \verb|Square| widgets~(\Cref{listing:keys_page_stateless}). Each \verb|Square| (as a~\textit{StatelessWidget}) has defined random colour through a~constructor. After a~button is clicked, the~squares are swapped. With \verb|Square| as \textit{StatelessWidgets}, everything works as expected.
\begin{listing}[ht]
\begin{listing}[!htb]
\begin{minted}{dart}
class Square extends StatefulWidget {
Square({Key key}) : super(key: key);
@@ -672,8 +670,9 @@ \subsection{Notion of Keys}
\label{listing:keys_square_stateful}
\end{listing}
However, if the~\verb|Square| becomes \textit{StatefulWidget}~(\Cref{listing:keys_square_stateful}) and the~button is clicked, it seems like nothing happened -- squares stay on the same place. When the~widget is marked to rebuilt, it walks through \textit{Elements} and if the~widget type and the~\textit{Key} match, the~\textit{Element} updates its reference to new Widget. In the~case of \textit{StatefulWidget}, the~associated state is linked to the~\textit{Element} object~(\Cref{fig:keys_start}). When squares are shifted, the~\textit{Element} is marked as dirty. It walks through square's \textit{StatefulElement} and checks if the~widget type and the~\textit{Key} match. They match because no \textit{Keys} are assigned to them. Hence, the~\textit{Element} updates its widget reference, but the~associated state remains the~same~(\Cref{fig:keys_wrong}).
The~key is to add \textit{Key}. There are several types of Keys such as \textit{ValueKey}, where some unique value can be assigned (for example article's id). For \verb|Square| example, the~\textit{UniqueKey} which generates unique identification is enough for usage. After the~\textit{Keys} are assigned, \mint{dart}|final squares = [Square(key: UniqueKey()),Square(key: UniqueKey())]| the example works again as expected. The~full example code is available as~before within appendix.
The~problem can occur when some widget uses a~collection of widgets of the~same type that holds some state. Consider a~concrete example where \verb|SquarePage| holds a~list of \verb|Square| widgets~(\Cref{listing:keys_page_stateless}). Each \verb|Square| (as a~\textit{StatelessWidget}) has defined random colour through a~constructor. After a~button is clicked, the~squares are swapped. With \verb|Square| as \textit{StatelessWidgets}, everything works as expected.
However, if the~\verb|Square| becomes \textit{StatefulWidget}~(\Cref{listing:keys_square_stateful}) and the~button is clicked, it seems like nothing happened --~squares stay on the same place. When the~widget is marked to rebuilt, it walks through \textit{Elements} and if the~widget type and the~\textit{Key} match, the~\textit{Element} updates its reference to new Widget. In the~case of \textit{StatefulWidget}, the~associated state is linked to the~\textit{Element} object~(\Cref{fig:keys_start}). When squares are shifted, the~\textit{Element} is marked as dirty. It walks through square's \textit{StatefulElement} and checks if the~widget type and the~\textit{Key} match. They match because no \textit{Keys} are assigned to them. Hence, the~\textit{Element} updates its widget reference, but the~associated state remains the~same~(\Cref{fig:keys_wrong}).
The~key is to add \textit{Key}. There are several types of Keys such as \textit{ValueKey}, where some unique value can be assigned (for example article's id). For \verb|Square| example, the~\textit{UniqueKey} which generates unique identification is enough for usage. After the~\textit{Keys} are assigned, \mint{dart}|final squares = [Square(key: UniqueKey()),Square(key: UniqueKey())]| the example works again as expected. The~full example code is available as~before within appendix.
The keys should be put to the most top widget, which is used as a~root widget of collection. Otherwise, the rebuilding algorithm fails once again, and wrong behaviour will occur. In practice, \textit{Key} should be used when stateful widgets are used within collections (such as \textit{ListView}, \textit{Row} or \textit{Column}) and they are manipulated -- moved, removed and similar. Moreover, sometimes the \textit{GlobalKey} can be used to manage some widget's state ``outside''. This approach is often used with managing text inputs.
% --- # --- # --- # --- # --- # --- # --- # --- # --- # --- # --- # --- # --- # --- # --- # --- # --- # --- #
14 changes: 7 additions & 7 deletions chapters/02_analysis.tex
Original file line number Diff line number Diff line change
@@ -413,12 +413,12 @@ \subsubsection{Low Fidelity Prototype}
As a~task graph was defined, the~\textit{Lo-Fi} prototype could be made. Although the application is considered as multi-platform application, the~prototype was focused on Android, and its Material design \cite{material-design}. The~inspiration was taken from typical Material layouts, such as \textit{AppBar} with title and subsequent actions or tabs the bottom of the screen.

First of all, the rough prototype was drawn on paper. Its purpose was to come up with some ideas and considered layout. After that, the~\textit{Balsamiq} \cite{balsamiq} prototyping software was used. The~\textit{Balsamiq} tries to mimic pencil and paper. The~prototype is created with a~set of components which looks like they are drawn by hand.
The~most important feature was the~ability to create deep links between screens or components. With a~few clicks, the prototype was able to handle actions such as the open application menu or navigate to detail. With that tool, the clickable prototype focused on essential app's features was created. As a result, the PDF was exported. The PDF is enclosed as part of the thesis located at \verb|prototype/lofi.pdf|. The portion of the result is shown in~\Cref{fig:lofi}.
The~most important feature was the~ability to create deep links between screens or components. With a~few clicks, the~prototype was able to handle actions such as the~open application menu or navigate to detail. With that tool, the~clickable prototype focused on essential app's features was created. As a result, the PDF was exported. The~PDF is enclosed as part of the thesis located at \verb|prototype/lofi.pdf|. The portion of the result is shown in~\Cref{fig:lofi}.

\begin{figure}[htp]
\centering
\includegraphics[width=0.75\textwidth]{img/analysis/lofi.png}
\caption{\gls{lofi} prototype. Cafe list (left) and Detail Screen (right).}
\caption{\gls{lofi} Prototype. Cafe List (Left) and Detail Screen (Right).}
\label{fig:lofi}
\end{figure}

@@ -453,7 +453,7 @@ \subsubsection{Low Fidelity Prototype}
\end{questions}

\subsubsection{High Fidelity Prototype}
The \gls{hifi} prototype was created as Flutter application. Because of that, in the future, the already written code could be reused. The aim was to create a fully functional prototype for Android devices. As was said earlier in this chapter, the aim of \gls{hifi} is to provide an application so it behaves as real one, which is mainly focused on user interface interaction. That means that the~application does not have any real communication with back-end services. For Coffee Time there was prepared local JSON data source with randomly generated cafe names and their data. Besides that, a~few, real one cafes were added to be less general and more known for potential testers. The~\gls{hifi} focused on all earlier described use cases. The cafe list screen and cafe's detail screen is shown~in~\Cref{fig:hifi}. The prototype's source code can be found at~\verb|https://github.com/petrnymsa/coffee-time/releases/tag/prototype|~\cite{hifi-prototype}.
The \gls{hifi} prototype was created as Flutter application. Because of that, in the future, the already written code could be reused. The aim was to create a fully functional prototype for Android devices. As was said earlier in this chapter, the aim of \gls{hifi} is to provide an application so it behaves as real one, which is mainly focused on user interface interaction. That means that the~application does not have any real communication with back-end services. For Coffee Time there was prepared local JSON data source with randomly generated cafe names and their data. Besides that, a~few, real one cafes were added to be less general and more known for potential testers. The~\gls{hifi} focused on all earlier described use cases. The cafe list screen and cafe's detail screen is shown~in~\Cref{fig:hifi}. The prototype's source code can be found at \verb|https://github.com/petrnymsa/coffee-time/releases/tag/prototype|~\cite{hifi-prototype}.

\begin{figure}[htp]
\centering
@@ -706,10 +706,10 @@ \subsubsection{Nearby Search}
\hline
\textbf{Parameter} & \textbf{Usage} \\ \hline
key & API key \\ \hline
location & latitude,longtitude \\ \hline
radius & circular radius in meters, max 50 000m \\ \hline
location & latitude, longtitude \\ \hline
radius & circular radius in meters, max 50 000~m \\ \hline
language & language code \\ \hline
opennow & place should be open. If place does not have this field, it is omitted from results \\ \hline
opennow & place is currently open; if place does not have this field, it is omitted from results \\ \hline
type & place type, always set to \textit{cafe} \\ \hline
pagetoken & token for next page \\ \hline
\end{tabularx}
@@ -854,4 +854,4 @@ \subsubsection{Firebase Authentication}

% ----- % ----- % ----- % ----- % ----- % ----- % ----- % ----- % ----- % ----- % ----- % ----- % ----- % ----- %
\section{The Conclusion}
In this chapter, the considered application Coffee Time was introduced. The~analysis of existing alternatives was made to obtain inspiration for how each application behaves. The~prototype was created to propose user interface and tested it with users. In the~end, the~analysis of Coffee Time API was made along with analysis of chosen technology to build this API.
In this chapter, the considered application Coffee Time was introduced.\\ The~analysis of existing alternatives was made to obtain inspiration for how each application behaves. The~prototype was created to propose user interface and tested it with users. In the~end, the~analysis of Coffee Time API was made along with analysis of chosen technology to build this API.
54 changes: 28 additions & 26 deletions chapters/03_implementation.tex

Large diffs are not rendered by default.

8 changes: 4 additions & 4 deletions chapters/04_deploy.tex
Original file line number Diff line number Diff line change
@@ -1,7 +1,7 @@
\chapter{Application Release}
\label{ch:testing}

Before application can be released to production it should be properly tested. In this last chapter, the development process is outlined, automated unit testing and pull-request approach of development even as single developer. Later on, the process of incrementally tested application though internal a beta testing channels on the Android devices is explained. In the end, released version of the application is shown along with link to \textit{Google Play Store}.
Before application can be released to production, it should be properly tested. In this last chapter, the~development process, automated unit testing and pull-request approach of development even as a~single developer are outlined. Later on, the process of incrementally tested application though internal a beta testing channels on the Android devices is explained. In the end, released version of the application is shown along with link to \textit{Google Play Store}.

\section{Development Workflow}
Coffee Time was developed as fully open-sourced (MIT licensed) application available at GitHub. Even as a~single developer, author wanted to have full control over development process. The~development workflow was setup accordingly:
@@ -131,9 +131,9 @@ \section{User Testing Re-Evaluation}
\begin{answer}
Landscape mode was disabled.
\end{answer}
\item The map marker could contain more information than the cafe's name only.
\item The map marker could contain more information than the~cafe's name only.
\begin{answer}
Currently it is not doable due to a~limitation of the maps plugin.
Currently it is not doable due to a~limitation of the~maps plugin.
\end{answer}
\end{questions}

@@ -144,7 +144,7 @@ \section{User Testing Re-Evaluation}
\section{Release}
Coffee Time was released as version \textit{1.0.0} to the \textit{Google Play Store} for Android devices. In order to publish a release, a proper name and description in all available languages had to be filled before the application could be accepted. Moreover, the store displays application photo, logo and a~cover image. These fields were necessary to fill as well. After the~release, two minor versions \textit{1.0.1} and \textit{1.0.2} were released as hotfixes to prevent application crashes on some devices.

\Cref{fig:ct-released-version} shows released version. In contrast with prototype version (\Cref{fig:hifi}), there are no significant graphical changes other than
\Cref{fig:ct-released-version} shows the~released version. In contrast with prototype version (\Cref{fig:hifi}), there are no significant graphical changes other than

\begin{itemize}
\item changed font typeface,
12 changes: 6 additions & 6 deletions chapters/_conclusion.tex
Original file line number Diff line number Diff line change
@@ -3,7 +3,7 @@

Next chapter was focused on introducing proposed application, its designing process, prototyping and user testing. Low-Fidelity and High-Fidelity prototypes were created to verify proposed design. Both prototypes are also included along with final implementation in the~appendix.

In the~implementation, more details were covered and also introduced several popular packages and solutions within Flutter community. In the~end, the~\textit{Android} version was successfully tested and released for download.
In the~implementation chapter, more details were covered and also several popular packages and solutions within Flutter community were introduced. In the~end, the~\textit{Android} version of the~Coffee Time application was successfully tested and it was released for download.

\section{Next Steps}
Coffee Time is for sure not ``feature-complete'' and there is plenty of space for improvements. Ongoing future development is planned to obtain more experience with Flutter framework and bring an~even better, feature ``rich'', application.
@@ -12,15 +12,15 @@ \section{Next Steps}

\begin{itemize}
\item Add missing feature ``searching cafes in custom location''.
\item Synchronization of favorited cafes.
\item Better map view with more information in it.
\item Optimise application performance, responsivity and adaptability to different form factors, screen sizes and resolutions.
\item To synchronize favourite cafes.
\item A~better map view with more information in it.
\item Optimise application performance, responsivity and adaptability to different form factors (mobile phones, tablets, \ldots), screen sizes and resolutions.
\item Add full \textit{iOS} support. This includes redesign of the application to more modern cross-platform look.
\item As a experiment, build application also for web and desktop platform.
\item As an~experiment, build application also for web and desktop platform.
\end{itemize}

\subsection{Personal Author's Note in the End}
\begin{quote}
I really believe that Flutter is a~promising framework, which increasingly gains on popularity and in the closest future there will be more opportunities as the~framework will get adopted by larger companies. In contrast with Xamarin, my subjective opinion is that the~Flutter development workflow is faster, more convenient and easier to use. Of course, as with every new popular framework, there is no guarantee that Flutter will be truly the right solution in the future. But I am convinced that, at this moment, Flutter is stable to use as a production-ready framework. If the application does not use very specific platform features, Flutter can be used without any hesitation.
I really believe that Flutter is a~promising framework which increasingly gains on popularity and in the closest future there will be more opportunities as the~framework will get adopted by larger companies. In the~contrast with Xamarin, my subjective opinion is that the~Flutter development workflow is faster, more convenient and easier to use. Of course, as with every new popular framework, there is no guarantee that Flutter will be truly the right solution in the future. But I am convinced that, at this moment, Flutter is stable to use as a production-ready framework. If the application does not use very specific platform features, Flutter can be used without any hesitation.
\end{quote}
\end{conclusion}
19 changes: 8 additions & 11 deletions dp_nymsa.tex
Original file line number Diff line number Diff line change
@@ -32,6 +32,9 @@
\usepackage{minted} % code highlight
\usemintedstyle{friendly}

% HIDE red boxes around links
% \hypersetup{hidelinks} % #### ENABLE BEFORE PRINT ####

% FIX https://tex.stackexchange.com/questions/343494/minted-red-box-around-greek-characters
\makeatletter
\AtBeginEnvironment{minted}{\dontdofcolorbox}
@@ -65,7 +68,6 @@
}

% Q.A env

\newenvironment{questions}{\begin{enumerate}[label=\bfseries\arabic*.]\bfseries}
{\end{enumerate}}
\newenvironment{answer}{\par\normalfont}{}
@@ -83,14 +85,14 @@

\acknowledgements{I would like to thank my supervisor \textit{Ing. David Šenkýř} for his guidance and~valuable advices. Sincere gratitude belongs to my partner and~family for their support during work on this thesis.}

\abstractCS{Práce se zabývá využitím multiplatformního frameworku Flutter pro tvorbu mobilních, webových tak i~desktop aplikací. Hlavním tématem práce framework Flutter a~jeho použitelnost při tvorbě aplikací. Flutter je prakticky vyzkoušen na návrhu~a~implementaci aplikace Coffee Time pro operační systém Android. Coffee Time uživatelům pomáhá vyhledávat kavárny v~blízkém okolí s~možností filtrování dle různých kritérií.}
\abstractCS{Práce se zabývá multiplatformním frameworkem Flutter, a~to nejen pro tvorbu mobilních aplikací. V~práci je popsán samotný framework, jeho použitelnost a~využití při vývojí aplikací. Následně je famework použit při~návrhu a~implementaci aplikace Coffee Time pro operační systém Android. Aplikace vyhledává kavárny v~blízkém okolí s~možností filtrování dle různých kritérií. Uživatelé aplikace si mohou zobrazit detailní informace, spustit navigaci nebo přečíst hodnocení. Aplikace byla navrhnnuta pomocí prototypu uživatelského rozhraní a~jeho postupném otestování. Nakonec byla aplikace zpřístupněna a~nasazena ke stažení pro mobilní telefony se systémem Android.}

\abstractEN{A~thesis is focused on multi-platform framework Flutter for creating mobile, web and desktop applications. The~main topic is Flutter framework and its usability during application development. In practice, Flutter is used to design and implement a~Coffee Time application for Android devices. Coffee Time helps users to search nearby cafes with filtering by different criteria.}
\abstractEN{This thesis is focused on multi-platform framework Flutter for creating not only mobile applications. In the~thesis, Flutter framework and its usability during application development are described. Flutter is used to design and implement the~Coffee Time application for Android devices. This application is able to search nearby cafes with options to filter them by different criteria. Application users can display cafe details, launch navigation or read reviews. The~application was designed using a~prototype user interface and its gradual testing before the~actual implementation. In the~end, the~application was released for download to Android devices.}

\placeForDeclarationOfAuthenticity{Prague}
\declarationOfAuthenticityOption{4} %volba Prohlášení //TODO

\keywordsCS{Flutter framework, reaktivní programování, Android aplikace, vyhledávač kaváren, serverless, Firebase.}
\keywordsCS{Flutter framework, reaktivní programování, Android aplikace, vyhledávač kaváren, serverless, Firebase.\clearpage}

\keywordsEN{Flutter framework, reactive programming, Android application, cafe search, serverless, Firebase.}
%volitelná URL práce, objeví se v tiráži
@@ -100,17 +102,12 @@
\begin{document}

% Acronyms and glossary
% \newglossaryentry{formula}
% {
% name=formula,
% description={A mathematical expression}
% }
\newacronym{aot}{AOT}{Ahead-of-time}
\newacronym{aot}{AOT}{Ahead-of-Time}
\newacronym{bloc}{BLoC}{Business Logic Component}
\newacronym{ctu}{CTU}{Czech Technical University}
\newacronym{cta}{CTA}{Coffee Time API}
\newacronym{gpa}{GPA}{Google Places API}
\newacronym{jit}{JIT}{Just-in-time}
\newacronym{jit}{JIT}{Just-in-Time}
\newacronym{jwt}{JWT}{JSON Web Token}
\newacronym{lofi}{Lo-Fi}{Low Fidelity}
\newacronym{hifi}{Hi-Fi}{High Fidelity}
109 changes: 53 additions & 56 deletions ref.bib

Large diffs are not rendered by default.

0 comments on commit f9ea0dc

Please sign in to comment.