Department of Computer Science

BSc (Hons) Computer Science (Software Engineering)

Academic Year 2016 - 2017

Using Smartphone technology to simulate human behaviour within an indoor environment

Michael Beaseley 1407118

A report submitted in partial fulfilment of the requirements for the degree of Bachelor of Science

Brunel University Department of Computer Science Uxbridge Middlesex UB8 3PH United Kingdom T: +44 1895 203397 F: +44 (0) 1895 251686 Using Smartphone technology to simulate human behaviour within an indoor environment

Abstract

The purpose of this project is to research, investigate and design software application, on android, to develop an application that enables a user to track and monitor their behaviour within an indoor environment. Apart from tracking of an individual, there will be research into other smartphone technologies, such as NFC and Bluetooth. GPS is a great way for tracking an individual outdoors but not very good for indoor navigation.

There are multiple examples of software application for business, especially within healthcare, but there is a real need for an android application for the public to use for indoor navigation within a complex building. These example software applications used within business are used for assert tracking and staff locating.

The approach use for this project will be the waterfall model. This model will be used as a mechanism to facilitate the development of an indoor navigation android application. By using this model, an android application will be developed. In this project, the author will show you why this model will help in developing this application.

The author will also evaluate the approach made and the result of the project to discover with the aim and objectives have been met at the end of the day.

i Using Smartphone technology to simulate human behaviour within an indoor environment

Acknowledgements

During the research and development of the application, the author would like to acknowledge the following parties:

 Research and Development o Indooraltas o Infsoft o Senion o Android

 Development tutorials o Altbeacon (Radius Networks) o Codexpedia (NFC)

I certify that the work presented in the dissertation is my own unless referenced.

Signature ____MTBEASELEY______

Date ____30th March 2017______

Total Words:

ii Using Smartphone technology to simulate human behaviour within an indoor environment

Table of Contents

Abstract ...... i Acknowledgements ...... ii Table of Contents ...... iii List of Tables ...... vii List of Figures ...... viii 1 Introduction ...... 10 1.1 Aims and Objectives ...... 11 1.2 Success Criteria ...... 11 1.3 Project Approach and Methodology ...... 12 1.4 Abbreviations ...... 12 1.5 Dissertation Outline ...... 13 2 Background ...... 14 2.1 Android ...... 14 2.1.1 Android Phone ...... 14 2.1.2 User Interaction Channels ...... 14 2.1.2.1 Visual Interaction ...... 15 2.1.2.2 Haptic Interaction ...... 15 2.1.2.2.1 Kinesthetic Interaction ...... 15 2.1.2.2.2 Tactile Interaction ...... 15 2.1.2.3 Gesture Based Interaction ...... 15 2.2 GPS...... 16 2.3 Indoor GPS Alternatives ...... 16 2.4 Existing Solutions ...... 17 2.4.1 Example RTLS ...... 17 2.4.1.1 John Hopkins Hospital ...... 17 2.4.1.2 King Hamad University Hospital ...... 18 2.4.1.3 NHS Forth Valley ...... 19 2.4.2 Available on Google Play ...... 20 2.4.2.1 Google Indoors ...... 20 2.5 Implementation ...... 21 2.5.1 Android SDK and Software ...... 21 2.6 Conclusion & next step ...... 23 2.6.1 Software Development Process ...... 24

iii Using Smartphone technology to simulate human behaviour within an indoor environment

3 Requirement ...... 25 3.1 Introduction ...... 25 3.2 Requirement Elicitation ...... 25 3.2.1 Literature Review ...... 25 3.2.2 Survey Research ...... 25 3.3 Requirement Prioritisation ...... 28 Critical ...... 28 Significant ...... 28 Non-vital ...... 28 3.4 Hardware & Software Requirements ...... 28 3.5 Functional Requirements ...... 29 3.6 Non-Functional Requirements ...... 31 4 Design ...... 32 4.1 Introduction ...... 32 4.2 Deployment Diagram ...... 32 4.3 Application Server ...... 33 4.4 UML Modelling ...... 33 4.4.1 Class Diagram ...... 33 4.4.2 Sequence Diagram ...... 34 4.4.3 Use Case Diagram & Narrative ...... 35 4.5 User Interface Design ...... 36 4.5.1 Application User Interface ...... 37 4.5.2 Log in Activity ...... 38 4.5.3 Mapview Activity...... 38 4.5.4 NFC Activity ...... 39 4.6 Next Step & Conclusion ...... 40 5 Implementation ...... 41 5.1 Introduction ...... 41 5.2 Indooraltas SDK ...... 41 5.2.1 Implementation SDK ...... 41 5.3 Implementation of Other features...... 44 5.3.1 Implementation Beacon Support ...... 44 5.3.2 Implementation NFC Reader/Writer ...... 45 5.4 Rapid Target Test ...... 46 5.5 Implementing the User Interface ...... 47 5.5.1 Log in Interface ...... 47

iv Using Smartphone technology to simulate human behaviour within an indoor environment

5.5.2 Map View Interface ...... 48 5.5.2.1 Navigation Drawer ...... 48 5.5.2.2 Mapping Fragment ...... 49 5.5.2.3 Final Implemented View ...... 50 5.5.3 NFC Reader/Writer Interface ...... 50 5.6 Testing ...... 52 5.6.1 Requirement Verification ...... 52 5.6.2 Requirement Failures ...... 52 5.6.3 Performance Testing ...... 53 5.6.3.1 CPU Testing ...... 54 5.6.3.2 GPU Testing ...... 55 5.6.4 Beta Testing ...... 56 6 Results & Evaluation ...... 57 6.1 Application Accuracy ...... 57 6.2 Host and Target Environment ...... 57 6.3 Guidelines for creating application ...... 58 6.4 Application Evaluation ...... 59 7 Conclusions...... 60 7.1 Project Overview ...... 60 7.2 Future Work ...... 62 7.2.1 Further Development ...... 62 7.2.2 Location-based Enhancements ...... 62 7.2.3 NFC Enhancements ...... 63 7.2.4 Human Computer Interaction ...... 63 References ...... 64 Appendix A Personal Reflection ...... 67 A.1 Reflection on Project ...... 67 A.2 Personal Reflection ...... 68 Appendix B Appendices ...... 69 B.1 Requirements Verification Testing Log ...... 69 Hardware & Software Requirements ...... 69 Target Requirements ...... 69 Host Requirements ...... 69 Functional Requirements ...... 69 Functional Requirement for Log in Activity ...... 69 Functional Requirement for Map View Activity...... 70

v Using Smartphone technology to simulate human behaviour within an indoor environment

Functional Requirements for NFC activity ...... 70 Functional Requirements for Profile Activity ...... 70 Functional Requirements for Settings Activity ...... 71 Non-Functional Requirements ...... 71 Non-Functional Requirements for application ...... 71 Non-Functional Requirements for Interface ...... 71 B.2 Low fidelity Designs ...... 72 B.2.1 Login Activity ...... 72 B.2.2 Mapview Activity ...... 73 B.2.3 NFC Activity ...... 73 B.3 Ethics Form and Confirmation ...... 75

vi Using Smartphone technology to simulate human behaviour within an indoor environment

List of Tables

Table 1 - Reference from Infsoft (13) and Bin Hu, Wi-Fi Based Indoor Positioning System Using Smartphones (14) ...... 17 Table 2 - table point out differences between Android Studio and Eclipse ...... 22 Table 3 - ...... 23

Table 4 - Targettwo example Requirements SDK providers’ ...... comparison ...... 29 Table 5 - Host Requirements ...... 29 Table 6 - Functional Requirement for Log in Activity ...... 29 Table 7 - Functional Requirement for Map View Activity ...... 30 Table 8 - Functional Requirements for NFC activity ...... 30 Table 9 - Functional Requirements for Profile Activity ...... 30 Table 10 - Functional Requirements for Settings Activity...... 31 Table 11 - Non-Functional Requirements for application ...... 31 Table 12 - Non-Functional Requirements for Interface ...... 31 Table 13 - Features that can be noticed via Android Monitor (Android, 2017) ...... 53

vii Using Smartphone technology to simulate human behaviour within an indoor environment

List of Figures

Figure 1 - Example activity using Google Maps Indoor ...... 20 Figure 2 - Waterfall Model ...... 24 Figure 3 - Beohm's Spiral Software Process Model ...... 24 Figure 4 - Number of smartphone users in the United Kingdom (UK) from 2011 to 2018 (in millions) (Statista)(25) ...... 26 Figure 5 - Respondents who own or have access to a smartphone (3,251) (Deloitte Survey UK edition 2016) ...... 26 Figure 6 - ...... 27

Figure 7 - GraphGlobal showingsmartphone Android’s sales by strong operating hold onsys thetem Market from 2009 Telegraph, to 2016 (Statista) (26) ...... 27 Figure 8 - Deployment Diagram of Project ...... 32 Figure 9 - Simple Entity-Relationship Model ...... 33 Figure 10 - Class Diagram for Login, MapView and NFC activities ...... 34 Figure 11 - Sequence Diagram for the Map scenario ...... 34 Figure 12 - Use Case diagram of Application ...... 35 Figure 13 - Example Navigation Drawer from Google Map Application ...... 37 Figure 14 - Custom Navigation Drawer for application...... 37 Figure 15 - High and Low Fidelity Designs of Login Activity ...... 38 Figure 16 - High and Low Fidelity designs for Mapview Activity ...... 39 Figure 17 - Low and High Fidelity Designs for NFC Reader/Writer Activity ...... 40 Figure 18 - Floorplan inputted into Indooraltas...... 42 Figure 19 - Waypoint and Paths created through the MapCreator application ...... 42 Figure 20 - OnResume Method where map is initialised ...... 43 Figure 21 - locationListener used to update Latitude and Longitude ...... 43 Figure 22 - onLocationChanged method used to set the location of the user on the map ...... 43 Figure 23 - FetchFloorPlan method ...... 44 Figure 24 - setupGroundOverlay method...... 44 Figure 25 - Snippet of code onResume method. The area within the red border is the identified code for the Beacon Implementation...... 45 Figure 26 - Snippet of Code showing how beacon is noticed and implemented ...... 45 Figure 27 - Code Snippet showing how NFC is detected ...... 46 Figure 28 - Code Snippet showing initial read phase ...... 46 Figure 29 - Code Snippet showing initial writing phase ...... 46 Figure 30 - Code Snippet showing button click event ...... 48 Figure 31 - Login Activity Evolution ...... 48

viii Using Smartphone technology to simulate human behaviour within an indoor environment

Figure 32 - XML Code Showing menu list structure ...... 49 Figure 33 - Fragment within Navigation Drawer XML Code ...... 49 Figure 34 - Highlighted area within code snippet show UI features on Map Fragment included...... 50 Figure 35 - mapview Evolution...... 50 Figure 36 - Java Methods to set UI features visibility ...... 51 Figure 37 - NFC Activity Evolution ...... 51 Figure 38 - CPU of high-end device under test scenario ...... 54 Figure 39 - CPU of low-end device under test scenario ...... 54 Figure 40 - GPU reading of high end device under test scenario ...... 55 Figure 41 - GPU reading of low end device under test scenario ...... 55 Figure 42 - Android Development Choice ...... 58

ix Using Smartphone technology to simulate human behaviour within an indoor environment

1 Introduction

The purpose of this project is to research, investigate, design and develop an android application that can be used to track and monitor human behaviour and objects within an indoor environment. Apart from tracking an individual location, the application will also provide NFC scanning function and beacon detection capability. This problem has been already solved on a large scale within hospitals through asset and staff management systems but on the

Android market, this kind of application doesn’t really exist, apart from Google Maps. Real-time location systems (RTLS), also known as -positioning , incorporate various types of hardware with a software interfaceindoor. Simply, the systemssystems deployed work by having a hardware tag, which can be placed on individual or object, that communicates its location through the network of sensors that are triangulates its position. (Jill A. Fisher, Evaluation of real-time systems in their hospital contexts)

Most of the research will come from a healthcare point of view, especially towards hospital use of RTLS for multiple reasons:

 Locate tagged Equipment  Assert Management  Staff and patient location  Geographical location There are multiple related to the use of RTLS within hospital; how beneficial the use of this kind of system will be for patient care and staff efficiency and what serious obstacles are being faced to effective deploy this kind of system. (Jill A. Fisher, Evaluation of real-time systems in their hospital contexts)

The application will be developed for android smartphones using Java as the main language of choice. The application will use a software development kit, SDK, from Indooraltas with the map interface being from google. The software used for development will be Android Studio, over Eclipse.

It would be interesting and desirable to find out how technology can benefit the healthcare industry to work efficiently. Technology can be used, firstly, to manage hospital resources more effectively and most importantly, improve patient care.

10 Using Smartphone technology to simulate human behaviour within an indoor environment

1.1 Aims and Objectives The main aim for the project is to design and develop a prototype android application for indoor navigation. This kind of application has been solved as a part function on Google Maps.

The main objectives of this Indoor Navigation Application are as follows:

 Undertake a relevant background study to identify existing work in this area and identify appropriate techniques which can be used to produce a solution in this project.

 Research and identify an appropriate approach which will bring out the best results from which a throughout conclusion can be drawn.

 Research and identify the best software development kit to use for the project.  Research and identify relevant smartphone technologies that can benefit application development.

 Design and implement to create an appropriate android application.  Evaluate the results of the project using set of success criteria.

1.2 Success Criteria For the project to be classified as a success, a prototype application needs to be designed and developed through android framework and an identified software development kit. The project will demonstrate and simulate human behaviour within an indoor environment. The application will be built using Android Studio and developed further using Java to allow for future enhancement and additions.

11 Using Smartphone technology to simulate human behaviour within an indoor environment

1.3 Project Approach and Methodology The approach that is being followed is the Waterfall Model, which states that the phases are organised in a linear order. Due to the limited time of the project running, I concluded that a simple non-repetitive approach was the most sensible thing to do, as with the waterfall model, each phase must be completed before the next phase can begin. The model followed is shown within figure 1.

background research of the topic and,

Afterif existed, defining example the project’s application aim is and necessary objectives, to gai obntaining data and information for the next phase and can be used as a basic model for what is needed for the application. After gaining requirements from the background research, the designing starts. The designing phase includes both scratches and digital designs, using Axure. Following this phase, the implementation begins, which in turn needs to be completed before testing can be completed.

The linear ordering of these activities is critical as the end of each phase is the output of phase of that phase. Each output is the input of other phase. The output of each phase is to be consistent with the fulfillment of the aim and objectives. The background phase is contiuned throughout the planning, requirement and design phases and ended during implement phase. The reason for this is that research still being done for coding reasons.

The Waterfall model was being chosen over other models such as the Spiral Model because all the requirements can be found from example application and other background research.

1.4 Abbreviations SDK - Software Development Kit GPS Global Positioning System

RFID– Radio-Frequency Identification NFC – Near Field Communication –

12 Using Smartphone technology to simulate human behaviour within an indoor environment

1.5 Dissertation Outline The project in which has been undertaken has been structured very simple to the Waterfall model where there is:

 A section on defining the problem  A section on gaining requirements from background data on both the technique and knowledge aspects.

 A section on design  A section on implementation  A section on evaluation As shown through the flowchart presented on the right, each chapter will follow a simple theme to a phase in the Waterfall model. Each chapter will produce an output which in turn becomes the input towards the next chapter. For example, background research identifies the features and function needed for the design phase.

Chapter 2 discusses the background of my project. This chapter will show how literature had impacted me into making decision that would change how the project would step forward.

Chapter 3 refers to defining the functional, non-functional, software and hardware requirements on this project.

Chapter 4 uses the features and function discussed and discovery from a previous chapter to be used within creating designs.

Chapter 5 is the implementation of the project. This chapter shows how the designs was created into a prototype. Following both previous chapters and knowledge which was gained, the decision that was made will be shown within a practical example.

Chapter 6 is all about using the develop prototype application and gaining testing results to discuss if the aim and objectives have been met.

Finally, chapter 7 is using the data gained from evaluated to see if the application meets its objective, if its application fulfils the success criteria and possible future work.

13 Using Smartphone technology to simulate human behaviour within an indoor environment

2 Background

Before designing and development of this android application, it was important to understand the domain in which this application will be used on. As with any domain, this will help define the functions and features available and the relevance of the project.

To complete the aim and objectives of the project, the literature review will be aimed towards identifying existing technologies, tools, and application available on the android platform. This review is to also provide a thorough list of necessary technologies required to produce an indoor-navigation based application. From these pieces of literature, a list of requirements will be created.

2.1 Android Understanding the platform in which the application will be on is necessary and fundamental to understanding as many different aspects of the project. For example, technologies and examples that will define the possibility of this project.

2.1.1 Android Phone For any technically driven project, understanding the platform you are developing on is essential to understand. As the project is all about where the user is in relation to a map, according android, there smartphone consist primarily of two sensors that let you determine the position of a device (12):

 Geomagnetic field  Accelerometer networkThese sensors signal will strength. be useful for determining a device’s physical position but are affect my

2.1.2 User Interaction Channels Even though android provides a useful and clever process of user interaction, based on touch screen technology and interactive gestures, smartphone are being used across an increasing range of places and situations.

attention.Most mobile When user these interfaces devices are are designed used outside for a of per homeson who or office is standing contexts, still however, and paying users full must adapt their use of the device to an external environment which places high demands on their 5) ability to interact.

14 Using Smartphone technology to simulate human behaviour within an indoor environment

During the present-day environment, a user is more likely to use their smartphone while on the move. Due to this reason, the interaction the user makes with any application needs to be taken under consideration. The application will be required to be used and interacted with on the go, more than most application on the android market as the propose of the application is to be used for navigation.

2.1.2.1 Visual Interaction To take under safety consideration for this project is how the user interact with application. Due to the development of smartphone technology, phones are much more than just a calling devices these days; they are more like small portable computers. (7) Lumsden and Brewster (2003) argue t pay all their

hat smartphone that are being used in motion, users shouldn’t attention(8) to their phone or any of their visual resources to interacting with the mobileas a device requirement. This might as be the a purposerelevant ofsmall the applicationpoint to make is tobut be it’s use important as a navigation to recognise application.

2.1.2.2 Haptic Interaction This term refers to how the user interact with the device itself by touch. Mobile devices can be enhanced through a well-designed UI. (9) This includes the both kinaesthetic and tactile.

2.1.2.2.1 Kinesthetic Interaction This term refers to mobile device to detect movement of the body. For example, the location, orientation and an associated information. (11) This could refer to user location passing within a reasonable distance of a beacon and/or NFC tag. For this reason, the application will always update the current location and scan for nearby devices.

2.1.2.2.2 Tactileuser’s Interaction This kind of interaction is most commonly included within mobile devices. For example, the feeling gained by mobile device in the form of vibration. (10) Therefore, using this knowledge could allow the user to notice an application screen update when in active use.

2.1.2.3 Gesture Based Interaction All smartphone devices, these days, use gestures to support their applications. These interacts could refer to tilting and/or shaking the device. (11) Applications, such as Pokémon Go, use gesture based interactions to help the application to preserve the device battery. For this reason, the application giving the option to its users to save battery life could benefit the application popularity for the long run.

15 Using Smartphone technology to simulate human behaviour within an indoor environment

2.2 GPS Position information is vital to all location-based services such as mobile users, personnel and asset tracking. Through location-based services, users can find anything of their choosing from items in a clothes store to doctors in a hospital. These kinds of application can also benefit visually impaired individuals so that they can navigate within an indoor environment. (5) Global Positioning Systems, GPS, is great for outdoors navigation but not very useful for indoor environments. In these cases, GPS may give us no answer, the wrong answer or an answer with insufficient accuracy whe 4) GPS has three main limitations which sadly link to location-basedn we simply applications. ask Where Th areese we?.are:  Signal reception  Signal Integrity  Signal Accuracy

Developing an indoor navigation application, these kinds of application require an accurate user position for both indoor and outdoor environments. As previously mentioned, GPS is effective in providing accurate user positioning and is widely used in multiple devices, such as smartphones which this project is being developed around. However, currently global navigation systems do not work satisfactorily indoors since the satellite signals are blocked by roofs, walls and nearby building. (5)

2.3 Indoor GPS Alternatives As discussed in the previous section, GPS has its limitation, mainly an indoor environment. To solve this problem, alternatives had to be found.

Alternative Accuracy Advantage Disadvantage GPS High (10meter) Good accuracy Line of Single is needed. Wi-Fi Medium (10- Good accuracy for High cost for 100meter) indoor environments infrastructure and and no need for line limited coverage of single. Bluetooth (Beacon) High medium High flexibility and Cost can become

(1-3meter)– accuracy experience depending on size of area.

16 Using Smartphone technology to simulate human behaviour within an indoor environment

Cellular Network Low-medium (1km) No requirements for Problematic in low infrastructure signal conditions. Ultra-wideband High (10-30cm) High accuracy High cost for infrastructure. Only suitable for special industry applications. Table 1 - Reference from Infsoft (13) and Bin Hu, Wi-Fi Based Indoor Positioning System Using Smartphones (14) 2.4 Existing Solutions During the earlier phases of the project, there were few application on the android market of real quality but it is important to understand the feature and function in which make this application. For this reason, performing a search and analysis of the most popular applications, so that the application has these features and function from hardware to software down. For each solution, strengths, weaknesses, and lessons learned have been identifiedso it isn’t let

2.4.1 Example RTLS

2.4.1.1 John Hopkins Hospital From Versus (16), they installed one of the largest hospital construction projects in history. The building in question is a state-of-the-art hospital, Johns Hopkins, located in Baltimore, Maryland. Highlighted are some of the key parts of the use case:

 1.6 million square feet  System consisted multiple applications: Asset Management, Nurse call automation, staff locating, Reports PlusTM Analytics

 3550 personnel badges  8900 asset tags  3200 sensors  53 floorplan Views  Logging 3500 to 5000 location changes per minute.  System uses three RTLS technologies, Infrared (IR) and radio frequency (RFID) solution, a beacon IR/RFID system, and a Wi-Fi.

Back in 2012, Mike McCarty, Chief Network Officer at John Hopkins hospitals, mentioned that using Wi-Fi technology alone was no sufficiently accurate to pinpoint patient locations during their simulations. The only solution was to add more access points which the willing to do. (17) hospital wasn’t

17 Using Smartphone technology to simulate human behaviour within an indoor environment

There was a series of features that has been identified from a hardware point of view that will have an influence on this project. The system that John Hopkins Hospitals uses multiple hardware, such as sensors and tags, to locate hospital equipment and personnel. The project will consider uses Wi-Fi technology combined within beacons to simulate an indoor environment infrastructure. Beacons can be used as tags for locating key objects and individuals. The inclusion of using multiple times of hardware will likely influence the designs of the application as this will enable the application to communicate data about several times of data.

2.4.1.2 King Hamad University Hospital King Hamad University Hospital (35), located in Bahrain, is a technologically advanced hospital which uses an access-tracking within their existing ERP system. The RFID solution aimed to deliver:

 Improved safety of new born babies  Reduced costs from fewer overstocked items  Increased inventory visibility  Decreased theft of assets Within the hospital, a series of technologies to monitor the usage of items and patients, such as new born babies. Some large items and mobile pharmaceutical carts are tagged with readers deployed throughout the hospitals above doorways and elevators to monitor the assets. The data gathered by the readers is send to the system which imposes restrictions on the assets. If the rules are broken, the system notifies and alert of the issue. In the maternity ward, mothers and new born babies are given tags so that their safety can be monitored.

There was a series of features that are been identified from a hardware point of view and the what kind of data can be gathered and used to benefit a large infrastructure like a hospital. This is the kind of system used in multiple hospitals across the world. Whereas this system using RFID technology, this case study has identified the benefit of tags on items and individuals and what can be gathered. This project use implement the usage of tags to be used on items and individuals. The full implementation may be out of scope for the project but including the core features of implementing this kind of technology.

18 Using Smartphone technology to simulate human behaviour within an indoor environment

2.4.1.3 NHS Forth Valley The NHS (36) are also using asset tracking systems to benefit overall healthcare within the UK. NHS Forth Valley, located in Scotland, is one of the most modern and well equipped facilities within Europe. The introduction of RFID Asset tracking for mobile medical devices was driven by:

 Problems keeping track of large number of movable medical devices  Nursing and technician time being wasted searching for equipment  Poor equipment utilisation  Budget constraints The Asset Tracking system uses the same technology as the example previously. Each tag on a device transmits a unique ID at pre-set intervals and signals are picked up by fixed readers. Staff have readers to perform local equipment searches within different wards. The data gathered is a sent back to a central database.

The system improved equipment utilisation, with the benefit of reducing capital expenditure and time spent to find the right equipment. In terms of the project, this case study has identified so important features such as the tags containing unique IDs with the data been stored and sent to a central database. For terms of this project, the full implementation of a database will be out of scope but the design should show how a database should be implemented.

19 Using Smartphone technology to simulate human behaviour within an indoor environment

2.4.2 Available on Google Play There is only one available android application of real note that supports and supplies a means to indoor navigation with an additional of outdoor navigation as well.

2.4.2.1 Google Indoors © 2017 Google Inc. Version 9.47.3 Google is one of the most recognise for indoor navigation whichcompletely can be free seen to use.on google Google maps Indoors itself is and just it’s a fe ature of google maps and can be accessed via the same interface. The main interfaces display an interactive map that shows you points of interest and your current location. Zooming abilities allow the user to almost see a three- dimensional view of buildings. It is reliant on companies uploading floorplans and maps of indoor environment. Google indoors is still relatively new so it only works on selected venues but given time this can only improve. The application has the abilities of sharing via exporting maps in emails, webpages and even social media.

The identified strengths (15): Figure 1 - Example activity using Google Maps Indoor  Google Maps has a wealth of information and provides layout of roads, locations of cities and towns all the way to maps of airports, museums and many more.

 Google map great for developers to use for their own applications as all location, zoom and indoor environment features can be used.

 Google maps is available from google play complete free and installed as standard on all android smartphones. The identified weaknesses (15):

 The application has limited accuracy. Ambiguities and flaws in location data recover by smartphone may produce a route to different destination than expected.

 Does not have up to minute information on usual conditions  Has limited floorplans of indoors environment as it very much relies to individuals uploading them.

20 Using Smartphone technology to simulate human behaviour within an indoor environment

Regardless of the issues with Google Maps, this application is well developed, and has a series of features that will make an influence on this project. Google Maps uses android GPS capabilities to access a user location and bearing and provide visual feedback through a map interface. This project will be impacted by using maps and be impacted by the feedback of sensorial data. One of the most interesting aspects of Google Maps is how the interface is structure and what features are included from selected which floor level to the abilities of zooming. Taking these kinds of features into consideration in designing the application will in term influence in the outcome of the project as interaction in android application is highly important for success.

2.5 Implementation As the project is going to be developed on the android platform, understanding android capabilities is important. Android application are written in java programming language.

2.5.1 Android SDK and Software Two of the key topic of interests, in relation of development, are what SDK are used for and what software is used for development. These points of interests determine both how an application is developed but also tested.

From Avocarrot co-founder Panos Papageorgiou (18), Android studio has the edge over Eclipse, as presented within the table below. Topic Android Studio Eclipse Build Tools Utilises the fast growing Uses Apache Ant as its prime Gradle build system; builds build system on top of the concepts of It is very familiar with java Apache Ant and Apache developers. Maven but it also introduces a Groovy DSL that allows for scripting builds. Advanced Code Completion Google, owners of Android Studio, have given the software a deeper support for specific Android code a refactoring. Refactoring can be done in places when Eclipse cannot. User Interface (UI) Able to physically move Have to manually set in the object within XML code much XML code faster. More customization options available.

21 Using Smartphone technology to simulate human behaviour within an indoor environment

Organisation of Project Switching between

Doesn’tOne module, need ato library restart and )DE workspace, that can project android SDK can be files, cannot be done without integrated within the Gradle restarting whole IDE. build files. Multiple dependencies can be added. Can take time to get use to if use to Eclipse. System Stability Still relatively new and Purely Java based Software consist of its own bugs that To run reliably, more than crash the IDE every now and decent amount of RAM and then. Good CPU power. Overall, runs faster and more reliably. Table 2 - table point out differences between Android Studio and Eclipse

Following these points and the hardware device that most of the application will be developed on, multiple things was needed over other things. Personally, a software that is both more reliable and faster to run was more needed. With Android Studio suppling these plus greater customisation, it become more obvious which software is more appropriate to use.

The other topic of interest is what SDK to use to simulate user location and fletch floorplans. These two points are the most important requirement of the application as the two are criteria for the application to be a success. Indooraltas Infsoft There platform consist of: There platform consist of:

 Indoor Positioning (Blue dot)  Indoor Navigation  Geofencing  Indoor Positioning  Way-finding  Indoor Analytics  Search  Indoor Tracking  Multi-dot Enables an easy platform to build highly Offers both hardware and software solutions. targeted proximity marketing

22 Using Smartphone technology to simulate human behaviour within an indoor environment

Highly Scalable: Cloud platform simplifies Software solutions: your infrastructure enabling you to scale cost  LocAware platform effectively, quickly and securely  SDK Software-only solution: reduces the need to Hardware solutions include: Locator tags, purchase, install and maintain costly Bluetooth beacons and Wi-Fi hardware 1- The accuracy of the application will depend positioning meters’ accuracy with blue dot on where hardware solution is selected. Intuitive workflow enables easy Map Editor enables creation of waypoints implementation, designed with the developer and paths, with points of interests in mind Utilise Wi-Fi and Bluetooth technology Using android application to create sensor data based on created floorplan.

Table 3 - two example SDK providers’ comparison

Aftertwo effective identifying software the benefits development of using kits both to compancreate aies’n application SDK, )ndooraltas with. To and decide, )nfsoft the both aim show was important to look back at and the platform in which the application is based on. As how they use mapping technology was similar from a development point of view, a difference was find. Personally, Indooraltas map editor was much easier to understand and allow actual sensor data via a separate android application also free to use. With its easy to understand tutorials on using the SDK and the map editor, therefore Indooraltas was chosen over Infsoft.

2.6 Conclusion & next step After fully understanding the literature in this topic, it was clear that my approach had a requirement to fulfil. As there are very limited number of working application on the android market, producing a working location-aware prototype and, in turn, improving android functionality. The remainder of this report will show and discuss the issues experienced and decisions made when creating the application.

23 Using Smartphone technology to simulate human behaviour within an indoor environment

2.6.1 Software Development Process As mentioned within Chapter 1, this project uses the standard phases which are recognised as the Waterfall Model. The first identified stage that time will be spent on is the project Requirements. The requirement is important as they are used to define the next phase, design phase. Building the architectural and user interface designs give the developer an idea on what design fulfil the Figure 2 - Waterfall Model requirements but also allows a user- friendly environment to be created. After the design phase, the project will move into the implementation; the creation of the project. The created application will be further tested in the Verification phases. The maintenance phases will not be performed as the application will not be developed past the first prototype.

The project follows a basic construct of the as waterfallthis project model is only but following this isn’t thecompletely model once. true, The requirements and design will remain static throughout the duration. The waterfall model shows a clear and general illustration of the process in which this project will be performed under. As previously mentioned, this project follow this model as there are a doesn’tdegree offreely backtracking from one activity to the next. (37) As this is true especially for the Figure 3 - Beohm's Spiral Software Process Model As thedevelopment learning of process, technologies it should will be affect viewed developmen more as Bot progression,ehm’s Spiral being software impacting process by model. a model that is applicable to the development of application is important. The target environment requires the application to be developed and tested in iteration. A requirement that would be impossible to fulfil under a linear process model, for example the waterfall model.

24 Using Smartphone technology to simulate human behaviour within an indoor environment

3 Requirement

3.1 Introduction The identification of requirements is highly important to the development of the application and creation of the first prototype. Identifying these requirements will allow the developer to formalise what is needed and paid enough attention to part of the implementation over others.

This chapter is all about outlining the functional and non-functional requirements for all aspect of the application development from hardware and software to the application itself. Defining the functional and non-functional requirements will define how the application will be seen and how the application will behave for the user.

3.2 Requirement Elicitation

3.2.1 Literature Review Most of the requirements for this application has come from existing solutions which are either showing the project aim on an extremely large scale and/or part feature of a large application. From these solutions, they offer a wide range of functional features, which in term provide the basis requirement for the application. Many requirements discovered are also included but are out of range for the scope of the project.

3.2.2 Survey Research For the basis of the application, it is highly important to identify further requirements and, in turn, set the context of the application. Due to this, a series of surveys was researched to help in this stage.

devices but these days,

Mobile phone technology aren’t just simple communication smartphonesdevelopers to hasaccess now whole become new a markets:hub Deloitte Survey. Smartphone enable users and  Mobile Payments  Internet of Things  Location-based Advertising  Virtual Reality  Social Media These are just examples of the market that can be access in this day of age. An individual without access to any phone technology will find it difficult to fully participate in daily activities that comprise the global economy and this century.

25 Using Smartphone technology to simulate human behaviour within an indoor environment

According to Ofcom (2016), the number of 4G mobile subscriptions has increased from 23.6 million (May 2014) to 39.5 million (May 2015)(24). This will only increase more and more. As predicted by Statista, the number of smartphone users will reach 46.4 million in the UK. (25)

Figure 4 - Number of smartphone users in the United Kingdom (UK) from 2011 to 2018 (in millions) (Statista)(25)

The users of smartphones are not limited by age. A survey conducted by Deloitte between May and June 2016 based on 3251 s that this statement is true. Following the data received from these figures,smartphones it is importa users’nt state to design the interface so that is understandable for developing the application so that is easy to use for all ages.

Figure 5 - Respondents who own or have access to a smartphone (3,251) (Deloitte Survey UK edition 2016)

Based on a report from the Telegraph (May 2016)(23) system has reported growth of 7.1 percent across Europe, Google’s within Android the market smartphone compared operating whereas Apple market share has stand the same within the same period. The figure below also supports this data.

26 Using Smartphone technology to simulate human behaviour within an indoor environment

Figure 6 - Graph showing Android’s strong hold on the Market Telegraph, 6 (23)

Figure 7 - Global smartphone sales by operating system from 2009 to 2016 (Statista) (26)

Following these past two figures, it is easy to suggest that a high number of smartphone users use and/or own an Android phone. This is an important factor that needs to be notices for the application for multiple reasons. The first thing to notice is that a high number of potential users are both familiar with the Android platform and familiar with the interface of the Android. Following these assumptions, the application will follow the features of an Android Interface as close of possible so users will be comfortable using the application. The second thing to notice is that there is a high number of users of Android which supports my adoption of this platform to develop on.

The research above has given a good understanding of what is expected for this application fromon creating the user’s a typical prospective. Android The User data Interface. received have concluded that the application should focus

27 Using Smartphone technology to simulate human behaviour within an indoor environment

3.3 Requirement Prioritisation All the requirements stated for the development of this application will be given a priority from following:

 Critical  Significant  Non-vital The defining of this requirement under priority will define the importance of the requirements to the application.

Critical The requirement under this sub-category are identified to be core to the functionality of this application. Not meeting all the requirement identified as critical would mean the application is not fit for purpose as identified within the aims and objectives. This requirement set the tone of the application so this requirement need to be met.

Significant The requirements under this sub-category are identified to be highly important for the functionality and implementation of the application. The application will be fit for purpose if critical requirements are met but very much at a basic capability. This requirement will have an effect on the application to a degree. Without these requirements, the application will be considered as a functional prototype at best.

Non-vital The requirements under this sub- These requirements are no way near importantcategory to would the appli be bettercation definedon a basic as levelnice butto have. would provide extra functionality to the application.

3.4 Hardware & Software Requirements The requirements under this section relate to the building and using of the application. As these kind applications need both a host and target environment to be used, the requirement will be split into tables that show the requirements separately.

No. Requirement Priority 1 The application should run on Android API Critical

2 The application should utilise android built in GPSand receiver.later Lollipop, …. Critical 3 The application should utilise android built in Bluetooth functionality, Significant including NFC.

28 Using Smartphone technology to simulate human behaviour within an indoor environment

Table 4 - Target Requirements

No. Requirement Priority 4 The application should be built and deploy on Window 10. Critical 5 The application should be compile and run on an Android phone running Critical minimum API. 6 The application should be built using Android SDKs, supported by Critical Indooraltas and Beacon Library. 7 The application should be written in Java. Critical 8 The application should be developed and compiled in Android Studio. Critical Table 5 - Host Requirements 3.5 Functional Requirements As this application is needing to complete the aim and objective set at the problem definition phase, defining the functional requirement for the application is important. These will be split into the following tables:

 Log in  Map View  NFC  Profile  Settings

No. Requirement Priority 9 The application will allow the user to enter a Username and password. Critical 10 The application should be able check user data to see if correct against Non-Vital an android recommended server (SQLite Database for example). 11 The application should be able to request a change of password. Non-Vital 12 The application should be able to request a creation of a new account. Non-Vital 13 The application should check if following is active: Critical

 Wi-Fi/ Mobile Data  GPS/location Table 6 - Functional Requirement for Log in Activity

No. Requirement Priority 14 The application should display a map with the user current location Critical displayed. 15 The application should display on map indoor areas that are mapped out. Critical

29 Using Smartphone technology to simulate human behaviour within an indoor environment

16 The application should display nearby beacons on map for user to locate. Significant 17 The application should display the following map functions: Critical

 My location button  Zoom in/out  Floor Level selector 18 The application should follow a typical Android UI. Critical 19 The application should allow user to navigate to selected location. Non-vital Table 7 - Functional Requirement for Map View Activity

No. Requirement Priority 20 The application should be able to scan NFC tags. Critical 21 The application should be able to display what is written to NFC tags. Critical 22 The application should be able to edit NFC tags. Critical 23 The application should allow user to see history of NFC tags. Non-Vital 24 The application should allow user to see the following data: Non-Vital

 Location  Main Content  Date/Time 25 The application should check if user device has NFC compatibility. Critical 26 The application should check if NFC is active. Critical Table 8 - Functional Requirements for NFC activity

No. Requirement Priority 27 The application should support multiple user profiles Non-Vital 28 Profile Data should be stored on an android recommended server. Non-Vital 29 The profile data that will be stored on the server: Non-Vital

 Profile ID  Username  Password  Email Address  Profile Image  Home Location 30 The application should allow user to edit or add profile data. Non-Vital 31 The application should allow user to remove/delete profile data. Non-Vital Table 9 - Functional Requirements for Profile Activity

30 Using Smartphone technology to simulate human behaviour within an indoor environment

No. Requirement Priority 32 The application should allow the user to change the desired font size. Non-Vital 33 The application should allow the user to select a power save mode. Non-Vital 34 The application should allow the user to turn on and off audio feedback. Non-Vital 35 The application should allow the user to change the desired GPS Non-Vital accuracy. Table 10 - Functional Requirements for Settings Activity 3.6 Non-Functional Requirements

No. Requirement Priority 36 The application should provide as accurate as possible GPS tracking Significant 37 The application should take no longer than a couple of minutes training Significant for the user to understand the application with no android experience. 38 The application should take no training for a user with android Significant experience. 39 The application should conserve battery. Significant 40 The application should not contain any memory leaks. Critical 41 The application should exit as smooth as possible in case of error. Critical Table 11 - Non-Functional Requirements for application

No. Requirement Priority 42 The application should include a loading screen to inform a user the Non-Vital application is loading. 43 The application should have a logo display both on the application and Non-Vital within the android menu. Table 12 - Non-Functional Requirements for Interface

31 Using Smartphone technology to simulate human behaviour within an indoor environment

4 Design

4.1 Introduction After the requirements being defined, the next step is designing the application. This chapter outlines the application structure and user interface. The designs will display how the requirements will affect the system architecture and how the application will look for the user.

During this phase of development, a series of design techniques have been used so that a thorough approach has been completed. This will not only enhance the application visual look but the functionality of the application itself.

4.2 Deployment Diagram The first step to creating an application is identifying all the connecting parts that the deployment of the application will need to work. This architectural can be illustrated as shown below.

Figure 8 - Deployment Diagram of Project

The deployment diagram shows the key architectural of the application from the phone itself to the servers connected to the application. The application will be connected to two servers:

 Server: this is where the developed floorplans will be placed and get from.

This)ndooraltas’s is a part of the service the SDK supplies. The server connection also provides access to their location-based framework provided as part of the android SDK.

 MySQL Database: this is where external data will be stored and retrieved from, such as Profile data, NFC locations and Beacons.

32 Using Smartphone technology to simulate human behaviour within an indoor environment

Thethe application MYSQL Database would isn’tbe developed a critical parton a ofmuch the applargelication scale. but would be important to mention if

4.3 Application Server As previously mentioned, the application aims to store profile data and NFC data in a MYSQL database. This will therefore mean that it would be available when the application is started. During this beginning phase of the application development, critical to the success of the project but would need to be addedusing to bea server put on for a larger such data scale. isn’t To present what data will be stored and retrieve for the application, a simple entity-relationship diagram has been created.

Figure 9 - Simple Entity-Relationship Model

During this very earlier stage of development, it is hard to determine the actual size and complexity of the dataset to be stored on the server. For example, the NFC tags stored on the database could be an extreme high. If the database is going to be developed, a much larger and more complex database will need to be designed included, for example, normalization to keep data integrity.

4.4 UML Modelling The next stage was to develop UML models which allows the visualisation of the application to be presented. This will show the basic layout of the application and how the features and functions will be shown. Unified Modelling Language Diagrams(UML), such as use case, class and sequence, have been created to show how the application will work.

4.4.1 Class Diagram The figure below shows a simple version of the application class diagram. The full and final version of the application will include a much larger number of classes from a series of external libraries, that will need to be included as dependences within the implementation of the application. The diagram below only shows the core classes that will be developed during the next phase. The main activity of the application is the mapview as this contains the main functionality or links onto other functions, such as NFC. The classes have been colour codes to show what classes are the sub-classes, grey, and which are the super-classes, light oranges. Classes, such

as m)Alocationlistener and onBeaconSupport, are there to add function

33 Using Smartphone technology to simulate human behaviour within an indoor environment significant functionality t map activity which allowso furtherthe map, functionality whereas the to onNavigationDrawer be added to the application. is an e xternal to the

Figure 10 - Class Diagram for Login, MapView and NFC activities

4.4.2 Sequence Diagram As shown below, a sequence diagram has been developed to demonstrate one of the main aspects of the applications, Map View. This diagram will show how each activity and methods will be used to complete the task. The diagram will start when the user will be entering their username and password to access the application.

Figure 11 - Sequence Diagram for the Map scenario

Accessingrequirement a map phase. will The the diagramuser’s current shows location a basic layout is a core of howrequirement the requirement highlighted is completed within the via the application. The profile class is not included in this prototype as no server storing the data is included. A very limited number of methods once on the map activity is used. The location of the user will be obtained from the used SDK and returned as coordinates to be presented on the map.

34 Using Smartphone technology to simulate human behaviour within an indoor environment

4.4.3 Use Case Diagram & Narrative The final UML diagrams show how the application will be interacted with by the users. As shown below, allow the d defines a goal-oriented seteveloper of interactions to visually between see each external activity actors of the and appli thecation. system A under use case consideration The actors could range from users. Ruth to other Malan, systems, Functional such Requirementsas servers and anddatabases. Use Cas es,

Figure 12 - Use Case diagram of Application

The application will consist of the following actors: User, Server/Administration, and Server. The main sectors that will be included within the implementation are

)ndoorAtlas’sshown within the border. As previously mentioned, the additional server/database includes profile and NFC data that are not critical for the application to be a success.

Within the figure below is a use case narrative describing how to navigate through the proposed application. The narrative, essentially, describes the interaction between the actor/s to achieve a goal of observable value. These will include a series of simple steps. This case is to navigate to scanning an NFC tag to get data. These will be useful to use for the FAQ/User Guide activity as these narratives can be used to give the users an easy to understand walkthrough.

35 Using Smartphone technology to simulate human behaviour within an indoor environment

Figure 9 - Use Case Narrative for the Scan NFC Scenario 4.5 User Interface Design The User interface of any application of this kind is highly important and this is especially android application. The interface impacts how the user can interact with the application so creating a user-friendly and effective UI. These days, android smartphones are not limited by display size or screen resolution. Android phone companies, such as Sony, LG and Samsung, have a range of phones that rely of developers to make the software of their phones are visually appealing for the user. This section will outline the work that will be implementation through hi a modelgh and of low the fidelity system prototypes. resembles Asthe referenced targets system by Al refersethea toBlackler the fidelity 8, model. the Lowdegree fidelity to which prototypes are represented via paper and can be seen within more detail within the appendix; whereas high fidelity resembles the application end look more closely digitally. Refer to the appendix for the full low fidelity designs.

When creating the designs of the interfaces, the use of the previous year group project designs was highly useful. Usability was the research topic, especially how visually impaired and disabled can use an application of any kind. These topics include best colours, fonts and sizes. Selecting a preferred primary colour of the application was a key starting point. From my opinion, any degree of colour blindness can affect how a user interacts with the application as it will become less appealing. As mentioned

- by Bernhard Jenny , the commonly called red green blindness is by far the most frequent form.

36 Using Smartphone technology to simulate human behaviour within an indoor environment

4.5.1 Application User Interface Android Studios provides a framework that enables any developer to create an application that uses the same standard UI. Using this, the application, main activity, Mapview, will incorporate a navigation drawer, which can be commonly seen across multiple google application, such as Google Maps.

These drawers are normally displayed from the left-hand side of application by either pressing a button or a sliding action. These navigation drawers are used to give a direct link to other parts of an application and this will be no different for this Figure 13 - Example Navigation application. The following application will consist of a series of Drawer from Google Map Application links:

 NFC Reader/Writer  User Guide  Settings  About Us  Log Off Only one of these will be developed for this application as it is a significant function of the application, NFC Reader/Writer.

This application navigation drawer has been designed as closely as possible to the example shown above. The colours, heading and links have been changed to fit with this application. Icons, that fit with their respective heading, have been selected from Android set of clipart images. The navigation drawer for this application, shown within figure on right, was designed using Android Studio but later shown through over digital and drawn designs.

Figure 14 - Custom Navigation Drawer for application.

37 Using Smartphone technology to simulate human behaviour within an indoor environment

4.5.2 Log in Activity As this is not as important as other activities within the application, very limited functionality designwill work how when the userimplementing will first access these thedesigns applicati but thison. Thisdoesn’t activity mean has that been it isn’t designed important to enable to the user to input their details to access the map activity of the application. The inputted details can be checked access profile information. The UI will utilise simple edit boxes and buttons to allow the user to interact with the application. The two edit boxes will need a username and password input. These data inputs can be captured to check against any SQL database of choice. The proposed design will allow user to click and changed, allowing multiple profiles to be access. The choice to use these UI features are based on several factors:

 Example Log in Screen using typical Android layouts.  Interactive gestures can be recognised with ease. For example, a user touching the edit box to change current display text.

 It allows data to be easily captured and checked access any SQL database of choice.

Figure 15 - High and Low Fidelity Designs of Login Activity

4.5.3 Mapview Activity This is the main activity of the application as it is allowing user to display current location, other map related functions and the stated navigation drawer. The map fragment, which takes up majority of the UI, allows the user to use a series of google default functions that is integrated on their own mapping application. Features, such as Zooming and my location, can be gestured to access and change the map. The map itself will display a series of other features such as:

 See Current Location  Nearby Beacons The application aim is to allow the user to navigate through an indoor environment. Features, such as selecting the floor level, will be important and only visual when parameters are true.

38 Using Smartphone technology to simulate human behaviour within an indoor environment

When first loaded on the activity, the map fragment will display with the following identified functions. The current location will be also loaded on first loading. This activity is heavily impacted by google themselves and aims to provide a simple design with an additional aim of provided accurate location input. The map fragment with its additional features will utilise methods that are by default developed when using Android Studios. On the other hand, the beacons are supported by android beacon library with methods shown within example code on the android Beacon library website. (http://altbeacon.github.io/android-beacon-library/)

Figure 16 - High and Low Fidelity designs for Mapview Activity

4.5.4 NFC Activity This is another activity that is a significant feature within the identified requirements. The interface utilised the NFC functionality within most up-to-date smartphones. Set by the requirements, a NFC tag needs to be scanned and display its current data so it can be viewed and/or re-written. No UIButtons will be used to start the scan but will be activate within the onCreate method. Buttons and Edit boxes will only be used once NFC signal is received and data is read. A clear all button will allow the activity to be reset to default layout.

The methods and classes needed for this activity will be used from a tutorial. (http://www.codexpedia.com/android/android-nfc-read-and-write-example/)

39 Using Smartphone technology to simulate human behaviour within an indoor environment

Figure 17 - Low and High Fidelity Designs for NFC Reader/Writer Activity 4.6 Next Step & Conclusion The requirements have now been structured into a series of structured diagrams and visual designs. The designs completed highlight the core functionality of the application. A basic level of testing has been completed to see if each added part works at a basic level and show promise for any future work. The next step in the development process is, now, implementation.

40 Using Smartphone technology to simulate human behaviour within an indoor environment

5 Implementation

5.1 Introduction This chapter outlines the implementation of the project. This chapter will be used not to cover the entire implementation completely but only key areas that was either problematic or interesting from a developer point of view. This chapter will also consist of the challenges that was faced when creating the application for the android platform.

5.2 Indooraltas SDK For the application to establish the device locations and display floorplans on to a map fragment, the SDK must be implemented. Implementing the SDK within the code is easy as the company offers a simple tutorial to follow to integrate its code. However, the implementation can bring its challenges. One of the issues discovered was based around the compiling the application. Android Studios offers a host environment to simulate the application on to an Android environment but simulate location within an emulator can be problematic so the testing was all done on a real-life smartphone, Sony Xperia Z5 Compact (high-end phone) and Motorola Moto G 1st Gen (Low-end phone).

During the background research, Indooraltas show that implementing their SDK was easy to do and was identified as the primary kit to use for the application development. The easy to understand instructions and tutorials showing how to integrate the SDK made it an easy choice in the end. However, the tutorial (http://docs.indooratlas.com/ explain some key sections that needed to implemented. These issues was basedout of arounddate and the didn’t SDK itself makes the development of the application challenging.

5.2.1 Implementation SDK Before implementing any Java within the application, Indooraltas requires the developer to create a floor plan based around a location of their choice. The Test location that was used for the application was Brunel University Lecture Centre Entrance area; a relatively small area. Developing the Floor plan was this area become problematic during the collection of sensor data to enhance the accuracy in the environment. The interesting part of this was that it was done via another android application, called MapCreator 2. Indooraltas based their development of any application using their SDK under four steps: 1. Create Location & Add Floor Plan 2. Map Location 3. Manage Map Data

41 Using Smartphone technology to simulate human behaviour within an indoor environment

4. Build App

Figure 18 - Floorplan inputted into Indooraltas

Within figure 18 is the floor plan added on to the Indooraltas framework. For this dissertation, the area that was tested needed to be a small area which is available to a mass amount of the public. For this reason, the lobby area within the lecture centre at Brunel University was used as Student and Staff of the university walk through this simple area every day. Once uploaded, the developer needs to develop waypoints and paths

tocurrent record location so that withinapplication the indoor can follow environment. when placi A ngmi nimumthe user’s of two waypoints needs to be added to the floorplan before the path can be record. The interesting part of this application is that to record the paths, you simply only need to walk from waypoint to your destined end goal. With every generated floorplan, a unique ID is associated with it and this ID is used to Figure 19 - Waypoint and Paths created through the MapCreator access the floorplan to be overlaid on the same coordinators as application suggested through the ID.

The methods involved in initialising the Indooraltas SDK, which includes the locationlistener, and Google Map framework are as follows.

Google Map framework involves some default methods that added within Android Studio when the activity is used. All these default methods, such as onResume, are initialised when activity starts. The initialisation of the map and LocationManager allocated a segment of memory to work in, and is told to start updating the location. This is where the Indooraltas SDK is used. The LocationManager request a location updates where the user current Latitude and Longitude is found. Within the onLocationChanged method, where the marker is created, this is where these two figures are assigned to a variable which is assigned to the markers object. Each time a new

42 Using Smartphone technology to simulate human behaviour within an indoor environment location update is received from the LocationManager, this method will be called. This is where the SDK will change the location data each time it is received.

Figure 20 - OnResume Method where map is initialised

Figure 21 - locationListener used to update Latitude and Longitude

Figure 22 - onLocationChanged method used to set the location of the user on the map

The uploading of the floor plans is also initialised when the activity first loads. Within this application, only one floorplan is accessed, Brunel University Lecture Centre, via the ID when is given by Indooraltas. The floorplan is only visible when the Regionlistener notices the user is close and/or entering the area in which the floorplan coordinators are located are at. The floorplan uploaded onto Indooraltas is converted into a Bitmap, which means the image when moved across onto any map will not look stretch or out of place. From the result of fetching the

43 Using Smartphone technology to simulate human behaviour within an indoor environment floorplan for the web server, which all floorplans are stored, The bitmap image is centred on the coordinator and placed on the map, once the user is registered close enough to the location.

Figure 23 - FetchFloorPlan method

Figure 24 - setupGroundOverlay method

This process is repeated until the user either moves over to other features or exits the application. If other features, such as NFC Reader/Writer, is accessed, then the onPause methods is accessed and, as the method suggests, pauses any processes within the activity. Otherwise, the onDestroy method is accessed and kills all processes. All data shown within the map is discarded until activity is loaded once again.

5.3 Implementation of Other features Some of the significant features that are being developed onto the application are as below. Developing Beacons and NFC functionality required learning as these are being relatively new areas of research, especially NFC and tags. Implementing both the beacons and NFC with the application involved following tutorials, which will be included within their respective sections.

5.3.1 Implementation Beacon Support Following the tutorial, (38), enabled beacon support was also simple to understand. The methods are accessed via the onResume method and run when the map is first initialised. The BeaconManager required an additional segment of memory when initialised. When initialised,

44 Using Smartphone technology to simulate human behaviour within an indoor environment

BeaconManager continuous searching for any beacon signal which uses the Eddystone UID layout. Once a signal is found and its respective ID identified, the signal is identified as a marker within the map, as well as a short message for a short duration will appear.

Figure 25 - Snippet of code onResume method. The area within the red border is the identified code for the Beacon Implementation.

Figure 26 - Snippet of Code showing how beacon is noticed and implemented

As these methods appear within the same activity as the core functionality, the process is also repeated until the activity is either paused and destroyed. All data shown within the map is discarded until activity is loaded once again.

5.3.2 Implementation NFC Reader/Writer Understanding NFC was a little harder to implement as reading and writing onto a tag required multiple different methods. As previous mentioned, following a tutorial (39) was key to understanding how to implement this technology within the application.

Once this activity loads, the first process that is done involves checking if the device in use has NFC and/or NFC activated. If NFC is not activated, an error message will appear sending the user to the wireless settings within the device. The method readFromIntent is initialised when the activity first loads but only works if the NFCAdapter is equal to the Intent action. If NFC is

45 Using Smartphone technology to simulate human behaviour within an indoor environment activated correctly, the NFC tag is read and built via buildTagViews method. The information within the tag appears within a label.

Figure 27 - Code Snippet showing how NFC is detected

Figure 28 - Code Snippet showing initial read phase

The Tag can be rewritten through the write method which simply creates the instance of the tag, overrides message which is inputted within the edit box object. This process is only activated by appear.the user touches the Write button. With the same tag signal is seen, the rewritten text will

Figure 29 - Code Snippet showing initial writing phase 5.4 Rapid Target Test

currentOne of the location identified marker. issues As thatnot discoveredcame across during was z oomingbackground in on research, the area aroundthe typical the wayusers’ of for zooming in required thezooming compiled in wasn’t and testing working, on the testingtarget environment, of multiple didn’t real worldalternatives device. Rapid testing showed errorthat the that application was discovered had issues either with showed initialising the map the wou user’sld only location zoom when in on map a random is zoomed area in. but The not With identifying this error, it also identified the need for withresearch the user’son alternative location methodsmarker. of zooming in.

46 Using Smartphone technology to simulate human behaviour within an indoor environment

5.5 Implementing the User Interface Although, Android application are deployed to an Android device using the Android Debug Bridge and installing it onto the device. This section is about showing the interface implementation and the key features behind these interfaces.

The application is written in Java but the compilation process for Android application is very different. The Interface is developed within XML. One of the useful features within Android Studios as it allows the developer to literally drag objects on the screen. This creates an easy environment for any developer, from beginners to experts, to create a professional Android user interface.

For an Android application to be deploy on to a device, the class files and the resources from the application, which includes images and layouts, are compressed into a zip-like file referred as apk file, Android Package. This file can then be deployed and ran to be tested and used. Using the Interface tools allowed a clear layout to be developed during a short time scale. However, many issues arose which applied to the changing how the application would look after an action or event took place. This refers to the NFC Reader/Writer feature of the application. For this reason, the use of multiple relative layouts with unique IDs was used to allow UI objects to be pressed and removed though the associated class files. This removed creating multiple interfaces for the same activities.

This section outlines the work required to move the design stage to final implemented interfaces.

5.5.1 Log in Interface As identified during the design phase of the user interface, this interface will utilise a series of objects:

 Image View  Edit Boxes  Buttons  Labels These objects are easy to implement as the developer can simply drag and drop these objects. In terms of development of this interface, there is very limited implementation besides assigning visual characteristics through the properties and/or within the associated XML file and, any processes linked to other activities.

47 Using Smartphone technology to simulate human behaviour within an indoor environment

The shown code demonstrates how a clickable object can send user to another activity. For example, the log in Activity to mapview activity via click event. The button object within this thatactivity important initialises for a the method application which butvalidates lays the a usebacr’skbone username for a server and password. to be integrated This method later. isn’t

Figure 30 - Code Snippet showing button click event

Below shows the progression of the UI from the low and high fidelity designs to the implemented UI running on an Android device.

Figure 31 - Login Activity Evolution

5.5.2 Map View Interface This is main user interface that is the user will be interacting with. For this interact to follow the requirement gathered, the interface needs to follow typical android interfaces as displayed though the existing solutions. Due to this, the interface, as display within the designs, will consist of a navigation drawer and only interface buttons only allowed through the map, for example zooming and buttons.

5.5.2.1 Navigation Drawer This part of the interface is key to allowing the user to access the only features. Android Studio as with any type of activity allows the developer to open a new activity with the default XML and class files needed. As established in the design phase, this feature within the User Interface will utilise the same files which can be produced when creating the activity through Android Studio. One of the main XML files which was changed was called activity_mapview_drawer, as

48 Using Smartphone technology to simulate human behaviour within an indoor environment shown through the figure below. In terms of development, there is very little implementation involved as it is all done via Android Studio default options. Colours, fonts and images was the only thing changed of note. The code below loads when the activity is first loaded and initialised the declared names and associated images.

Figure 32 - XML Code Showing menu list structure

5.5.2.2 Mapping Fragment The map fragment is, compared to every other feature, is the most improve feature as it shows the implementation of both SDK and rela the navigation drawer. Android Studios alsoted haslibraries. an activity To implement with default this Java wasn’t and as XML easy code as with to follow. Implementing the map fragment with the Navigation Drawer involved produced the code from both activity and combining them together.

Figure 33 - Fragment within Navigation Drawer XML Code

As displayed above (Figure 22), the Fragment which implemented in the correct file, content_mapview, allows a map to be display. For the map to physically show up, the API key needs to be placed within the values folder.

49 Using Smartphone technology to simulate human behaviour within an indoor environment

To allow the user to navigate easier through buildings and open areas, the basic UI features was included through the initialisation of the map on first loading. The implementation UI features are all default on Google Maps (my location, zoom controls and floor level picker).

Figure 34 - Highlighted area within code snippet show UI features on Map Fragment included.

5.5.2.3 Final Implemented View Below shows the progression of the UI from the low and high fidelity designs to the implemented UI running on an Android device.

Figure 35 - mapview Evolution

5.5.3 NFC Reader/Writer Interface The implementation of the User Interface involved a lot of trail and errors as this activity needs to be show two completely different views. These views are shown within design phase and involved the inclusion of multiple UI features which need the visibility changed so that the different views can be seen:

 Labels  Image view  Edit boxes  Buttons

50 Using Smartphone technology to simulate human behaviour within an indoor environment

Figure 36 - Java Methods to set UI features visibility

Below shows the progression of the UI from the low and high fidelity designs to the implemented UI running on an Android device.

Figure 37 - NFC Activity Evolution

51 Using Smartphone technology to simulate human behaviour within an indoor environment

5.6 Testing During the implementation phase, a series of testing approaches have been applied. These methods will allow the application to deliver its expected functionality and at an expected performance level. This section will outline the methods used to ensure that the application will met its requirements, set within chapter 3, and perform effectively.

5.6.1 Requirement Verification The following process aims to ensure that an application meets the requirement set before implementation. As shown within the appendix, this log will display the set requirements and whether the requirement as passed or failed. Within the appendix, the passed requirements will be highlighted in green and the failed requirements will be highlighted in red. The requirements that have failed will be discussed within the following section.

5.6.2 Requirement Failures Of all the listed requirements stated within chapter 3, 17 of the requirement was considered as failed with 1 of these requirements (No. 16)

- Requirement 16 is basedwas classified around scanning as Significant and adding and the a marker rest being to the mapclassified of the as beacon Non Vital. location. This requirement was part completed as the application, once on the mapview activity, searches for Bluetooth based devices but is unable to add a marker to the map based on the its location. For this required to be succeed, a MySQL database is needed for the locations to be stored on as the locating of beacon through code is impossible. The database can store the location of the beacon with its unique ID. Simply down to timing constraints within the development of the project, these requirements can be only completed beyond the scope of the application development.

Since this dissertation was based around the development of an end application, these failed requirements would have added significant value to the end development of this project but was out of scope for the project based on the time scale of the project. - requirements would be important if the application is going to be releasedThese as Non a commercialVital product. Due to the scope of the dissertation, these requirements are not important for the implementation of this application.

52 Using Smartphone technology to simulate human behaviour within an indoor environment

5.6.3 Performance Testing Performance testing for any application is critical for success. This is no different for an Android application as the phone itself has limited memory and processing power. Obviously, the better the phone, the more memory and processing power can be used. Compared to iPhones, each Android application runs in a separate process within its own Dalvik instance, relinquishing all responsibility for memory and process management. This, in turn, stops and kills processes as necessary to manage resources. As the aim of this project is create an Android application which can allows the user to navigate within an indoor environment, ensuring the application is al errors related to performance is critical to the project.

durable and doesn’t experience any fat The development of the application will be created on Android Studio, which has a built-in Monitor which allows developers to optimize, debug and improve an application performance. The monitor allows the following aspects of any application from devices or the Android Emulator. As previously mentioned, many issues arose when testing the application within the emulator. For this reason, the performance testing of the application was done on both low end and high devices.

The performance monitoring allows the following aspects to be looked at: Monitoring Aspects Can be used for? Memory Usage Find deallocated objects, locate Memory leaks, and tracking amount of memory the device is using. Central Processing Unit Display usage in real time and Percentage of total time used in (CPU) Usage user and kernel mode Graphics Processing Unit Shows how much time it takes to render the frames of a UI (GPU) Usage window. Table 13 - Features that can be noticed via Android Monitor (Android, 2017)

From a Software Engineering point of view, android code smells are bad implementation practices within application that may lead to poor software quality, especially in terms of performance. (28) For this reason, performance of the application has been the main concern of the application development. When referring to code smells, bad practices could refer to (33)

 Large Classes  Duplication  God Class  Coupling  Distorted Hierarchy

53 Using Smartphone technology to simulate human behaviour within an indoor environment

 Etc. This section will discuss the performance testing which applied to this application and evaluate the results.

5.6.3.1 CPU Testing The two devices that will be used for testing can handle completely different levels of processing power. The high-end android device, Sony Xperia Z5 Compact, features a 64-but Qualcomm Snapdragon 810 processor with four cores running 1.5 GHz and four at 2 GHz. (Sony, 2016) Compared to the available phone in the present day, this phone can handle relatively large processing power. The low-end android device, Motorola Moto G 1st Gen, is the complete oppose as it features 1.2Ghz quad-core Qualcomm Snapdragon 400 processor. This device can handle much less, in terms of processing power. For this reason, testing the application CPU performance is critical for all devices to be able to run the application without issues. The figures below show the CPU monitor log for a running time of one minute. The graph below is defined under two terms. The lighter red graph refers to the User load (the application and libraries used) and the brighter red refers to the kernel load (OS load).

2 3 1 1

Figure 38 - CPU of high-end device under test scenario

2 1 1 3

Figure 39 - CPU of low-end device under test scenario

The above figures highlight three key event which happens during the test scenario on the CPU. At event 1, the application was loading from the device, which means the loading of the interface, XML files, establishing all objects and initialising the activity on the device screen to be seen. For this reason, an increase in CPU usage is expected, as the device is loading all related data that is required to load the application. The reading between the devices is similar and expected.communicate The betweenkernel reading multiple is much hardware lower until than event expected 2. Event but 2the refers OS isn’t to the required loading to of the mapview via the press of the login UI button on the previous activity. A CPU sudden increase is expected as the application is initialising the map fragment, navigation drawer and other UI features, such as UI map features and toolbar. Once this is completed, the CPU usage

54 Using Smartphone technology to simulate human behaviour within an indoor environment dramatically drops. Event 3 refers to the device getting a location fix on the user device and initialising Bluetooth adapter to scan. The kernel reading is expected to increase as multiple hardware is used but the usage will down once both are completed. Any following CPU spikes are referring to the application f facilities. inding the user’s new location and any Bluetooth devices in the

The highest percentage CPU reading refers to event 2 as multiple. At this point the two devices are showing two different percentage values, which was unexpected. This could be for a number reasons such as the device finding it hard to load the interface to the background application causes the device to find it harder to run any application. After this point, the application remains at a low reading which can be handled by many android devices.

5.6.3.2 GPU Testing The two devices used for the testing also feature two different levels of Graphic Processing Units. The high-end device features the Adreno 430, whereas the low-end device features the Adreno 305. As expected the two devices has two different levels of performance. As the running the User interface is critical for the project, testing how each device reacts to the loading of the UI properties is important and using of UI features.

2 3

1 4

Figure 40 - GPU reading of high end device under test scenario

2 3

1 4

Figure 41 - GPU reading of low end device under test scenario

The above figures refer to four key events which takes place during the same test scenario used within the CPU testing. GPU reading allow visual representation of the time taken for frames to render within an UI window. f a username and password in edit boxes on the Login Activity.Event This eventrefers isto muc the huser’s more input noticeable o on the low-end devices and further code optimization is needed to reduce the delay. This is followed by event 2, which refers to the pressing on the login UI button. A GPU spike is expected as multiple methods need to be initialised and ran to completion. This will be needing optimization also once a server connection is adding within the application. Events 3 and 4 refer to UI features within the map

55 Using Smartphone technology to simulate human behaviour within an indoor environment fragment. Event 3, the sudden GPU spike, refers to the map fragment initialisation as well as the

myto interactive location withfunction the mapappearing fragment. on map. The Eventlittle GP refU increasesers to the are zooming caused U) by buttons the map being fragment used loading different map segments.

The application only contains core functionality and will be affected once a server is connected - GPU data is important to toreduce application, the and other Significant and Non Vital requirements. devices. If futureaffect workextra codeis carried has on out, the this application’s would have efficien to be keptcy and in mind.performance on real world

5.6.4 Beta Testing Since the application only includes core functionality without a server and/or database supporting the profiles created by potential users, it is not possible to release the application to the public via the play store to gather users feedback. For this reason, beta testing is out of the scope for this project. This would be step for the future if the project was continue passed this year.

56 Using Smartphone technology to simulate human behaviour within an indoor environment

6 Results & Evaluation

Within chapter contains the key results that had emerged from the testing of the application. The designing and development of the application has resulted in the following points:



 )mprovingUsing both accuracyhost and oftarget )ndoorAtlas’s environments SDK  Guidelines for creating application using Indooraltas SDK

6.1 Application Accuracy During the testing of the application with both high-end and low-end devices, the current location of the user was very inaccurate and/or incorrect. The marker would jump between points. Due to this, multiple approaches were consisted from a development point of view and through hardware as followed:

 Creating a simple algorithm to cancel out inaccuracy  Using Multiple Hardware (Future Work) Under the restriction of time, only the algorithm was added to the application to aid in producing a more effective location reading. The algorithms using the following points was included:

 If the longitude and/or latitude accuracy of the updated location is a negative value, the location is discarded, as the location is clearly wrong.

 If the longitude and/or latitude accuracy of the updated location is less than desired accuracy, the location is discarded, as the location is inaccurate.

 If the updated location is more accurate, the previous location is discarded and the new location used instead. These simple steps when implemented within the application will aid in improving accuracy and removing inaccurate data points being using instead.

6.2 Host and Target Environment Especially during rapid testing, implementing the application on host environment, Android Simulator, has displayed some issues towards the application. This application is based around displaying location accurately and this was one of the highlighted issues which resulted from testing. The Simulator, while it is good in showing the User Interface, has issues in displaying location as with the target environment GPS via Wi-Fi and mobile network can be used. To ensure that the project developed an effective application, using iterative testing between host and target environments will allow the location issue to be solved as well as other highlighted challenges in development.

57 Using Smartphone technology to simulate human behaviour within an indoor environment

Host (Android Target (Android Simulator) Device)

 Simulation of  Real-life android Android platform Iterative platform Testing  Debugging UI  Debug all features features without  Includes location location based based sensors services  Lacks device sensors

Figure 42 - Android Development Choice

Due to these highlighted issues, most of the testing was completed on the target environment instead with some UI features being tested on the simulator. When applies during testing, it helped in improved both UI and location based features of the application.

6.3 Guidelines for creating application

Therefore,The development the development of the application of the application was based wasaround based the around use of )ndooraltas’sthe use of their Android guidelines SDK. and tutorials on using their built-in features. The SDK implements Android features, such as Google Maps, using their own framework. While development, a series of issues was discovered which was highlighted during earlier phases in the project. One the first discovered issues was based around the waypoints and paths within the application. This is a critical function within the application. Indooraltas do give instructions on help to use the android application, MapCreator -tracking points and how the

,floorplan to aid in needs floorplan to be creation as accurate but don’tas possible. give any warning on geo

Developers should and/or need to have a form of an understanding of when developing a floorplan, as this would affect the end-result. Thus, it is recommended to follow the same steps, as mentioned within the implementation chapter, to allow accuracy generation of floorplans.

As not mentioned by Indooraltas, developers

accurate readings. Indooraltas does mention thatshould it has realise an accuracy that the ofSDK 1 and doesn’t 3 meters always but provide in

multiple occasions, this wasn’tork, itthe is recommendedcase. When deve toloping follow their the same application steps as around highlighted the within )ndooraltas’ssection 6.1. SDK framew

58 Using Smartphone technology to simulate human behaviour within an indoor environment

6.4 Application Evaluation With the application is now developed and tested, the next step is to evaluate the application to see how well the application performances, during live use. The applications features no memory leaks, and uses a low CPU and GPU resources within the tested devices. Following this, the application has been tested against applications with similar purpose within the real world, as mentioned with chapter 2. The results are displayed below. High-End Device Low-End Device App Load Time GPS Fix Battery Load GPS Fix Battery Usage Time Usage Project ~1s ~2 8% ~2s ~3s 10% Application Google Map ~1s ~1s 9% ~2s ~2s 13% Table - Tested Over 30 minutes on both devices under the same conditions and both under the map initialisation scenario.

Compared against other application, the application is very lightweight but this is since the developed application only includes core functionality. This might change when all functionality tor for completion, especially isdatabase included inclusion. with the application when time isn’t as much as a fac

One of the main issues of the application is based on getting the user location as accurate as possible. Based from the results, it is also clear the application needs improvement on getting a location fix and updating the location. The map and markers, when the map activity is loaded, is one of the first things to initialised. wanted. This could be for several reasons,From this as state conclusion,d as followed: the application isn’t as accurate as  Gathering location data is affected by the indoor and outdoor environment that surrounds the user. The application is tested within a simple indoor environment but the application will be affected differently under different environment. Especially with indoor environment, less signal to Wi-Fi and other network technologies will affect the accuracy of the data.



AndroidThe application platform has and been Java. developed Having experience with limited with kno thewledge stated of will, the )ndooraltas’sin turn, aid in SDK,the creation of a better application.

With the developed application only containing a core application, it is hard to fully test and compare to other application with similar functions. This application contains a much less in

59 Using Smartphone technology to simulate human behaviour within an indoor environment terms features that are available already on the google play. Further development would be needed to bring it up to specification with the requirements.

When discussing the application in terms of this dissertation, this application gives an insight in the requirements needed to design and develop an application on the Android platform. This application gives an insight of the issues that faces a developer when wanting to create an application with the same aim and objectives.

7 Conclusions

Within this final chapter, it will outline the important finding from each of the previous chapters and a reflection on the project. As this project is restricted in terms of scope, a series of potential areas of future work and research have been identified.

7.1 Project Overview For any project to start, a set of objectives and an overall aim needs to be set so the project has a goal to go for. This is all with in chapter 1. With the project following a linear approach, an initial review of all previous work via papers and journals and some existing solutions on the Android platform already. From this, one of the key considerations identified through this was the environment in which the application will be based on and how to enhance this kind of application to benefit the user and the developer. The literature highlighted some key important aspects which was impossible to fully implement until the strict time scale. An example of this is based around understanding and implementing beacons usages, which played very little part within development of the application. The literature review also identified external SDKs and the benefits of using each one to support the development of the application. Following further literature, it was clear that the use of different network types can have an extreme effect on the accuracy of the location within the application. One of the final key aspects was based around NFC. Again, full implementation was impossible under the scope of the project but the literature identified the usage of NFC which can be implement at a future date.

From all the knowledge gathered during the review, the identification of requirements, both functional and non-functional, took place. The mass of the requirements was gained through further literature reviews but in this case, surveys and statistics. Using the statistical data gained, it identified what potential users of the application was used to from a UI point of view. This kind of statistic data was important to understand the type of individual the application will be used by. For the future of this application, user participation would be beneficial as the application potential audience would allow further requirements to be found. For the scope of

60 Using Smartphone technology to simulate human behaviour within an indoor environment the project, user participation ndix. Many more of the requirements was gathered throughwasn’t existing needed, solution as showns based with appeon the Android platform and on a larger scale through RTLS in Hospitals. As this dissertation is aimed on creating a location-based Android application, deriving requirements from existing solutions allowed the application to reflect actual application from a UI and function based point of view.

Following this phase, the architectural and User Interface was designed so that a clear base was stated before development. The design phase of this project ensures that the application is formalised before development of the application can go forward. The implementation phase was where all the key aspects identified within the designs are performed to create an application to support both Android platform and Indooraltas framework. To improve the performance and efficiency, the application was tested with results being evaluated. From the testing and evaluating the results, a series of improvements was made to help both the accuracy of the location and the performance of the application on the Android platform. The results shown some key areas in which the application needed improving. One of those key areas was based on the use of iterative testing. This approach became very useful when making changeseffective totesting the U) within and map a timely interface manner. respectively. With thos Tehe improvements, normal waterfall a series approach of guidelines didn’t enable from usingThe results )ndooraltas’s from this SDK, project as well will as provide a basic a algorit small hminsight to remove to any inaccurateAndroid developer, location coordinates.with the additional of improving the performance of the application.

At the very beginning of the project, the aim was clearly mentioned, which is to develop an Android application that is capable of allows a user to navigate within an indoor environment. When looking back at this aim, the project has been a success but only touches the surfaces of this idea. Developing this application highlighted the possible uses and technologies involved but again, technologies, such as indoor mapping, NFC and Beacons, have only been used at a basic level and lacks the proper understanding to advance the project. All aspects of this application needs improvement and/or further development, especially the technologies stated above. The project has only served at highlighting novel solutions to help in solving problems associated with other mapping application. Using and modifying Indooraltas SDK to improve the following areas:

 The changes made enabled the application to run more efficiently and, in the process improve more accurate location based data within an indoor and outdoor environment.

 The changes can be also used to modify other map based developments.

61 Using Smartphone technology to simulate human behaviour within an indoor environment

Overall, the general feeling that is that the project has been a success in a small extent but needs more time to prove hundred per cent successful as the project underlining technologies involved has only been touched upon at a very basic level. For the application to enter beta testing at a minimum, further work is needed.

7.2 Future Work Below are areas of further development which can improve the application significantly.

7.2.1 Further Development As previously stated and presented through the designs phase, the implementation only touches the surface of the core functional. One of the biggest areas in which was scoped out of this project is server support. For the application to be ready for beta testing at a minimum, the use of an external server so profile, beacon and location based data can be stored is ensure for application to work on a larger scale. As shown through the requirement testing, many of the requirements was not completed.

Through the additional of further functionality within the application, the optimisation of the code will need to happen as the effects of further implementation will affect the performance of the application on real world devices.

7.2.2 Location-based Enhancements The solution used within this dissertation only provides a small practical insight into mapping a to enhance the user’s outdoorSDK and involvement indoor environments. and efficiency. This Furtherapplication research can be sh builtould upon be performed into the )ndooraltas’s creating an accurate marker based on the user’s device. Possible areas of research could involve using multiple network types to local a user’s location. Beacon support was only included on a core level with a dumpy location access to it to show that in principle it works. Further development is needed so that the location of different beacons are stored on a server in which the application connects to when needed. Further research needs to done on what information can be stored on the beacon and/or the best methods to stored and access the information.

62 Using Smartphone technology to simulate human behaviour within an indoor environment

7.2.3 NFC Enhancements Within most up-to-date smartphones, NFC is relative new technology which can be stored on NFC tags and accessed and rewritten when scanned. The application only consists of the core functionality. Further research needs to be performed on what kind of data can be stored on the tags and kind of formats, such as tables.

7.2.4 Human Computer Interaction With any device, such as the smartphone, the use of human communication is mostly interactive. Smartphones support a large range of multi-touch gestures and communication channels. This dissertation only touches the basic into interactive technique a smartphone can deploy. For this reason, future work is needed to provide the user with an intelligent User Interface and as well as utilises the android libraries available to the target environment.

63 Using Smartphone technology to simulate human behaviour within an indoor environment

References

1. Gary Sims. (2016). I want to develop Android Apps – What languages should I learn?. Available: http://www.androidauthority.com/want-develop-android-apps- languages-learn-391008/. Last accessed 26th March 2017. 2. Jill A. Fisher, Torin Monahan. (2012). Evaluation of real-time location systems in their hospital contexts. International journal of medical informatics. 81 (5), p705 712.

3. Tutorials point. (2016). SDLC - Waterfall Model. Available: – https://www.tutorialspoint.com/sdlc/sdlc_waterfall_model.htm. Last accessed 26th March 2017. 4. Alfred Kleusberg & Richard B. Langley. (March 1990). The Limitation of GPS. Innovation. 1 (2), p1-3. 5. Kegen Yu, Ian Oppermann, Eryk Dutkiewicz, Ian Sharp & Guenther Retscher. (2014). Indoor Navigation and Tracking. Physical Communication. 13 (1), p1-3. 6. Shaun K. Kane, Jacob O. Wobbrock & Ian E. Smith. (2008). Getting Off the Treadmill: Evaluating Walking User Interfaces for Mobile Devices in Public Spaces . Proceedings of the 10th international conference on Human computer interaction with mobile devices and services.. 10 (12), p109-118. 7. Shigeru HAGA, Ayaka SANO , Yuri SEKINE , Hideka SATO , Saki YAMAGUCHI & Kosuke

MASUDA.walking. Procedia . EffectsManufacturing of using. a3 smart(564), phonep2575-2580. on pedestrians’ attention and 8. Lumsden, J., & Brewster, S. 2003. A Paradigm Shift: Alternative Interaction Techniques for Use with Mobile & Wearable Devices. Proceedings of the 2003 conference of the Centre for Advanced Studies on Collaborative research, Toronto, Ontario, Canada 6-9 October 2003, pp.197-210 9. Joseph Luk , Jérôme Pasquero , Shannon Little , Karon MacLean , Vincent Lévesque , and Vincent Hayward. (2006). A Role for Haptics in Mobile Interaction: Initial Design Using a Handheld Tactile Display Prototype . Proceedings of the SIGCHI Conference on Human Factors in Computing Systems. 6 (21), p171-180 . 10. Megha Goyal, Dimple Saproo, Asha Bagashra, Kumar Rahul Dev. (2013). Haptics: Technology Based on Touch. International Journal of Scientific Research Engineering & Technology (IJSRET). 2 ( ), p468-471. 11. Siltanen, S., Woodward, C., Valli, S., Petri, H., & Rauber, A. 2008. User Interaction for Mobile Devices. Multimodal Processing and Interaction, 33(4) pp.1-17.

64 Using Smartphone technology to simulate human behaviour within an indoor environment

12. Google. (2016). Position Sensors. Available: https://developer.android.com/guide/topics/sensors/sensors_position.html#sensors- pos-prox. Last accessed 26th March 2017. 13. infsoft. (2017). Indoor Navigation. Available: https://www.infsoft.com/solutions/indoor-navigation. Last accessed 26th March 2017. 14. Bin Hu. (2013). Wi-Fi Based Indoor Positioning System Using Smartphones. . ( ), p1-77. 15. Techwalla Editor. (2017). Disadvantages & Advantages of Using the Google Maps Website. Available: https://www.techwalla.com/articles/disadvantages-advantages-of- using-the-google-maps-website. Last accessed 26th March 2017. 16. Versustech. (2016). Case Study. Available: http://www.versustech.co.uk/rtls-case- studies/johns-hopkins-hospital/. Last accessed 26th March 2017. 17. john DeGaspari. (2012). RTLS for Asset Tracking and Staff Location. Healthcare Informatics. 18. Panos Papageorgiou. (2014). Android Studio vs Eclipse: What are the main differences?. Available: http://www.avocarrot.com/blog/android-studio-vs-eclipse- main-differences/. Last accessed 26th March 2017. 19. Indooratlas. (2016). Home. Available: https://www.indooratlas.com/. Last accessed 26th March 2017. 20. Ruth Malan & Dana Bredemeyer. (1999). Functional Requirements and Use Cases. ARCHITECTURE RESOURCES For Enterprise Advantage. ( ), p1-10. 21. Blackler, Alethea Liane (2009) Applications of high and low fidelity prototypes in researching intuitive interaction. In: Undisciplined! Proceedings of the Design Research Society Conference 2008, 15-19 July 2008, Sheffield Hallam University, Sheffield 22. Bernhard Jenny & Nathaniel Vaughn Kelso. (2007). Color design for the color vision impaired. Cartographic Perspectives. 58 (3), 61-67. 23. Rhiannon Williams. (2016). Android roars back in strongest growth in two years, as iOS shrinks. Available: http://www.telegraph.co.uk/technology/2016/05/17/android- roars-back-in-strongest-growth-in-two-years-as-apple-shr/. Last accessed 26th March 2017. 24. ofcom. (2016). CMR Facts & Figures 2016. Available: https://www.ofcom.org.uk/__data/assets/pdf_file/0021/12828/facts-figures- table16.pdf. Last accessed 26th March 2017. 25. Statista. (2015). Number of smartphone users in the United Kingdom (UK) from 2011 to 2018 (in millions). Available: https://www.statista.com/statistics/270821/smartphone- user-in-the-united-kingdom-uk/. Last accessed 26th March 2017.

65 Using Smartphone technology to simulate human behaviour within an indoor environment

26. Statista. (2016). Global smartphone sales by operating system from 2009 to 2016 (in millions). Available: https://www.statista.com/statistics/263445/global-smartphone- sales-by-operating-system-since-2009/. Last accessed 26th March 2017. 27. Deloitte. (2016). There's no place like phone. Global Mobile Consumer Survey 2016: UK Cut. p1-65. 28. Geoffrey Hecht, Naouel Moha & Romain Rouvoy. (2016). An Empirical Study of the Performance Impacts of Android Code Smells. MOBILESoft '16 Proceedings of the International Conference on Mobile Software Engineering and Systems. 3 (20), p59-69. 29. N. Pritt, "Indoor location with Wi-Fi fingerprinting," 2013 IEEE Applied Imagery Pattern Recognition Workshop (AIPR), Washington, DC, 2013, pp. 1-8. 30. Google. (2016). Android Monitor Overview. Available: https://developer.android.com/studio/profile/android-monitor.html#monitors. Last accessed 26th March 2017. 31. Sony. (2016). Sony Xperia z5 Compact. Available: https://www.sonymobile.com/gb/products/phones/xperia-z5-compact/specifications/ . Last accessed 26th March 2017. 32. Versus. (2016). Qualcomm Adreno 305 vs Qualcomm Adreno 430: 8 facts in comparison. Available: https://versus.com/en/qualcomm-adreno-305-vs-qualcomm- adreno-430. Last accessed 26th March 2017. 33. Umme Ayda Mannan, Iftekhar Ahmed, Rana Abdullah M Almurshed, Danny Dig & Carlos Jensen. (2016). Understanding Code Smells in Android Applications. Proceedings of the International Conference on Mobile Software Engineering and Systems. 16 (41), p225- 234. 34. Sagar V. Ramani & yagnik N. Tank. (2014). Indoor Navigation on Google Maps and Indoor Localization Using RSS Fingerprinting. International Journal of Engineering Trends and Technology (IJETT). 11 (4), p171-173. 35. IMPINJ. (2016). Asset Tracking Case Study: King Hamad University Hospital. Available: http://resources.impinj.com/h/i/10909053-asset-tracking-case-study-king-hamad- university-hospital. Last accessed 26th March 2017. 36. RFID Discovery. (2016). NHS Forth Valley Case Study. Available: http://rfiddiscovery.com/wp-content/uploads/2015/07/NHS-Forth-Valley-case-study- for-website.pdf. Last accessed 26th March 2017. 37. Sommerville, I. 2004. Software Engineering (7th Edition), Pearson Addison Wesley. 38. Radius Networks. (2016). Example Code. Available: http://altbeacon.github.io/android- beacon-library/configure.html. Last accessed 26th March 2017.

66 Using Smartphone technology to simulate human behaviour within an indoor environment

39. codexpedia. (2016). NFC Reader/Writer Tutorial. Available: http://www.codexpedia.com/android/android-nfc-read-and-write-example/. Last accessed 26th March 2017.

Appendix A Personal Reflection

A.1 Reflection on Project The aim of the dissertation was to develop an application which allow a user to navigate within an indoor environment. This is the core of the project but further knowledge was gained about Bluetooth enabled technologies such as NFC and Beacons. The project itself was performed under a linear approach which, at the time, was the best approach to follow due to the limited scope. In hindsight, using time more cleverly and involving more agile based approaches with user participation, through surveys and questionnaires for example, would have produced a better prototype application.

The background gathering was extremely problematic as no real world android application, apart from Google Maps, was found. More examples of RTLS and RFID systems on a large scale within hospitals was useful in identifying functional and non- useful during testing and evaluating the end prototype. Due tofunctional the limited requirement scope of the but project, wasn’t this phase needed to be ended before all possible information was gathered. For this reason, more time should have been used for the background research as finding Indooraltas example application would have been useful to evaluate against to see where the application was.

In terms of development, understanding the variable and statements used within Indooraltas SDK is important and difficult. that would have been useful to knowThe before tutorials’ implementatio )ndooraltasn phasepresented took leftplace. important To encounter gaps this problem, more research would have been useful as long delays took place, wasting time which could have been used to implement the 17 failed requirements.

During development, the UI behaviour was problematic as crashes was a frequent event. This was either through using too much of the CPU and/or the UI elements taking too long to implement their purpose on respectively high and low end devices. Too many errors were discovered late in the implementation phase, which cause a degree of panic. A lot of these highlighted issues was related around the map fragment and SDK. For this reason, using a more agile based approach might have been more appropriate as noticing code which needed optimisation to work more efficiently would have been picked up much earlier within implementation.

67 Using Smartphone technology to simulate human behaviour within an indoor environment

Overall, the project duration was not used sufficiently to create a better prototype application as possible. Problematic issues sometimes cannot be avoided but if predicted correctly, the approach can be structure to lesser those identified risks. For this reason, risk analysis should have been used organise the approach.

A.2 Personal Reflection The dissertation process has been an important journey for me as multiple skills from a development point of view as well as other learning skills, such as organisation, time management and many more, have been learnt. During the process, there has been many challenges along the way. This dissertation has been a time-consuming process which needed a lot more focus and commitment compared to any previous assignments during my time at Brunel University. To be honest, I thought the process would be straightforward and that I had toono too. much time. My opinion changed dramatically due to family commitments that ) couldn’t say

A linear approach was used to structure the process so time could be used as best as possible. As this dissertation is all based on the development of an application, it would be useful for the project that user participation as well as a more of an agile based approach was involved so an improved prototype could have been developed. To be honest, I was disappointed in myself that

) did have enough time to involve the users’. One area of improvement that I strongly believe would had made a huge difference was creating an action plan. This refers to separating key areas of research into separate time periods. This would make mainly in the gathering of resources but it would also help in achieving smaller goals. Skills such as being self-disciplined, organised and time management could have been improved, which are all important to employment. Better research could also benefit development as multiple issues, such as within the SDK, was discovered after the completion of the background phase and caused long delays.

Improving the research within the dissertation process would also allow much more time being used for testing and evaluation phases of the project. Greater testing will improve the performance of the application which would only improve the impression the application given within the evaluation and of course conclusion.

68 Using Smartphone technology to simulate human behaviour within an indoor environment

Appendix B Appendices

B.1 Requirements Verification Testing Log

Hardware & Software Requirements

Target Requirements No. Requirement Priority 1 Critical

2 The application should utiliserun on androidAndroid built AP) in GPSand receiver.later Lollipop, …. Critical 3 The application should utilise android built in Bluetooth functionality, Significant including NFC.

Host Requirements No. Requirement Priority 4 The application should be built and deploy on Window 10. Critical 5 The application should be compile and run on an Android phone running Critical minimum API. 6 The application should be built using Android SDKs, supported by Critical Indooraltas and Beacon Library. 7 The application should be written in Java. Critical 8 The application should be developed and compiled in Android Studio. Critical

Functional Requirements

Functional Requirement for Log in Activity No. Requirement Priority 9 The application will allow the user to enter a Username and password. Critical 10 The application should be able check user data to see if correct against Non-Vital an android recommended server (SQLite Database for example). 11 The application should be able to request a change of password. Non-Vital 12 The application should be able to request a creation of a new account. Non-Vital 13 The application should check if following is active: Critical

 Wi-Fi/ Mobile Data  GPS/location

69 Using Smartphone technology to simulate human behaviour within an indoor environment

Functional Requirement for Map View Activity No. Requirement Priority 14 The application should display a map with the user current location Critical displayed. 15 The application should display on map indoor areas that are mapped out. Critical 16 The application should display nearby beacons on map for user to locate. Significant 17 The application should display the following map functions: Critical

 My location button  Zoom in/out  Floor Level selector 18 The application should follow a typical Android UI. Critical 19 The application should allow user to navigate to selected location. Non-vital

Functional Requirements for NFC activity No. Requirement Priority 20 The application should be able to scan NFC tags. Critical 21 The application should be able to display what is written to NFC tags. Critical 22 The application should be able to edit NFC tags. Critical 23 The application should allow user to see history of NFC tags. Non-Vital 24 The application should allow user to see the following data: Non-Vital

 Location  Main Content  Date/Time 25 The application should check if user device has NFC compatibility. Critical 26 The application should check if NFC is active. Critical

Functional Requirements for Profile Activity No. Requirement Priority 27 The application should support multiple user profiles Non-Vital 28 Profile Data should be stored on an android recommended server. Non-Vital 29 The profile data that will be stored on the server: Non-Vital

 Profile ID  Username

70 Using Smartphone technology to simulate human behaviour within an indoor environment

 Password  Email Address  Profile Image  Home Location 30 The application should allow user to edit or add profile data. Non-Vital 31 The application should allow user to remove/delete profile data. Non-Vital

Functional Requirements for Settings Activity No. Requirement Priority 32 The application should allow the user to change the desired font size. Non-Vital 33 The application should allow the user to select a power save mode. Non-Vital 34 The application should allow the user to turn on and off audio feedback. Non-Vital 35 The application should allow the user to change the desired GPS Non-Vital accuracy.

Non-Functional Requirements

Non-Functional Requirements for application No. Requirement Priority 36 The application should provide as accurate as possible GPS tracking Significant 37 The application should take no longer than a couple of minutes training Significant for the user to understand the application with no android experience. 38 The application should take no training for a user with android Significant experience. 39 The application should conserve battery. Significant 40 The application should not contain any memory leaks. Critical 41 The application should exit as smooth as possible in case of error. Critical

Non-Functional Requirements for Interface No. Requirement Priority 42 The application should include a loading screen to inform a user the Non-Vital application is loading.

71 Using Smartphone technology to simulate human behaviour within an indoor environment

43 The application should have a logo display both on the application and Non-Vital within the android menu.

B.2 Low fidelity Designs

B.2.1 Login Activity

72 Using Smartphone technology to simulate human behaviour within an indoor environment

B.2.2 Mapview Activity

B.2.3 NFC Activity

Activity Before Scanning Tag

73 Using Smartphone technology to simulate human behaviour within an indoor environment

Activity After Scanning Tag

74 Using Smartphone technology to simulate human behaviour within an indoor environment

B.3 Ethics Form and Confirmation (Click on form object to see complete form)

75 Using Smartphone technology to simulate human behaviour within an indoor environment

76