A Mobile Application For Freshers Joining UoM

A MOBILE APPLICATION FOR FRESHERS
JOINING UOM
Name: Moorateeah Tashil Rye Student ID: 1611496
Name: Bhagowantin Avi Gireshan Student ID: 1612225
Supervisor: MR Selvanaden Sathan
A thesis submitted in partial fulfillment of the requirements for the award of

the degree of
BSc (Hons) in Computer Science

University of Mauritius
Faculty of Information Communication and Digital Technologies
Department of Information and Communication Technologies
Submitted on: 2nd April 2019

Table of Contents
List of Figures................................................................................................................................ v
List of Tables ............................................................................................................................... vii
List of Abbreviations and Acronyms ........................................................................................... viii
Acknowledgement ......................................................................................................................... x
Abstract ........................................................................................................................................ xi
1. Introduction ........................................................................................................................... 1
1.1 Problem Statement .......................................................................................................... 1
1.2 Aims and Objectives ....................................................................................................... 3
1.3 Motivations .................................................................................................................... 4
1.4 Methodology .................................................................................................................. 4
1.5 Gantt chart ...................................................................................................................... 5
1.6 Distribution of task ......................................................................................................... 5
2. Background Study .................................................................................................................. 6
2.1 Related Work: Literature Review .................................................................................... 6
2.1.1 Indoor/Outdoor Management System ...................................................................... 6
2.1.2 A Mobile Indoor Positioning System ....................................................................... 7
2.1.3 Indoor Localization and Guidance ........................................................................... 8
2.1.4 Campus-wide Wireless Indoor Positioning .............................................................. 9
2.1.5 Interactive Mobile Campus ................................................................................... 10
2.2 Proposed Solution ......................................................................................................... 14
2.3 Requirement Specification ............................................................................................ 15
2.3.1 Functional Requirements FR ................................................................................. 15
2.3.2 Non Functional Requirement................................................................................. 16
2.4 Chapter Summary ......................................................................................................... 16
3. Analysis ............................................................................................................................... 17
3.1 List of Components Overall .......................................................................................... 17
3.2 Mobile Platform ........................................................................................................... 17
3.2.1 Criteria for Mobile Platform .................................................................................. 17
3.2.2 Options for Mobile Platform ................................................................................. 18
3.2.3 Selection of Mobile Platform ................................................................................ 19
3.3 Mobile Development Platform ...................................................................................... 20
3.3.1 Criteria for mobile application Platform ................................................................ 20
i
3.3.2 Mobile App Development Platform Available ....................................................... 21
3.3.3 Selection of Mobile Development Platform ........................................................... 23
3.4 Programming Language ................................................................................................ 24
3.4.1 Criteria for programming language........................................................................ 24
3.4.2 Option for programming language ......................................................................... 24
3.4.3 Selection of Programming language ...................................................................... 25
3.5 Database ....................................................................................................................... 25
3.5.1 Criteria for database .............................................................................................. 25
3.5.2 Options for Database............................................................................................. 27
3.5.3 Selection of database............................................................................................. 28
3.6 Operating System ......................................................................................................... 29
3.6.1 Criteria for Operating System ................................................................................ 29
3.6.2 OS Host Available ................................................................................................ 30
3.6.3 Selection of Operating System .............................................................................. 31
3.7 Map Location Technology ............................................................................................ 31
3.7.1 Criteria for Map Location Technology .................................................................. 31
3.7.2 Map Location Technology Available..................................................................... 32
3.7.3 Selection of Map location technology .................................................................... 33
4. Design.................................................................................................................................. 34
4.1 Purpose and Scope ........................................................................................................ 34
4.2 Class Diagram .............................................................................................................. 34
4.3 Use Case ...................................................................................................................... 34
4.4 Sequence Diagram ........................................................................................................ 36
4.5 Activity Diagram .......................................................................................................... 39
4.6 Algorithm Design ......................................................................................................... 41
4.7 System Architecture...................................................................................................... 42
4.7.1 GPS Satellites ....................................................................................................... 42
4.7.2 Estimote iBeacons ................................................................................................. 43
4.7.3 Cloud Database (Firebase) .................................................................................... 43
4.7.4 Mobile application ................................................................................................ 43
4.8 Database Design ........................................................................................................... 43
4.8.1 Structure of Database ............................................................................................ 43
4.9 Mobile Application ....................................................................................................... 49
4.9.1 News and Events ................................................................................................... 49
ii
4.9.2 Navigation Menu .................................................................................................. 49
4.9.3 Bus ....................................................................................................................... 50
4.9.4 Rules & Regulation ............................................................................................... 50
4.9.5 Timetable .............................................................................................................. 51
4.9.6 Indoor/Outdoor Map ............................................................................................. 51
4.9.7 CPA Calculator ..................................................................................................... 52
4.9.8 Authentication Screen ........................................................................................... 52
4.9.9 Settings ................................................................................................................. 53
4.9.10 Feedback .............................................................................................................. 53
4.9.11 Cafeteria ............................................................................................................... 54
4.9.12 Admin Panel ......................................................................................................... 54
4.10 Chapter Summary ......................................................................................................... 55
5. Implementation .................................................................................................................... 56
5.1 Cafeteria ....................................................................................................................... 56
5.1.1 Select cafeteria ...................................................................................................... 57
5.1.2 Cafeteria Menu ..................................................................................................... 58
5.1.3 Cafeteria Cart........................................................................................................ 59
5.1.4 Cafeteria Checkout................................................................................................ 60
5.1.5 Cafeteria Admin.................................................................................................... 64
5.2 Events and News .......................................................................................................... 66
5.2.1 News .................................................................................................................... 66
5.2.2 Events ................................................................................................................... 67
5.2.3 Add News Articles (Admin) .................................................................................. 68
5.2.4 Add Events (Admin) ............................................................................................. 70
5.3 Indoor and Outdoor Navigation/Map ............................................................................ 73
5.3.1 Outdoor Navigation .............................................................................................. 73
5.3.2 Indoor Navigation ................................................................................................. 77
6. Integration and Testing ......................................................................................................... 79
6.1 Methodology ................................................................................................................ 79
6.2 Functional Testing ........................................................................................................ 79
6.2.1 Navigation on the mobile application .................................................................... 79
6.2.2 Indoor/Outdoor Map ............................................................................................. 80
6.2.3 News and Events ................................................................................................... 81
6.2.4 Notifications ......................................................................................................... 82
iii
6.2.5 Timetable .............................................................................................................. 82
6.2.6 Bus schedule ......................................................................................................... 83
6.2.7 Cafeteria ............................................................................................................... 84
6.2.8 Rules and Regulations ........................................................................................... 86
6.2.9 Feedback .............................................................................................................. 87
6.2.10 Authentication ...................................................................................................... 87
6.2.11 Admin Panel ......................................................................................................... 88
6.2.12 Admin Panel (Cafeteria)........................................................................................ 90
6.3 System Testing ............................................................................................................. 94
6.3.1 Performance Testing ............................................................................................. 94
6.3.2 User Acceptance Testing ....................................................................................... 98
6.3.3 Requirement Matrix ............................................................................................ 100
7. Evaluation .......................................................................................................................... 102
7.1 Qualitative assessment ................................................................................................ 102
7.1.1 Ease of use .......................................................................................................... 102
7.1.2 Performance........................................................................................................ 102
7.1.3 Availability ......................................................................................................... 102
7.2 Comparison between similar systems .......................................................................... 102
7.3 Critical assessment ..................................................................................................... 103
8. Conclusion ......................................................................................................................... 104
8.1 Problems and Proposed Solution ................................................................................. 104
8.2 Design ........................................................................................................................ 105
8.2.1 Problem faced ..................................................................................................... 105
8.2.2 Changes made to design ...................................................................................... 105
8.3 Actual Application...................................................................................................... 106
8.4 Future Works .............................................................................................................. 106
References ................................................................................................................................. 107
Appendix ................................................................................................................................... 110
Section 1 ................................................................................................................................ 110
Section 2 ................................................................................................................................ 129
Section 3 ................................................................................................................................ 132
iv
List of Figures
Figure 1.1 Schedule Plan ................................................................................................................ 5

Figure 4.1 Class Diagram ............................................................................................................. 34
Figure 4.2 Use Case ..................................................................................................................... 35
Figure 4.3 Sequence Diagram for user (1) .................................................................................... 36
Figure 4.4 Sequence Diagram for User (2)................................................................................... 37
Figure 4.5 Sequence Diagram for User (3) ................................................................................... 38
Figure 4.6 Sequence Diagram for Admin ..................................................................................... 38
Figure 4.7 Activity Diagram for User ........................................................................................... 39
Figure 4.8 Activity Diagram for Admin ........................................................................................ 40
Figure 4.9 Algorithms - Get Power and Calculate Distance .......................................................... 41
Figure 4.10 Algorithms - Calculating user’s position .................................................................... 42
Figure 4.11 Architecture Diagram ................................................................................................ 42
Figure 4.12 Buses JSON Format .................................................................................................. 45
Figure 4.13 Cafeteria JSON Format ............................................................................................. 45
Figure 4.14 Events JSON Format ................................................................................................. 46
Figure 4.15 Feedback JSON Format ............................................................................................. 46
Figure 4.16 News JSON Format ................................................................................................... 46
Figure 4.17 Orders JSON Format ................................................................................................. 47
Figure 4.18 Rules JSON Format ................................................................................................... 47
Figure 4.19 Timetable JSON Format ............................................................................................ 47
Figure 4.20 User JSON Format .................................................................................................... 48
Figure 4.21 Admin JSON Format ................................................................................................. 48
Figure 4.22 Cafe Admin JSON Format ......................................................................................... 48
Figure 4.23 Wireframe for news & Events ................................................................................... 49
Figure 4.24 Wireframe for navigation menu ................................................................................. 49
Figure 4.25 Wireframe for bus ..................................................................................................... 50
Figure 4.26 Wireframe for Rules & Regulations ........................................................................... 50
Figure 4.27 Wireframe for timetable ............................................................................................ 51
Figure 4.28 Wireframe for Indoor/Outdoor map ........................................................................... 51
Figure 4.29 Wireframe for CPA Calculator .................................................................................. 52
Figure 4.30 Wireframe for authentication ..................................................................................... 52
Figure 4.31 Wireframe for Settings .............................................................................................. 53
Figure 4.32 Wireframe for Feedback ............................................................................................ 53
Figure 4.33 Wireframe for Cafeteria ............................................................................................. 54
Figure 4.34 Wireframe for Admin system .................................................................................... 54
Figure 4.35 Wireframe for admin café .......................................................................................... 55
Figure 5.1 Code for selecting cafeteria ......................................................................................... 57
Figure 5.2 Code for cafeteria menu .............................................................................................. 58
Figure 5.3 Code for cafeteria cart ................................................................................................. 59
Figure 5.4 Code for cafeteria checkout ......................................................................................... 60
Figure 5.5 Code for cafeteria checkout ........................................................................................ 61
Figure 5.6 Code for cafeteria checkout ......................................................................................... 62
v
Figure 5.7 Code for selecting cafeteria checkout........................................................................... 63
Figure 5.8 Code for cafeteria admin - Update Credits ................................................................... 64
Figure 5.9 Code for cafeteria admin - View order ......................................................................... 65
Figure 5.10 Code for cafeteria admin - View Order ...................................................................... 65
Figure 5.11 Code for News ......................................................................................................... 66
Figure 5.12 Codes for News ......................................................................................................... 67
Figure 5.13 Codes for Events ....................................................................................................... 68
Figure 5.14 Codes for Add News (Admin) ................................................................................... 69
Figure 5.15 Codes for Add Events (Admin).................................................................................. 70
Figure 5.16 Codes for Event (Admin)........................................................................................... 71
Figure 5.17 Codes for Event (Admin)........................................................................................... 72
Figure 5.18 Code for outdoor ...................................................................................................... 73
Figure 5.19 Code for outdoor ....................................................................................................... 74
Figure 5.22 Code for indoor ......................................................................................................... 78
Figure 6.1 Performance Testing - Application running on different devices .................................. 95
Figure 6.2 Performance Testing - Screen size ............................................................................... 95
Figure 6.3 Performance Testing – Maximum Lag in render frames ............................................... 96
Figure 6.4 Performance Testing - CPU Usage .............................................................................. 96
Figure 6.5 Performance Testing - Power Usage ............................................................................ 97
Figure 6.6 Performance Testing- Average Ram usage .................................................................. 97
Figure 6.7 Performance Test – Storage ......................................................................................... 98
vi
List of Tables
Table 1.1 Task Distribution ........................................................................................................... 5

Table 2.1 Similar Systems Comparison ....................................................................................... 12
Table 3.1 Comparison for Mobile Platform and its criteria............................................................ 19
Table 3.2 Comparison for Mobile Development Platform and its criteria ...................................... 23
Table 3.3 Comparison for Programming language against its criteria ............................................ 25
Table 3.4 Comparison for Database against criteria ...................................................................... 28
Table 3.5 Comparison for OS and Criteria .................................................................................... 31
Table 3.6 Comparison for Map location and criteria ..................................................................... 33
Table 4.1 Details of information to be stored in firebase ............................................................... 44
Table 6.1 Testing for navigation ................................................................................................... 79
Table 6.2 Testing Map ................................................................................................................. 80
Table 6.3 Testing News and Events .............................................................................................. 81
Table 6.4 Testing notification ....................................................................................................... 82
Table 6.5 Testing Timetable ......................................................................................................... 82
Table 6.6 Testing Bus schedule .................................................................................................... 83
Table 6.7 Testing Cafeteria .......................................................................................................... 84
Table 6.8 Testing Rules and Regulation ....................................................................................... 86
Table 6.9 Testing Feedback .......................................................................................................... 87
Table 6.10 Testing Authentication ................................................................................................ 87
Table 6.11 Testing for admin panel .............................................................................................. 89
Table 6.12 Testing Admin Cafeteria ............................................................................................. 92
Table 6.13 Students who tested the application ............................................................................. 98
Table 6.14 Mobile Application Rating ........................................................................................ 100
Table 6.15 Requirements matrix FR ........................................................................................... 101
Table 6.16 Requirement matrix NFR .......................................................................................... 101
vii
List of Abbreviations and Acronyms
Admin Administrator
API Application Program Interface
BLE Bluetooth Low Energy
CILL Center for Innovative and Lifelong Learning
CPA Cumulative Point Average
CPU Control Processing Unit
CSS Cascading Style Sheets
DB Database
FLM Faculty of Law and Management
FOA Faculty of Agriculture
FOE Faculty of Engineering
FOICDT Faculty of Information, Communication and Digital Technologies
FOS Faculty of Science
FR Function Requirements
FSSH Faculty of Social Sciences and Humanities
GB Gigabyte
GPS Global Positioning System
GPU Graphics Processing Unit
GUI Graphical User Interface
HTML Hypertext Markup Language

viii
iOS iPhone Operating System
JS JavaScript
JSON JavaScript Object Notation
LPA Level Point Average
MB Megabyte
NFC Near Field Communication
NFR Non Functional Requirements
OS Operating System
PDF Portable Document Format
QR Quick Response
RAM Random Access Memory
SQL Structured Query Language
SU Student Union
UI User Interface
UoM University of Mauritius
Wi-Fi Wireless Fidelity
ix
Acknowledgement
This has been a project which imposed a lot of challenges. We would like to give our sincere
gratitude to all those people who has contributed to make the project less complex for us and helped
us.
First of all, we would like to thank our project supervisor Mr. Selvanaden SATHAN. He has
provided us with essential guidance, advices and support. A very dedicated supervisor, without
whom the project would not be what it is.
A really special thanks to the developers of NativeScript and Mapwize who helped us tremendously
during our implementation stage. Some would get into close contact with us trying to help us debug
our codes.
And lastly, all family members and friends who have supported us and encouraged us throughout
this journey.
x
Abstract
Every year several students are enrolled in courses at the University of Mauritius. In order to help
them start their journey at the university, we decided to create a mobile application which will help
them navigate around the university. However, after conducting a survey, we found out that
students face several other issues. We determined that we could find solutions to most of these
problems and that some of them would be beneficial to the administration department of the
institution. Thus, we added several other features in our application which helped both the students
and staffs of the university. In order to attain the maximum number of users, we made our
application cross-platform using native languages to code it. The result was very fruitful as the
students liked it a lot. A number of freshers used the application and rated the individual features.
An overall rating of around 4.2 was obtained. The freshers mentioned that the application can be
very useful to the senior students as well. The SU also tested the application and concluded that it
will be a very good platform to promote the events being organized at the university. More work
can be done in order to add new features in the application to help the students during their journey
at the University of Mauritius.
xi
1. Introduction
This chapter pertains to a general review of the chosen project and is made of different sub
sections, each containing a specific aspect. The problem statement will give details on the
issues being faced by students when they start their journey at the University of Mauritius.
The aims and objectives section will introduce the proposed solution, while the motivation
section will present the different reasons that have pushed us to work on this project. Next
we will explain the methods and techniques adopted for the development of this project in
the methodology section. Finally, the progress and distribution of tasks sections will show
the advancement of the project under a specific time period.
1.1 Problem Statement

Students who have freshly joined UoM encounter several problems during their first few weeks. In
order to find out the issues faced by freshers, we carried out a survey among the freshers and the
following problems were identified:
 Bus Schedule Problem

 Rules and Regulation at the University
 Procedures at the University
 Changes/Events at the University
 Deadlines
 Issues of communication
 Difficulty with timetables
 Problems to find classes
 Canteen menu
 No knowledge on how CPA works
Please refer to Appendix Section 2 where statistics about the survey are given.
1
Bus Schedule Problem
The transport schedule from UoM to various places across the island is unknown to a large number
of students even though there is a planning provided by several bus companies in Mauritius. This
may cause a big problem for students who have classes ending late in the afternoon.
Rules and Regulation
The survey revealed there is a high percentage of students that are moderately or slightly unaware
of the rules and regulation of UoM. This can cause several problems during the years they will be
studying at UoM.
Procedures
1) Loss of ID
Most students do not know what to do when their Student ID or Bus Pass is lost. This delays the
process for them to get a new ID and also deprives them from several privileges.
2) Obtaining a testimonial
Students are often asked for a testimonial when they go for an internship. However, many students
have no idea where to go in order to obtain their testimonial.
3) Reservation of locker
A great number of students are unaware that lockers are available at the university and the
procedures to book a locker are unknown to them.
Changes/Events
The university hosts several activities such as concerts and talks for the students. However,
sometimes, these events are unknown to students. There may also be day-to-day changes such as
cancellation of lecture or change in class venue. Some students fail to receive information about
these changes and this makes them lose a lot of time.
Deadlines
Many students happen to miss deadlines, especially for official questionnaires and module
registration. Some fail to complete the tasks either because they do not check their email or they
simply forgot. This often results in students having to pay some fine which can be inconvenient.
2
Timetables
Several students find it easier to do group work in classes rather than in the library or the raised
plaza. But unfortunately they do not know where to find free classes at a given time.
Finding classes
Through our survey, we found out that some students have issues finding classes especially in the
FOA building. Students also lose time looking for their classes which might result in them being
late in class and missing part of their lecture.
Canteen
According to the survey, some students had issues due to lack of information on the canteens of
UoM. Some students had problem finding the different canteens on the campus, while others
wanted to have a better visibility on the menu of each of the canteen with its associated price.
Credits
Another issue which we found quite shocking is that many students do not know about things which
are very important for their journey at the university such as how CPA is calculated.
1.2 Aims and Objectives

Having seen the problems faced by the freshers at UoM, we shall design a mobile application to aid
the students. The aim of the project is to help students joining UoM to be more acquainted to the
university and alleviate all the problems that the student might be facing.
The objectives required for the accomplishment of the aims are described as follows:
 Implementation of a map to help the students navigate around the campus. The map will have a
real-time tracking system and it will indicate the path to classrooms with appropriate directions.
The map will consist of the following :
 Location of the classes around the campus

 Location of the facilities such as post office, shops and food snacks near the
campus
 Location of all canteens in the campus
 A platform where the students can find all the procedures and Rules & Regulation to aid them
 A calculator to help the students track their CPA
3
 A canteen menu where the students can find all the food available and their respective price.
 A timetable for the student to find the schedule of the classrooms at UoM
 Implementation of a push-up notification system where nearby events would be sent to the
students as a notification. Other information about the event will be given to the students such
as whether there is a change in the location or time of the event. Notification such as
cancellation of lectures or reminders for test will be provided to the students.
 List of the bus schedule system where the student will find all the routes from their home to
Reduit and vice versa with their associated estimated time and duration of the travel.
 Implementation of user-friendly system whereby the students will be able to navigate freely
through the mobile application.
1.3 Motivations
The reasons for conducting this particular project at this university were:
1. To help freshers to get acquainted to UoM as soon as possible.

2. To help the students that has already been enrolled to get information that they are unaware of.
3. To help the SU in reaching out to the students in a better way.
4. To reduce queues and customer waiting time at the cafeteria.
5. To reduce the work load of administrators.
1.4 Methodology
The main aim of this project is to help the freshers of UoM. In order to do so, GPS signals will be
used to locate the user whenever he is in open space. As for inside buildings, iBeacons will be
placed in the buildings. The mobile application will look for the beacons and communicate with
them via Bluetooth. Upon detecting a beacon, an algorithm will be used to calculate the location of
the user relative to the beacon it connected to. After retrieving the user’s location, his position will
be displayed on a map on the application. The user will also be able to search for classes and he will
be shown the path he should take to reach the class. The application will also provide other features
such as cafeteria menu, notifications for events and class timetables.
4
1.5 Gantt chart
The figure below shows the planning of the project. The duration specified for each chapter is in
month.
Figure 1.1 Schedule Plan
1.6 Distribution of task

This section shows the individual contribution of the team members involved in the project. The
project has been broken in several tasks and distributed equally between the team members as
shown below:
Table 1.1 Task Distribution
5
2. Background Study
2.1 Related Work: Literature Review

In this section research papers and existing systems related to our project will be critically analyzed.
This will help us to identify the key features of the systems and how they can be used to implement
a mobile application for freshers. We will also look at the limitations of the systems so we can
identify the best solution.
2.1.1 Indoor/Outdoor Management System

According to Guenda et al. (2011), nowadays, the demand for indoor and outdoor location systems
has increased greatly. Such systems are not only used at the academic level, but at the commercial
level as well. To match the need of this system, they developed an indoor/outdoor location system
which consists of the GPS location system, ZigBee location system, Data Server and User Interface
& Service.
The proposed system uses ZigBee to setup its indoor location system. Every ZigBee coordinator
has a PC connected which send data to a FTP server. For outdoor location, either Machine to
Machine (M2M) modules together with a GSM module can be used to send GPS receiver geo-
referenced data to the Data Server, or a mobile device which has software working with GPS can be
used. The modules are then displayed with the help of Google Maps. The use of ZigBee is
beneficial as it is cheap, has low-power consumption and can easily be deployed. The system also
uses GPS and Google Maps which is easy to implement and already used in many places.
On the other hand, the system is restricted to Android systems. Furthermore, with the use of GPS,
line of sight of the signal is required; therefore the outdoor positioning can be affected by the
presence of many buildings. Also, the system does not show the paths the user can take to his
destination.
6
2.1.2 A Mobile Indoor Positioning System
According to Lin et al. (2015), the emergency room of hospitals all over the world is usually
overcrowded. As a result, people have to wait a lot and meanwhile they will tend to move around
the hospital. This might make the staff lose a lot of time looking for the patients. In order to solve
this issue, a mobile-based system which can track the positions of the patients with the help of
iBeacon is proposed.
The system proposed uses BLE beacons which are placed at strategic places so as to cover
maximum space using the least number of iBeacons. This will help to reduce the cost of the system.
The system also consists of a server which reads and saves data. It also maps the beacons to the
locations they correspond to, so that we know where the patients are in the hospital. To test the
system, an experimental test-bed was set up in one of their buildings. One major feature of this
system is that it synchronizes with the users at regular intervals to update and store their location on
the server. The use of iBeacon was favored as compared to other wireless technologies, it is
cheaper, lighter and easier to install. IBeacons also have low power consumption properties and are
integrated in many devices.
However, one drawback of iBeacons is the absence of native iBeacon support in Android. Also,
since BLE beacons work on batteries, the batteries will need to be changed every year. Finally, the
deployment of the beacons must be carefully calculated as its signals may be muted by some
structures.
7
2.1.3 Indoor Localization and Guidance
According to Hammadi et al. (2012), with the increase in the number of buildings around us, it is
becoming for difficult for people to navigate themselves. In order to solve this issue, they proposed
an Android based indoor map guidance system that helps and directs visitors inside buildings.
Several other features such as storing car parking location are provided by the system. It is
implemented using QR codes and NFC technology.
The system has been fully developed using freely-available and open source software. The web
server, map server and spatial database of the system were stored on a server on which the system is
dependent. To know the position of the users, NFC tags are placed at several locations in the
building. In order to be tested, the system has been implemented in a smart campus environment to
guide students and staffs. NFC tags are known to have very good accuracy and a small setup time
for communication. They are also very cheap. A very desirable feature of this system is that it can
find the shortest path for the user.
In spite of the system being cheap and easy to set up, it can have some inconvenience. The NFC
tags have a very small range and the phones used need to have NFC reading capability. Also, the
users need to scan the NFC tags or QR codes in order to update their location which can be a hassle.
8
2.1.4 Campus-wide Wireless Indoor Positioning
According to Bai et al. (2017), the importance of indoor positioning and navigation has grown a lot
lately. This is due to the increase in the number of people who come to the university campus from
abroad. Some come to study whereas others come to take part in academic activities and therefore a
navigation system will be very beneficial for them. They came up with a hybrid system which
consists of using iBeacon together with the Wi-Fi network and fingerprint technique.
The iBeacons were placed to give the precise location of the users inside the building. In order to
get the outdoor positioning of the users, several Wi-Fi APs were used. They also created a database
containing the signal strength from different Wi-Fi Access Points and iBeacons as the fingerprint
technique is used in these positioning systems. To test the hybrid system, they implemented a
prototype in one of their buildings. This idea of using Wi-Fi combined with iBeacons is very
beneficial as it reduces cost a lot. Additionally, Wi-Fi is a good alternative to GPS for outdoor
location and both Wi-Fi and Bluetooth are usually already integrated in smartphones. The hybrid
system shows the path the user should take and also provides long-range coverage while improving
accuracy as well. Moreover, the system is easy to deploy as existing Access Points can be used.
While this may be true, the use of too many Aps and BLEs may be an issue as they can cause
interferences. Also, these technologies make use of fingerprint technique to establish
communication which makes the setup of a signal strength database necessary.
9
2.1.5 Interactive Mobile Campus
According to Liu et al. (2011), in this modern era, people want everything to be fast and readily
available. It is the same in universities as students want to be able to communicate with their
lecturers and classmates as quickly as possible. They also want to be informed of events and to be
able to interact with university facilities easily. To provide them with this facility, a mobile system
which will help students during their university life was proposed.
The main components of the proposed system are the GUI, the mapping module, the location-based
service, databases and mobile communication network module. The signal strengths are used to
determine the position of the person even if he/she is moving. An algorithm is implemented in the
system to add the various user requirements. These information are then sent to the server where
they are analyzed in XML format, and the appropriate action is taken, such as displaying the map of
the university or the location of an event. The algorithm used to determine the positions of the uses
is adjusted according to environment and user requirements. Since GPS cannot give accurate
positioning, the system makes use of ZigBee localization system which as we saw before is cheap,
easy to install and consumes little power.
However, ZigBees have a limited battery life and thus will need to be changed after a few years.
They also have a short range and therefore more ZigBees will be needed to cover a large area. In
addition, not many end devices are compatible with ZigBee.
10
Having explored these systems, it has been found that they have several features in common such
as:
1. Low energy consumption characteristics

2. Easy to deploy
3. Map
4. Automatic regular update of location
5. Gives path to reach destination
6. Cross-platform
Low energy consumption characteristics
This feature is very important as it reduces the cost of the systems a lot and the battery usage of the
mobile application will be decrease drastically. If the systems would consume a lot of energy, they
would not be beneficial to both the user and the developers.
Easy to deploy
Ease of deployment is a crucial aspect as these systems are usually implemented in places which are
quite crowded. Therefore, the implementation of the system should not be much of an
inconvenience to the people/clients.
Map
A map is a must for such systems so that the users do not get lost. It also allows them to find their
destination and track their progress towards it. A map will be a guide to the freshers in their new
environment.
Automatic regular update of location
This feature makes it easier for the users to locate themselves on the map while they are moving. It
also allows them to know exactly when they need to take a turn or when they reached their
destination.
Gives path to reach destination
By showing the path to be taken, the system helps the users to guide themselves more easily and
will prevent them from taking a wrong way. It also allows the users to save a lot of time as they do
not need to look for the way to their destination.
11
Cross-platform
A cross-platform system is very beneficial as it makes the system available to a larger number of
people. The number of iOS users is increasing in this competitive era and since many years the
number of android users has been dominating.
The table below represents the comparison between the similar systems.
Table 2.1 Similar Systems Comparison
12
The desired features for the project are as follows:
1. Login
2. Menu and easy navigation
3. Map tracking
4. Bus information
5. Events and news
6. Cafeteria
7. Class timetable
8. User feedback
9. Push notification
10. Settings
Login
A username and a password will be used by the user to access the system. Nevertheless, the system
will be not restricted to only users related to UoM. The university often organizes events whereby
parties not related to UoM will be present on the campus. These users should be able to use some
features of the mobile application without having to login.
Menu and easy navigation
This feature will allow the user to have a better comprehension of the system and will not be bored
to use the system. The system should be user friendly and minimizing the number of clicks, swipes
and actions is a key point for this app.
Map tracking
 This feature includes a detailed outdoor map of the whole campus including the location of all
class in the different faculties.
 Map tracking accurately locates the user and guides them through the campus from their start
position to their destination, showing the path that needs to be taken.
Bus information
 This feature gives an overview of all the bus schedules from the university to various places
across the island.
 The arrival time of the next bus should also be given to the users.
13
Events and news
 All the events and news will be displayed on the homepage.

 Users will be notified about any changes in events.
 Details of the events will be shown on the map.
Cafeteria
 Any updates about the cafeteria will be given to the user

 Users can make a purchase on the application itself.
Class Timetable
 Students will be able to view the timetable for any class across the campus
 Students should be able to search for any free classes.
User Feedback
This feature will allow the user to give a feedback on the system or about the university so that the
necessary can be done to solve the issue.
Push notification
 This feature will allow the user to receive a notification about the events and updates for the
university.
Settings
Users will be able to change their personal details.
2.2 Proposed Solution

Having studied similar systems and calculating the desired features of the system, a proposed
solution has been envisaged. The system will consist of:
1. The user will be presented with a menu where he will be able to access different section of
the system.
2. Upon accessing the map, the user’s location will be tracked and shown on a detailed map.
The user will also be given a path to his destination.
14
3. Upon accessing the events and news feature, the user will be presented with upcoming
events and news about the university.
a. The user can view each event independently and more details about the event
will be given.
b. The user will be able to view the events on the outdoor map during the day the
event will be held.
4. Upon accessing the cafeteria feature, the user will be given all the different cafeterias at the
university
a. The user will choose the cafeteria of his/her choice,
b. The user will be presented with the menu and the associated price,
c. The user will be able to customize his order and make a purchase,
d. The user will be able to update his credits by going to the cafeteria.
5. Upon accessing the bus feature, the user will be able to see the different routes available at
the Reduit bus stop. He shall also see the next bus arrival time for each bus.
6. Upon accessing the class timetable feature, a timetable for the whole week will be
presented to the user.
7. Upon accessing the user feedback feature, the user will be able to comment on any problem
concerning the system and the university.
8. The settings option will allow the user to change his personal details.
9. The user can log out of the system at any given time.
10. The admin will be able to add/update news and events.
11. The cafeteria admin will be able to post any news for the cafeteria and update the credits of
students.
12.
2.3 Requirement Specification

The proposed system should meet specific requirements. It is an important phase of the system
which must be clearly defined and understood. These requirements are classified into functional and
non-functional requirements.
2.3.1 Functional Requirements FR

FR 1: The system shall allow the user to navigate freely through the application.
FR 2: The system shall provide the user with a fully detailed map of the whole campus
FR 3: The system shall locate the user on the campus.
FR 4: The system shall provide a guide between start and end points of the user (outdoor map).
FR 5: The system shall display a floor plan for buildings and locate the user.
15
FR 6: The system shall provide the user about any upcoming events and news about the university.
FR 7: The system shall notify the user about any updates in cafeteria.
FR 8: The system shall provide the user with the appropriate timetable for classes.
FR 9: The system shall provide the user with details of buses going through Reduit.
FR 10: The system shall allow users to make purchase at any of the cafeteria whenever they want.
FR 11: The system shall present users with the rules and regulations of the university.
FR 12: The system shall allow users and admins to log in the system for more permission.
FR 13: The system shall allow users to give feedbacks.
FR 14: The system shall allow admins to update the application.
FR 15: The system shall allow cafeteria admins to view orders of the cafeteria.
2.3.2 Non Functional Requirement

NFR 1: Performance: The system must notify the user of any change about events, news, or
cafeteria within 10 seconds.
NFR 2: Usability: The mobile application interface should be menu driven and user friendly.
NFR 3: Performance: System must be able to run on a minimum of 1GB RAM.
NFR 4: Accuracy and Precision: The system should position the user accurately on the outdoor
map.
NFR 5: Performance: The system must position any user using the indoor map within 10 seconds.
NFR 6: Scalability: The mobile application must be scalable for any mobile devices’ size.
NFR 7: The system must be less than 1 GB.
NFR 8: Performance: The system must make optimal battery use.
NFR 9: Performance: The application must run on all android smartphones with version 4.0 or
higher.
2.4 Chapter Summary

This chapter summarizes the research done to arrive at a proposed solution. Several existing
systems were studied and important information was gathered. The next chapter provides a
thorough analysis of the components required to elaborate the proposed system.
16
3. Analysis
In the previous chapter, we were able to acquire a wider knowledge on the functionality of other
similar systems after carrying out an extensive research. As a result, a more reliable and efficient
solution was proposed. Subsequently, the components of the proposed solution will be analysed in
this chapter. The analysis section consists of a thorough investigation and elaboration on the various
components required for the implementation of the mobile app. The system’s performance is taken
into consideration as the choice of components affects it directly.
3.1 List of Components Overall

The mobile app for freshers joining UoM requires certain components to be able to solve the
problems efficiently.
The list of components is as follows:
 Mobile Platform
 Mobile Development Platform
 Programming Language
 Database
 Operating System
 Map Tracking
3.2 Mobile Platform

Mobile Platform is the hardware/software environment on which the mobile app will be deployed to
and tested.
3.2.1 Criteria for Mobile Platform

According to Lilia Udovychenko (2016), the criteria for choosing a mobile platform are:
 Target Audience
 Moderation
 Features
17
Target Audience
The target audience for the mobile application consists of the students that have recently joined
UoM. There are both Android and iOS users on the campus.
Moderation
Moderation depends on the type of mobile platform being used and on how an application should
behave in order to be submitted to their market place. iOS apps are always strictly moderated
whereas Google Apps have a more reliable moderation system.
Features
The features and the user experience required for the mobile app need to be considered. A “run
once run everywhere” approach would be more efficient in the mobile app currently being
developed.
3.2.2 Options for Mobile Platform

The mobile platform that are most widely used across the world as follows:
1. Apple iOS
2. Google Android
3. Microsoft’s Windows Phone
4. Nokia’s Symbian
Apple iOS
iOS (iPhone Operating System) was developed specifically to be used with the hardware of Apple.
iOS has become very popular and the number of users is drastically increasing. (En.wikipedia.org,
n.d).
Google Android
Android was developed by Google mainly for touchscreen devices such as tablets and smartphones
but is now used in several other devices as well. (En.wikipedia.org, n.d).
Nokia’s Symbian
Symbian is a mobile OS which was used by several brands such as Samsung, Sony Ericsson and
Motorola. (En.wikipedia.org, n.d).
18
Microsoft’s Windows Phone
Microsoft developed Windows Phone as a replacement for Windows Mobile. The mobile OS
consisted of several releases such as Windows Phone 7 and Windows Phone 8.1.(En.wikipedia.org,
n.d).
3.2.3 Selection of Mobile Platform

The comparison for mobile platform and the criteria are as follows:
Table 3.1 Comparison for Mobile Platform and its criteria
19
3.3 Mobile Development Platform
A smart application development platform should be chosen to provide a good interface that is user
friendly and attractive to users.
3.3.1 Criteria for mobile application Platform

According to Robert Sheldon (2014), the following are the criteria needed to choose an appropriate
platform for mobile application development:
 Multi-Platform Capabilities
 Cost
 Emulator
 Security
 Usability
 Integration
 Multi Operating System Capabilities
Multi-Platform Capabilities
From a development standpoint, it is extremely efficient if the development and deployment codes
can be used on the same platform only once.
Cost
A free and open-source platform should be chosen and it should be ensured that most of the
additional key functionalities are free.
Emulator
The emulator should be fast to execute and should act as a real device to be able to test on various
devices such as phone and tablets. It should be able to simulate map tracking technology.
Compatibility with Operating System
The mobile development platform chosen should be compatible with the chosen OS.
Security
The platform should allow features to be easily built for in-app security by using a single stack
solution.
20
Usability
The mobile development platform should be easy to use and intuitive. It should also provide
developers with a wide range of tools.
Integration
The mobile application development tool should be able to integrate with the systems and services
that touch the application throughout its lifecycle.
3.3.2 Mobile App Development Platform Available

As cross platform app was chosen, a list of the best cross platform mobile app development was
chosen.
1. Xamarin
2. NativeScript
3. Ionic
4. Apache Weex
5. React Native
Xamarin
Xamarin contains native, standard UI controls and leverages platform-specific hardware
acceleration. It is also compiled for native performance. Xamarin has access to the complete range
of functionality exposed by the underlying platform and device. (Visual Studio, n.d).
Type: Native
Platform: Android, iOS, Windows Phone 8
Language(s): C#
Open-Source: Yes
React Native
React Native builds mobile application using a rich mobile UI. React Native combines smoothly
with components written in Swift, Java, or Objective-C. (Facebook.github.io, n.d.).
Type: Native
Platform: Android, iOS
Language(s): JS
Open-Source: Yes
21
NativeScript
NativeScript is an open-source framework used to develop applications on both iOS and Android
platforms. NativeScript applications are built using JavaScript and other languages that transpiles
from JavaScript such as Typescript. NativeScript supports frameworks such as Angular and
Vue.JS. (En.wikipedia.org, n.d).
Type: Native
Platform: Android, iOS
Language(s): HTML, CSS, JavaScript
Open-Source: Yes
Ionic
Ionic is built using web components and it comes with feature, performance and usability. Ionic is
a cross-platform mobile application development framework that combines its own UI library with
Angular. (GitHub, 2018).
Type: Hybrid
Platform: Android, iOS, Windows Phone 8, Chrome, Desktop
Language(s): JS, Typescript
Open-Source: Yes
Apache Weex
Weex is a client-side technology but it also acts as a bridge from local development environment to
the cloud deployment and distribution. It is efficient in terms of performance and a Weex is very
fast in executing JS applications (Weex.apache.org, n.d).
Type: Native
Platform: Android, iOS, Web
Language(s): JS
Open-Source: Yes
22
3.3.3 Selection of Mobile Development Platform
Following the criterias previously discussed, the platform was chosen as follows:
Table 3.2 Comparison for Mobile Development Platform and its criteria
23
3.4 Programming Language
The most optimum programming language for mobile application development needs to be chosen
for a more efficient system.
3.4.1 Criteria for programming language

The criteria for choosing a programming language are as follows:
 Scalability and Robust

 Usability
 Documentation facilities
3.4.2 Option for programming language

The following are the programming languages that NativeScript supports:
1. JavaScript
2. VueJS
3. Angular/Typescript
JavaScript
JavaScript is a high-level interpreted programming language which supports object-oriented and
functional programming. It is the language that is run on browsers and it is used to control web
pages. It is possible to create mobile applications with JavaScript only when used with CSS,
HTML, and AJAX (En.wikipedia.org, n.d).
VUE
Vue.js focuses on declarative rendering and component composition. Vue.js is a language that has
been transpiled from JS to make is easier to code by providing libraries which can be used to build
complex applications such as routing and state management. (En.wikipedia.org, n.d)
Angular/Typescript
Angular is a framework which has been entirely built in Typescript. Many mobile application
development platforms make use of Angular to build their UI components (Typescriptlang.org,
n.d).
24
3.4.3 Selection of Programming language
The table below shows the factors taken into consideration to choose the programming language.
Table 3.3 Comparison for Programming language against its criteria
3.5 Database
Database is where all the data about students and the university will be stored.
3.5.1 Criteria for database

According to Parihar (n.d), the criteria given is the best one considering implementation of a mobile
application.
 Storage Capacity
 Cost and Suitability
 Usage
 Security
 Reliability
 Ease to handle through codes
 Cross Platform
 Notification implementation
25
Storage capacity
The storage capacity of the database is crucial to this project as the number of students’ information
that will be stored in the system will be relatively large. Therefore, the chosen database should be
one which has an unlimited capacity of storing data. The tradeoff is that storage is limited in mobile
phones. The solution might be the use of cloud computing.
Cost and Suitability
The database should be free of charge as the system being developed will be used mainly by
students.
Mode and speed of access
The database should be able to retrieve and save data as fast as possible so that the user experience
is not affected.
Reliability
The database should be a reliable one as loss of data or database crash would have a negative
impact on the system.
Security
The database software should guarantee user access control, data integrity as well as backup and
recovery functionalities for a secured system. Tampering of data should also be avoided since it
may have negative consequences to the system.
Cross Platform
The database should be able to provide APIs for different mobile devices OS.
26
3.5.2 Options for Database
Based on the above criteria, the mobile development platform chosen (NativeScript) and the
programming language chosen (TypeScript), a number of databases will be compared. The
databases to be reviewed are (Parihar, n.d):
1. Realm DB
2. SQLite
3. Couchbase Lite
4. Microsoft Azure database
5. Firebase
SQLite
SQLite is relational DB designed for mobile devices. SQLite can be stored both on disk as well as
in memory. SQLite is fast in processing data and the data is stored in the memory itself.
Realm DB
Realm is a relational database management system in which data can be queried and filtered. It is
cross-platform and server-less. Data in realm DB can be secured through a transparent encryption
and decryption.
Couchbase Lite
Couchbase Lite is a NoSQL database and it syncs with Cloud. Couchbase Lite is deployed on
device itself and is stored as a binary and JSON format.
Microsoft Azure Database
Microsoft SQL Azure is found in the Microsoft’s Windows Azure cloud computing platform and is
based on the SQL Server database system. It enables organizations to store relational data in the
cloud. It is also scalable as per the size of the database needed (Azure.microsoft.com, n.d).
Firebase
Firebase Real-time Database is a database hosted on the cloud. Information is saved as JSON and is
updated to every client who is connected. They offer Real-time and offline support. It is stable with
very low latency and it scales to approximately 1,000 writes per second in just one database and
100,000 concurrent connections. Firebase database is used in mobile app such as Shazam,
Alibaba.com and Watt pad among others. (Firebase, n.d)
27
3.5.3 Selection of database
The databases are evaluated through the different criteria mentioned previously.
Table 3.4 Comparison for Database against criteria
28
3.6 Operating System
The OS which is more compatible with the chosen components above need to be chosen for
implementation of the system
3.6.1 Criteria for Operating System

 Compatibility with chosen Database
 Compatibility with chosen Mobile Application Development Platform
 Longevity
 Cost
 Security
Compatibility with chosen database
The database chosen should be compatible with the OS.
Compatibility with chosen Mobile Application Development Platform
The mobile application development platform chosen should be compatible with the OS.
Longevity
An OS which provides adequate security measures and is operating for a long term should be
considered.
Cost
An OS with free maintenance cost and upgrades should be considered. The operating cost of the
server should be free so as to minimize the cost for implementation of system.
Security
An OS which is less susceptible to viruses should be considered and which requires admin rights
virtually.
29
3.6.2 OS Host Available
The OS chosen are the latest ones pertaining to the market.
 Ubuntu 18.04
 Microsoft Windows 10
 OS X
Ubuntu 18.04
Ubuntu server is an open source OS which supports network, web services and database
management and offers maximum system performance with high security (Wiki.ubuntu.com,
2018).
Microsoft Windows 10
Windows 10 is a licensed OS which is very user friendly and can be used to program software.
(En.wikipedia.org, n.d).
OS X
OS X is a licensed graphical OS by Apple. It is mainly used for graphical projects as it offers very
good graphical images (En.wikipedia.org, n.d).
30
3.6.3 Selection of Operating System
The Operating Systems are evaluated based on the different criteria mentioned previously.
Table 3.5 Comparison for OS and Criteria
3.7 Map Location Technology

Map location technology is the technology that will be used to locate the student at any particular
moment in time at the university.
3.7.1 Criteria for Map Location Technology

The criteria for choosing Map Location Technology are as follows (Top Mobile and Web App
Development Company, 2018):
 Power Usage
 Ability to work with platform and devices
 Accuracy of localization
 Range
 Cost
31
Power Usage
The power drainage of mobile phones is very important as map localization is mainly used by the
students if they are lost across the campus. The quick drainage of the mobile device might become
an issue.
Ability to work with platform and devices
The technology used for map localization should be able to work with different mobile devices’ OS
and mobile development application platform to ensure fluid flow of work.
Accuracy of localization
The accuracy to locate a student across the campus increases the efficiency of the system.
Range
UoM is a large campus consisting of several faculties and administrative office. The coverage of the
whole campus for map localization is a vital part into implementing the system.
3.7.2 Map Location Technology Available

The map location technology given below are the latest one using for map location (Gomez, 2017).
1. GPS
2. Beacons
3. Wi-Fi
4. NFC
Global Positioning System (GPS)
GPS can determine the ground position of an object by a method called triangulation. GPS has an
unlimited range. GPS drains mobile device batteries quickly as it requires a lot of power. GPS is
susceptible to obstruction making its indoor accuracy very low.
Beacons
Beacons emit a signal which allows mobile applications (running on both iOS and Android devices)
to get the power rating of the signal from the device. Depending on the power, the distance between
the user and the beacon, the location can be calculated. The technology makes use of BLE, a power-
efficient Bluetooth technology which optimizes battery usage. (IBeacon.com Insider, n.d).
32
Wi-Fi
Wi-Fi can pinpoint the location of a user by detecting devices that have Wi-Fi turned on. This
method has been used for sending push notifications and can also be used to pinpoint a user’s
location.
NFC (Near Field Communication)
NFC is a set of protocols used for close-proximity wireless communications between devices. NFC
transfers data faster than Bluetooth. Its short range makes it ideal for secure mobile payments.
3.7.3 Selection of Map location technology

The selection of the map location technology will be done for both indoor and outdoor
simultaneously.
Table 3.6 Comparison for Map location and criteria
33
4. Design
4.1 Purpose and Scope

The purpose of the design phase is to provide a clearer view of what should be implemented in the
system. Also, this chapter consists of all the wireframes of the proposed mobile application. The
chapter will also consist of the use case and sequence diagrams which will indicate the flow of
work of a user through the system.
The design phase will consist of the following:
 Class Diagram
 Use Case
 Sequence Diagram
 Activity Diagram
 Algorithm Design
 System Architecture
 Database Design
 Wireframes
4.2 Class Diagram

The class diagram, found on the next page, consists of the set of classes that will be used to
implement the mobile application.
34
Figure 4.1 Class Diagram
4.3 Use Case
The following Use Case diagram shows the interactions within the system through graphical
illustration. It specifies the expected system behavior in terms of scenarios.
Figure 4.2 Use Case
35
4.4 Sequence Diagram
The Sequence diagram shows the object interactions and the messages being passed between
them.
Figure 4.3 Sequence Diagram for user (1)
36
Figure 4.4 Sequence Diagram for User (2)
37
Figure 4.5 Sequence Diagram for User (3)
Figure 4.6 Sequence Diagram for Admin
38
4.5 Activity Diagram
Activity diagram represents the flow from one activity to another activity in terms of a flowchart.
Figure 4.7 Activity Diagram for User
39
Figure 4.8 Activity Diagram for Admin
40
4.6 Algorithm Design
In this section, the pseudocode for determining the distance and position of the user on the map
using the iBeacons are shown:
1. Getting power from the iBeacons and calculating distance
The power (TxPower) and power at one meter (Rssi) given by the beacons are used to calculate
the distance from the iBeacon. An average is performed on the values obtained to get a more
accurate distance.
Figure 4.9 Algorithms - Get Power and Calculate Distance
2. Converting the meters into latitude and longitude
The distance from the beacon is converted into latitude and longitude along a straight line inclined
at a certain degree in x and y coordinates. Using the beacon’s latitude and longitude as initial
position, the new user location is calculated.
41
Figure 4.10 Algorithms - Calculating user’s position
4.7 System Architecture

This section contains information on how the different components of the system will interact with
each other. A brief diagram is shown to demonstrate the interaction between the components
making up the system. The figure below shows an overview of the architecture of the system and
interactions of the components of:
Figure 4.11 Architecture Diagram
Having seen the components which make up the system, we will now explain the job of
each component:
4.7.1 GPS Satellites

GPS Satellites are a very important part of the system. Their aim is to localize the user whenever
the person is in an open area. The information is then sent to the application via Wi-Fi. This helps
to guide the users towards their destination and can allow them to locate themselves on the map .
42
4.7.2 Estimote iBeacons
Since GPS Satellites can locate the user only if there is a line of sight, these iBeacons are needed so
we can find the location of the user inside buildings. They also come with built-in NFC which can
be used to trigger beacon events. The Estimote iBeacons use Bluetooth to communicate with the
application.
4.7.3 Cloud Database (Firebase)

Firebase cloud database is a real-time database and is usually used to store data which is common to
all users. Thus, the cloud database will contain most of the data which will be used by the
application such as events, schedules and any update for the university.
4.7.4 Mobile application

The main objective of the mobile application is the help the user navigate around the campus using
the map. It will also inform the users about events and changes in the university.
4.8 Database Design

This section will elaborate more on how the database is designed by taking into consideration the
class diagram.
4.8.1 Structure of Database

The database structure determines a specific format for data organization and storing. The data in
real-time database firebase is stored in a JSON format.
43
Table 4.1 Details of information to be stored in firebase
44
Below is a list of parent nodes and their respective JSON format showing how the data is stored
in the Firebase database:
1. Buses
Figure 4.12 Buses JSON Format
2. Cafeteria
Figure 4.13 Cafeteria JSON Format
45
3. Events
Figure 4.14 Events JSON Format
4. Feedback
Figure 4.15 Feedback JSON Format
5. News
Figure 4.16 News JSON Format
46
6. Orders
Figure 4.17 Orders JSON Format
7. Rules
Figure 4.18 Rules JSON Format
8. Timetable
Figure 4.19 Timetable JSON Format
47
9. User
Figure 4.20 User JSON Format
10. Admin
Figure 4.21 Admin JSON Format
11. Café admin
Figure 4.22 Cafe Admin JSON Format
48
4.9 Mobile Application
Wire framing is done to establish the basic structure of the pages of the mobile application.
Wireframes ensure that each page has a purpose, achieve the goals set out to develop the mobile
application and define a logical navigation for your mobile application.
4.9.1 News and Events

When the user starts the application, he will be presented with the news page. This page will act as
the home page for the application, providing the users with all the news and events at the university.
Figure 4.23 Wireframe for news & Events
4.9.2 Navigation Menu

The navigation for the application will consist of a simple structure where the user needs to open a
side drawer using the hamburger icon.
Figure 4.24 Wireframe for navigation menu
49
4.9.3 Bus
The bus section will consist of a search field and the list of buses which go through Reduit with
their appropriate attributes.
Figure 4.25 Wireframe for bus
4.9.4 Rules & Regulation

This section will consist of 2 pages, one with the rules titles and the other with content of each rule.
Figure 4.26 Wireframe for Rules & Regulations
50
4.9.5 Timetable
The timetable section will consist of the list of classes pertaining to several rooms of the university.
Figure 4.27 Wireframe for timetable
4.9.6 Indoor/Outdoor Map

The outdoor map will consist of the UoM campus map and all interaction will be done on the map
itself. The indoor map will be composed of the floor plan of buildings at UoM.
Figure 4.28 Wireframe for Indoor/Outdoor map
51
4.9.7 CPA Calculator
The CPA calculator will consist of a button to add modules. This button will contain several input
text boxes and a calculate button to calculate the CPA.
Figure 4.29 Wireframe for CPA Calculator
4.9.8 Authentication Screen

The authentication screen will consist of 3 pages namely login, signup and forget password.
Figure 4.30 Wireframe for authentication
52
4.9.9 Settings
The settings page will allow the user to modify his personal details.
Figure 4.31 Wireframe for Settings
4.9.10 Feedback
The feedback page will consist of a simple paragraph, guiding the student and setting some rules on
the feedback, and a submit button to send the admin any queries.
Figure 4.32 Wireframe for Feedback
53
4.9.11 Cafeteria
The cafeteria will consist of 2 pages. One page for the cafeterias available and the other page will
be a tab view which divides into 3 sections (Item, Cart and QR Code). The item section will contain
menu items with checkboxes for customization. The cart will have the items the user wants to buy.
The QR Code will give the user a barcode so that he can pick up his order at the cafeteria.
Figure 4.33 Wireframe for Cafeteria
4.9.12 Admin Panel

There will be two types of admins, one to manage the system and one to manage the cafeteria.
4.9.12.1 Admin System
Figure 4.34 Wireframe for Admin system
54
4.9.12.2 Admin Cafe
Figure 4.35 Wireframe for admin café
4.10 Chapter Summary

This chapter consists of the design and structure of the mobile application .The next chapter will
consist of the actual implementation of the mobile application based on the design.
55
5. Implementation
During this chapter, we will describe how the cross-platform mobile application was developed. We
will focus on the 3 main features of the system, namely:
● The Cafeteria
● The Events and News
● The Indoor and Outdoor Navigation/Map
The platform used to develop the application is NativeScript which consisted of 2 main
programming languages:
● Angular JS (Typescript)
● HTML & CSS
5.1 Cafeteria
The Cafeteria is a major part of the application. It allows users to view the menus of both cafeterias
found in UoM (Main cafeteria and Secret cafeteria). The users may also place an order on the
application. An admin panel has also been implemented where the staffs of the cafeteria may view
orders placed by students, update credits of users or announce promotions.
56
5.1.1 Select cafeteria
Figure 5.1 Code for selecting cafeteria
The code above retrieves all the cafeteria options (Main and Secret cafeteria) from our cloud
database (Firebase) and pushes them in an array.
57
5.1.2 Cafeteria Menu
Figure 5.2 Code for cafeteria menu
Once the user has selected the cafeteria he wants to interact with, the menu of that cafeteria is
fetched from Firebase.
58
5.1.3 Cafeteria Cart
Figure 5.3 Code for cafeteria cart
The piece of code above allows the user to add or remove items he wants to order to a cart.
59
5.1.4 Cafeteria Checkout
Figure 5.4 Code for cafeteria checkout
After making his choice, the user checks out to place his order. The code checks if the user has
enough credits in his account. If so, the order is placed and the user receives a QR code which is
generated from the number of the order. The user has to present the QR code at the cafeteria to pick
up his order.
60
61
The 2 previous set of codes above help to display the QR code whenever the user accesses the
cafeteria until he picks up his order and also to display his amount of credits.
62
Figure 5.7 Code for selecting cafeteria checkout
The HTML code above displays a tab view where the user can either:
● View the menu of the cafeteria and add items to his cart.
● Place an order and checkout.
● View the QR code of his order.
63
5.1.5 Cafeteria Admin
When a cafeteria admin log in, he is immediately directed to the admin panel of his cafeteria which
gives him the following list of options to choose which action he wants to perform.
5.1.5.1 Update Credits

To update the credits of a student, first, the email of the student is requested. After providing the
email, the admin is directed on another page where he is asked to input the amount of credits he
wants to add to the student’s account.
Figure 5.8 Code for cafeteria admin - Update Credits
After entering the amount, the admin taps on “Add” and the code above updates the credits of the
user for that cafeteria on the cloud database.
64
5.1.5.2 View Orders
When the admin selects the “View Orders” options, he is presented with the list of orders which
have not been completed yet with the help of the following codes.
Figure 5.9 Code for cafeteria admin - View order
Figure 5.10 Code for cafeteria admin - View Order
65
The second picture shows how the orders are retrieved from the database and pushed in an array to
be displayed. It also shows how admins can delete orders that have already been served.
5.2 Events and News

The news helps to inform users of events or any other information such as cancelation of lectures.
5.2.1 News
Figure 5.11 Code for News
The above code retrieves the news articles from Firebase, sorts them and pushes them in an array.
The users can tap on the news articles to get more information about that article.
66
Figure 5.12 Codes for News
The array is then used to display the news articles on the home page.
5.2.2 Events
The outdoor map is used to display the events ongoing in the university. The description of the
events is also displayed on the home page as a news article.
67
Figure 5.13 Codes for Events
When the user enters the outdoor map, markers are automatically placed at the location of event
taking place. This is done by the code above. First, data about all events are fetched from the cloud
database and are filtered so that only event taking place on that day is retained. The latitude and
longitude of those events are then used to add markers on the map when the map is loaded.
5.2.3 Add News Articles (Admin)

In order to add news articles, one need to be logged in as an admin. The admin can choose to view
feedback, add news or add events. If the person chooses “add news”, the code below is run.
68
Figure 5.14 Codes for Add News (Admin)
Upon tapping on the “Add” button, the details of the news article is pushed to the Firebase database
and a notification is sent to all users.
The same method is used to add news for the cafeteria.
69
5.2.4 Add Events (Admin)
If the admin chooses to add an event, he is first directed to a page where the following codes ask
him to input a title, description and author for the event. These details are stored in the database so
they can be used to display information about the event.
Figure 5.15 Codes for Add Events (Admin)
Figure 43 Codes for Event (Admin)

70
After filling in the required information, the user is directed to three other pages where he is asked
to input the date, start time and end time of the event.
Finally, after performing all these steps, the code below is used to present the admin with an
outdoor map of the university on which he has to choose the location of the event. The map already
contains the location of events that will take place on that date so that there is no clash. It also adds
a marker wherever the user taps to confirm the selection of the location.
Figure 5.16 Codes for Event (Admin)
71
Figure 5.17 Codes for Event (Admin)
After placing a marker on the wanted location, the user taps on the “Add” button to finalize the
creation of the event. The events in then stored on the database and a news article is created. Users
also receive a push notification to inform them about the new event.
72
5.3 Indoor and Outdoor Navigation/Map
In terms of navigation, the user has two options:
● Outdoor navigation which uses GPS signals.

● Indoor navigation which uses iBeacon technology.
5.3.1 Outdoor Navigation
Figure 5.18 Code for outdoor
The piece of code above consists of HTML which is used to display the outdoor map.
73
74
75
The 3 latter codes are primarily used to display the map and the location of events as mentioned
previously. It also asks the user for permission to retrieve his location. If the user agrees, the
location of the user is tracked and represented on the map with a small blue circle.
The user can interact with the map by zooming or rotating with his fingers. If the user wants to find
the path to a place, he must first drop a marker at the location by tapping and holding on the map.
He can then tap on the navigate button which will open Google Maps or Apple Maps (if Google
Maps is not installed) and show him the path to his destination.
76
5.3.2 Indoor Navigation
In order to display the indoor map and the user’s location, the HTML code in Figure 51 was used.
The user’s location was retrieved through the help of beacon. The codes in Figure 52 are used to
range for beacons and thus calculate the distance of the user from the beacon detected. This distance
is then converted into latitude and longitude, and stored in a file to be used for display.
77
Figure 5.22 Code for indoor
78
6. Integration and Testing
At this stage, the system has already been implemented. This chapter consists of the testing done on
the system. This phase helps to investigate and determine if the system is meeting all the
requirements and runs well performance wise on a mobile phone.
6.1 Methodology
This section elaborates on the various tools and approaches that can be used to test the system. It
ensures that the system meets the system requirements. It comprises of the functional testing and
system testing (Experience, n.d).
6.2 Functional Testing

In functional testing, tests are performed against the functional requirements of the system as
mentioned in Section 2.3.1.
6.2.1 Navigation on the mobile application

FR 1: The system shall allow the user to navigate freely through the system.
Table 6.1 Testing for navigation
79
6.2.2 Indoor/Outdoor Map
FR 2: The system shall provide user a fully detailed map of the whole campus
FR 3: The system shall locate the user on the campus.
FR 4: The system shall provide a guide between start and end point of user (outdoor map).
FR 5: The system shall display a floor plan for buildings, locate the user and help then to navigate
to a specific class.
Table 6.2 Testing Map
80
6.2.3 News and Events
FR 6: The system shall provide the user about any upcoming events and news about the university.
Table 6.3 Testing News and Events
81
6.2.4 Notifications
FR 7: The system shall notify the user whenever a news article (both university and cafeteria) or
event is added.
Table 6.4 Testing notification
6.2.5 Timetable
FR 8: The system shall provide the user with the appropriate timetable of classrooms.
Table 6.5 Testing Timetable
82
6.2.6 Bus schedule
FR 9: The system shall provide the users with the details of busses going through Reduit.
Table 6.6 Testing Bus schedule
83
6.2.7 Cafeteria
FR 10: The system shall allow users to make a purchase at any at the cafeteria at any time.
Table 6.7 Testing Cafeteria
84
85
6.2.8 Rules and Regulations
FR 11: The system shall present users with the rules and regulation at the university
Table 6.8 Testing Rules and Regulation
86
6.2.9 Feedback
FR 12: The system shall allow users to give feedbacks.
Table 6.9 Testing Feedback
6.2.10 Authentication
FR 13: The system shall allow users and admins to log into the system for more permission.
Table 6.10 Testing Authentication
87
88
6.2.11 Admin Panel
FR 14: The system shall allow admins to update the system.
Table 6.11 Testing for admin panel
89
90
91
6.2.12 Admin Panel (Cafeteria)
FR 15: The system shall allow admins to view orders and update news on their cafeteria.
Table 6.12 Testing Admin Cafeteria
92
93
6.3 System Testing
System testing is done to check if the mobile application meets its requirements when deployed for
use. There are many types of system testing. However, for this project we have decided to do the
user acceptance testing and performance testing.
6.3.1 Performance Testing

To check whether the mobile application is technically performing well and within the
requirements, it is important to do a performance testing.
Monkop has been the tool used to do the performance testing.
Monkop tool runs the mobile application on different versions of android and devices of different
sizes. The following sections will show the results of the performance test done and how some of
the results are satisfying the non-functional requirement in Section 2.3.2.
94
6.3.1.1 Execution on different versions of android
NFR 9: The application must run on all android smartphones with version 4.0 or higher
Figure 6.1 Performance Testing - Application running on different devices
The green circle indicates that the app execution and analysis processes were successful. This
demonstrates that the application is running on different version of android satisfying NFR 9.
6.3.1.2 Compatibility with different size screen

NFR 6: The mobile application must be scalable for any mobile devices’ size.
Figure 6.2 Performance Testing - Screen size
According to the above information, the mobile application is compatible with different screen sizes
and supports any density.
95
6.3.1.3 Performance of mobile application
In order for the application to appear fluid (60 fps), a frame must not take more than 16ms to
complete. Else, the animation of the application may be disrupted and it may even ‘freeze’.
Moreover, high CPU and GPU usage is required when detailed drawings are used which reduces
the lifetime of the battery.
Figure 6.3 Performance Testing – Maximum Lag in render frames
6.3.1.4 Resource usage

CPU usage
High CPU usage may result in rapid battery drain and lethargic response of applications on the
mobile phone. Also, using too much of the CPU may block other services from running correctly.
Figure 6.4 Performance Testing - CPU Usage
96
Power usage
NFR 8: Performance: The system must make optimal battery use.
The battery life of phones and tablets are very important for users. Thus, developers need take
battery consumption into consideration while creating their applications
Figure 6.5 Performance Testing - Power Usage
6.3.1.5 Ram Usage

NFR 3: The system must be able to run on a minimum of 1GB RAM system.
The following image shows the results for the memory load processed by the application. The
average amount of RAM used was 25MB, which is way below 1 GB as per the requirements.
Figure 6.6 Performance Testing- Average Ram usage

97
6.3.1.6 Mobile Application Size
NFR 7: The system must be less than 1 GB.
The following data was obtained from the mobile device where the application was deployed and
tested.
Figure 6.7 Performance Test – Storage
6.3.2 User Acceptance Testing

In order to check if the mobile application is really effective when a fresher actually uses it, it is
important to do an acceptance testing. For acceptance testing, year 1 students tested the mobile
application and the results were recorded.
A total of 20 year 1 students from all the faculties were involved in the exercise.
Table 6.13 Students who tested the application
98
After testing the application, they students were asked to fill a Google form where they rated the
features and overall aspects of the mobile application. The results are shown on the next page (The
result of the survey can be found in Appendix Section 3):
99
Table 6.14 Mobile Application Rating
6.3.3 Requirement Matrix

On the next page, the tests done are compared against the requirements derived in Section 2.3.
100
Table 6.15 Requirements matrix FR
Table 6.16 Requirement matrix NFR
101
7. Evaluation
After the mobile application is developed, it is important to ensure that the mobile application
serves the purpose it was made for effectively. This chapter evaluates the game in terms of its
strengths and weaknesses and the further improvements that can be made to the system in the
future.
7.1 Qualitative assessment
7.1.1 Ease of use

The mobile application has been developed in a user-friendly manner so that users of different
background can make use of it. The user can easily navigate through the different pages of the
application. Moreover, a clean user interface has been considered so as to make the information
being displayed clear and easy to read. We have also made us of simple colors and fonts.
7.1.2 Performance
To ensure that the application keeps working, a constant internet connection must be guaranteed.
This can be achieved by having a reliable Wi-Fi connection. According to the system testing, the
performance of the application meets all the NFR.
7.1.3 Availability
The mobile application has been developed in a manner so as to ensure that there is no interruption.
The Firebase database has many substitute nodes to ensure the appropriate functioning of the
system. Hence, preventing the system from crashing.
7.2 Comparison between similar systems

Comparing the application with the systems compared in chapter 2, the missing features of the
compared systems have been integrated in the application as follows:
 The navigation path in both the indoor and outdoor map to be taken have been implemented
 The application is cross platform
 The location of user is updated regularly
102
7.3 Critical assessment
The system has been developed in order to help the freshers embark in their journey at UoM. Yet
there are some limitations to the system:
 The user must have active internet connectivity for the application to function. If no Wi-Fi
connection, then the whole application goes down.
 When checking out an order in the cafeteria section, the time taken to generate QR Codes
are too large
 The accuracy of the proximity beacons are low. The waves emitted by the beacon are used
to calculate the distance between the beacon and the user. But the waves are often
obstructed by object or a person.
103
8. Conclusion
Every year, thousands of students join UoM and these are the students which will make our island a
more developed in the upcoming year. University is the bridge where students must be prepared in
order to enter the working world. To help them achieve this goal, we decided to leverage the
problems they face when they enter the university.
8.1 Problems and Proposed Solution

The main problems faced by the students according to a survey carried out are as follows:
 Bus Schedule Problem

 Rules and Regulation at the University
 Changes/Events at the University
 Problems to find classes and buildings
 Canteen menu
In order to solve the problems that the freshers faced, we decided to create a mobile application
where various features would be implemented to solve the problems.
 Map Tracking
This feature consists of both an indoor and outdoor map where the user can track his position on the
campus. The outdoor map makes uses of GPS to track the user whenever he is outside whereas the
indoor map makes use of iBeacons to locate the user inside buildings by make use of the radio wave
emitted by the beacon.
 Bus information
The bus feature will give an idea of all the routes and the approximate time for the next bus. The
user can also search for the destination of his choice.
 Events and News
Whenever there is a news or event at the university, the user is updated with the details of the news
and a notification.
104
 Cafeteria
This feature allows the user to purchase food at any of the cafeteria at UoM at any time, generating
a QR code which shall be presented to the cafeteria as evidence for the order. The user shall update
his credits at both cafeterias individually. The users are able to customize their orders.
8.2 Design
Design is one the most important phase before implementing an application. During the design
phase we had to go in depth into designing the skeleton of the mobile application. Several diagrams
were made in order to demonstrate the interaction between classes and the flow of the system.
In order to get a skeleton of the application, the use case, class diagram, database design, activity
diagram and wireframes were drawn.
8.2.1 Problem faced

There were several problems faced during implementation and changes had to be made in the
design. The problems faced are:
1. Initially the mobile application did not need authentication of any user but an admin was
needed and authentication of user was later needed for feedback and cafeteria.
2. At first we decided to use a local database, but it was later noted that the size of the mobile
application is exceeding what was expected.
3. The UI of several frames in the mobile application were changed due to the libraries offered
by NativeScript. Some UI were added but some were also removed.
8.2.2 Changes made to design

When we encountered the problems and made the necessary changes, those changes had to be
reflected in the design section. The following are the changes made:
1. UI changes
Due to the changes in UI, some of the wireframes had to be redesigned in such a way that it is
similar to what it resembles in the application.
2. Authentication
Authentication brought a massive change in the design section. Almost every diagram had to be
redesigned. The use case actors and interaction had to be added. The new activity diagram needed
to be able to reflect the flow of the mobile application when a user authenticates and the sequence
diagram was updated in such a way that it reflects what the admins can do in the system.
105
3. Database
The database design had to be changed completely. Initially a database schema was made in the
context of a SQL database. But upon shifting to cloud database, firebase, which is a NoSQL
database, the schema were represented in a completely different format.
4. New attributes and method
During the implementation, new attributes and methods were added in the different classes of the
mobile application. This brought changes to the class diagram in the design section.
8.3 Actual Application

The actual application is the reflection of the design. The implementation phase took 2 months to
complete and at the end it really reflected the skeleton made. The application contains all the
features that were required to solve the main problems that the freshers faced.
After the application was implemented, several testing was done on the application. The unit testing
helped us prove that the application is doing what it should be doing by agreeing with all the
functional testing. System testing was performed to show all the non-functional requirements. After
the user acceptance testing, we noted an overall rating of 4.2 out of 5 which is very good. The
feedback given by the students were taken into consideration for further improvements of the
mobile application.
8.4 Future Works

Given the restricted amount of time and the size of the project, only the main parts of the project
were implemented. Further enhancements can be made to the mobile application such as:
 Use of location beacon which can only be bought by enterprises but which will give a better
positioning of the user.
 Implementation of a personalized timetable which the student can use as an agenda or
reminder.
 A communication platform which will allow freshers to get in contact with their fellow
classmates or even students from other courses.
 A communication platform which will allow freshers to get in contact with lecturers,
programme coordinator or other administrative staff.
 Implementation of a system to allow freshers to enter clubs at the university.
 Implementation of the student online system on the mobile.
106
References
Azure.microsoft.com. (n.d.). SQL Database – Cloud Database as a Service | Microsoft Azure.

[online] Available at: https://azure.microsoft.com/en-us/services/sql-database [Accessed 21 Nov.
2018].
En.wikipedia.org. (n.d.). Android (operating system). [online] Available at:

https://en.wikipedia.org/wiki/Android_(operating_system) [Accessed 20 Nov. 2018].
En.wikipedia.org. (n.d.). IOS. [online] Available at: https://en.wikipedia.org/wiki/IOS.[Accessed

20 Nov. 2018]
En.wikipedia.org. (n.d.). JavaScript. [online] Available at: https://en.wikipedia.org/wiki/JavaScript

[Accessed 21 Nov. 2018].
En.wikipedia.org. (n.d.). MacOS. [online] Available at: https://en.wikipedia.org/wiki/MacOS

En.wikipedia.org. (n.d.). NativeScript. [online] Available at:

https://en.wikipedia.org/wiki/NativeScript [Accessed 21 Nov. 2018].
En.wikipedia.org. (n.d.). Symbian. [online] Available at: https://en.wikipedia.org/wiki/Symbian

En.wikipedia.org. (n.d.). Vue.js. [online] Available at: https://en.wikipedia.org/wiki/Vue.js

En.wikipedia.org. (n.d.). Windows 10. [online] Available at:

https://en.wikipedia.org/wiki/Windows_10 [Accessed 22 Nov. 2018].
En.wikipedia.org. (n.d.). Windows Phone. [online] Available at:

https://en.wikipedia.org/wiki/Windows_Phone [Accessed 20 Nov. 2018].
Experience, A. (n.d.). 4 Types of Mobile App Testing Your QA Team Needs to Be Doing. [online]
Axblog.sigos.com. Available at: http://axblog.sigos.com/four-types-of-mobile-testing [Accessed 15
Mar. 2019].
Facebook.github.io. (n.d.). React Native · A framework for building native apps using React.
[online] Available at: https://facebook.github.io/react-native/ [Accessed 21 Nov. 2018].
107
Firebase. (n.d.). Firebase. [online] Available at: https://firebase.google.com [Accessed 21 Nov.
2018].
GitHub. (2018). Ionic-team/ionic. [online] Available at: https://github.com/ionic-team/ionic

Gomez, A. (23 August 2017). 4 Location-Based Technologies For Mobile Marketing.. [online]
Curatti. Available at: https://curatti.com/location-based-tech/ [Accessed 23 Nov. 2018].
iBeacon.com Insider. (n.d.). What is iBeacon? A Guide to iBeacons. [online] Available at:
http://www.ibeacon.com/what-is-ibeacon-a-guide-to-beacons/ [Accessed 23 Nov. 2018].
Ludimar Guenda ,Luis Brás,,Marco Oliveira & Nuno Borges Carvalho (April
2011). Indoor/outdoor management system compliant with Google Maps and Android® OS.
[online] Available at:
https://www.researchgate.net/publication/221290979_Indooroutdoor_management_system_complia
nt_with_Google_Maps_and_AndroidR_OS[Accessed 10 November 2018].
Omran Al,Ahmed Al Hebsi,Jamal Zemerly & Jason W P Ng (December 2012). Indoor Localization
and Guidance Using Portable Smartphones. [online] Available at:
https://www.researchgate.net/publication/236632545_Indoor_Localization_and_Guidance_Using_P
ortable_Smartphones [Accessed 10 November 2018].
Parihar, A. (n.d.). Five of the Most Popular Databases for Mobile Apps. [online] Blog.trigent.com.
Available at: https://blog.trigent.com/five-of-the-most-popular-databases-for-mobile-apps
Robert Sheldon(26 July 2014). Eight factors when choosing mobile application development
tools.[online] Available at :https://searchmobilecomputing.techtarget.com/tip/Eight-factors-when-
choosing-mobile-application-development-tools [Accessed 21 November 2018]
Shu-Yui Bai,Ching-Chieh Chiu,Jen-Chieh Hsu & Jenq-Shiou Leu (May 2017). Campus-wide
wireless indoor positioning with hybrid iBeacon and Wi-Fi system. [online] Available at:
https://www.researchgate.net/publication/318330172_Campus-
wide_wireless_indoor_positioning_with_hybrid_iBeacon_and_Wi-Fi_system [Accessed 11
November 2018].
108
Top Mobile and Web App Development Company. (13 July 2018). Key points to consider when
building a location tracking mobile app. [online] Available at: https://hypersense-
software.com/2018/07/13/key-points-location-tracking-mobile-app/ [Accessed 23 Nov. 2018].
Typescriptlang.org. (n.d.). TypeScript – JavaScript that scales.. [online] Available at:

https://www.typescriptlang.org/index.html [Accessed 21 Nov. 2018].
Udovychenko, L. (31 March 2016). How to Choose the Right Development Platform for a Mobile
App. [online] Mlsdev.com. Available at: https://mlsdev.com/blog/56-how-to-choose-the-right-
development-platform-for-a-mobile-app [Accessed 20 Nov. 2018].
Visual Studio. (n.d.). Xamarin App Development with Visual Studio | Visual Studio. [online]
Available at: https://visualstudio.microsoft.com/xamarin/ [Accessed 21 Nov. 2018].
Weex.apache.org. (n.d.). Weex. [online] Available at: https://weex.apache.org/wiki/ [Accessed 21

Nov. 2018].
Wenzhi Liu,Zhaobin Liu & Yan Zhang (October 2011). Interactive Mobile Campus Based on
Position Perception. [online] Available at:
https://www.researchgate.net/publication/221261487_Interactive_Mobile_Campus_Based_on_Posit
ion_Perception [Accessed 11 November 2018].
Wiki.ubuntu.com. (22 November 2018). BionicBeaver/ReleaseNotes – Ubuntu Wiki. [online]

Available at: https://wiki.ubuntu.com/BionicBeaver/ReleaseNotes [Accessed 22 Nov. 2018].
Xin-Yu Lin , Te-Wei Ho, Cheng-Chung Fang, Zui-Shen Yen, Bey-Jing Yang & Feipei Lai
(August 2015). A mobile indoor positioning system based on iBeacon technology. [online]
Available at:
https://www.researchgate.net/publication/308813705_A_mobile_indoor_positioning_system_based
_on_iBeacon_technology [Accessed 10 November 2018].
109
Appendix
Section 1
1.1 Navigation
Screenshot 0.1.1.1 - Navigation Screenshot 1.1.2- Navigation Restriction
1.2 Map
Screenshot 1.2.1 - Outdoor Map Screenshot 1.2.2 – Outdoor Map Tracking
110
Screenshot 1.2.3 - Outdoor Map Navigation Screenshot 1.2.4 - Outdoor Map Error
Screenshot 1.2.5 - Indoor Map Screenshot 1.2.6 - Indoor Map Screenshot 1.2.7 - Indoor Map
positioning the user showing navigation showing path is updated
111
1.3 News and Events
Screenshot 1.3.1 - News and Events Screenshot 1.3.2 - News and Events
1.4 Notification
Screenshot 1.4 - Notifications
112
1.5 Timetable
Test case – Selecting Monday Test case – Selecting Tuesday Scroll Feature to view
different slot
Screenshot 1.5.1 - Timetable
Test Case – Searching Free Test Case – Searching Full Test Case – Searching partial
Classes named Classes named Classes
Screenshot 1.5.2 - Timetable searching
113
1.6 Bus Schedule
Screenshot 1.6.1 - Bus Schedule
Test case: Using “Port Test case: Using “port

Test case: Using “Herm
Louis” as keyword louis” as keyword
“as keyword
Test case : Using
Cross
Screenshot 1.6.2 - Screenshot 1.6.3 - Search Screenshot 1.6.4 - Screenshot 1.6.5 -

Search in Bus schedule in Bus schedule Search in Bus schedule Search in Bus
schedule
114
1.7 Cafeteria
Screenshot 1.7.1 – Cafeteria choice Screenshot 1.7.2 – Cafeteria Menu
Test case selecting Test case selecting

Test case selecting
Test case selecting “Main Cafeteria”
“Secret Cafeteria” “Secret Cafeteria
“Main Cafeteria”
Screenshot 1.7.3 – Cafeteria choice load Screenshot 1.7.4 – Cafeteria choice load
appropriate views (Menu) appropriate views (Credits)
115
Test case when user has no order pending. Test case when user has an order pending.
Screenshot 1.7.5 - Cafeteria Displays (QR Code display)
Test case – User checks no item and

Test case - arrow is down
Test case - arrow is up and adds to cart
and no item is shown
customizable item is shown
Screenshot 1.7.6 - Cafeteria Drop arrows Screenshot 1.7.7 - Cafeteria add no

items
116
Test case – User checks 1 or more items and adds to cart
Test case – Mine bouille with soy sauce

was removed
Screenshot 1.7.8 - Cafeteria add one or more customizable Screenshot 1.7.9 - Cafeteria remove
item one item
Test case – The user checks yes but do not have

enough credits
Screenshot 1.7.10 - Cafeteria Checkout message Screenshot 1.7.11 - Cafeteria not enough credits
117
Screenshot 1.7.12 - The user checks out successfully
1.8 Rules & Regulations
.
Screenshot 1.8.1 Rules Menu
118
“Selection and admission to taught programmes” “Registration and Conduct of Students”
Screenshot 1.8.2 - Rules & Regulation
1.9 Feedback
Screenshot 1.9.1 – Feedback Screenshot 1.9.2 – Screenshot 1.9.3 – Feedback

menu Feedback admin view error
119
1.10 Authentication
Screenshot 1.10.1 Login menu
Test case using “[email protected]” as username and “123456” as password
Screenshot 1.10.2 Login
120
Test case using “[email protected]” as username and “adminuom” as password
Test case using “[email protected]” as username and “123456” as password
121
Test case using “[email protected]” as
Test case using “” as username and “” as username and “12345879” as password
password
Screenshot 1.10.5 - Login Screenshot 1.10.6 - Login
Screenshot 1.10.7 – Forget Password Screenshot 1.10.8 – Forget Password
122
Screenshot 1.10.9 – Sign up Error
123
1.11 Admin Panel
Screenshot 1.11.1 – Admin Panel Menu Screenshot 1.11.2 – Admin Panel View Feedback
Screenshot 1.11.3 – Admin Screenshot 1.11.4 – Admin Screenshot 1.11.5 – Admin error in
Add news Add news add news
124
Screenshot 1.11.6 – Admin Screenshot 1.11.7 – Admin add event Screenshot 1.11.8 – Admin add
add event date event start time
Screenshot 1.11.9 – Admin Screenshot 1.11.10 – Admin add Screenshot 1.11.11 – Admin
add event end time event location location error
125
Screenshot 1.11.12 – Screenshot 1.11.13 – Admin event Screenshot 1.11.14 – Admin
Admin location error updated location error
1.12 Cafeteria Admin
Screenshot 1.12.1- Cafeteria admin menu
126
Test case – Main Cafeteria Test case- Secret Cafeteria
Screenshot 1.12.2 - Admin Cafeteria
Test case- Secret Cafeteria Updating

Test case- Main Cafeteria Updating
Screenshot 1.12.3 - Update cafeteria news
127
Screenshot 1.12.4 – Add Screenshot 1.12.5 – Add Screenshot 1.12.6 – Add
Credits credits credits error
Screenshot 1.12.7 – Add Screenshot 1.12.8 – Add Screenshot 1.12.9 – Add

credits error credits error credits updated
128
Section 2
Students that have freshly joined the University of Mauritius have been encountering several
problems during their first few weeks. A survey was carried out among the fresher’s and 119
responses were obtained:
Bus Schedule Problem
Rules and Regulation at the University
According to this survey there is a high percentage of the Students that are moderately or slightly
unaware of the rules and regulation of UoM that can cause several problem during the years they
will be studying at UoM.
129
Procedures
Lost Bus Pass and Student ID
Obtaining a testimonial
Reservation of locker
130
Problems of communication
131
Section 3
A survey was carried out to determine the rating of the mobile application. The results are as
follows:
132
133
134
135
136
137

A Mobile Application For Freshers Joining UoM

Uploaded by

Copyright:

Available Formats

A Mobile Application For Freshers Joining UoM

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

A Mobile Application For Freshers Joining UoM

Uploaded by

Copyright:

Available Formats

A MOBILE APPLICATION FOR FRESHERS

Name: Moorateeah Tashil Rye Student ID: 1611496

Name: Bhagowantin Avi Gireshan Student ID: 1612225

Supervisor: MR Selvanaden Sathan

A thesis submitted in partial fulfillment of the requirements for the award of

BSc (Hons) in Computer Science

Department of Information and Communication Technologies

Submitted on: 2nd April 2019

Figure 1.1 Schedule Plan ................................................................................................................ 5

Table 1.1 Task Distribution ........................................................................................................... 5

API Application Program Interface

BLE Bluetooth Low Energy

CILL Center for Innovative and Lifelong Learning

CPA Cumulative Point Average

CPU Control Processing Unit

CSS Cascading Style Sheets

FLM Faculty of Law and Management

FOA Faculty of Agriculture

FOE Faculty of Engineering

FOICDT Faculty of Information, Communication and Digital Technologies

FOS Faculty of Science

FSSH Faculty of Social Sciences and Humanities

GPS Global Positioning System

GPU Graphics Processing Unit

GUI Graphical User Interface

HTML Hypertext Markup Language

JSON JavaScript Object Notation

LPA Level Point Average

NFC Near Field Communication

NFR Non Functional Requirements

PDF Portable Document Format

RAM Random Access Memory

SQL Structured Query Language

UoM University of Mauritius

Wi-Fi Wireless Fidelity

1.1 Problem Statement

 Bus Schedule Problem

Rules and Regulation

1.2 Aims and Objectives

 Location of the classes around the campus

1. To help freshers to get acquainted to UoM as soon as possible.

Figure 1.1 Schedule Plan

1.6 Distribution of task

2.1 Related Work: Literature Review

2.1.1 Indoor/Outdoor Management System

1. Low energy consumption characteristics

Low energy consumption characteristics

Automatic regular update of location

Gives path to reach destination

Table 2.1 Similar Systems Comparison

Menu and easy navigation

 All the events and news will be displayed on the homepage.

 Any updates about the cafeteria will be given to the user

Users will be able to change their personal details.

2.2 Proposed Solution

2.3 Requirement Specification

2.3.1 Functional Requirements FR

2.3.2 Non Functional Requirement

2.4 Chapter Summary