MASARYK
UNIVERSITY
FACULTY OF INFORMATICS
Mobile Application and Tablet
Reader for Web-based Attendance
Application
Bachelor's Thesis
MICHEL ŠUSTEK
Brno, Fall 2024
MASARYK
UNIVERSITY
FACULTY OF INFORMATICS
Mobile Application and Tablet
Reader for Web-based Attendance
Application
Bachelor's Thesis
MICHEL ŠUSTEK
Advisor: Mgr. Luděk Bártek, Ph.D.
Brno, Fall 2024
Declaration
Hereby I declare that this paper is my original authorial work, which
I have worked out on my own. A l l sources, references, and literature
used or excerpted during elaboration of this work are properly cited
and listed in complete reference to the due source.
In the preparation of this thesis, I have used ChatGPT and Grammarly
for the purpose of grammar correction and suggestions. After
using these tools, I have checked the content and take full responsibility
for it.
Michel Šustek
Advisor: Mgr. Luděk Bártek, Ph.D.
iii
Acknowledgements
I sincerely want to thank Mgr. Ludek Bartek, PhD, for supervising my
thesis, and my family and my girlfriend for everlasting support on
this neverending journey.
iv
Abstract
This bachelor's thesis focuses on the design and implementation of a
cross-platform attendance application for tablets and mobile phones.
Its goal is to provide a cost-effective and flexible solution that can
replace traditional hardware terminals, offering comparable functionality
for employee attendance tracking. The work presents a tabletbased
component that uses PIN codes for user authentication and a
mobile application that simplifies employee and supervisor access to
attendance records, vacation balances, and other relevant information.
The development process employed React Native with Expo to
enable efficient, single-codebase development for both platforms. The
thesis also addresses security measures, data synchronization, offline
capabilities, and geolocation integration. The solution is tailored to
minimize costs and complexity while delivering enhanced functionality
compared to conventional hardware systems.
The outcome is a functional prototype ready for further expansion,
such as perimeter-based tracking or integration with personnel
modules. By doing so, this work provides an innovative and sustainable
attendance-tracking solution optimized for the current needs of
businesses.
Keywords
react native, mobile application, attendance systems, application design,
typescript
v
Contents
1 Introduction 1
1.1 Motivation for tablet readers 1
1.2 Motivation for phone application 2
2 Analysis 3
2.1 Tablet mode 4
2.1.1 Enrollment 4
2.1.2 Main Screen 5
2.1.3 Project tracking 6
2.1.4 Offline mode 6
2.1.5 PIN code generation 7
2.1.6 Settings 7
2.1.7 Pinning of the screen 7
2.2 Phone mode 8
2.2.1 Logging in 9
2.2.2 Dashboard 9
2.2.3 Reader 9
2.2.4 Workload Planning 9
2.2.5 Absence requests 10
2.2.6 Settings 10
2.2.7 Timesheet 10
2.3 REST API communication 11
2.4 Available Tools 17
2.5 React Native 18
2.5.1 Expo 20
2.6 Minimum compatibility 20
3 Design 21
3.1 Tablet mode use-case diagram 21
3.2 Phone mode use-case diagram 22
3.3 Class components vs functional components 22
3.4 Tablet mode design 23
3.5 Phone mode design 25
3.6 Used technologies 34
3.6.1 TypeScript 34
vi
3.6.2 StyleSheet API 35
3.6.3 Redux Toolkit 35
3.6.4 Expo Router 36
3.6.5 Shopify Flashlist 38
3.6.6 React Hook Form and Zod 38
4 Implementation 40
4.1 Project Structure 40
4.2 Generation of the PIN codes 42
4.3 Synchronization between tablet and remote server . . . 43
4.4 User state handling in the phone application 44
4.5 Deployment 45
5 Conclusion 47
Bibliography 48
A Use-case diagrams 51
B Application Design (PO) 53
C Source code 59
vii
List of Tables
viii
List of Figures
2.1 Communication diagram between services 3
2.2 Enrollment process of a new tablet 5
2.3 Main Screen of an Alveno H W reader showing the design 6
2.4 Calendar overview in the web version of Alveno 10
2.5 Simple HelloWorld component written in JSX 19
2.6 Example Hello World component 19
3.1 Simple HelloWorld class component example 26
3.2 Simple HelloWorld functional component example . . . . 27
3.3 PIN code entry modal 27
3.4 Dashboard Screen 28
3.5 Settings Screen (iOS) 29
3.6 Difference between hardware (a) and tablet (b) reader . . 29
a Hardware reader screen 29
b Tablet reader screen 29
3.7 Morphing Tab Bar 30
3.8 Dashboard Screen 30
3.9 Timesheet Screen 31
3.10 Timesheet Day Detail 32
3.11 Exception Reader 32
3.12 Denied Request Message 33
3.13 Projects Reader 33
3.14 TypeScript example 34
3.15 StyleSheet API example 35
3.16 Expo Routing Example 37
3.17 Zod validation schema example 39
A . l Tablet mode use-case diagram 51
A.2 Phone Mode use-case diagram 52
B. l Dashboard 53
B.2 Dashboard - graph and vacation 54
B.3 Timesheet 55
B.4 Absence Request - Form 56
B.5 Menu design 57
B.6 Reader design 58
ix
1 Introduction
The use of tablets and mobile phones has become increasingly prevalent
within companies in today's business landscape. This widespread
adoption reflects a growing market demand for more cost-effective
solutions and dedicated mobile applications that meet the needs of
employees. In response to this demand, this project focuses on developing
a unified application that serves both as a tablet reader for
employees' attendance and a mobile application for employees. The
application aims to streamline development and maintenance processes
and reduce the complexities associated with managing separate
platforms by maintaining a single code base for multiple device types.
The motivation behind this initiative is two-fold.
• companies seek affordable solutions that do not require significant
upfront investments in hardware or software, and
• users' preference for mobile applications that provide quick and
convenient access to essential tools and information.
The application offers a versatile and efficient approach to attendance
tracking and other critical functions by addressing these needs.
The subsequent sections will describe the specific motivations
for implementing tablet readers and developing a dedicated phone
application. This thesis proposes how these applications can benefit
companies with multiple work sites and a small number of employees
at each location, providing them with nearly the same experience as
current hardware readers at a chunk of the cost.
1.1 Motivation for tablet readers
The motivation for implementing the tablet mode is to enable companies
which may have numerous work sites with a small number of
employees at each location (such as small shops, cafes, clinics, etc.)
to allow their employees to track their time in Alveno. These employees
can then use a PIN code provided to them by the application for
authentication.
1
i . INTRODUCTION
There are only three options for tracking working hours in Alveno:
• software reader, in which the user has to have access to an
internet-connected computer or a smartphone,
• buying a biometric hardware reader, which is a separate device
that can be relatively expensive when buying in bulk or for small
companies, or
• manually editing the timesheet.
Tablet mode will include interfaces for employees to start and stop
tracking their work, enter exceptions, and check their remaining vacation,
along with some statistics about their timesheets. It is offered to
companies for a monthly fee rather than a one-time upfront payment,
like the hardware readers.
Currently, hardware readers are divided into three categories, of
which the cheapest (as of 2024) is priced at 18 000 C Z K [1]. If we
consider a company that has a lot of branches and thus needs a lot of
readers for each branch, this solution can be more cost-effective than
buying a lot of expensive readers upfront.
The cost is not the sole motivation. Tablet readers eliminate the
necessity of having to support the hardware itself. They also introduce
new possibilities for connectivity. For example, we can use Bluetooth
Low Energy (BLE) to open doors upon arrival at the office or for
tracking on-site using Bluetooth beacons [2].
Furthermore, unlike hardware readers, whose only function is to
track attendance, tablets can serve multiple purposes, such as a cash
register, without needing a secondary device.
1.2 Motivation for phone application
Today, in many requests for proposals for attendance systems, there
is a growing demand for attendance systems to include their own
dedicated smartphone applications. The primary objective of this
application is to fulfil that specific need.
In addition, users expect quick and convenient access to information
in today's world. Relying only on a web-based interface for
frequent tasks is no longer sufficient, as users increasingly prefer the
immediacy and ease provided by mobile applications.
2
2 Analysis
Requirements state that the application will consist of two separate
parts:
• mobile application,
• tablet reader.
In this chapter, we take a look at both functional and non-functional
requirements for this project, along with some technical details.
There will be two modes for the application, which will be contextswitched
based on the device's screen size. These screen sizes are
defined in the Expo specification [3]. Devices with screen sizes smaller
than 6.9" but larger than 3" are considered phones, and devices larger
than 7" but smaller than 18" are categorised as tablets.
This thesis will not go deep into the backend side of things due
to the complexity, scope and time constraints; however, some highlevel
overview is necessary for the context, and then we will dive into
specifics of PIN code generation in the Section 4.2.
The phone application is going to use REST API built on Windows
Communication Foundation [4], which is going to then communicate
with the endpoint service, which serves as a facade [5] between the
endpoint service and the main application and is going to be secured
using a generated token. This API is going to accept the token in the
AuthorizationToken header, which is the Alveno-specific version of the
Authorization [6] header. The high-level communication diagram can
be seen on the Figure 2.1.
The reason for the facade is the possibility of support for multiple
versions and abstraction around the old source code with its Czechnamed
variables for a future replacement by a modernized API.
Phone / Tablet
HTTPS Mobile Endpoint
(WCF Service)
HTTPS Web Application Services
(WCF Service)
Phone / Tablet
Mobile Endpoint
(WCF Service)
Web Application Services
(WCF Service)
Figure 2.1: Communication diagram between services
3
2. ANALYSIS
2.1 Tablet mode
The tablet mode should support the following functionality:
• Pairing the app to an Alveno instance using a generated QR code
or manually.
• Entering attendance or project records, verification of employees
using a PIN code.
• Allow employees and administrators to generate new PIN codes
randomly whilst avoiding commonly used PIN codes.
• Allow administrators to manage the reader buttons and employees
from the web.
• Offline mode and synchronization of the records entered while
the reader was offline.
• Display information about vacation, monthly balance and similar
to the employee.
• Allow administrators to display the unsynchronized records
and pin the application to the foreground.
2.1.1 Enrollment
The tablet can be enrolled into an Alveno instance by QR code or
pairing code. The enrollment can be done by an administrator on the
website in the Settings section.
These two enrollment ways have to be identical; if, for example, the
system administrator does not wish for the application to access the
camera, a pairing code with a company's identification number (IN)
can be used instead. A pairing code is a 10-digit code used to pair the
device to the company's Alveno instance, which the administrator can
generate in the administration. This exact code is going to be stored
alongside the I N in the QR code using JSON.
As seen on Figure 2.2, the pairing process using the QR code is
straightforward. It comprises two screens on which the user first selects
if they would like to pair the tablet to their instance using a QR code
4
2. ANALYSIS
User Application Server
Scans the QR code OR enters IN
[if entered IN manually): Enters Pairing Code
. Navigates to "enrollment registration information" screen
Enters Device Name
. Navigates to the reader home page
GET register-information
, Returns information about the instance
POST enrollment
Returns token for communication
User Application Server
Figure 2.2: Enrollment process of a new tablet
or entering I N and pairing code, and after confirming the code and
entering the device name, the tablet is ready to be used.
After successful enrollment, the administrators in the Alveno administration
can list all tablet pairings registered to their instance or
disable and wipe the application remotely. Administrators also need to
generate PIN codes for all users who have not yet used tablet readers
and assign them to the reader through the Tools tab in Alveno.
2.1.2 Main Screen
The main screen will closely resemble that of the existing, more expensive
hardware readers as seen on Figure 2.3. This user interface
was selected to leverage users' familiarity with the current design of
the hardware readers.
The main screen will feature two large buttons that display each
user's most common daily actions. A l l buttons can be customized by
administrators and may include custom exceptions, such as "break,"
"out for a doctor," and so on.
Information about the device's network status and clock will be
located in the screen's bottom left and right corners, along with a
battery indicator when the application is pinned.
The main screen will feature a special button in the top right corner
that allows users to access information about their remaining vacation
5
2. ANALYSIS
Figure 2.3: Main Screen of an Alveno H W reader showing the design
and general statistics, including overtime, remaining, planned, and
used vacation hours. Additionally, the overview screen will have an
automatic timeout, signing users out after 30 seconds of inactivity.
2.1.3 Project tracking
The project tracking system will allow employees to monitor the time
they spend on projects that the company manages for other clients.
Users will be able to search for assigned projects and start or stop
tracking their time. This tracking feature will only be visible if the
company has purchased the project tracking module.
2.1.4 Offline mode
The application must remain partially operational when the tablet
is offline because some employers, for example, use Alveno to track
employees on construction sites. If the application is offline, the data
is saved in local storage up until successful synchronization with the
server.
6
2. ANALYSIS
This means that while the application does not need to allow employees
to view their statistics, it must enable them to enter records.
These records will be synchronized as soon as an internet connection
is established.
Additionally, the application must check for time continuity to
prevent malicious behaviour of an employee, as changing the device's
time and skipping a few hours is easy.
2.1.5 PIN code generation
Due to security risks, the application does not permit users to change
their P I N codes. These risks include users creating easily guessable
PIN codes such as 123-456 or one user guessing another user's P I N
while setting up their own. Therefore, the application must allow users
to generate a new PIN code, which must not be easily guessable, avoiding
combinations like 111-111, 222-222, 000-000,123-456, or similar
patterns.
After enrolling the device, the administrator can distribute the PIN
codes verbally, via email, or through other methods.
2.1.6 Settings
The tablet mode should include a user-friendly settings screen that
allows employees to generate a new P I N code. Additionally, administrators
should have the ability to perform specific tasks, such as
disabling the reader, pinning it to the screen, or viewing unsynchronized
records.
2.1.7 Pinning of the screen
This will be provided on Android by the screen pinning API provided
by the operating system.
Due to distribution reasons, lock task mode [7], which is a stronger
version of screen pinning, cannot be used.
On iOS similar APIs are not available, however, an accessibility
feature called Guided Access [8] is available, which is analogue to the
Android's screen pinning.
7
2. ANALYSIS
2.2 Phone mode
The mode enables a single employee to log in and perform actions like
those on the web. This effectively eliminates the need for employees
to access the web UI for common tasks such as clocking in and out,
entering vacation requests, and submitting timesheets.
The user interface for the mobile mode should maintain consistency
with the web application and utilize colours that mirror those used in
the web version.
The phone mode should support the following functionality:
• Allow employees to log in using their existing credentials.
• Show employees their information on the dashboard like the
web version.
• Allow employers to track employee attendance and project involvement,
including GPS location at the time of attendance
entry.
• Show employees their timesheet with an overview and information
about each day.
• Allow employees to request leave, list them and view them in a
calendar.
• Allow supervisors to respond to leave requests and filter them.
• Allow employees to view their work plan.
• Allow employees to set entry P I N code and enable biometric
authentication.
• Allow employees to set their preferred initial tab when launching
the application.
• Provide alerts for actions like returning the timesheet, approval
or rejection of exceptions (requests). These categories should be
consistent with the notification centre in the web application.
8
2. ANALYSIS
2.2.1 Logging in
Unlike enrollment in tablet mode, logging in through phone mode
will require the user to sign in with their Alveno credentials.
After entering the correct credentials, the server will verify the
user's permissions and grant access to the application, provided they
have the necessary permissions.
Employees need to log in just once; after that, the token is issued,
and they can open the application without having to log in.
2.2.2 Dashboard
The dashboard will display statistics similar to those currently available
in Alveno on the Web. This means users will have access to essential
statistics, including their overtime hours, the number of meal
tickets allocated for the month, their vacation time, and more.
2.2.3 Reader
Employees use the reader to track their arrival and departure, along
with other exceptions. These exceptions can be set in the Alveno web
application.
Employers can also set a policy to force the employees to enable
their GPS to mark their arrival or departure location. This is useful
in many scenarios, such as construction sites or house cleaning jobs,
but not limited to those. If the employee decides to disable or limit the
GPS location, they cannot use the reader until they enable the location
services.
Additionally, if the location is saved, the employee can display it
under the given exception record in the day details or in the timesheet.
2.2.4 Workload Planning
Workload Planning operates as a module within Alveno. With access
to this feature, employees can utilize a straightforward calendar view
or a list view to view their work plans.
They will not be able to modify the plan in any way for now.
9
2. ANALYSIS
©A\veh6
© ».,2024 - ©
W-Wa
. . . . . .
_
18/130
a
__
Figure 2.4: Calendar overview in the web version of Alveno
2.2.5 Absence requests
The absence requests tab will allow the employee to see the requests
they planned for the upcoming month in a calendar. Employees can
also request leave on this screen and see the state of their requests,
whether the requests were declined or approved and any comments
regarding requests.
The employee can also request a new absence here, or if the employee
is a supervisor of other employees, they are going to be able to
see the employees' requests and react to them.
2.2.6 Settings
In the settings, users can manage application preferences, including
options for biometric authentication and selecting their default tab.
2.2.7 Timesheet
The timesheet screen will be read-only, meaning that, unlike in the
web version, employees cannot make manual changes to the timesheet,
such as modifying working hours or shifts. The modification will,
however, be present in later versions, as it is an essential function.
The timesheet will utilize the same set of icons as the web version
to indicate manual edits to shifts, errors in records, and manual record
10
2. ANALYSIS
editing. Additionally, the timesheet will display bonuses, overtime,
and negative balances. Every icon can be long-pressed to reveal its
meaning.
Employees will be able to view their timesheets for a given month
and submit them if they are happy with it.
2.3 REST API communication
The application communication is going to be built using RESTful
APIs. REST API is a set of rules and conversions for building and
interacting with web services[9].
As said earlier in Section 2, the API will be built on Windows
Communication Foundation (WCF) and communicate over HTTPS
and secured using an Authorization token, which will be generated
upon successful login.
It should be noted that mobile endpoint service supports two basic
paths for differentiating between tablet and phone mode application
calls - PhoneAPIService.svc and TabletAPIService.svc.
The supported endpoints of the REST API are as follows (at the
time of writing).
11
2. ANALYSIS
Method Endpoint
POST account/login
POST account/logout
GET account/me
PUT account/push-token
Description
Tries to log the user in. If
multiple instances are detected,
it returns them for the user to
choose one; otherwise, returns
the authorization token.
Invalidates the authorization
token and deactivates the device.
Returns user information about
the current user.
Registers push token after the
user has accepted notification
receiving.
Account-Related Endpoints (Phone)
Method Endpoint Description
GET
GET
dashboard/overview
dashboard/interruptions-graph
Gets information
about the current
workload, such as
its balance and
remaining vacation
time.
Gets information
about every day in
a given month to be
displayed as a
graph.
Dashboard Related Endpoints (Phone)
12
2. ANALYSIS
Method Endpoint Description
GET work-plan Gets the work plan for the given month.
Work Plan Related Endpoints (Phone)
Method Endpoint Description
GET
GET absence-requests/overview
absence-requests/initial-data Returns data such
as allowed
exceptions and
their information
(icon, name,
whether it can be
halved).
Returns an
overview of the
user's absence
requests and
supervised
employees' absence
requests.
Creates a new
absence request
from the given
body.
Changes the state
of the absence
request; requires
the given workload
to be a supervisor.
POST absence-requests/create
PATCH absence-requests/state
Absence Requests Related Endpoints (Phone)
13
2. ANALYSIS
Method Endpoint Description
GET contracts/reader Gets the allowed projects in
"in-work" mode for the user to
start recording.
GET contracts/entries Gets entries for the project
recorded on the given date.
POST contracts/tracking Starts tracking on the given
project. If none is given, stops
the tracking.
POST contracts/note Saves a note for the given
record.
GET contracts/dashboard Gets projects that are being
worked on for the given time
period.
Project-Related Endpoints (Phone)
Method Endpoint Description
GET reader Gets buttons mapping,
last entered exception,
and whether or not
geolocation is forced.
POST reader/add-entry Adds an attendance entry
to the timesheet for the
current timestamp.
POST reader/set-note Sets a note for a given
day.
GET reader/exception-ent: ries Gets entered exception
entries for the given day
Attendance Reader Related Endpoints (Phone)
14
2. ANALYSIS
Method Endpoint Description
GET timesheet Gets day-by-day timesheet data of
the given workload for the given
month.
GET timesheet/data Gets timesheet summary, such as
balance and overtime, of the given
workload for the given month.
PATCH timesheet/state Sets the timesheet state to the given
state, for example, marks it as
submitted.
Timesheet-Related Endpoints (Phone)
Method Endpoint Description
PATCH admin/regenerate-pin Generates a new PIN code for
the given workload.
DELETE admin/device Deactivates the authorization
token associated with the
device from which this path
was called.
Admin Related Endpoints (Tablet)
Method Endpoint Description
GET enrollment/information Retrieves information from
the server about the
company.
POST enrollment/device Similar to log in - creates
the device and returns the
authorization token to be
used on the specific device.
Enrollment-Related Endpoints (Tablet)
15
2. ANALYSIS
Method Endpoint
POST synchronize
Description
Main synchronization method
for synchronizing
unsynchronized records.
More details in Section 4.3.
GET synchronize/workload Retrieves information about
the given workload OID (its
balance, vacation,...).
Synchronization Related Endpoints (Tablet)
16
2. ANALYSIS
2.4 Available Tools
There are many tools for the development of native and near-native
mobile applications, and this section is dedicated to the reasons why
React Native was chosen.
Initially, the options considered were as follows:
• React Native
• Flutter
• Ionic
• .NET MAUI
• PWA
• Native Development (iOS, Android)
The final requirement was to develop applications for both A n droid
and iOS. Developers at my company needed to be proficient
in the language to be used, which eliminated Flutter and Native Development,
as they require entirely different languages (Dart and
Swift/Kotlin, respectively).
PWA was ruled out due to its web-based nature and poor track
record with the Apple A p p Store and its ecosystem. Apple clearly
states in their A p p Store Review Guidelines that applications should
be app-like, not merely web clippings [10].
Although Ionic is web-based, it utilizes Cordova or Capacitor as its
bundler and can create native application packages for distribution on
app stores. However, since Ionic is built on the Angular framework, it
was also eliminated, as our team primarily uses React for development.
Finally, I chose to discard .NET M A U I due to its relatively small
community, support and ecosystem compared to React Native.
In conclusion, React Native emerged as the best choice. It boasts a
large community and an extensive ecosystem and is based on JavaScript,
which aligns well with our team's experience.
17
2. ANALYSIS
2.5 React Native
React Native (RN) is an implementation of React that can be run crossplatform
and interact with native environments. It is open-source and
developed by Meta. Unlike React JS, which runs in the browser1
, which
allows developers to create cross-platform applications for Android,
iOS, Windows, macOS or the aforementioned web.
Its premise is to enable developers to "Learn once, write anywhere"
[11]. This is achieved by creating a translation layer called
the "Bridge" [12], which facilitates communication between JavaScript
(using JSON data) and native code.
Developers can also create native components, which can then be
used from the JavaScript code-base.
Since the platforms cannot natively understand JavaScript, it uses
a JavaScript Virtual Machine on iOS and Android[13].
Both React and React Native make use of so-called JSX components,
which are similar to H T M L (Hypertext Markup Language) and look
like H T M L embedded in JS.
A simple JSX component written using R N can look something
like the one shown in Figure 2.5.
This simple component uses components View and Button from
R N and also React Hook useState.
React Hooks are functions that are prefixed with "use" and can
be used only within JSX components or other hooks. These hooks
cannot be called conditionally, so they can only appear at the top of
the JSX component. As the specific useState hook is quite complex,
more information can be found in the React documentation useState.
This component will, therefore, first use the state hook and initialize
it to the value 0. Then, it renders the View with the Button and
text "You pressed me «count» times1
.". The onPress event on the Button
increases the count by one every time the user presses the button.
A n example of the component's output is shown in Figure 2.6.
1. There is also ReactDOM functionality, which allows React JS to server-side render
(SSR), similarly to P H R One notable framework is NextJS, which leverages SSR.
18
2. ANALYSIS
function HelloWorldO {
const [ count, setCount ] = useState(O);
return (
<View style={
{ flex: 1,
alignltems: "center",
justifyContent: "center"
}}>
<Button
onPress={() => setCount(count +1)}
title={'You pressed me ${count} times!'}
/>
</View>
);
Figure 2.5: Simple HelloWorld component written in JSX
r
'(•M fJ f^'w.l me 6 times!
Figure 2.6: Example Hello World component
19
2. ANALYSIS
2.5.1 Expo
Expo is a framework built on top of React Native. It is currently the
recommended way[14] to create new React Native apps, as the CLI of
React Native can be quite complex and cumbersome.
Unlike the barebones React Native CLI, Expo provides a complete
software development kit (SDK) [15] for creating applications. It also
uses Continuous Native Generation (CNG), which is useful for generating
native interfaces and code from configuration files [16].
Expo offers a rapid prototyping solution through its application,
Expo Go. The primary advantage of this application is that it eliminates
the need for manual builds. Users can download the app from the
Play Store or A p p Store and connect it to their computers via a local
network.
In the past, the Expo faced criticism from the community for "vendor
lock-in" and perceived incompleteness. However, in recent years,
this perception has improved significantly.
Expo SDK itself is open-source and free [17]; however, the Expo
company also provides Expo Application Services (EAS), which is a
service that allows developers to quickly build and deploy applications
to their respective app stores for a fee [18].
2.6 Minimum compatibility
The source code provided with this thesis utilizes Expo SDK 51, which
requires a minimum of Android 6 and iOS 13.4 for support. Consequently,
the minimum compatibility is Android 6 and iOS 13.4. This
minimum requirement means that 98% [19] of current Android devices
and 96% [20] 2
of current iOS devices connected to the Internet
are supported.
2. Information regarding the support for both platforms is accurate as of October
2024
20
3 Design
This chapter discusses the application's design, covering both the
technical aspects and the main technologies used to build it. This
includes an overview of the structure using use-case diagrams, as well
as the tools that were essential in creating the application. This chapter
will also present the design of the phone application's key screens.
3.1 Tablet mode use-case diagram
The use-case diagram for the tablet mode can be found on Figure A . l .
For simplicity, only a few key use cases will be demonstrated.
Force reader synchronization is a feature that allows administrators
to initiate a synchronization cycle, performing all the tasks
associated with the Synchronize reader use case.
The Synchronize Reader use case is executed by the TIME actor,
which runs the process in a loop every 60 seconds. The synchronization
gathers all unsynchronized records, excluding exceptions or project
records, and pushes them to a server via an endpoint.
The screen for Show unsynchronized records is designed for
reader administrators to view unsynchronized records. These records
may be unsynchronized for various reasons, such as an error, a synchronization
loop that has not yet run, or the reader being offline.
The Regenerate PIN Code feature is the only way for an employee
to request a new PIN code independently. The application contacts an
endpoint to generate the PIN code, and upon receiving a response, it
updates its offline records and displays the P I N code on the screen.
From that moment on, the employee can log in using only the provided
PIN code. Employees can utilize this functionality multiple times to
create a PIN code that they prefer. Please refer to Section 4.2 for more
information about how PIN codes are generated.
The Display Dashboard with Vacation and Balance use case enables
employees to view a dashboard that presents information about
their selected workload. This information includes their balance, vacation
data, and details about their next vacation. The vacation data is
displayed in a graph similar to the one found on the web.
21
3. DESIGN
3.2 Phone mode use-case diagram
The use case diagram for the phone mode can also be found on Figure
A. 2.
The Login use case enables users to log in using their Alveno
credentials. After logging in, if a user has access to multiple instances
of Alveno, they will be prompted to select one. However, the majority
of users typically have only one active instance at a time.
Once users have set up authentication via a P I N code in the settings,
they can use the Authenticate feature every time they start the
application or after five minutes of inactivity1
. Additionally, users can
take advantage of the built-in biometric sensors for faster access.
The Reader feature enables users to track their attendance or
project status. Additionally, both readers send location data to the
server upon request from the employer. They also allow users to set
or modify notes related to the day or project.
A n employee can have multiple roles. For instance, if Employee A
works as both a dishwasher and a cashier at a restaurant, the employer
may require two separate timesheets for each position. The Change
Active Workload use case allows the employee to switch between
active workloads. When the workload changes, the application reloads
with the relevant data for the selected role.
View Work Plan allows users to view their work plan for the
month. It is displayed both in the calendar and in a day-by-day list.
Timesheet allows users to view and manage their timesheets for
the selected month. Currently, the only actions an employee can take
are to confirm the timesheet and add notes for specific days. The
timesheet provides a detailed overview of the actions taken on the selected
day and notifies the user if there are any errors in their timesheet.
3.3 Class components vs functional components
There are two types of components that you can use to build your
application in React - class components and functional components.
1. Unfocusing from the application, such as backgrounding or accessing the notification
shade, is considered inactivity.
22
3. DESIGN
They differ in syntax. Class components are created by defining a
class that extends the React.Component (or React.PureComponent)
base class. These components resemble the example shown in Figure
3.1. As illustrated, a significant amount of boilerplate code for
a simple component performs the same function as the example in
Figure 2.6.
Before proceeding with further comparisons, let's examine the
same component written as a functional component in Figure 3.2.
As you can see, the code in the functional component is significantly
shorter than that of the class component. However, the reduction
in boilerplate code is not the only reason to favor functional
components.
Another reason is the ability to reuse component state throughout
the application. React hooks provide a way to add context to child
components without resorting to prop drilling, which is a well-known
anti-pattern in React [21]. Prop drilling becomes particularly problematic
when using TypeScript (Section 3.6.1) instead of plain JavaScript.
Without hooks, managing a component's state can become challenging
very quickly. According to React's development team, complex
components can be difficult to understand [22].
Moreover, functional components are the preferred method for creating
new components. Since the release of React 16.8 and React Native
0.59 over five years ago, nearly all community packages have adopted
functional components. Those that have not can still utilize functional
components, as both types of components are interchangeable in terms
of usage.
A notable exception that cannot be implemented using functional
components is the ErrorBoundary, which functions as a try/catch
mechanism for components [23].
3.4 Tablet mode design
Since the tablet mode, as mentioned in Section 2.1.2, retains the design
of the hardware readers to avoid confusing new users, the overall design
has been kept consistent. However, as illustrated in Figure 3.3, the
PIN code entry process has undergone some visual changes. Notably,
the PIN code entry screen now functions as a modal rather than a full-
23
3. DESIGN
screen window, as is the case with the hardware readers. Additionally,
unlike the hardware readers, the tablet's P I N code entry screen features
animations when the user enters an incorrect PIN. Furthermore,
unlike the P I N codes used in hardware readers, this authentication
method serves as the primary and sole means of authentication for
tablet readers.
In addition to these changes, a completely new screen, the dashboard,
has been introduced. This dashboard provides information
about the current workload balance, overtime, and vacation details,
offering users a comprehensive overview of their work status, as illustrated
in Figure 3.4.
One significant upgrade over the existing tablet readers is the
definition of buttons. In the hardware readers, administrators had to
define the buttons twice: once in the Alveno administration interface
and once in the reader itself. This was necessary because the only
information transferred was the identification of the button clicked
by the user. For example, when User A clicked the Arrival button
(Bl), only the information that User A clicked on B l was transferred.
Now, this process has been streamlined. Administrators need to define
the buttons only once in the Alveno administration, and they will
automatically sync with the end devices during synchronization.
Unlike hardware readers, which provide settings for various features
such as time, clock adjustments, wireless networking, and fingerprint
management, the tablet reader has a more limited settings
menu. It includes options for forced synchronization, regenerating
the PIN code, displaying unsynchronized records, and allowing the
administrator to pin the application to the foreground, as shown in
Figure 3.52
.
Furthermore, in Figure 3.6, a comparison between the hardware
reader and my tablet reader is shown. If you examine the bottom
left and right corners, you'll notice that the information is presented
differently. While the hardware reader displays the current user count
in the left corner, the tablet reader indicates whether it is Online or
Offline.
Additionally, when we pin the application to the foreground, a
new status indicator for battery status will appear. This happens be-
2. The option for pinning the reader is available only on Android devices
24
3. DESIGN
cause when the application is pinned, the status bar—which displays
information such as the clock, network status, and date—disappears.
3.5 Phone mode design
Unlike tablet mode, which had a counterpart, the design for phone
mode is entirely new. It needed to embody Alveno's aesthetic in terms
of colours, spacing, and icons while prioritizing a mobile-first approach.
Alveno's Product Owner at Iresoft provided an example of the
desired UI, along with several screen samples. Using this as a foundation,
I iterated to enhance both the appearance and functionality.
A l l screenshots in this chapter depict the application, while the
product owner's design can be found in Chapter B.
Each screen (except for settings) prominently displays the Alveno
logo at the top, alongside a button that navigates users to the menu.
Employees can change their active workload within the full-screen
menu, which features large buttons that are easy to press. Additionally,
the menu can be effortlessly dismissed by performing a "fling" gesture
from the top down. Users can navigate to various screens using
either the menu or the tab bar located at the bottom of the screen, as
illustrated in Figure 3.7.
25
3. DESIGN
class HelloWorld extends React.Component {
constructor(props) {
super(props);
this.state = {
count: 0,
};
this.incrementCount = this.
incrementCount.bind(this);
}
function incrementCount() {
this.setState(prevState => ({
count: prevState.count + 1
}));
};
render() {
const { count } = this.state;
return (
<View style={styles.container}>
<Button
onPress={this.incrementCount}
title={'You pressed me
${this.state.count} times!'}
/>
</View>
);
}
}
Figure 3.1: Simple HelloWorld class component example
26
3. DESIGN
function HelloWorldO {
const [ count, setCount ] = useState(O);
return (
<View style={styles.container}>
<Button
onPress={() => setCount(count +1)}
title={'You pressed me ${count} times!'}
/>
</View>
);
Figure 3.2: Simple HelloWorld functional component example
Figure 3.3: PIN code entry modal
27
3. DESIGN
6:26 Sun 3.11.
Š u s t e k M i c h e l Sign out (oo)
November 2024 Vacation
Monthly Balance as of 11/3
00:00
My next vacation is on
not planned yet
Remaining
61 hours
7.6 days
0 Used up
8 hours
1 day
Planned
56 hours
7 days
Figure 3.4: Dashboard Screen
28
3. DESIGN
Figure 3.5: Settings Screen (iOS)
n I
(a) Hardware reader screen
(b) Tablet reader screen
Figure 3.6: Difference between hardware (a) and tablet (b) reader
1Paid break Shift interruption Break
29
3. DESIGN
This navigation bar features an animation: when the user is at the
top of the screen, it floats and does not occupy the full width. However,
as the user scrolls down, it transforms into a full-width tab bar.
Figure 3.7: Morphing Tab Bar
As you can see in the Figure 3.8, the dashboard draws inspiration
from the existing Alveno dashboard. Notably, the title is aligned to
the left, distinguishing it from other titles that are centred within the
application. It also greets the user based on the time of day. In Czech,
it also correctly uses vocative case.
18:59
ps &*A\veno »
Good evening, Pepa!
Monthly Bal. as of9.11. -24:00
Surcharges No
Overtime 00:00
0 Work 00:00
0 Vacation 00:00
0 Sick 00:00/0 days
0 Business trip 00:00
w w
Figure 3.8: Dashboard Screen
There is information about the monthly balance of the employee
as of «today» and about hours counted as overtime. Following that
are points about some data that are configurable in the Alveno web
30
3. DESIGN
application3
. By default, the following information is displayed: the
total worked hours of the employee, the number of vacation days
taken, the number of sick days, the hours spent on business trips, and
the hours dedicated to doctor visits.
Continuing with Figure 3.9, you can see the timesheet. A s you
can see at the top, an employee can select any month by clicking the
arrows from the point their workload starts until the end of it.
19:02 'MIPS
©AXveno »
November 2024
3 invalid days
Fr Invalid Day -oa.OG
3.11.
Sa
Su
10/1.
Mo Flexible (08:31 AM - 05:31 PM] 00:3C
©
Tu Flexible (08:29 AM - 05:29 PM) 00:3C
©
V
We Flexible (08:32 AM - 05:32 PM) 00:3C
13.11. *
© ©
Figure 3.9: Timesheet Screen
Employees can also confirm their timesheet is correct by clicking
the green button. They can also click on any day, and it will open up
details for the day as seen on Figure 3.10.
3. There is no way to configure them from the application for now.
31
3. DESIGN
Mo Flexible (38:31 AM - 05:31 PM) 00 30
11.11.
•
Flexible
08:31 AM - 05:31 PU
(n) Break
©
\-S 02:31 F>M- 03:01 PM "
Figure 3.10: Timesheet Day Detail
Reader has two parts - the exception reader and the projects reader.
In the exception reader, as you can see in Figure 3.11, an employee
can record their arrival, departure or any other allowed exception.
This is configurable in the Alveno web application settings.
19:11 •<? 'MiPS
SAXveno "
Reader
[ Attendance Projects
Arrival 19:11 v
0 ©
Arrival Departure
© (*)
Business trip Shift interruption
© ©
Break Other
© © © ®
Dashboard Reader My Timcshccl Absence
Figure 3.11: Exception Reader
If the administrator has enabled geolocation in the settings, the
location will be sent upon clicking the button. These buttons can be
disabled if the administrator requires the employee's location and the
employee denies the request, as seen in Figure 3.12. The project reader
32
3. DESIGN
Your Alveno administrator forced the
use of location services on the mobile
reader but the permissions have been
denied. Before continuing, set the
permissions correctly.
Q More information
Figure 3.12: Denied Request Message
is enabled only if the company has purchased the project module and
looks like the Figure 3.13. This reader allows the employee to start and
stop recording time on a project. This can also, like the exception reader,
force users to give their location and cease to work if the individual
denied the request.
19:12
PS ©Äveno ::
Reader
1 - Code Review for IB111 ,
00:01 I
Masarykova univerzita
2 - Working on thesis
Masarykova univerzita
Figure 3.13: Projects Reader
33
3. DESIGN
This was only the basic overview of the most used screens that can
be found in the tab bar. The rest of the application's screen is in the
same style with reused components and functions as it was written in
Phone Mode.
3.6 Used technologies
3.6.1 TypeScript
TypeScript is a superset of JavaScript developed by Microsoft that
enhances the language by introducing static typing. These static types
enable developers to catch potential type-related errors at compile
time instead of at runtime, thereby improving code reliability and
maintainability. This type safety also facilitates better tooling and
autocompletion in integrated development environments (IDEs).
You can see an example of TypeScript in Figure 3.14.
interface User {
id: number;
name: string;
isAdmin: boolean;
}
function displayUser(user: User): string {
return 'User ID: ${user.id},
Name: ${user.name},
Admin: ${user.isAdmin ? 'Yes' : 'No'}
}
const userl: User = {
id: 1,
name: "Alice",
isAdmin: true
};
console.log(displayUser(userl)) ;
Figure 3.14: TypeScript example
34
3. DESIGN
3.6.2 StyleSheet API
As our application requires custom components with custom design,
the StyleSheet API provided by React Native directly was chosen 4
.
While the syntax resembles CSS, it is important to note that it is
not CSS and possesses certain distinct characteristics. For instance,
instead of the default display: block, it employs flexbox for positioning
components.
The StyleSheet API operates using the Yoga Layout Engine, developed
by Meta [24]. This engine functions as a computational tool that
determines the placement of components within the layout.
At first glance, the code that utilizes the StyleSheet API appears
as a standard JavaScript object that mimics CSS. A n example of the
StyleSheet API can be found in Figure 3.15.
const styles = StyleSheet.create({
container: {
...StyleSheet.absoluteFillObject,
background: "#3D6BCC"
}
»
Figure 3.15: StyleSheet API example
3.6.3 Redux Toolkit
Redux Toolkit is designed to manage the global state of an application,
facilitating communication between the server and client and caching
responses.
The application can store items such as authentication tokens, user
preferences, and data utilized elsewhere in the global state. However, it
is generally discouraged to store data related to individual components
in the global state, as this can increase complexity by unnecessarily
enlarging the global state, making maintenance more challenging [25].
Additionally, changes in the global state may trigger re-renders in
components that do not rely on the updated data, potentially leading
4. StyleSheet API website
35
3. DESIGN
to performance issues. This approach also violates the principle of
separation of concerns by mixing local component data with globally
shared data, complicating debugging and testing. Nevertheless, with
careful planning, leveraging the global state for specific componentrelated
data can be advantageous.
Redux Toolkit provides an opinionated implementation of the
Redux store and introduces key concepts such as slices, selectors, and
middleware. It also features a method for querying data (RTK Query)
using REST APIs and offers straightforward response caching based on
query parameters. This method has been the preferred way to interact
with Redux for years and is the primary reason for the creation of
Redux Toolkit [26].
While there are numerous other state management libraries, such
as Zustand, none implement both server-state and global state in quite
the same way as Redux Toolkit.
3.6.4 Expo Router
Expo Router is a relatively new React Native routing package built
on the well-established React Navigation package. It introduces filebased
routing for both React Native and web applications, drawing
inspiration from the routing system of Next.js [27].
As mentioned earlier, unlike React Navigation, which employs
code-based routing, Expo Router utilizes a file-based routing concept.
In this method, each file within a specific directory corresponds directly
to a route in the application. This approach establishes routes
based on the folder and file structure, thereby making the app's routing
organization clear and intuitive without the need for additional
code configurations. For example, an app/index.ts file would automatically
map to the / route. This contrasts with code-based routing,
as seen in React Navigation, where routes are defined and managed
through code rather than generated from the file structure [28].
For an example of file-based routing, see Figure 3.16. Along the
files, such as contracts.tsx, or index.tsx, there are also prefixed file Jayout
and folder names, such as (tabs) or (phone).
36
3. DESIGN
v app
v (phone)
v (tabs)
> reader
Jayout.tsx
•fr absence-requests.tsx
contracts.tsx
& index.tsx
my-time s heettsx
•> operations.tsx
work-plan.tsx
Figure 3.16: Expo Routing Example
Here is an overview of the special name formats used in routing.
• _layout.tsx
This file can contain only one layer, indicating that a new layout
should be applied to this and all child pages. The available layouts
include Stack, Slot, Tabs, Drawer, or any custom option. For
example, the stack layout presents the pages as a deck of cards,
with one card positioned on top of another.
• folder with the name in parentheses, e.g. (phone)
This folder name indicates that the name, for example, phone does
not have to be used in links. Because of this, in the Figure 3.16,
both /my-timesheet and / (phone) / (tabs) /my-timesheet are completely
valid paths that can be used for linking.
• files with square brackets in the name, e.g. [name].tsx
In this case, the name in the name marks a parameter of the route
that can be then read by hooks such as useLocalSearchParams or
useGlobalSearchParams[29].
• +not-found.tsx, [...wild.tsx]
These files are used as a "not found" page when the link fails to
find the match for the required resource[30].
• +html.tsx
This file is used as a wrapper for the application in a web browser.
It is unused in my project.
37
3. DESIGN
3.6.5 Shopify Flashlist
React Native's FlatList is a component that implements a concept
known as List Virtualization (or Windowing). List Virtualization is
a technique used to display large amounts of data within a viewport
[31].
According to the FlashList homepage [32], this implementation
relies solely on the JavaScript (JS) thread, which can limit performance
when managing intensive or complex tasks, such as maintaining
smooth scrolling or handling rapid user interactions. As a result,
operations are constrained by the processing capacity of the JS thread,
potentially leading to delays or jank when many elements require
simultaneous updates.
To address these issues, Shopify's development team has created an
open-source implementation for Virtual Lists. This implementation is
similar to FlatList but offers a performance boost of up to 5x compared
to React Native's version.
It is claimed that FlashList is a drop-in replacement for FlatList,
with the primary distinction being the need to provide an additional
prop called estimatedltemSize, which represents the estimated size of
the rendered item in pixels (height or width).
However, FlashList is not a complete drop-in replacement and
lacks certain functionalities that Shopify never required. Notably, the
event onEndReached does not report distanceFromEnd [33], which many
developers find essential.
3.6.6 React Hook Form and Zod
React Hook Form was chosen to manage forms in my application, a
popular library widely adopted across the web and supports React
Native.
Handling user inputs can be challenging due to the need for manual
management of state, validation, and error handling. React Hook
Form simplifies this process by providing an API for managing form
state, validation, and submissions. Additionally, it minimizes unnecessary
re-renders, which is particularly beneficial for performance when
dealing with complex forms. The library integrates seamlessly with
several validation packages, such as Yup and Zod.
38
3. DESIGN
For validation, Zod was chosen, which works smoothly with the
React Hook Form. Zod's schema-based approach enables the definition
of validation rules that can be reused throughout different parts
of the application. This configuration allows for complex validation
logic and ensures effective form handling. By combining React Hook
Form with Zod, efficient form-state management alongside robust
validation can be achieved.
In Figure 3.17, you can see an example of what the validation
schema for a registration form might look like.
const registrationsenema = z.object({
username: z.string()
.min(3, "Username must be at least 3 characters long")
email: z . s t r i n g O
.email("Invalid email address"),
password: z . s t r i n g O
.min(8, "Password must be at least 8 characters long")
.regex(/[A-Z]/, "Password must contain
an uppercase letter")
confirmPassword: z . s t r i n g O ,
}).refine(data => data.password === data.confirmPassword,
{
message: "Passwords do not match",
path: ["confirmPassword"]
});
export default registrationSchema;
Figure 3.17: Zod validation schema example
39
4 Implementation
This chapter focuses on the implementation of several key concepts, including
the generation of PIN codes, synchronization for tablet mode,
and GPS location for the mobile application. Additionally, showcases
the project structure and the application's deployment to the A p p
Store and Google Play.
4.1 Project Structure
The proposed structure emphasizes the separation of concerns, modularity,
and scalability. The primary directories and their respective
responsibilities are outlined below.
• app/
This folder includes all screens for the application, and the expo
router uses them for routing. It is then split into two folders,
(phone) and (tablet), respectively, for each mode. The routing
is done in the index. The routing to each folder is based on the
screen resolution.
• assets/
This folder includes assets for the application, such as icons,
fonts and images.
• components/
The components folder includes all React Native components,
which can be reused on screens or in other components. Each
component has its own folder and at least 3 files, which are the
component itself (named after the folder), index.ts for exporting
the component and .types.ts file, which has the props interface.
Components do not generally use "export default «name»" since
it is better to have named exports when working in a team. The
only exception is the navigation, which needs default exports to
satisfy the router.
40
4. IMPLEMENTATION
• constants/
This folder includes constants reused throughout the application,
such as colour schemes or spacing.
• exceptions/
This folder includes custom exceptions that hooks or components,
such as ModuleNotEnabledError or InsufficientPermissionsError
can throw.
• hooks/
The hooks folder includes custom React Hooks. Hooks are parts
of code that can be reused throughout the application. Every
hook has its own folder and index.ts for exporting for cleaner
imports. These hooks also do not use default exports.
There are also more specific hooks in the store/hooks folder, which
are for manipulating the store directly; these do not have any
folder and are just as-is.
• il8n/
This folder contains files that manage the different language
versions of the application, specifically en, cs, and sk.
In addition to the language files, the folder also includes several
functions for date manipulation and other related tasks.
• models/
This folder has interfaces that come from the backend server.
The interface names are mostly the same as the file names, and
they correspond to the server names but without the MAAPI1
prefix.
There is also an enums/ folder included. The enums are primarily
numbered rather than using strings, as they are in Czech on the
server. I wanted to avoid incorporating any Czech language in
this new project.
• patches/
Patches include diff patches of specific versions of modules in
the nodejnodules. This is necessary because authors of different
1. Abbreviation for MobileApplicationAPI
41
4. IMPLEMENTATION
packages sometimes introduce bugs that require time to be fixed
through official updates. We can resolve these issues ourselves
by using the patch-package tool and applying patches.
• schemas/
This folder contains all zod validation schemas for the entire
application.
• secrets/
This folder contains sensitive information for the application,
such as the Firebase private key for notifications. While some
files are included, the majority are excluded, as specified in the
.gitignore file.
• store/
The store folder contains the complete global store of the application.
It includes all slices, API endpoints, middleware for
managing the store, and migrations for upgrading saved slices
on the device.
• utils/
This folder contains all functions for text and array manipulation,
as well as other utility functions that do not fit elsewhere. It also
includes global types for packages not bundled with TypeScript
out of the box, such as vokativ.
4.2 Generation of the PIN codes
The generation of PIN codes is handled on the server side using a single
static class. This class accepts two inputs: the IDs of the employees
for whom PIN codes need to be generated and a list of all previously
used PIN codes for that instance. This approach ensures that no two
users share the same PIN code, thereby reducing unnecessary round
trips to the database. As a precautionary measure against simple PIN
codes, a secret file containing a list of all simple PIN codes is stored on
the server. Over 2,000 simple PIN codes are currently excluded from
generation, and this list has been compiled from various sources.
42
4. IMPLEMENTATION
The generator, which utilizes a cryptographically secure random
number generator, creates a PIN code stored in the file. This code can
be recreated up to «threshold» times, currently set to 10,000.
While this method may not be the most efficient way to generate
PIN codes, it is adequate for our current needs involving hundreds
of employees. A more effective approach would be to implement this
generator as a procedure within the database.
4.3 Synchronization between tablet and remote server
Synchronization between the tablet and the remote server occurs via
the POST synchronize endpoint. In the production environment, the
synchronization request is sent every 60 seconds, while in the development
environment, it is sent every 15 seconds.
Each request contains a JSON body with two items: exceptionEntries
and contractEntries, which correspond to exception and project records,
respectively. Before sending the request, each record is assigned a
synchronization UUID for identification, as the records do not yet have
their own ID. Additionally, each request includes its own SHA256 hash
that encompasses all relevant information and the authorization token.
This measure is implemented to protect against low-effort tamper
attacks when the tablet is offline, as the authorization token should
not be readable outside of the application due to the use of secure
storage on each platform. However, it may become accessible if the
end device is jailbroken, rooted, or has compromised security. If an
invalid hash is detected, the entry is saved but marked as inactive, and
it is not considered when calculating attendance and shifts.
The response to the request includes the successfully synchronized
UUIDs, project reader data, permitted modules, button mappings for
the front screen, and a list of all employees who have access to the
specific tablet reader.
As you can see, the request and response size can be the Achilles'
heel of the entire synchronization process. This is due to the potential
for these requests to be very large—possibly reaching hundreds of
kilobytes—especially when combined with the polling required for
synchronization.
43
4. IMPLEMENTATION
While this solution has yet to be tested in production, it is acceptable
for the time being. One potential approach could be to implement
WebSockets, such as SignalR, for synchronization or to divide the endpoint
into several smaller ones, each with varying polling intervals.
4.4 User state handling in the phone application
Upon logging in, the user state is requested from the endpoint /account/me
and every minute thereafter. This endpoint can also be used
to verify the login status; if it returns a 400 error, we know the user is
not logged in.
This API endpoint returns an interface called UserlnformationResponse,
which contains all information about a specific user, including
currently active workloads, permissions, and application settings.
Application settings refer to the configurations specific to the instance
and dictate how the application should behave when connected.
Currently, these settings only include information about whether work
planning is enabled, which additional modules are activated, and
whether the instance is read-only2
. Additional modules are utilized to
determine whether to display the Projects screen button, among other
functions. While not every module is visible within the application,
all potential modules that can be enabled are included.
Permissions are represented as an array containing objects that
include the permission code from the backend and the corresponding
permission state, which can be either Read, Edit, or Forbid. Currently,
there are no permission codes specific to the mobile application, so I
have attempted to match all codes with their counterparts in the web
application.
The response is cached and can be accessed through useCurrentUser
throughout the application. This hook also simplifies permission
management by providing functions for checking permissions, along
with many other useful features.
2. A n instance may be set to read-only if the customer has not paid for the following
month.
44
4. IMPLEMENTATION
4.5 Deployment
The application's deployment is divided into two parts: the backend
and the frontend. The backend runs on Internet Information Services
(IIS), so to deploy it, we copy the files from the Release folder after
building the Mobile Application Endpoint.
The application dependencies can be installed using the command
npm install, which downloads all the necessary packages from the
npm repository. To run this command, you will need at least Node.js,
which is a server-side JavaScript runtime, as well as Xcode and the
Java Development Kit (JDK). For building, you must install the eas
command, an abbreviation of expo application services. You can run npm
install -g eas-cli to do that.
You can also try running the application using npm start, which
launches the development client for iOS. If you prefer to use Android,
you can execute npm run android, which starts the client for Android
devices. For either of these, you will need to download the necessary
simulators.
The application can be built in two ways:
• on the developer's machine or
• on the cloud using expo.dev.
Developers can build the application on their machines using the
command eas build -local —profile «profile_name», where the profile
name can be either "preview" or "production." The —local parameter
forces the Expo Application Services to use the machine's Xcode and
JDK to build the specified application type [34]. However, this approach
has the inherent downside of not allowing the building of both
operating systems simultaneously, which is possible when building
in the cloud.
The building process for the cloud uses the same command but
omits the -local parameter. The cloud version can also deploy the application
directly to the respective app stores for the given operating
system. These cloud builds incur charges that are paid using an allocation
of building credit per month, of which a certain amount is
available for free [18].
Once the build is complete, an authorized employee can upload it
to Google Play using the Google Play Console or to the App Store via
45
4. IMPLEMENTATION
a program called Transporter, as Apple does not offer a browser-based
option for uploading applications.
After uploading and testing the application using TestFlight or
Google Play's testing features, we can deploy it to our users as soon as
it passes the review process from the app stores. Both stores require
us to provide testing accounts for smoke testing, typically involving
their team navigating through the application until they encounter
any issues. This process can take several days. While this is manageable
when we release a new feature, it can become problematic if we
inadvertently release a bug that crashes the application in a common
scenario that the review team did not test. This is where OTA updates
come to the rescue.
OTA (over-the-air) updates enable developers to publish updates
directly, circumventing the app store processes. This mechanism operates
by downloading a bundle that contains the JavaScript code and
executing it in place of the embedded code [35]. I used expo-updates,
which utilizes EAS to build and distribute update packages through
Expo's content delivery network (CDN).
The expo-updates checks for updates on the specific branch for
which the application was built, which may differ from the one in
Git. If an update is found, it is downloaded and executed at the next
restart. This process helps minimize common bugs and enables faster
release of new features.
You may have noticed that one deployment method was deliberately
omitted: sideloading. This is because the application will later
utilize App Attestation APIs [36] (or SafetyNet for Android), which
verify the source from which the application is installed and communicate
this information to the remote server. Therefore, sideloading
(or modifying) should theoretically be impossible.
46
5 Conclusion
This thesis aimed to detail the design decisions made and implement
a functional multi-platform application for the Alveno attendance
system. The application was designed to operate on both Android and
iOS, featuring two modes optimized for tablets and smartphones. Additionally,
selected platforms were presented with the rationale behind
my choice, described the key packages utilized, and the advantages
of each.
Key application implementation concepts were also presented,
such as generating PIN codes, managing user statuses, and deploying
the application.
The application is not yet complete, as numerous potential extensions
could enhance its functionality. For instance, perimeter tracking
could be implemented, allowing employees to add exceptions that are
accessible only within a specific distance from a designated location.
Furthermore, we could integrate the second Alveno system—an H R
system—that would enable the electronic signing of documents.
The download links for the application are provided below:
• Google Play Store for Android
• Apple App Store for iOS
Login information is attached in the digital attachments.
47
Bibliography
[1] Iresoft, Alveno hardware readers, Accessed: 2024-06-02. [Online].
Available: https: //www.alveno. cz/biometricke-ctecky.
[2] Wikipedia contributors, Bluetooth low energy beacon — wikipedia,
thefree encyclopedia, Accessed: 2024-11-09. [Online]. Available:
https : / / en . wikipedia . org/wiki/Bluetooth_Low_Energy _
beacon.
[3] Expo Documentation, Devicetype, Accessed: 2024-05-21. [Online].
Available: https : //docs . expo . dev/versions/latest/
sdk/device/#devicedevicetype.
[4] Microsoft, What is windows communication foundation, Accessed:
2024-10-19. [Online]. Available: https : / /learn . microsoft .
com/en-us/dotnet/framework/wcf/whats-wcf.
[5] Refactoring.Guru, Facade, Accessed: 2024-11-24. [Online]. Available:
https://refactoring.guru/design-patterns/facade.
[6] M D N Web Docs, Authorization, Accessed: 2024-05-21. [Online].
Available: https : / /developer . mozilla . org /en -US /docs/
Web/HTTP/Headers/Authorization.
[7] Android, Lock task mode, Accessed: 2024-10-13. [Online]. Available:
https://developer.android.com/work/dpc/dedicated-
devices/lock-task-mode.
[8] Apple, Use guided access with iphone, ipad, and ipod touch, Accessed:
2024-10-13. [Online]. Available: https : //support. apple. com/
en-us/111795.
[9] IBM, What is a rest api? Accessed: 2024-06-06. [Online]. Available:
https://www.ibm.com/topics/rest-apis.
[10] Apple, App review guidelines, Accessed: 2024-10-19. [Online].
Available: https : //developer. apple. com/app-store/review/
guidelines/#design.
[11] React Native Documentation Team, React native, Accessed: 2024-
06-06. [Online]. Available: https : //reactnative. dev.
[12] React Native Documentation Team, Communication on ios, Accessed:
2024-10-13. [Online]. Available: https ://reactnative.
dev/docs/communication-ios.
48
BIBLIOGRAPHY
[13] J. Kosmal, How does react native work? understanding the architecture,
Accessed: 2024-10-13. [Online]. Available: https : //
medium . com / f ront - end - weekly / how - does - react - native -
work-understanding-the-architecture-d9d714e402e0.
[14] React Native Documentation Team, Get started with react native,
Accessed: 2024-10-13. [Online]. Available: https : //reactnative.
dev/docs/environment-setup.
[15] Expo Documentation Team, Expo sdk documentation - latest version,
Accessed: 2024-10-13. [Online]. Available: https : //docs.
expo.dev/versions/latest/.
[16] Expo Documentation Team, Continuous native generation (cng),
Accessed: 2024-10-13. [Online]. Available: https : //docs. expo.
dev/workflow/continuous-native-generation/.
[17] Expo, Expo license (mit), Accessed: 2024-10-13. [Online]. Available:
https://github.com/expo/expo/blob/main/LICENSE.
[18] Expo, Expo application services (eas) pricing, Accessed: 2024-10-13.
[Online]. Available: https: //expo.dev/pricing.
[19] apilevels.com, Android versions, sdk/api levels, version codes, codenames,
and cumulative usage, Accessed: 2024-10-13. [Online].
Available: https: //apilevels . com/.
[20] iosref.com, Ios version usage, Accessed: 2024-10-13. [Online].
Available: https: //iosref . com/ios-usage.
[21 ] React Antipatterns, Prop drilling, Accessed: 2024-10-20. [Online].
Available: https: //reactantipatterns . com/#propdrilling.
[22] React Development Team, Introducing hooks, Accessed: 2024-10-
20. [Online]. Available: https : //legacy. react js . org/docs/
hooks-intro.html.
[23] React Documentation, Catching rendering errors with an error
boundary, Accessed: 2024-10-20. [Online]. Available: https: //
react.dev/reference/react/Component#catching-rendering-
errors-with-an-error-boundary.
[24] Meta, Yoga layout engine, Accessed: 2024-10-20. [Online]. Available:
https://www.yogalayout.dev/.
[25] N . Saxena, Should we use global state? Accessed: 2024-10-28. [Online].
Available: https : / /dev . to / saxenani ckk / should - we-
use-global-state-177d.
49
BIBLIOGRAPHY
[26] Redux Authors, Why redux toolkit is how to use redux today, Accessed:
2024-10-28. [Online]. Available: https : //redux-toolkit.
js.org/introduction/why-rtk-is-redux-today.
[27] Next.js Documentation Team, Building your application: Routing,
Accessed: 2024-10-28. [Online]. Available: https : //nextjs .
org/docs/pages/building-your-application/routing.
[28] Expo Documentation Team, Introduction to expo router, Accessed:
2024-10-28. [Online]. Available: https : / /docs . expo . dev/
router/introduction/.
[29] Expo Documentation Team, Use url parameters - expo router reference,
Accessed: 2024-10-28. [Online]. Available: https : //docs.
expo.dev/router/reference/url-parameters/.
[30] Expo Documentation Team, Notfound routes - expo router reference,
Accessed: 2024-10-28. [Online]. Available: https : //docs. expo.
dev/router/reference/not-found/.
[31] Patterns.dev, List virtualization, Accessed: 2024-10-28. [Online].
Available: https : / /www . patterns . d e v / v a n i l l a / v i r t u a l -
lists/.
[32] Shopify, Flashlist documentation, Accessed: 2024-10-28. [Online].
Available: https: //shopify .github. io/f l a s h - l i s t / .
[33] Shopify, Flashlist known issues, Accessed: 2024-10-28. [Online].
Available: https : //shopify .github . io/f l a s h - l i s t / d o c s /
known-issues.
[34] Expo Documentation Team, Run eas build locally with a localflag expo
documentation, Accessed: 2024-11-15. [Online]. Available:
https://docs.expo.dev/build-reference/local-builds/.
[35] M . Moroz, Ota updates with expo, Accessed: 2024-11-15. [Online].
Available: https : //pagepro . co / blog/ota-updates-with -
expo/.
[36] Apple Inc., Establishing your app's integrity, Accessed: 2024-11-24.
[Online]. Available: https : //developer. apple. com/documentation/
devicecheck/establishing-your-app-s-integrity.
50
A Use-case diagrams
51
A . USE-CASE DIAGRAMS
B Application Design (PO)
These screens were proposed by the Product Owner.
9:41 ..ll B
MK SAXveno ::
Měsíční přehled
Měsíční saldo k 18. 4.
Příplatky
Přesčasy
-1410:40
Ne
0:00
O Práce
9 Dovolená
0:00
8:00
0 Nemoc
0 Lékař
0:00/0dnů
8:00
Figure B.l: Dashboard
B. APPLICATION DESIGN ( P O )
9:41 .III B
MK SAXvéŕío • a
• •
lor Březen Duben Květen
A A A
lln
Dovolená
r ©
® 1L Můj výkaz Žádosti Smery M oje práce A
k .
A ŕ p r n a n á 16 hodin
Figure B.2: Dashboard - graph and vacation
54
B. APPLICATION DESIGN ( P O )
9:41 -
MK
^™"» « "RESORT
C-A\veno
• •
Můj výkaz
< D u b e n 2024
A Chybné dny: S
>
Po
1,4,
Svátek
(8:00)
0:03
út A
2.4.
Neexistující záznamy -S:00
3 :
Lékař
(8:00)
o.oa
Čt
4.4.
Pružná (8:00-16:00)
Přestávka (14:00-14:30)
o.oa
Pá
5,4.
Pružná (8:00-16:00]
Přestávka (14:00-14:30)
•0:30
So
6,4.
•
Ne
7.4.
•
f (í) © ® 0Můj výkaz Žádosti S miny Moje prác*
W
Figure B.3: Timesheet
55
B. APPLICATION DESIGN ( P O )
MK
9:41 ..Ii •
« «RESORT
QirAweno
Nový požadavek
Zaměstnanec
Martin Kyncl
Dovolená
Období
25. 4. 2024 30.4. 2024 0
Doba trvána
Dlí rozpisu smír
Orientační čas
Poznámka
Figure B.4: Absence Request - Form
56
B. APPLICATION DESIGN ( P O )
9:4i . , i i ~ M
eA l I R E 5 D F T
^ Axveno
(s)
Čtečka Dashboard
© ®
Můj výkaz Žádosti o dovolené
<§> 0
Plán směn Práce na zakázkách
Martin K.
Odhlásit
Kontaktujte nás
Figure B.5: Menu design
57
B. APPLICATION DESIGN ( P O )
MK
9:41
oANveno
Dnešní aktivita
Příchod 05:26
0
Příchod
®
Odchod
©
Přestávka
Služební cesta
©
Přestávka
©
Přerušení směny
©
Ostatní
O
Prerušení směny
Figure B.6: Reader design
58
C Source code
The archive attached to this thesis (in .zip format) contains the application's
full source code and R E A D M E . It also contains a copy of
a mock server, which allows the testing of the copy in the archive
without relying on the server to support it.
Use R E A D M E to set up your development/runtime environment
and test the application. If it does not work, the newer version is
available on Google Play or the A p p Store. Credentials are available
in the .zip file and will be valid for one year from the publishing date.
59