attendane monitoring using ibeaconjoshmustafa.com/assets/uploads/images/projects/ibeacon.pdf ·...

of 73

Attendance monitoring using iBeacon

BSc Hons Computer Science

Abstract

This dissertation researches the limitations of traditional attendance monitors. At the moment of this

project, iBeacon is not used to monitor attendance. Hence why the main scope of the dissertation is

to walk through the planning, designing and execution to implement new technology to track

attendance. The final result will be a physical product that gives location aware services to the

university in order to accurately monitor student’s attendance through iBeacon technologies.

Author:

University: Faculty:

Supervisor: Project Type:

Word Count:

Due Date:

Joshan Hasan Mustafa

University of Greenwich

Faculty of Architecture, Computing & Humanities Dr Ralph Barthel Final Year Project

11486

24/4/2018

of 73

Acknowledgments

I would like to acknowledge and thank the following important people who have supported me, not

only during the project, but throughout my degree.

Firstly, I would like to express my gratitude and thank my advisor Dr Ralph Barthel, for his

guidance, support and insight throughout this project.

And finally, I would like to thank all my close friends and family for all the support and

encouragement which helped me focus on what has been a hugely demanding and daunting process.

of 73

Table of Contents

1 Introduction ................................................................................................................................ 5 1.1 Background ..................................................................................................................................... 5 1.2 Aims and objectives ........................................................................................................................ 6 1.3 Approach ......................................................................................................................................... 7

1.3.1 Waterfall Model............................................................................................................................ 7 1.3.2 Spiral Model ................................................................................................................................. 7 1.3.3 RAD Model .................................................................................................................................. 7

2 Literature Review ...................................................................................................................... 9 2.1 Identifying the problem .................................................................................................................. 9 2.2 What is RFID? ................................................................................................................................ 9 2.3 Can smart phones solve the problem? ........................................................................................ 10 2.4 What are BLE (Bluetooth Low Energy) Beacons? .................................................................... 11 2.5 Location assisted emergency evacuation .................................................................................... 13

3 Product Research ..................................................................................................................... 14 3.1 Attendance monitors..................................................................................................................... 14

3.1.1 Safescan Clocking in system ...................................................................................................... 14 3.1.2 Replicon Time & Attendance ..................................................................................................... 15 3.1.3 Conclusion .................................................................................................................................. 15

4 Legal, Social, Ethical and Professional Issues and Considerations ..................................... 16

5 Requirements ............................................................................................................................ 18 5.1 Analysis of requirements .............................................................................................................. 18 5.2 Functional requirements .............................................................................................................. 18 5.3 Non-functional requirements ....................................................................................................... 19

6 Design/Development................................................................................................................. 20 6.1 Introduction ................................................................................................................................... 20 6.2 User Interface Design ................................................................................................................... 20

6.2.1 Design Guidelines ...................................................................................................................... 20 6.2.2 Colour Palette ............................................................................................................................. 21 6.2.3 Typography/Font ........................................................................................................................ 22 6.2.4 Responsive and Adaptive Design ............................................................................................... 23 6.2.5 High Fidelity Prototype – Web Application ............................................................................... 24 6.2.6 High Fidelity Prototype – iOS Application ................................................................................ 28

6.3 User Interface Development ........................................................................................................ 31 6.3.1 Developed Web Application ...................................................................................................... 31 6.3.2 Developed iOS Application ........................................................................................................ 37

6.4 System Usability Scale - Evaluation ............................................................................................ 39

7 Tools Used ................................................................................................................................. 40 7.1 Hardware ....................................................................................................................................... 40

7.1.1 MacBook Pro .............................................................................................................................. 40 7.1.2 iPhone ......................................................................................................................................... 40 7.1.3 Estimote Beacons ....................................................................................................................... 40

7.2 Programming/Mark-up languages and Frameworks ................................................................ 42 7.2.1 HTML ......................................................................................................................................... 42 7.2.2 CSS ............................................................................................................................................. 42 7.2.3 Bootstrap 4.................................................................................................................................. 42 7.2.4 JavaScript ................................................................................................................................... 42 7.2.5 PHP ............................................................................................................................................. 42 7.2.6 SQL............................................................................................................................................. 42 7.2.7 Swift 4 ........................................................................................................................................ 42

7.3 Software/Services .......................................................................................................................... 43 7.3.1 Atom IDE ................................................................................................................................... 43 7.3.2 Xcode .......................................................................................................................................... 43

of 73

7.3.3 Postman ...................................................................................................................................... 43 7.3.4 1&1 Web and Database Hosting ................................................................................................ 43 7.3.5 phpMyAdmin ............................................................................................................................. 43 7.3.6 Apple Developer Program .......................................................................................................... 43 7.3.7 REST API web service ............................................................................................................... 43

8 Back-End Implementation/Prototyping ................................................................................. 44 8.1 MySQL database........................................................................................................................... 44 8.2 UML Diagrams ............................................................................................................................. 45

8.2.1 UML Use Case Diagram ............................................................................................................ 45 8.2.2 UML Sequence Diagram [Login] ............................................................................................... 46 8.2.3 UML Sequence Diagram [Mark attendance] ............................................................................. 47

8.3 Web Application Development .................................................................................................... 48 8.4 iOS Application Development...................................................................................................... 49 8.5 Attendance log [Excel] .................................................................................................................. 49 8.6 REST API/Web-Service ............................................................................................................... 50

9 Testing ....................................................................................................................................... 51 9.1 White Box ...................................................................................................................................... 51

10 Critical Evaluation ............................................................................................................... 55 10.1 Future Implementation ................................................................................................................ 55 10.2 Reflection ....................................................................................................................................... 56

11 Appendices ............................................................................................................................ 57 11.1 Appendix A - Gantt Chart ........................................................................................................... 57 11.2 Appendix B - System Usability Scale Research.......................................................................... 57

11.2.1 SUS - iOS Application [1] ..................................................................................................... 58 11.2.2 SUS - iOS Application [2] ..................................................................................................... 59 11.2.3 SUS – iOS Application [3] ..................................................................................................... 60 11.2.4 SUS – iOS Application [4] ..................................................................................................... 61 11.2.5 SUS - iOS Application [5] ..................................................................................................... 62 11.2.6 SUS – Web Application [1] ................................................................................................... 63 11.2.7 SUS – Web Application [2] ................................................................................................... 64 11.2.8 SUS – Web Application [3] ................................................................................................... 65 11.2.9 SUS – Web Application [4] ................................................................................................... 66 11.2.10 SUS – Web Application [5] ................................................................................................... 67

11.3 Appendix C - Diagrams ................................................................................................................ 68 11.3.1 Rich picture ............................................................................................................................ 68 11.3.2 Flow diagram ......................................................................................................................... 68

11.4 Appendix D - File List .................................................................................................................. 69

12 References ............................................................................................................................. 71

13 Bibliography ......................................................................................................................... 73

of 73

1 Introduction

1.1 Background

Today it is more common to monitor attendance using RFID technology, The University of

Greenwich uses this type of system at the time of this project and will probably do so for years to

come unless, there is a more viable solution. This system is designed so students tap their RFID cards

on the scanner which will clock in their attendance. This will then be stored in the universities

database. The system is usually set up at the beginning of lectures and classes, students will then get

up and queue to clock in.

The project will be based on developing a system using iBeacon which can work alongside the

traditional RFID method to make it more accurate. The iOS application will integrate Bluetooth Low

Energy wireless technology that was developed by the Bluetooth Special Interest Group (SIG). BLE

will be used with Apple’s iBeacon capabilities to be able to automatically track student’s attendance

simply by checking if they are in within the proximity of a given location at a given time.

Lecturers will have access to a web application which will enable them to view data that has been

collected by the iOS application and stored in the MySQL database. “Smart Workplace” which was

researched by Menon et al, 2017 have already started to adopt this method in workplaces in order to

make the tracking of staff more efficient.

Under the assumption that the student is already registered on a particular course, for their attendance

to be registered, they will have to present at the given location of their class. Using location based

services like iBeacon, gives the potential to be used accurately to log a student’s attendance. An

application can be designed in order to communicate with these proximity beacons, which could

respond to the database along with the student’s location.

Such project can be further developed in order to create a Location Aware Emergency Evacuation

system which will be able to help track and assist users to evacuate a building using BLE technology.

Eksen et al, 2017 used this method in order to aid elderly people during evacuation circumstances.

Therefore, if the attendance monitor system has tracked who is in the building it can be further

developed in order to help aid evacuating students in the event of an emergency.

This project will show the research and development of how BLE beacons can make an attendance

system for schools, colleges, companies more efficient and accurate.

Keywords: [Bluetooth Low Energy, RFID, iBeacon, attendance, Attendimote, Estimote, Location]

of 73

1.2 Aims and objectives

The aim of this project is to develop software which will enable the use of Bluetooth Low Energy

beacons to monitor student’s attendance in real time. The project aims to:

1. Researching how the use of Bluetooth Low Energy beacons can be used to provide real time

location based services for students.

2. Research how the current attendance system can be improved with the use of Bluetooth Low

Energy beacons.

3. Investigate how this system can be further developed to maximise student’s safety during

evacuation scenarios.

4. Investigate what the limitations are when using Bluetooth low energy beacon services to

track student attendance.

of 73

1.3 Approach

A number of methodologies were taken into consideration for the planning, designing and

development of this project;

1.3.1 Waterfall Model

The waterfall model (Royce, 1970) was the first methodology taken into consideration during the

development life cycle of the system. This particular model has distinct goals set out in a linear and

sequential flow (hence being called Waterfall model). This method would be beneficial in the sense

of setting deadlines for each goal to then move onto the next phase of development.

This methodology was dropped early during design stages as traditionally the waterfall methodology

doesn’t allow for the development to revise a phase which is a huge disadvantage. Requirements are

most likely going to developed throughout the design stages of the system due to the feedback that

will be gained in order to make the system more robust.

1.3.2 Spiral Model

However, since the waterfall wouldn’t work due to not being flexible enough, the second option was

the spiral model. The spiral model (Boehm, 1986, p.7) is a system development lifecycle that

combines the prototyping model and the waterfall model. The spiral model allowed for feedback to

take place so it can be applied to the system throughout development stages.

This model was also dropped for a number of reasons, the main reason is that it’s not very time

efficient to the constant feedback needed. This methodology is also widely used in a large system

which this system isn’t.

1.3.3 RAD Model

Rapid Application Development (Martin, 1992) is software development methodology which uses

minimal planning through prototyping. This means that a prototype is developed in incremental steps

for each requirement. This enables the ability to get feedback on a particular requirement during early

stages in order to notice any problems during early stages. Therefore, a huge benefit is the model

enables the development of the system to be broken up into smaller sections which makes it easier to

develop.

of 73

2.4 Justification of the suitability of a Methodology or a Framework followed.

Due to the implications that arose from the other methodologies, RAD is the option that is going to

be used throughout the development of the system. There are a number of beneficial reasons behind

using this method;

RAD is known for reducing the development time of the system. This will be beneficial as the less

time used during development stages allows more time for testing in order to make the system more

robust. Feedback is also encouraged which will also be beneficial in order to make sure specific

requirements are met.

Figure 1 - RAD Model

of 73

2 Literature Review The aim of this literature review is to critically analyse and research into academic journals, books

and other research based media. This will allow for an in depth understanding of the problems and

limitation of current or previous technologies.

In order to find the correct literature, the initial step was to identify the problem with traditional

attendance monitors. Further research will then take place by branching of the initial problem, in

order to find how these problems can be solved.

2.1 Identifying the problem

Being present in a classroom has a huge impact on the knowledge that the students will gain

throughout their degree. This is why the students should be provided with the correct engagement

and guidance from their teachers/lecturers. According to Stanca (2004, p. 2-6) research shows that

there is a direct correlation between attendance and the academic performance of a student. For an

educational institute to track the academic performance of a student they need an effective way to

track the attendance of the student. Which is why most of, if not every educational institution, has

some sort of attendance monitoring system.

Traditionally, a paper based system was used where the student would be required to manually tick

their name to mark that they are in on an attendance sheet, which would be passed around during the

class/lecture. There’s a number of problems with this paper system; is that a student could easily mark

in other students that are not attending which would make the attendance monitoring paper based

system inconsistent, therefore it makes it difficult for the institution to track the academic

performance of a student (Gatsheni et al, 2007).

Systems have recently been developed to automate the process in which attendance is taken. These

automated systems have allowed the reliability and accuracy of attendance monitoring. Radio

Frequency Identification (RFID) has become a popular method of doing so.

2.2 What is RFID?

RFID technology emerged in the 1940s as a way of remotely identifying aircraft for the military,

since then it was used in civil aviation. The Parliamentary Office of Science and Technology (2004,

p. 1) stated how, due to technology advances over the years, production costs of RFID have been

reduced dramatically which has opened up a wider range of uses commercially.

However, having mentioning the limitations of paper based systems, the proposed system that is used

today is an RFID attendance tracking system. The idea behind this system is for the student to tap

their student card on the RFID reader on entering the lecture hall or classroom, which would then

directly capture the student ID to then be sent to an online database (Tokiwa et al, 2009). As a result

of this method, data is instantly uploaded to the server which prevents data-loss and accessible to

view whenever the lecturer needs. A huge benefit is taken from this, which is to turn this data into

useful information, which would be to visually display the percentage of the student’s attendance.

Therefore, tracking a student academic performance can easily be related back to their attendance.

There’s still one major drawback to this system, only one student can provide their attendance at a

given time, this makes the system a time-consuming process. This could lead to students not marking

themselves in when they are in fact attending their lecture/class; which could result in their attendance

information being incontinent.

of 73

2.3 Can smart phones solve the problem?

The paper “A Smart Phone Integrated Smart Classroom” (Mahesh, Jayahari and Bijlani, 2016) have

researched interesting topics on smartphone usages in lectures. A particular section states how the

implementation of smartphones can be used on increasing the total engagement time lectures have,

by using smartphones to track attendance.

Figure 2 shows collected data on how long it takes to collect the attendance for 60 students; which is

around 5 minutes. Overall, throughout the year, this could waste hundreds of hours in lectures. The

figure above also displays that on average there’s 1-5 proxy attendance marks, as a result affecting

the consistency of the students.

Consequently, this is taking into consideration that the lectures are for 60 students. In other lectures

this can easily double or even triple taking the attendance process even longer.

Some workplaces have started to adopt the use of smartphones in a workplace for the intention to

make the workplace automated and smart, therefore enhancing the efficiency of the employees work

flow (Menon et al 2017, p. 396). In order to make workplace “smart” the method of implementing

BLE (Bluetooth Low Energy) devices along with an iOS iBeacon application. For the intention of

capturing employee clock in/out times, when the user reaches proximity of the iBeacon the app makes

a log of entry and exit times.

Existing applications for iBeacon are mostly used for the retail world, according to Aishwarya &

Kavya (2015, p. 74) this method has made a big impact with sales. In the retail industry, iBeacon

gives the opportunity to attract the attention of consumers at the moment of a customer being present

in or near a store. iBeacon is able to send direct marketing notifications to a customer’s Bluetooth

enabled device. Therefore, promoting products and offers when a consumer is in proximity to the

store.

Figure 2 - A Smart Phone Integrated Smart Classroom (Mahesh, Jayahari & Bijlani,

2016, p. 91)

of 73

2.4 What are BLE (Bluetooth Low Energy) Beacons?

Bluetooth Low Energy (BLE) is an emerging wireless technology that is being developed by the

Bluetooth Special Interest Group (SIG) in order to make short-range communication more efficient

for everyday devices. BLE has become a popular feature since Bluetooth 4.0 which first appeared on

smartphones in 2011. According to the Bluetooth Special Interest Group, 2017 Bluetooth 5 will

commercially be available on popular devices this year like the Samsung Galaxy S8 and Apple iPhone

8 onwards. This means that consumer technology is now accessible to most of the market.

Apple was the first technology company to support BLE on their devices operating system which was

announced back in 2011; this acted as a foundation for the future development of iBeacon to later be

announced on iOS 7 devices and later. iBeacon is a technology that enables new location awareness

opportunities for applications by leveraging the current BLE technology.

BLE emitters operate in short range distances that allow sensors to be able to communicate to each

other on a single coin cell battery, that can power the sensor for an average of 2 years. BLE is an

important factor to consider in this project as users would be able to preserve battery life on their

devices.

Due to the development of technology becoming cheaper, a range of BLE beacons have now been

produced commercially which is having a huge impact on the development of the Internet of Things.

In order for beacons to save energy, they are in sleep mode by default and wake up periodically in

order to listen out for packets from any incoming transmissions. Bluetooth emitters provide the

following information via Bluetooth Low Energy:

Field Size Data Structures Description

UUID 16 bytes 128-bit string Application developers

should define a UUID

specific to their app and

deployment use case.

Major 2 bytes Unsigned 16-bit

integer, ranging from 0

to 65536

Further specifies a

specific iBeacon and

use case.

Minor 2 bytes Unsigned 16-bit

integer, ranging from 0

to 65536

Allows further

subdivision of region or

use case, specified by

the application

developer

Table 1 - iBeacon address structure

of 73

As a result, to iBeacon’s API that Apple developed, the developer is given two important factors

about the signal of the beacons. Which are:

• RSSI: This is the Received Signal Strength Indicator of the BLE emitter.

• Proximity: This indicates the proximity of the beacons distance from the devices that is

being transmitted to, the proximity of the beacon is indicated using four different

representations; Immediate, Near, Far and Unknown.

As a result of this API, Indoor Positioning Systems can then be developed in order for developers to

build their own systems. In order for developers to build an IPS, the location needs to have iBeacon

emitters placed at the specific location. An iOS application also needs to be created to read the

emitters.

On the contrary, to ensure that the effectiveness of the IPS is at its best, it’s important to consider any

physical objects that may obstruct the signal that is being broadcasted by the emitter. As signals are

being received by the student’s device, signal strength will generally be a direct correlation of how

far the device is from the emitter. Therefore, it is important to ensure there are no obstructions within

the broadcasting range of the emitters, or if so, how it may affect the user experience. Physical objects

can range from anything, such as the walls of a building where the emitter is placed causing the loss

of intensity of the signal. Which can cause the emitter to seem further away from the device than it

actually is. In fact, the human body itself can attenuate the Bluetooth signals, just a student having

their back turned to the beacon while holding their device will affect signal strength, therefore

effecting the accuracy too.

Figure 3 - Physical object reducing

signal strength

Figure 4 - Human body reducing

signal strength

of 73

2.5 Location assisted emergency evacuation

Indoor positioning systems as previously mentioned in section 3.5, have been further developed to

act as an emergency evacuation assistant. The article “inLoc: Location-aware Emergency Evacuation

Assistant” (Eksen et al. 2017) refers to a system that was developed to aid elderly people to exit their

homes in a timely and effective manner.

In order to detect an emergency, the system takes advantage of the sensors that are embedded into the

BLE beacons. Firstly, the accelerometer/motion sensor is used to detect earthquakes, then the

temperature sensors are used to detect the ambient temperature of the room. The temperature data can

then be evaluated if abnormal temperatures are detected, which could have been caused by a fire.

An emergency interface is activated when a sensor is triggered, known as the “emergency phase”.

After an emergency is detected the first step of the system is to identify the nearest beacon to the user,

this way the exact location of the user is pinpointed. At which point the shortest path can then be

calculated for the user to take in order to evacuate the premises in a timely manner. In order to

calculate the shortest path, Eksen et al opted to use Dijkstra’s algorithm. The reason Dijkstra’s

algorithm was used is because the shortest path can change depending on where unsafe areas are.

This way, the algorithm is able to dynamically adapt a safe way through the premises guiding the user

around any unsafe areas that were detected by the beacons sensors.

of 73

3 Product Research Gathering and comparing similar products will be difficult due to the products being closed systems.

As a result, to the systems being closed, a physical examination of the product will be not be possible.

This section will be researching attendance monitors as a whole; not particularly location enabled

attendance systems. This will allow for the pros and cons of other attendance systems to be

investigated, allowing other methods to be explored.

3.1 Attendance monitors

3.1.1 Safescan Clocking in system

Figure 5 – Safescan products

This system uses RFID technology to record the in and out times of employees. The RFID scanner

reads the card which the employee's data will then be directly uploaded to the cloud service for

storage. This is very similar to the system being used in The University of Greenwich at this current

time. Unfortunately, this can be very time-consuming in a lecture/class. For example, if over 50

students were to present, they would each have to be tapping their cards one after another. As a result,

adding unnecessary time to the process.

of 73

3.1.2 Replicon Time & Attendance

Figure 6 – Replicon Time and Attendance product

Replicon’s Time & Attendance software is a cloud-based approach to how attendance is taken. Their

system allows employees to clock themselves in. Employees are able to interact with the system via

an application, which is installed on the employee’s smartphone or to log in to a company machine

to access the system.

The benefit of this system that employees are able to use their smartphones to clock in and out, this

method will save time during peak hours of clocking in or out as attendance wouldn’t have to be taken

at a single instance, allowing multiple employees to clock in or out instantaneously.

On the other hand, there is a downside to this method, in an educational institution, there would

nothing stopping students from marking their attendance at home when they are in fact not attending

a lecture. Which increase the chances of proxy attendance marks taking place.

3.1.3 Conclusion

After conducting research on similar systems, it was clear that there is huge gap in the market.

Currently there are no iBeacon integrated attendance monitors used in the real world. Unfortunately,

this made the product research very limited to what could be explored. On the other hand, this good

opportunity to develop something new using an attendance tracking technique that has never been

done before.

Relating to the Safescan clocking system a major drawback in the system is that only 3000 users are

only able to be stored. Which wouldn’t be practical for an educational institution like the University

of Greenwich with over 22000 students. Using iBeacon and a database developed for the project will

give an accurate reading of the student’s attendance log.

of 73

4 Legal, Social, Ethical and Professional Issues and

Considerations Privacy and security will be an important factor to consider in the development of this project as

sensitive information will constantly be sent from client to server. A number of legal guidelines will

need to be implemented in order to keep this information secure. Due to the database storing user’s

information it's important that this data is encrypted in order to comply with The Data Protection Act,

1998. During the development of the project, security will be taken into consideration in order to keep

the user’s data safe. The Data Protection Act 1998 has a number of areas that cover the storage of

sensitive information and how the information collected will be used. In order to follow this

legislation, passwords will be encrypted on the client’s application, which means the database

wouldn’t have any links back to the original password of the client.

Other methods like Hyper Text Transfer Secure (HTTPS) for the web application will be

implemented. Users will be required to log in to the system which means they will have to input their

password to access the service. Therefore, if the Web Page is secured using the HTTPS protocol,

passwords can’t be hacked using packet intercepting software.

Students may not like the fact this system will be using their phone to track their attendance. This

will need to addressed to show students location tracking is secured and not shared. This project will

be to monitor attendance which means it will involve location tracking of the user. Ethical limits will

be set on how far the tracking can go. Tracking will only be on campus, where the BLE beacons are

located. Otherwise, the users will not be tracked outside of campus. For example, if a student didn’t

turn up to a lecture the system will not have permission to check where they actually are located, they

will just be aware that they not on campus.

Since the Estimote API was built on top of Apples Core Location, user authorisation is required for

the application to be used. The users will be most likely be familiar with the location authorisation

alert that will be prompted to use the iBeacon API. Students will then be able to decide for themselves

whether to only make the app functional while it is open or allow location services to be running in

the background which makes the app functional even when it's closed.

Figure 7 – Attendimote location service notification

of 73

However, if the user decides to make any changes to the applications authorisation, they can do so in

the Settings app under Privacy > Location Services, where they can allow or deny the applications

access to iBeacon/location functionalities.

First of all, it will be important to meet set deadlines when developing the project. A low budget is

also needed for this project as the tools needed are cheap are already accessible. The research will

also apply when looking into specific BLE beacons in order to get the best suited for the situation it

is being used for in the project.

of 73

5 Requirements

5.1 Analysis of requirements

In this project, there will be a number of requirements that will need to be achieved to make the

system relatable for real-world use. As this project uses a number of different technologies along with

important ethical issues, the non-functional and functional requirements will vary depending what

the system is being operated on. In order for the development of the system to be efficient, the

MoSCoW requirements method is used. As a result of the MoSCoW method used, prioritization of

the requirements are easily visualised for the developers, which allows them to focus on what aspects

of the system should be focused on, in order to meet goals based on the importance of the requirement.

5.2 Functional requirements

Web Application Requirements MoSCoW Category

The web application allows different lecturers to log in to the

system.

Must Have

The web application a lecturer to select what room and course

attendance to view.

Must Have

The web application should display the attendance monitor in real

time in order to view students walking into the location in real time.

Must Have

The system is only useable after the user has logged in order to

protect student information.

Must Have

The web application logs the attendance data therefore allowing

staff to view the attendance on a given day and time.

Should Have

The system allows lecturers to make changes to the attendance log

(E.g. Remove student from attendance).

Could Have

Cookies to be used to allow faster login. Could Have

iBeacon iOS Application Requirements MoSCoW Category

The application must allow students to login. Must Have

The system must mark in student’s attendance in real time. Must Have

The application marks the time a student leaves their class. Could Have

The application has a student dashboard. Should Have

The application works in the background of their device. Could Have

The application works on android devices. Won’t Have

Table 2 – Web Application Requirement

Table 3 – iBeacon iOS Application Requirement

of 73

5.3 Non-functional requirements

Non-Functional Requirements MoSCoW Category

The systems must be scalable due to an ever-growing number of

students without affecting performance.

Must Have

Information is stored in a secure database. Must Have

The systems must take privacy into consideration, like mentioned in

ethical issues. (Asking the student for consent to access location

services)

Must Have

Communication to the database through a secure REST API. Should Have

Passwords to be stored using a hashing method (SHA1). Should Have

Responsive and Adaptive design allowing the applications to be used

on different screen sizes.

Could Have

Any communication over the web will be done secure using HTTPS

along with a valid certificate.

Could Have

Table 4 – Non-functional Requirement

of 73

6 Design/Development

6.1 Introduction

Overall, in order to create an effective system, the interface design must be simple and easy to use

for all users, irregardless of their computer literacy. In order to make the system usable for all these

users, design techniques have been researched and taken into consideration. This section will discuss

and walk through why certain design techniques were used during the development of the system.

Here is a video walkthrough of the system: https://youtu.be/WzXslPcf_vM

6.2 User Interface Design

6.2.1 Design Guidelines

The paper “HEURISTIC EVALUATION OF USER INTERFACES” (Molich and Nielsen, 1990,

p.249) mention nine basic usability principles which are used to minimise the complexity of a user

interface. These heuristics were developed further, as a result, the final set of guidelines were released

in 1994. Following a number of the guidelines, systems should have an outcome of being easily

navigated and usable without the user having to be taught how to use the system.

The 10 guidelines are;

1. Visibility of system status.

2. Match between system and the real world.

3. User control and freedom.

4. Consistency and standards.

5. Error prevention.

6. Recognition rather than recall.

7. Flexibility and efficiency of use.

8. Aesthetic and minimalist design.

9. Help users recognise, diagnose, and recover from errors.

10. Help and Documentation.

https://youtu.be/WzXslPcf_vM

of 73

6.2.2 Colour Palette

Above shows the colour palette that is used throughout the user interface of the system. These colours

were chosen in order to comply with one of the ten heuristics mentioned in section 6.2.1. The primary

and secondary colours create consistency for the students and lecturers at The University of

Greenwich, as these are a set of the main colours found on the universities login page in order to enter

the portal. Therefore, the users of the system will most likely be familiar with the colours used which

will result in the users being more willing to accept the system.

White was used for the background colour for the user interface in order to make text stand out. This

makes the user interface user-friendly as it makes any content on the application easier to read which

aids users with visual impairments.

Primary

Navy Blue

#070A5C

Secondary

Gold

#E5B229

Background

White

#FFFFFF

Figure 8 – Colour Palette

of 73

6.2.3 Typography/Font

Throughout the development of the system, consistency is an important factor which aims to improve

the usability experience. Hence the font family that is being used should be consistent throughout all

operating systems and devices. Taking into consideration that the application will be operating on

Apple's operating system, it would certainly make sense to use Apple's default font which is used

throughout most of the iOS-based applications.

As a result, the chosen font to be used on the iOS application is “San Francisco”. Apple has put a lot

of thought and development into San Francisco regarding that the font will be primarily used on

electronic devices with a screen. The devices screens are made up of thousands of pixels,

unfortunately, pixels can affect the way certain fonts look, which can make them harder to view for

users. San Francisco has been designed in a way to make letters easier to read on screens which will

help the overall user experience visually efficient to use.

Unfortunately, this font is only exclusively supported within Apples operating system which causes

an issue for the font used on the web application. In which case, a different font needs to be used

since the main operating system that will be used to access the system will likely be Windows. As a

result, this could affect the consistency of the interface depending on what operating system is being

used. Luckily San Francisco was heavily inspired by a font called “Helvetica Neue” (A comparison

is shown in figure 9).

Using Helvetica Neue for the main font of the Web application allows consistency to be carried out

through the system due to how similar the font types are.

Figure 9 – Helvetica Neue Thin vs San Francisco Display Thin

of 73

6.2.4 Responsive and Adaptive Design

In spite of there being a wide range of platforms that a web application can be viewed on, it’s

important to consider all the platforms that the web application will be accessed on. Hence why it is

vital to incorporate responsive and adaptive layouts of the user interface design. This will allow the

web application to be accessible on most if not all types of platforms; Screen sizes, operating systems

nor devices shouldn’t affect the functionality of the web application.

As the web application will mostly be accessed on a computer by a lecturer, a responsive design will

be the main focus out of the two. A responsive design will be affected by the available space that is

on a web browser. Hence why a single responsive design of the web application will be used in order

to flow across different displays. This a huge advantage as it allows the web application to be future

proof for any future platforms that will be released due to the responsiveness adaptive to the web

browser, not screen sizes.

Although both types of designs will be beneficial, an adaptive design is time-consuming to implement

due to the complexity. Which is due to the separate designs that will need to be created in order to

adapt to each device.

Figure 10 – Responsive and Adaptive design

of 73

6.2.5 High Fidelity Prototype – Web Application

In order to create the prototypes, a design toolkit called “Sketch” was used. This allows rapid

interactive prototyping which can be created in short amount of time.

Figure 11 shows the home page prototype for the web application. Due to the system only being

available to staff the navigation bar will be kept to a minimum in order to help guide the user through

the system. The home page practically gives one path for the user to take; which is to log in.

An advertisement of the application that supports the system will also be displayed on the home page

in order to show what the application supports, which is iOS.

Log In

APPLICATION NAME.

Home

Figure 11 – Web application home page prototype

of 73

In the case of the user clicking the “Log In” link on the navigation bar, they will be redirected to the

login page. The login will only consist of three objects; Username textbox, Password textbox, and a

Login button.

Object Description

Username Textbox The username textbox will be where the user inputs their

username. A placeholder will be used in order to show where the

user inserts their username.

Password Textbox The password textbox will be where the user inputs their

password. A placeholder will be used in order to show where the

user inserts their password.

Login Button The login button will execute the login action, as a result if

successful will redirect them back to the home page.

Username Textbox

Password Textbox

Login Button

Figure 12 – Web application login page prototype

Table 5 – Login page input breakdown

of 73

At the point of the user successfully logging into the web application they will be redirected to the

home page. This is where they will be presented with a new link in the navigation bar which gives

them access to the dashboard. Following clicking the “Dashboard” link they will be presented with

the page shown in Figure 13, which requires the user to select which location they would like to view.

In order to select the location, the user is required to select which campus, building, and the room.

Dropdown boxes were used in order to reduce any human error. Dropdown boxes give the user a set

of choices to select, guiding them through which options they are required to choose.

Object Description

Select campus dropdown

box

The select campus dropdown box gives the user a number of

campuses to choose from.

Select building dropdown

box

The select building dropdown box gives the user a number of

buildings to choose from which are located within the campus

they selected.

Select room dropdown box The select room dropdown box gives the user a number of rooms

to choose from which are located within the campus and building

they selected.

Go Button The Go button will redirect the user to the location they have

selected, following what campus, building and room they have

selected.

Select Campus dropdown box

Select Building dropdown box

Select Room dropdown box

Go Button

Figure 13 – Web application select room page prototype

Table 6 – Select room page input breakdown

of 73

Figure 14 shows the dashboard which is one of the most important sections of the project. This is

where the lecturer is able to view which students are in the class.

Object Description

Student Table The student table is a section that will display what students have

walked in and out the class/lecture. This section will be

automatically updated every second which allows the lecturer to

view which students have entered/exited in real time.

Each row of the table will contain student information. Which

consists of their name and student ID. As a result, giving the

lecturer valuable student information.

First name Textbox This will display the students first name.

Second name Textbox This will display the students second name.

Student email Textbox This will display the students email

Student ID Textbox This will display the students ID.

Export Button The export button allows the lecturer to log the who attended

their class/lecture. At the moment of the export being clicked an

excel file will be saved with the student’s information being

saved.

Student Table First name Textbox

Second name Textbox

Student email Textbox Student ID Textbox

Export Button

Figure 14 – Web application dashboard page prototype

Table 7 – Dashboard page input breakdown

of 73

6.2.6 High Fidelity Prototype – iOS Application

The iOS applications main functionality will be to give iBeacon based location services to students.

Hence why there will not be much visual content for the application.

Firstly, the student will be required to log in, in order to access the system. The login will only consist

of three objects that the student interacts with; Username textbox, Password textbox, and a Login

button.

Object Description

Username Textbox The username textbox will be where the student inputs their

username. A placeholder will be used in order to show where the

student inserts their username.

Password Textbox The password textbox will be where the student inputs their

password. A placeholder will be used in order to show where the

student inserts their password.

Login Button The login button will execute the login action. As a result, if

successful will redirect them to the attendance interface.

Username Textbox

Password Textbox

Login Button

Figure 15 – iOS application login prototype

Table 8 – iOS login input breakdown

of 73

Figure 16 shows the attendance interface. Since the application is used to interact with Bluetooth

emitters automatically the student will not have much interaction with the application. The application

shows what the class/lecture the student is attending.

In order to comply with the usability guidelines mentions in section 6.2., standard Navbar and toolbars

were used.

Object Description

Log Out Button The Logout button will log out the student and destroy any

sessions created.

Location Label The location label will automatically update depending on where

the student. This will display to the student which class/lecture

they are attending.

Account button The account button will redirect the student to the

account/student dashboard.

Log Out Button

Location Label

Account Button

Figure 16 – iOS application attendance interface prototype

Table 9 – iOS attendance interface input breakdown

of 73

Here is the

Account/Student dashboard. This interface allows the student to view information about themselves.

The main focus of this interface is to allow the student to view their attendance and see what

classes/lecture they have attended or missed.

Object Description

Attendance Table The Attendance table is where the student is able to see what

classes/lecture they have attended or missed. The sessions will be

labelled as S1 – S10 which allows the student to refer to which

class/lecture. In order to tell which session, the student has and

hasn’t attended, the session will be marked with an Y (Yes) or N

(No).

First name Textbox This will display the students first name.

Second name Textbox This will display the students second name.

Student email Textbox This will display the students email

Student ID Textbox This will display the students ID.

Back Button The back button will redirect the student back to the attendance

interface.

First name Textbox Second name Textbox

Student email Textbox Student ID Textbox

Attendance Table

Back Button

Table 10 – iOS dashboard interface input breakdown

Figure 17 – iOS application dashboard interface prototype

of 73

6.3 User Interface Development

6.3.1 Developed Web Application

6.3.1.1 Navigation Bar

Due to the navigation bar being used to navigate through the web application this is where it made

sense to begin the development. The navigation bar consisted of two stages; firstly, where the user is

not logged in. Secondly, where the user is logged in.

Above displays the navigation bar when the user is not logged in. As mentioned in section 6.2.5 the

user will have to login in order to have full access to the system. Figure 18 also displays how the

navigation bar responds to different display sizes. In order to achieve a responsive navigation bar,

Bootstrap 4 was used (section 7.2.3).

Here is the navigation bar after the user logs into the web application. At which point they are

presented the dashboard link which will give them access to the dashboard feature.

Figure 18 – Responsive navigation bar (Not logged in)

Figure 19 – Responsive navigation bar (Logged in)

of 73

6.3.1.2 Home Page

Here is the final developed home page.

Figure 20 – Developed home page

)

of 73

6.3.1.3 Login Page

Above is the developed login page. A few changes were made from the original prototype due to the

student’s dashboard needing to be developed on the web application; the student login button was

implemented. this allows the student to log in and is redirected to the student dashboard.

Figure 21 – Developed log in page

of 73

6.3.1.4 Room Select Page

Here is the room select developed interface. Only the supported locations are active. This is to display

what locations will be supported if the system was to be further developed.

Figure 22 – Developed room select page

Figure 23 – Developed room select page dropdown options

of 73

6.3.1.5 Lecturer/Room Dashboard

Here is the final dashboard interface. The most important part was the left-hand side of the dashboard.

This is where the students present in the class/lecture are displayed. Like the planned in the prototype,

this section refreshes every second to give a real-time aspect to the system. The right side of the

dashboard interface shows how the student information can be displayed in future development.

Figure 24 – Developed dashboard (Not populated)

Figure 25 – Developed dashboard (Populated)

of 73

6.3.1.6 Student Dashboard

The student dashboard is used for the student to visually display their attendance. The reason this was

developed on the application is due to being accessible on mobile and pc. This allows the student to

interact with the system on other devices; not just through the iOS application.

Figure 26 – Developed student dashboard (Populated)

of 73

6.3.2 Developed iOS Application

Here is the final login interface for the iOS application. A logo was added just to add brand to the

application.

Figure 27 – Developed iOS application login

of 73

Under the assumption, the student successfully logged in to the application they will be presented

with the attendance interface. Most of the service operated in the background of the application

therefore not a lot of interaction design was needed. The label that displays the location dynamically

changes depending on the student’s location.

Figure 28 – Developed iOS application attendance interface

of 73

At the point of the student clicking on the “account” they will get redirected to the student dashboard

on the web application.

6.4 System Usability Scale - Evaluation

In order to evaluate the interfaces for the iOS application and Web application, the standard system

usability scale was used. Family and close friends anonymously filled out the questionnaire. The aim

of this evaluation technique is to study how well the user interface complies usability standards. The

results also give an understanding of how well the users interacted with the system. These results can

be found in section 11.2. After the five results were gathered, the average score was calculated for

each interface.

Relating to the iOS application the average score was 84, which places the interface on just below

excellent. Secondly, relating to the web application, the average score is 82.5; Which again places

the interface just below excellent. This is a good indicator that the interface is efficient enough for

practical use.

Figure 29 – Developed student login web

interface

Figure 30 – Developed student dashboard web

interface

of 73

7 Tools Used

7.1 Hardware

7.1.1 MacBook Pro

In order design and develop the system, a MacBook Pro was used to run the software and access the

services discussed below (section 7.3). Since Xcode was required to develop the iOS application, it

was vital to use a MacBook Pro due to Xcode only being available on an Apple operating system.

7.1.2 iPhone

Although simulators can be used to test the application, a physical device needed to be used in order

to access Bluetooth and location services. An iPhone 6 running on iOS11 was mainly used to test the

development of the application.

7.1.3 Estimote Beacons

Over the current years, a wide range of new companies have emerged up which produce iBeacon

emitters. Estimote was one of the first companies to announce iBeacon emitters, they were also the

emitters that were readily available for use for the project which made them the choice of which

emitter to use. Estimote also provides the developer with an API to make the development more

efficient. Table 11 displays the current version of Estimote beacons which are supported by

Estimote’s current API. Unfortunately, these beacons weren’t available at the time of development

of the system. The version that was used in the system is the hardware version D3.4 which were

produced in 2012. These particular Estimote beacons are powered by a 32-bit ARM Cortex M0 CPU,

256KB memory, Bluetooth 2.4 GHz low-energy radio, temperature and 3-axis motion sensors.

Consequently, this caused major limitations within the development of the system as features were

not supported by the current API or were available in the “legacy” SDK. Nonetheless, the features

that were supported was enough to develop the main scope of the project which was to capture

student’s attendance through the use of iBeacon.

of 73

Identification (Hardware Revision) G1.8, G1.10, G1.12 (currently shipped version)

MCU Bluetooth® SoC

ARM® Cortex®-M4 32-bit processor with FPU

64 MHz Core speed

512 kB Flash memory

64 kB RAM memory

Radio: 2.4 GHz transceiver

Bluetooth® 4.2 LE standard

Range: up to 70 meters (230 feet)

Output Power: -20 to +4 dBm in 4 dB steps,

“Whisper mode” -40 dBm

Sensitivity: -96 dBm

Frequency range: 2400 MHz to 2483.5 MHz

No. of channels: 40

Adjacent channel separation: 2 MHz

Modulation: GFSK (FHSS)

Antenna: PCB Meander, Monopole

Antenna Gain: 0 dBi

Over-the-air data rate: 1 Mbps (2 Mbps supported)

Sensors

Motion sensor (Ultra-low-power, high-

performance, 3-axis "femto" accelerometer)

Temperature sensor

Table 11 - Technical specification of current Estimote Beacons

Figure 31 - Estimote beacon teardown

of 73

7.2 Programming/Mark-up languages and Frameworks

7.2.1 HTML

Hyper Text Mark-up Language (HTML) was used to develop the web pages for the web application.

HTML allows was used to build the structure of the web page which any web browser is then able to

render the web page; making it viewable for anyone that has access to a web browser.

7.2.2 CSS

Cascading Style Sheets (CSS) were used to control the layout and design of the web pages. CSS

allows the implementation of the layout to respond to different devices and screen sizes. This was

used throughout the web application in order to make the web pages respond to the variations of

screen sizes that the users wish to use to access the system.

7.2.3 Bootstrap 4

Bootstrap 4 is an open source framework that has been developed by Twitter. Bootstrap is a

combination of HTML, CSS, and JavaScript which has been specifically designed to build user

interface components. This saved time during the front-end development of the web application as

bootstrap contains templates for forms, buttons, navigation bars, Grid systems and many more.

Bootstrap was mainly used to utilise its grid system, which allowed the layout of the dashboard to be

developed with a responsive implementation in a short amount of time.

7.2.4 JavaScript

JavaScript is a programming language that allows web pages to be more interactive allowing the web

page to do more than just display static information. JavaScript was an important factor in the

development of the Dashboard (section 8.3).

7.2.5 PHP

Hypertext Pre-processor (PHP) is used as the scripting language for the backend/server-side of the

system. Due to PHP being able to operate on a number of various platforms, (Mac OS X, Windows,

Unix, Linux, Android, iOS etc.) this allowed a number of aspects to be implemented throughout the

system (section 8.3).

7.2.6 SQL

Structured Query Language (SQL) was used to access and manipulate the data in the database. This

is done by executing queries with the following commands; SELECT, UPDATE, DELETE, INSERT

and WHERE. These queries are executed using PHP which communicates with the MySQL database.

7.2.7 Swift 4

Swift is a programming language developed by Apple which is used to develop applications

specifically for Apple devices. Since the first release of Swift, there has been a number revision

making Swift more reliable. Swift 4 which is the latest version of Swift (During the time of this

project) made improvements to a big factor that was used in the iOS application which is the

serialisation and de-serialising of external formation, such as JSON. As a result, making the handling

of data being requested by the REST API more secure and easier to implement.

of 73

7.3 Software/Services

7.3.1 Atom IDE

Atom is a free source code editor that runs on all major operating system (Windows, Linux, and Mac

OS X) which also supports a wide number of programming languages. Hence why it was used to

develop the Web application and REST API.

7.3.2 Xcode

Xcode is the IDE that was developed by Apple which makes it the official IDE to develop software

iOS devices. Due to being developed by Apple the IDE is only available on machines running on a

Mac operating system.

7.3.3 Postman

Postman is a HTTP client that is used for testing web services. Due to the REST API being a crucial

part of the system, allowing the iOS application to communicate with the database. This was an

important part of development hence why a reliable HTTP client was used for testing a development.

7.3.4 1&1 Web and Database Hosting

A web hosting service had to be used in order to make the system accessible. 1&1 is a company that

provides this service by supplying the desired domain name, SSL certificate, database and web

hosting for a monthly subscription. At the moment of developing the system, they offered the most

reliable servers which made them the go-to choice.

7.3.5 phpMyAdmin

Since 1&1 uses MySQL, phpMyAdmin is the administration service used to handle and maintain the

database.

7.3.6 Apple Developer Program

In order to run an application on a physical Apple device, a verified Apple Developer account is

needed. The program was vital to have access to as it allowed the iOS application to be distributed

on a physical device allowing testing and physical demonstration of the iOS application working in

the real world.

7.3.7 REST API web service

Representational State Transfer (REST) works over HTTP allowing it to be universal across many

platforms. This is a huge advantage as it allows the system’s communication to be universal and

maintainable. An example would be expanding the service to Android users, if this was to be

developed in the future it would be less time consuming to implement due to the service being

developed using universal technologies.

of 73

8 Back-End Implementation/Prototyping Due to the development methodology which was chosen during the planning of the project, (RAD,

section 2.4) incremental prototypes were developed which will eventually be combined in order to

create the final system.

Since a number of requirements had to be met in to make the overall system. The system was split up

into three separate revisions, the revisions being developed incrementally allowed the system to be

maintainable and rapidly tested in order to make sure each requirement was met.

8.1 MySQL database

The figure above is an entity relationship diagram which visually displays the storage of the data. The

database has been setup using MySQL and maintained using phpmyadmin. The students table is used

to store information about the student. This table is used during the login stages for the student; it’s

used to validate the login with their username and password. The staff table is only used for the staff

login, which grants them access to the system. The room table is used to store the attendance of the

students by storing the student’s information along with the combination of location and time.

Figure 32 – Entity Relationship diagram

of 73

8.2 UML Diagrams

8.2.1 UML Use Case Diagram

The figure above shows how the users will interact with the system. The student’s interaction will be

straightforward. Student/iOS application is where the interaction with the beacons take place. Under

the assumption the student logged into the iOS application, they will need to move in proximity to an

Estimote beacon. Information about the location (Class Room, Course) will be stored to the student’s

smartphone; which will then be sent via REST API to the database in real time.

The Lecturer/Web application is used to visually display who is attending the class/lecture. This will

be done using a web application that connects to the database. Information that Is being stored in the

database will be displayed in real time. The lecturer can then view and export the information.

Figure 33 – UML use case diagram

of 73

8.2.2 UML Sequence Diagram [Login]

The figure above shows how the sequence of the login will take place; under the assumption that the

user already has an account. The user will input their credentials, the password will then be encrypted

on the client side using a SHA1 hashing algorithm. Both the username and hashed password will then

be sent to the database. If the username and password match with the credentials stored in the

database, validation will be granted.

Figure 34 – UML sequence diagram (Login)

of 73

8.2.3 UML Sequence Diagram [Mark attendance]

The figure above shows how the sequence flows when the student’s attendance gets marked. Under

the assumption that the student has already logged in; the student service will then be granted. When

the student walks into a lecture/class (therefore moving within proximity of a beacon), the beacon

returns its location. The student details and location is then sent to the REST API, which then inserts

the data into the database; therefore, marking their attendance.

Figure 35 – UML sequence diagram (Mark attendance)

of 73

8.3 Web Application Development

The first revision of the system was the front end of the web application which was discussed in

section 6.3. Following the front-end development being completed in just a few days, the next step

was to implement backend functionalities which communicate with the database. To achieve this

PHP was used for a number of functionalities:

• Generate dynamic page content – As discussed in section 6.2.1, in order to create an efficient

user experience, it’s important to help users recognise, diagnose, and recover from errors.

PHP was used in this instance to notify the user if a username or password has been entered

incorrectly.

• Send and Receive cookies – During the login stage of the web application, cookies were

used to remember the user’s username. This helps speed up the login process for the next

time the user wished to use the system.

• Control user access – Due to the service only being available to the university, it’s an

important requirement to only grant access to specific users (lectures and students). PHP

was used to achieve this by authenticating the user during the login stage, which if correct

granting access to the service.

• Encrypting data – In order to comply to The Data Protection Act 1998, PHP has been used to

encrypt any sensitive data. This was used in two instances, firstly hashing the password

(SHA1) that the user uses to login into the system making their login credentials secure.

Secondly, HTTPS was initialised using PHP which was discussed in section 4.

• Populate Dashboard – One of the main aspects of the system is to allow the lecturer who is in

the class/lecture. In order to achieve this, an SQL query is executed which populate the

dashboard in correspondence to the campus, building and room that the lecturer selected.

Although PHP was used to populate the dashboard, the dashboard had to have a real-time aspect

which allowed the lecturer keep track of who has entered the room. In order to implement the real-

time aspect into the dashboard; JavaScript was used. JavaScript allowed the implementation of

automatically updating content on the dashboard every second.

of 73

8.4 iOS Application Development

The second revision was the development of the iOS application. Due to having no prior iOS

development experience it was important to allow contingency time in order to get familiarised with

the Xcode IDE and the programming language Swift 4. In order to achieve this a simple application

was developed which changed the background colour of the interface when in range of a Bluetooth

emitter (Estimote Beacon). This allowed the establishment of a number of technologies and

requirements to be met, while learning new frameworks. In order for the device to communicate with

an Estimote beacon, the Estimote SDK was used (section 7.1.3).

Following the iBeacon requirements being met, the next stage was to implement database

connectivity. This was needed to gather vital student information from the database. Firstly,

authentication had to be established which allowed the application to locate which student records to

gather. As discussed in section 8.3, an iOS application can’t directly communicate with a MySQL

database. Hence why a REST API had to be developed. Consequently, this stopped any further

development taking place on the iOS application, until which a functional REST API was developed.

After the REST API was developed, this enabled the application to complete two requirements; login

and mark attendance.

8.5 Attendance log [Excel]

An important aspect of the system is to be able to keep a log of the database, which will store past

attendance and help maintain the database. In the event of a member of staff clicking export on the

dashboard (section 6.3.1.5). This will export an Excel spreadsheet with the attendance log of that day.

The time and date is logged using the UNIX_TIMESTAMP. As the log is exported, a query is made

which removes that data from the database. This allows old data to be archived and documented using

accurate time and dates.

of 73

8.6 REST API/Web-Service

Due to the iOS application, not being able to directly communicate with the MySQL database an API

had to be developed to do so. The REST API was developed using SQL queries which are executed

using PHP.

The REST API was used for two instances, which are;

• Login – In the instance of the student logging into the iOS application, a HTTP POST

method was used. If the student supplies the correct username and password, the student’s

information is authenticated. Valuable student information is returned such as; First Name,

Last Name, Email and Student ID. This information is then returned in a JSON format

which is then de-serialised and stored on the device.

POST is an important factor to take into consideration as it enforces the login credentials to

be sent securely. The reason for this is the method gets sent directly to the server within the

HTTP packet rather than the URL.

• Mark attendance – In the event of a student walking into their class/lecture the interaction

with a Bluetooth emitter will take place. This will trigger an HTTP POST method which

inserts the student information (First Name, Last Name, Email and Student ID) into the

database.

After testing the REST API using Postman, this allowed the API to be used in the iOS application.

Allowing further development to be added to the iOS application.

Figure 36 – REST API interaction

of 73

9 Testing

9.1 White Box

White-Box testing is a method that is used to test a system with an understanding of the source

code. Due to having an understanding the code, this allows for a more technical testing to take

place. This testing technique is aimed to prevent any hidden errors that could take place. In order

for the system to have the best user experience it is important to minimise errors and have an error

free environment.

Test

Number

Test Expected outcome Actual outcome Correct?

1 Visit attendimote.co.uk Home page should

open

Home page opened

correctly

Yes

2 Click the login link User should get

redirected to the

login page

User gets redirected to

the login page

Yes

3 Shrink browser on login

page

Navigation bar and

login form should

respond to

shrinking browser.

Navigation bar and login

form responded to

shrinking browser.

Yes

4 Input incorrect login

credentials and click staff

login

Error message for

incorrect details

should be displayed

Error message for

incorrect details was

displayed

Yes

5 Input incorrect login

credentials and click student

login

Error message for

incorrect details

should be displayed

Error message for

incorrect details was

displayed

Yes

6 Input correct login

credentials and click staff

login

Should get

redirected to Home

page with updated

navigation bar

Redirected to Home

page with updated

navigation bar

Yes

7 Input correct login

credentials and click student

login

Should get

redirected to Home

page with updated

navigation bar

Redirected to Home

page with updated

navigation bar

Yes

Web Application – Staff Service

8 Click dashboard link in

navigation bar

Should get

redirected to Select

Room page

Redirected to Select

Room page

Yes

9 Only select campus and

leave other select options as

default

Shouldn’t redirect

to the dashboard

Didn’t redirect to the

dashboard

Yes

10 Only select building and

leave other select options as

default


to the dashboard

Didn’t redirect to the

dashboard

Yes

11 Only select room and leave

other select options as

default


to the dashboard

Redirected to the

dashboard

No

12 Select all required locations Should redirect to

the dashboard

Redirected to the

dashboard

Yes

of 73

13 Shrink browser on

dashboard page

Navigation bar and

login form should

respond to

shrinking browser.

Navigation bar and login

form responded to

shrinking browser.

Yes

14 Add student into room from

database

Dashboard should

automatically

update

Dashboard

automatically updated.

Yes

15 Click on student’s name Student information

should be viewed

on dashboard

Student information

wasn’t viewed on

dashboard

No

16 Click on export button An excel

spreadsheet should

download and room

should be cleared

An excel spreadsheet

downloaded and room

was cleared

Yes

17 Click the home link located

on the navigation bar

Should be

redirected to home

page

Should be redirected to

home page

Yes

18 Click the logout link located


User should be

logged out

(Sessions

destroyed) and

should be redirected

to home page

User was logged out

(Sessions destroyed) and

redirected to home page

Yes

19 Go directly to

(https://attendimote.co.uk/ro

omsl.php) without logging

in.

Access to the web

page should be

denied

Access to the web page

was denied

Yes

20 Go directly to

(https://attendimote.co.uk/m

onitor.php) without logging

in.

Access to the web

page should be

denied


was denied

Yes

Web Application – Student Service

21 Click dashboard link in

navigation bar

Should get

redirected to student

dashboard page

Redirected to student

dashboard

Yes

22 Resize browser on student

dashboard

Dashboard should

respond and resize

depending on size

of browser

Dashboard responded

and resized from size of

browser

Yes

23 Click the home link located


Should be

redirected to home

page

Should be redirected to

home page

Yes

24 Click the logout link located


User should be

logged out

(Sessions

destroyed) and


to home page

User was logged out

(Sessions destroyed) and

redirected to home page

Yes

25 Go directly to

(https://attendimote.co.uk/da

Access to the web

page should be

denied and redirect


was denied and

Yes

https://attendimote.co.uk/roomsl.php)

https://attendimote.co.uk/roomsl.php)

https://attendimote.co.uk/monitor.php)

https://attendimote.co.uk/monitor.php)

https://attendimote.co.uk/dashboard.php)

of 73

shboard.php) without

logging in

to student login

page

redirected to student

login page

iOS Application

26 Click application icon Application should

open

Application opened Yes

27 Enter incorrect login

credentials and click login


to iBeacon page

Redirected to iBeacon

page

No

28 Enter correct login

credentials and click login

Should redirect to

iBeacon page

Redirected to iBeacon

page

Yes

29 Check if correct user

information is returned from

HTTP request after logging

in

Should return

correct student

information in

JSON format

Returned correct student

information in JSON

format

Yes

30 Check if correct user is

asked permission in order

for the application to use

location services

Student should

receive notification

asking for location

service permissions

Student received

notification asking for

location service

permissions

Yes

31 Move into proximity of

Estimote beacon with

Bluetooth off

“You are attending:

None” should be

displayed


None” was displayed

Yes



Bluetooth on


KW116” should be

displayed


KW116” was displayed

Yes



Bluetooth on

HTTP method

should be called to

mark students

attendance

Students attendance was

saved to database and

displayed on lecturer

dashboard

Yes

34 Move out of proximity of


Bluetooth on


None” should be

displayed


None” was displayed

Yes

35 Click Account link on

toolbar

Should be

redirected to safari

opening student

dashboard on web

application

Redirected to safari

opening student

dashboard on web

application

Yes

36 Click logout button User should be

logged out

(Sessions

destroyed) and


to login page

User should be logged

out (Sessions destroyed)

and was redirected to

login page

Yes

Table 12 – White box testing table

https://attendimote.co.uk/dashboard.php)

of 73

In order to test powerful tools were used which allows the developer to visually display the data that

is being output in the application. These tools were used during the testing of the iOS application

and the RESTful API. Developers have access to a real-time debugger console which outputs data

for the developer to see. An example of where this was used is Table 12, test 29 shows the JSON

response being viewed in the debugger console.

Figure 37 – Testing JSON response in Xcode debug console

of 73

10 Critical Evaluation Overall, the system was able to meet most of the requirements that were listed in section 5. In order

to develop the system, a number of different technologies had to be made to work together. Since the

beginning of the project a sufficient amount of planning took place, which allowed different of aspects

of the project to be developed and executed.

Due to security being an important factor of the overall system, this resulted in the system being

extremely secure. Since the handling and storage of the data used a number of security techniques

(HTTPS, hashing passwords, Certified SSL certificate).

However, the iBeacon technology could be further improved which will make the system even more

accurate.

10.1 Future Implementation

Even though the main scope of the project was met, there is certainly space for further development

to make the system more efficient. With the combination of updated Estimote beacons, new

methodologies could be implemented giving the user access to new features. Features that could be

implemented in the future are;

• onEnter and onExit actions – Currently, an onEnter action is used in the system which only

logs the time a student has entered a class/lecture. If an onExit action was to be

implemented, the system will be able to log the time a student has left a class/lecture. As a

result, giving staff the ability to see the time a student has both entered and exited their

class/lecture.

• Geofencing – In order to implement geofencing, more Estimote beacons will need to be

used depending on the size of a room. Unfortunately, this will increase the cost of the

system dramatically. Since geofencing is a technology that virtually maps out a geographical

area, the system will be able to increase the accuracy the location services.

• Location guidance through Dijkstra’s Algorithm – After geofencing services are developed,

this could potentially allow the development for a location guidance service. Location

guidance will allow the user to find the shortest path to a particular room in a building, or

the shortest route to the building. Since the distance between one beacon to another would

have been developed in the geofencing service; Nodes and vertices should practically

already be mapped. This will be beneficial in the event of an evacuation as it allows the user

to the leave the premises in an efficient and rapid manor.

• Security improvements – Although the security of the system has already been taken

seriously, there is always room for improvement. Currently the passwords are stored in the

database which have been hashed using the SHA1 hashing method. This method is currently

secure but due to improvements in computational processing power, this will eventually be

able to be cracked. A newer hashing method could be implemented. Preferably a SHA-256

hashing algorithm could be implemented; generating an extremely secure hashed version of

a user’s password.

of 73

10.2 Reflection

Personally, I feel that that the project was very successful considering I had no prior experience with

iOS development. Due to having an interest in graphic design, I feel I utilised this well with the

implementation of the user interaction design. Although the user interaction wasn’t the main scope

of the project, I felt this was still an important aspect to consider as it is a user based system. I found

it difficult to not get too distracted with the user interface development which is why I set limits to

what the system interaction should do. This method helped me focus on the important aspects of the

code, which are; scalability, security and maintainability.

Unfortunately, there was an aspect of the web application that I wasn’t able to meet which was the

function to display the student’s information when the lecturer clicks on the student name, which

could have given the lecturer another useful feature. I feel this is due to my lack of knowledge of

JavaScript which could have been implemented through an onclick event. This has helped realise that

I should practice my JavaScript skills in order for me to reach my goal of being a full stack developer.

Since iOS development and Swift is on my list to learn, this project was a good kick start for me to

help understand the development. This was a good reason for me to sign up to the Apple Developer

Program. Going on to then developing the user interface, integrating technologies like Bluetooth and

iBeacon; this has motivated me to work on more side projects.

This was also the first time I developed and integrated a RESTful API, which at first seemed

challenging. Due to having some experience in PHP, I was able to develop my own API to be used

across the system which allowed to get a deeper understanding of how universal systems

communicate to a database.

Considering I would like my career to go in the direction of a Frontend and backend developer for

web and iOS application, I learned many methodologies that can be used future jobs. This has helped

build my confidence and able to present employers with first-hand experience.

of 73

11 Appendices

11.1 Appendix A - Gantt Chart

11.2 Appendix B - System Usability Scale Research

of 73

11.2.1 SUS - iOS Application [1]

System Usability Scale Instructions: For each of the following statements, mark one box that best describes your reactions to the application.

Strongly Disagree

1

2

3

4

Strongly Agree

5

1. I think that I would like to use

this application frequently. X

2. I found this application

unnecessarily complex.

X

3. I thought this application was

easy to use. X

4. I think that I would need

assistance to be able to use this

application.

X

5. I found the various functions in

this application were well

integrated.

X

6. I thought there was too much

inconsistency in this

application.

X

7. I would imagine that most

people would learn to use this

application very quickly.

X

8. I found this application very

cumbersome/awkward to use. X

9. I felt very confident using this

application.

X

10. I needed to learn a lot of things

before I could get going with

this application.

X

Total raw score 35 X 2.5 = 87.5 SUS score /100

Matching adjective = Excellent

Meaning of SUS Scores

92 = Best Imaginable

85 = Excellent

72 = Good

52 = Ok/Fair

38 = Poor

25 = Worst Imaginable

of 73



Strongly Disagree

1

2

3

4

Strongly Agree

5





X

3. I thought this website was easy

to use.

X



application.

X



integrated.

X


inconsistency in this website. X




X




application.

X



this website.

X

Total raw score 30 X 2.5 = 75 SUS score /100

Matching adjective = Above good



85 = Excellent

72 = Good

52 = Ok/Fair

38 = Poor


of 73

11.2.3 SUS – iOS Application [3]


Strongly Disagree

1

2

3

4

Strongly Agree

5





X


easy to use.

X



application.

X



integrated.

X



application.

X




X


cumbersome/awkward to use.

X


application.

X



this application.

X


Matching adjective = Almost best imaginable



85 = Excellent

72 = Good

52 = Ok/Fair

38 = Poor


of 73

11.2.4 SUS – iOS Application [4]


Strongly Disagree

1

2

3

4

Strongly Agree

5





X


easy to use.

X



application.

X



integrated.

X



application.

X




X



X


application.

X



this application.

X


Matching adjective = Almost best imaginable



85 = Excellent

72 = Good

52 = Ok/Fair

38 = Poor


of 73



Strongly Disagree

1

2

3

4

Strongly Agree

5





X


easy to use.

X



application.

X



integrated.

X



application.

X




X



X


application.

X



this application.

X





85 = Excellent

72 = Good

52 = Ok/Fair

38 = Poor


of 73

11.2.6 SUS – Web Application [1]


Strongly Disagree

1

2

3

4

Strongly Agree

5





X


to use.

X



application.

X



integrated.

X






X




application.

X



this website.

X


Matching adjective = Almost Excellent



85 = Excellent

72 = Good

52 = Ok/Fair

38 = Poor


of 73



Strongly Disagree

1

2

3

4

Strongly Agree

5





X


to use.

X



application.

X



integrated.

X






X




application.

X



this website.

X





85 = Excellent

72 = Good

52 = Ok/Fair

38 = Poor


of 73



Strongly Disagree

1

2

3

4

Strongly Agree

5





X


to use.

X



application.

X



integrated.

X






X




application.

X



this website.

X


Matching adjective = Above Excellent



85 = Excellent

72 = Good

52 = Ok/Fair

38 = Poor


of 73



Strongly Disagree

1

2

3

4

Strongly Agree

5





X


to use.

X



application.

X



integrated.

X






X




application.

X



this website.

X





85 = Excellent

72 = Good

52 = Ok/Fair

38 = Poor


of 73

11.3 Appendix C - Diagrams

11.3.1 Rich picture

11.3.2 Flow diagram

of 73

11.4 Appendix D - File List

Web Application

• index.php – This is the home page for the web application.

• indexstudent.php - This is the home page that the student gets redirected to after logging in.

• config.php – This is the controller that is called to get access to the database.

• login.php – This is the login page on the web application.

• loginiosweb.php This is the login page that the student gets redirected to when using their iOS

device.

• roomsl.php – This is used for the lecturer to select the location they would like to view the

attendance dashboard for.

• populate.php – This is the controller that is used to populate the attendance dashboard.

• monitor.php – This is the dahsbaord page that the lecturer used to view the attendance of their

selected location.

• dashboard.php – This is the student dashboard page which allows the student to view their

attendance log.

• datetime.php – This is the controller used to generate the UNIX_TIMESTAMP that is used

in the export controller.

• export.php – This is the controller that is used for the export button on the dashboard page.

Allwoing the lecturer to export an attendance log into a CSV file which can be viewed in

Excel.

• logout.php – This controller destroys the users sessions, logging them out.

• footer.css – This is the style sheet for the footer across the web application.

• lstyle.css - This is the style sheet for the login page.

• mstyle.css - This is the style sheet for the dashboard/monitor.

• navbar-top.css - This is the style sheet for the navigation bar across the web application.

• bootstrap.min.css – This is part of the bootstrap framework used across the web application.

• bootsrap.min.js - This is part of the bootstrap framework used across the web application.

• jquery-slim.min.js - This is part of the bootstrap framework used across the web application.

• popper.min.js - This is part of the bootstrap framework used across the web application.

RESTful API

• config_ios.php – This is the controller that stores the database access information.

• dbconnect_ios.php – This controller uses the config_ios.php file to connect to the database.

• dboperation_ios.php – This controller has a number of functions that are called in the login

and mark attendance stages of the application.

• login_ios.php – This is the file that the HTTP request uses to authenticate the student login.

• add_ios.php – This is the file that the HTTP request uses to add the student’s attendance to

the database.

of 73

iOS Application/Attendimote • Attendimote.xcodeproj – This is the project that stored the repositories for all files, and

resources that are used in the application.

• EstimoteSDK.framework – This is the Estimote framework that is used to implement

communication between the iOS device and Estimote beacons.

• ObjCBridge.h – This is the file used to import the Estimote SDK.

• AppDelegate.swift – This file is used to handed UIApplication states.

• BeaconViewController.swift – This is the file that contains the function behind the

iBeacon/Attendance interface.

• ViewController.swift – This is the file that contains the function behind the login interface.

• Info.plist – This property file stores the user’s settings, which is used to store the location

service permissions.

• LaunchScreen.storyboard – This file stores the user interface for the launch screen of the

application

• Main.storyboard - This file stores the user interface for the storyboard of the application.

of 73

12 References

Aishwarya, D. and Kavya, N. (2015) ‘UNFOLDING THE POTENTIAL OF IBEACON’,

International Journal of Advances in Electronics and Computer Science, (25), pp. 2393–

2835. Available at: http://www.iraj.in/journal/journal_file/journal_pdf/12-135-

143142490572-76.pdf (Accessed: 15 December 2017).

Anand S, Kamal Bijlani, Sheeja Suresh, P. P. (2016) ‘Attendance monitoring in classroom

using smartphone & Wi-Fi fingerprinting’. (Accessed: 14 December 2017).

Apple Inc. (2017) Core Data Programming Guide: What Is Core Data?(Accessed: 6 March

2018).

Apple Inc. (2014) ‘Getting Started with iBeacon Getting Started with iBeacon Overview’.

(Accessed: 17 March 2018).

Boehm, B. W. (1986) ‘A Spiral Model of Software Development and Enhancement’.


Eksen, K., Serif, T. and Ghinea, G. (2018) ‘inLoc : Location-aware Emergency Evacuation

Assistant’. (Accessed: 18 March 2018).

Estimote (2018) Technical specification of Estimote Beacons and Stickers – Estimote

Community Portal. (Accessed: 15 March 2018).

Gatsheni, B. N., Kuriakose, R. B. and Aghdasi, F. (2007) ‘Automating a student class

attendance register using radio frequency identification in South Africa’, Proceedings of the

2007 4th IEEE International Conference on Mechatronics, ICM 2007, (May), pp. 8–10. doi:

10.1109/ICMECH.2007.4279977.

Jakob Nielsen, R. M. (1990) ‘HEURISTIC EVALUATION OF USER INTERFACES’.

(Accessed: 7 April 2018).

Martin J (1992) Rapid Application Development. Prentice-Hall, Englewood Cliffs.

Mahesh, G., Jayahari, K. R. and Bijlani, K. (2016) ‘A smart phone integrated smart

classroom’, International Conference on Next Generation Mobile Applications, Services,

and Technologies, pp. 88–93. doi: 10.1109/NGMAST.2016.31.

Menon, S. et al. (2017) ‘Smart workplace - Using iBeacon’, 2017 International Conference

on Networks and Advances in Computational Technologies, NetACT 2017, (July), pp. 396–

400. doi: 10.1109/NETACT.2017.8076803.

Natalie Harrison, T. B. (2011) Apple Launches iPhone 4S, iOS 5 & iCloud - Apple.

Available at: https://www.apple.com/newsroom/2011/10/04Apple-Launches-iPhone-4S-

iOS-5-iCloud/ (Accessed: 10 March 2018).

Parliamentary Office of Science and Technology (2004) ‘RADIO FREQUENCY

IDENTIFICATION (RFID)’. (Accessed: 15 December 2017).

of 73

Royce, W. W. (1970) ‘MANAGING THE DEVELOPMENT OF LARGE SOFTWARE

SYSTEMS’. (Accessed: 17 March 2018).

Stanca, L. (2004) ‘The Effects of Attendance on Academic Performance: Panel Data

Evidence for Introductory Microeconomics’. (Accessed: 14 December 2017).

Tokiwa, Y., Nonobe, K. and Iwatsuki, M. (2009) ‘Web-based tools to sustain the motivation

of students in distance education’, Proceedings - Frontiers in Education Conference, FIE,

pp. 1–5. doi: 10.1109/FIE.2009.5350677.

of 73

13 Bibliography Anthony, R. J. (2015) Systems programming : designing and developing distributed applications.


Ashok, S. and Krishnaiah, R. V (2013) ‘Overview and Evaluation of Bluetooth Low Energy: An

Emerging Low-Power Wireless Technology’, International Journal of Advanced Research in

Computer Science and Software Engineering, 3(9), pp. 2277–128. (Accessed: 2 March 2018).

Goodwin, K. (2009) Designing for the digital age : how to create human-centered products and

services. Wiley Pub. (Accessed: 18 Feb 2018).

Hay, S. and Harle, R. (2009) ‘Bluetooth Tracking without Discoverability’, in, pp. 120–137. doi:

10.1007/978-3-642-01721-6_8. (Accessed: 2 Feb 2018).

Orozco-Ochoa, S. et al. (2011) ‘Bluetooth-Based System for Tracking People Localization at

Home’, in, pp. 345–352. doi: 10.1007/978-3-642-19934-9_44. (Accessed: 2 March 2018).

Rodríguez-Damián, M., Vila Sobrino, X. A. and Rodríguez-Liñares, L. (2013) ‘Indoor Tracking

Persons Using Bluetooth: A Real Experiment with Different Fingerprinting-Based Algorithms’, in.

Springer, Heidelberg, pp. 25–32. doi: 10.1007/978-3-319-00566-9_4. (Accessed: 5 March 2018).

Wiegers, K. E. and Beatty, J. (2011) Software requirements. (Accessed: 12 April 2018).

Zafari, F. et al. (2016) ‘Enhancing the Accuracy of iBeacons for Indoor Proximity-based Services’.

(Accessed: 2 April 2018).

attendane monitoring using ibeaconjoshmustafa.com/assets/uploads/images/projects/ibeacon.pdf ·...

Documents