University of ManchesterSchool of Computer Science

Project Report 2016

Grey MatterAn application to improve quality of life for people affected by

dementia

Author: Ben Nawaz

Supervisor: Dr. Steve Pettifer

Abstract

Grey MatterAn application to improve quality of life for people affected by

dementia

Author: Ben Nawaz

In this report I will be discussing what I have managed to achieve over the courseof my third year project, in addition to the approach I have taken to do so.

Over the course of this project I have successfully created a functioningapplication, aimed at helping people living with the early stages of dementia, orany form of memory impairment including the people who care for patients withsuch illnesses.

This has been done through the creation of a cross-platform smartphoneapplication created using JavaScript frameworks and libraries, in addition to thecreation of a REST API which runs on a cloud computing platform, also writtenusing a series of server side JavaScript libraries and this is the main topic area ofthe following report.

I would say that my main achievements have been successfully learninghow to use and implement a variety of new frameworks and libraries to createa functioning application, some of which are still subject to instability due totheir young nature, which gave rise to a number of challenges with regards to thedevelopment of the project.

The main conclusions that I have drawn are that there is a huge opportunityfor modern personal technology to play a helpful role in healthcare, and that whilsthybrid mobile application development using cross-platform frameworks and li-braries might save time by removing the need to develop multiple code bases indifferent languages, it certainly has a long way to go with regards to reliability,stability and performance and may not yet be a viable alternative to native appli-cation development.

Supervisor: Dr. Steve Pettifer

Acknowledgements

Thanks to my project supervisor Dr. Steve Pettifer for his helpand guidance throughout the project.

1

Contents

1 Context 51.1 Chapter Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 51.2 Subject Area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.3 Why work is done in this subject area . . . . . . . . . . . . . . . 61.4 What my project aims to achieve . . . . . . . . . . . . . . . . . . 61.5 Available Alternatives . . . . . . . . . . . . . . . . . . . . . . . . 7

2 Design and Implementation 82.1 Requirements Analysis . . . . . . . . . . . . . . . . . . . . . . . 8

2.1.1 Non-Functional Requirements . . . . . . . . . . . . . . . 82.1.2 Functional Requirements . . . . . . . . . . . . . . . . . . 9

2.2 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.2.1 System Architecture . . . . . . . . . . . . . . . . . . . . 12

2.3 Technical Challenges . . . . . . . . . . . . . . . . . . . . . . . . 142.3.1 Frontend Challenges . . . . . . . . . . . . . . . . . . . . 142.3.2 Backend Challenges . . . . . . . . . . . . . . . . . . . . 16

2.4 Considered Alternatives . . . . . . . . . . . . . . . . . . . . . . . 18

3 Evaluation 203.1 Backend Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . 203.2 Frontend Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.2.1 End to End Testing . . . . . . . . . . . . . . . . . . . . . 253.2.2 Performance Testing . . . . . . . . . . . . . . . . . . . . 28

4 Reflection and Conclusion 304.1 Time Management and Planning . . . . . . . . . . . . . . . . . . 30

4.1.1 Original Plan and Milestones . . . . . . . . . . . . . . . . 304.2 Potential Architectural Flaws . . . . . . . . . . . . . . . . . . . . 32

2

4.2.1 MongoDB . . . . . . . . . . . . . . . . . . . . . . . . . 324.2.2 Node.js . . . . . . . . . . . . . . . . . . . . . . . . . . . 324.2.3 Express.js . . . . . . . . . . . . . . . . . . . . . . . . . . 334.2.4 Angular.js . . . . . . . . . . . . . . . . . . . . . . . . . . 334.2.5 Ionic . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.3 Knowledge Gained . . . . . . . . . . . . . . . . . . . . . . . . . 344.3.1 Technical Knowledge Gained . . . . . . . . . . . . . . . 344.3.2 Knowledge Gained About Project Context . . . . . . . . . 36

4.4 Achievements and Results . . . . . . . . . . . . . . . . . . . . . 36

A Appendices 42A.1 Application Design and Structure In Depth . . . . . . . . . . . . . 42

A.1.1 Frontend Application Structure . . . . . . . . . . . . . . . 42A.1.2 Backend Application Structure . . . . . . . . . . . . . . . 44

A.2 External Libraries, Frameworks and Plugins Used . . . . . . . . . 45

3

List of Figures

2.1 A high level view of the overall system architecture of my project. 122.2 Retrieval and storage of “refresh” JSON web tokens in the client

application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.3 Conversation with Ionic.io developers . . . . . . . . . . . . . . . 18

3.1 Example of independent unit tests run against a singular API end-point method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.2 Example of an integration test which tests multiple API endpoints 223.3 The Mocha test runner in my IDE (WebStorm) used to test my API 243.4 Ionic Lab browser testing tool showing iOS and Android styling . 263.5 Debugging my Ionic application in the Google Chrome DevTools 273.6 Viewing a timeline of Network packets in Google Chrome DevTools 28

A.1 An example of dependency injection in Angular JS . . . . . . . . 42A.2 Angular project structure . . . . . . . . . . . . . . . . . . . . . . 43A.3 Server side project structure . . . . . . . . . . . . . . . . . . . . 44A.4 Definition of API endpoints on my server-side application . . . . 45

4

Chapter 1

Context

1.1 Chapter OverviewThis chapter discusses the context and subject area within which the project wasdeveloped, namely health technology and more specifically a subset of such tech-nology known as assistive technology. In addition to this I explore why peopleincluding myself use technology to create solutions related to such a topic, andwhat specifically I aimed to achieve when setting out to create my project.

1.2 Subject AreaThe topic area to which this project contributes is that of health technology, re-ferred to as the “application of organised knowledge and skills in the form ofdevices, medicines, vaccines, procedures and systems developed to solve a healthproblem and improve quality of lives.” as defined by the World Health Organisa-tion [1].

In particular, my project is concerned with the application of technology inhelping people who are living with the symptoms of dementia, as well as thosewho care for such people. Specifically, the type of health technology my projectaims to be a part of, is referred to as “Assistive Technology”, which is a type oftechnology which aims to help people maintain or even improve their indepen-dence, safety or wellbeing [2].

Assistive technology provides a number of potential benefits, and some ofthese benefits which I hope to provide as part of my project are:

• Promoting independence and autonomy

5

• Improving confidence and quality of life for the person living with dementia

• Supporting a person living with dementia to live in their own home forlonger

• Aiding memory and recall

• Providing peace of mind to carers as to the wellbeing of the patient

• Helping a person living with dementia to maintain abilities which are beingdiminished

1.3 Why work is done in this subject areaWork is done in this particular area as technology offers a fantastic opportunityto make a significant improvement to the quality of life for people living withdementia, and demand for such technology is only growing as age-related illnessessuch as dementia are becoming increasingly prevalent as a result of an ageingpopulation [3].

Such an opportunity has been created through recent advancements in moderntechnology, particularly with the advances in smartphone and wearable devicetechnology, which are seeing an increasing use for their ability to monitor variousaspects of our physicality, such as physical location [3].

1.4 What my project aims to achieveSpecifically, I hope to prolong and improve the patient’s ability to live indepen-dently, through the use of tools which help to replace and support vital skills thatare diminished over time as a result of their illness. Primarily I aimed to do this bycreating an app which encompasses a range of tools which people suffering fromdementia would find useful.

In addition to helping patients, I also aim to aid those people who care forsuch patients, through the creation of monitoring and communication tools that Ihave built into my application, such as a feature which allows carers to monitorthe location of their patient as well as a direct chat tool to easily and quickly talkto their patient via my app [4].

6

1.5 Available AlternativesThere are already various tools and applications that exist with this same purposein mind, and many operate in a similar way, which are specific to the care ofpeople with dementia. Such tools tend to fall into a number of categories withstand alone devices and tele-care solutions being the main two.

A number of alternatives to my project exist which perform similar or thesame function, and the most relevant examples of these are software tools as isthis project, which are available on devices such as smartphones and tablet com-puters. However, many such applications are very simplistic or underdevelopedand the majority seem to only perform one specific function such as “brain train-ing” games or “medication reminders”. This is in contrast to my project whichaims to provide a range of tools to help people live with dementia.

The main such alternatives to the application that I have developed are:

1. MindMate - http://www.mindmate-app.com/ - Probably the most simi-lar existing project to my own that is available. This project is an iOS appli-cation very similar to the one I have produced which provides both patientsand carers tools for living with dementia, with a focus on memory joggingtools for patients and some limited features for carers to monitor patientssuch as an in-app chat feature, as is present in my project. Other featuresthis app shares with mine are memory jogging tools, reminders to performtasks throughout the day and a log of a patient’s personal details there forreference. This project however, is lacking in functionality for tracking pa-tient and carer locations which constitutes perhaps the most valuable anduseful feature of my project.

2. CleverMind - http://myclevermind.com/ - This is the second most sim-ilar project to the one which I have developed. This app primarily providesreminders for patients (however this is specific to medical information) andfocuses mainly around cognitive games and puzzles to help measure cogni-tive function.

7

Chapter 2

Design and Implementation

2.1 Requirements AnalysisFrom the above context for my project, I devised a series of requirements whichthen allowed me to design a number of features that I felt would suit the purposeof the application. I did this in the following ways, which I shall detail in terms ofboth the functional and non-functional requirements.

2.1.1 Non-Functional RequirementsThe following are the significant non-functional requirements which define howmy project application should be in a more abstract manner, once it has been im-plemented and is ready to use by patients and carers. They have been determinedby analysing the context in which this application is intended to be used.

1. Easy to use - As the target audience of my project is primarily people whosuffer from dementia, in addition to their carers, I had to be aware of that thefact the majority of my users would be those who are most affected by suchillnesses. Specifically, the majority of such users will be elderly people,with 1 in 6 people over the age of 80 being affected by dementia, and over40,000 people in the UK with dementia who are under the age of 60 [5].In light of this, one of the first and perhaps most important non-functionalrequirements is that my application have a simple, easy to use user interfacewhich is accessible and navigable by elderly people.

2. Cross-platform - In an effort to make the application as accessible as pos-sible for its target audience, the application should be available to as wide

8

an audience of users as possible. In light of this, the application is intendedto work on both the Google Android OS (operating system) as well as theApple iOS operating systems, which constitute the vast majority of today’ssmartphone users, with 86% of smartphone users adopting the Android OS,13% adopting the Apple iOS and the remaining users distributed betweenthe Windows smartphone OS, Blackberry OS and others [6].

3. Open source - One of the final significant non-functional requirements isthat this project and resulting application should be free of charge whenbeing made available on the operating system’s distribution platforms suchas the Google Play Store and the Apple App Store. This is to ensure that asmany people as possible may derive some form of benefit from what I havedone and due to the fact that this is an academic project. Additionally, Ihave publicly shared the code for the application via GitHub so others mayuse and adapt it if they wish to do so.

2.1.2 Functional RequirementsStemming from the non-functional requirements, the functional requirements whichI have derived through an analysis of the context in which the project is to be usedare detailed below.

1. User Types - The application should allow for two different types of user,a user who is defined as a “patient” and a user who is defined as being a“carer” for an existing patient user who is signed up to use the applica-tion. The concept here is that the patient type user will be able to use theapplication to hopefully aid them in their day to day living, whilst theircorresponding carer users can make use of the application to monitor theirpatient throughout the day in order to help give them some reassurance asto their connected patient’s well-being.

2. Carer Connections - Patient and carer users should be “connected” in someway via the application, and this is done by associating one or more car-ers to a single patient user. This is to be done via the use of invitations,whereby a patient must invite a carer using the email address with whichsaid carer signed up to use the application. This is to ensure that when a pa-tient connects to a carer and thus provides said carer access to their personalinformation, there is a degree of control over which carer users can see saidpatient information, for security purposes.

9

3. In-app Instant Messaging - The application should allow patients to easilyand instantaneously communicate with their connected carers, to allow bothpatients and carers to have a greater peace of mind and easy access to com-munication with one another. This is mainly for the benefit of the patient,who again is likely to be less familiar with technology, and the idea here wasto remove the need to use multiple different applications on their device inaddition to removing as many of the configurable elements of this processas possible. An example of this would be a patient having to explicitly entera number or select a contact in order to make contact with a carer. The mes-saging service within the application should quickly and directly allow thepatient user to send a message to a carer by simply typing a message andgoing to the “Chat” tab.

4. Routine Manager - A feature to allow a daily routine to be defined fora patient, in which the repeated activities which are to be carried out oneach given day are outlined. Carers are given full control over this routine,allowing them to manage a patient’s day remotely, and patients are able toset activities as “completed” through the use of a simple “todo” style userinterface.

This idea was derived from the context of the project as I found that forpeople who are living with memory impairments it is useful to have a setroutine every day. This acts as a means of providing a repeated, constantstructure to their day to day activities [7].

5. Location Tracking and Wandering Alerts - This should allow the loca-tion of patients to be tracked and displayed in real-time to the carer users,providing carer users with useful location related features such as directionsto their patient and a recent history of where their patient has been, allowingthem to trace their patient’s recent path on a map.

Most significantly, carer users should be able to define “perimeters” aroundtheir patient user’s location, and be able to receive alerts via push notifica-tions when the patient either leaves or enters these perimeters. This ideawas derived from the project’s context, as a common problem faced withthe care of a person suffering from dementia is their tendency to “wander”accidentally, and losing a patient for whom you are caring can be a worryfor carers. A feature such as this is aimed again at helping to provide somesense of security for both the patient and the carer [8].

10

In addition to this, the locator feature is also intended to be of use to pa-tient users of the application, providing them with features to get directionshome and to their registered carers, also through the user of an interactivemap. Example use cases could be the patient becoming lost, which is alsoa common problem. This relates to the overall aim of the app as such a toolwill support a patient’s independence.

6. Personal Information Profile - This feature of the application is intendedto display all of a user’s personal information as registered with the applica-tion, in addition to the other application users to whom they are connected.For a user who is a patient, a range of personal of information is collectedwhen they are signing up and this is then displayed in this area of the appli-cation.

As well as being a point of reference and memory aid for patients this fea-ture of the application should also serve to show carers a connected patient’sinformation in addition to providing controls to both patients and carers asto which other users they are connected to within the application. Finally,this feature should allow the user to sign in and out of the application usingdifferent account credentials.

2.2 DesignThe following section details the architectural and structural designs of my projectin terms of the software which has been written and how the various componentsof the complete system interact with one another.

11

2.2.1 System Architecture

Figure 2.1: A high level view of the overall system architecture of my project.

The above diagram represents the main components of my project’s architectureconsisting mainly of a web based REST API and MongoDB database, which iscommunicated with via the front end client application. At the most basic levelthe front end smartphone application communicates with the REST API over theinternet using TCP packets via AJAX calls in addition to using web sockets forthe instant chat messaging feature. This happens whenever users perform actionsthat require some processing on the server-side of the application.

Such communications are listened for by the server side application. This op-erates in the Node.js runtime; a JavaScript engine and interpreter which has beenextracted from the Google Chrome web browser and developed upon. Node.jsis designed to run as an asynchronous input/output driven framework for makingscalable network and server-side applications [9].

12

On top of the Node.js runtime, I am using an additional framework to facilitatethe creation of a web API, called Express.js which is a very thin layer on top ofNode.js and provides a structure as well as some libraries for using Node.js tocreate a publicly accessible API [10].

It is this Express.js application, running in the Node.js platform that has anumber of URI “endpoints” (web addresses), which can be queried using stan-dard HTTP methods via the front end client. When queried, these then go on toperform processing on data and communicate with my backend storage which isimplemented using a MongoDB NoSQL database.

MongoDB is a highly-scalable non-relational database which simply storesrecords as JSON “documents”, and hence provides very fast accesses and is why Ibelieve it is better suited to web requests than a standard relational SQL database.The use of MongoDB here is advantageous to me and the project due to its speed,and due to the relatively low inter-dependencies between each of the different data“models” (equivalent to tables). With MongoDB, in some cases data accesses areperformed at 100 times the speed of traditional SQL queries [11].

With regards to the technology stack of the front end client application thereare also a number of frameworks in use, that allow me to write a single applicationusing JavaScript and have it run on both the iOS and Android platforms, whichcan be seen on the right hand side of the architecture diagram above.

At the lowest level, running natively on the mobile devices themselves, is theApache Cordova framework which runs a native application containing an in-appweb browser. Within this, a developer can run a rich web application which hasbeen optimised for a mobile device [12].

Above this layer, I then used the Ionic framework, which is an optimised li-brary of HTML, CSS and JavaScript components for creating rich mobile-orientedweb applications in conjunction with Cordova above [13]. Whilst applicationscan be developed purely using any form of HTML, CSS and JavaScript within theApache Cordova framework itself, these are often of poor quality both in terms oftheir user interface and performance, and it is for this reason I elected to use theIonic framework. Using Ionic the overall aesthetic and performance of the appli-cation is largely improved upon, allowing me to focus more time and attention onfunctionality and reliability than aesthetics.

As part of the Ionic framework, the web application which is created usingJavaScript is done so using an internal framework known as Angular JS whichenforces an MVC (Model, View, Controller) style of structure on the application.This improves the overall readability and maintainability, a topic I have writtenabout in the appendices of this report.

13

2.3 Technical ChallengesIn this section I will detail some of the more technically challenging aspects of theproject; features which when compared to others I found particularly challengingto implement. These are mainly the location based features, as well as the useof push notification APIs which required a complete re-write mid-project due tothe API in use moving from Alpha to Beta development stages and subsequentlydrastically changing the way in which it was meant to be interacted with.

2.3.1 Frontend ChallengesIn terms of the client side of my application there were a number of factors whichgave rise to a number of issues, and meant that some features ended up taking farmore time to complete than I had originally planned for.

The first of these issues was the use of the Apache Cordova framework, whichwhen communicating with a device’s native hardware, insists upon the use of Cor-dova “plugins” which are open source and maintained by a community of opensource developers. This fact makes such plugins relatively vulnerable to issuesand one such issue that I encountered was when trying integrate the official Cor-dova plugin for interacting with device locations, when first attempting to imple-ment the geofence location perimeter feature of my application.

I was unable to integrate the plugin into my application fully, as it was onlyworking for the iOS platform (with a multitude of open issues about this on theplugin’s GitHub page) and simply would not compile in XCode, due to missingdependencies and system updates that had been released after the developmentof the plugin. There were many people complaining of similar issues (and henceopen issues on GitHub) and so for me, it rendered this particular plugin unusableand I had to opt for an “unofficial” plugin which performed a similar functionof accessing location hardware, elsewhere [14] [15]. More details on this can befound in the appendices to this report.

Once I had found a plugin to act as a suitable replacement, I still howeverfound the implementation of the location tracking feature challenging. Whilst thegeolocation plugin did provide many useful pre-existing methods for detectingwhether a user had begun to move from being stationary, in addition to if a ge-ofence had been exited or entered, this plugin was not without issues itself. Alarge amount of experimentation and work was required to integrate the plugin:combing through documentation and even speaking directly to the developer todetermine that the documentation for the plugin was actually incorrect, with a

14

great deal of functionality simply not working as expected.In addition to this, the correct implementation and use of the Google Maps

APIs was relatively complex in terms of integrating these APIs properly into theuser interface of the application. I had to make use of their supplied methods forrendering location markers, points and paths on the given map whilst constantlypolling my server with up to date locations, in addition to retrieving up to datelocations of other users as well.

Another of the particular challenges and technically complex aspects of theclient side application was the use of JWT tokens to authenticate users. Theseare a fairly new development, and used as an alternative to cookies or sessions,meaning that the server-side of the application is not required to store any state,allowing it to run more efficiently as less memory resources are required. In thetoken based authentication process a token is initially acquired from the serverupon signing in, and for a set period of time (for which the token remains valid)this token is attached to every request from the client to the server, and henceauthenticates those requests with the server, removing the need for any storedstate. The particular library I used to do this in my Angular JS application isan open-source industry-standard (RFC 7519) known as “JWT” or “JSON WebTokens” [16].

An issue arose whereby the application would log users out every time theyexited the application (returned to the main menu on their device) and in light ofthis I had to make use of “refresh tokens”. These are an additional aspect of webtokens, which allow a newly acquired (and still valid) authentication token to beused to retrieve a longer lasting “refresh token” which can be used over a longerperiod of time, and allows users to remain signed into the application.

I did this to ensure that the usability of the application was not affected, ashaving to sign in multiple times would quickly become wearisome and likely putusers off of using the application altogether. The solution was to use the newHTML5 local storage API to periodically refresh the “refresh token” each time theuser restarted the application within the current refresh token’s life time. If thiswas attempted after a refresh token had expired however, after a time of around 3days, then the user would be required to sign in once more. An example of thiscode can be seen in Figure 2.2.

15

Figure 2.2: Retrieval and storage of “refresh” JSON web tokens in the client ap-plication

2.3.2 Backend ChallengesWhen developing the server-side of my application, I ran into fewer complicationsthan when developing the client-side, perhaps as this part of the application hadfewer components involved. However, there were still complications, challengesand complex components to integrate with one another.

One of the major difficulties which I was faced with in terms of the develop-ment of the server-side of my application, was the integration of cross-platform

16

push notifications. This turned out to be a rather arduous and multi-faceted prob-lem which took me far longer to fully implement than I had first imagined. Thiswas because of the need to generate the necessary credentials for both of the plat-forms on which I intended to run my application. This was easier to do for Google,as I simply had to register my application with the Google Cloud Messaging APIand generate an API key, but for registering my app with Apple’s iOS Push Noti-fications the process was much more complex and convoluted.

Apple not only required that I sign up for a paid membership as a developer(at a cost of $99 dollars), but I had to generate a series of different certificates,one for my development machine, one for the application itself and finally twocertificates just to allow my eventual iOS application to make use of Apple’s pushnotification servers. Luckily this process was well documented via the Ionic teamby a series of walkthroughs, however this process was still time consuming andprone to error [17] [18] [19].

In addition to this, I was also using services provided by the team behind Ioniccalled Ionic.io, which is a cross-platform push notification API allowing me tosend a single push notification to this service, and have it distributed to both of myapplication operating systems, with minimal configuration. This however was notthe case, as at the time of my project’s development this service was in its “alpha”stage, and although deemed highly unstable seemed to work reasonably well forme. This fact however served to disrupt my development, as near to the deadlinefor the project this service moved into its “beta” stage, and the way in whichmy application had to interact with it changed completely. This required a fairamount of code rewriting within both the server and client side applications. Thechangeover happened the night before my project was due to be demonstrated tomy project supervisors, and below is a snippet of conversion with the developersof the Ionic framework where they explain that the “issues” I seem to be havingare in fact because of the changeover of their live Ionic.io Push service from alphato beta. (See Figure 2.3)

17

Figure 2.3: Conversation with Ionic.io developers

2.4 Considered AlternativesThis section details some of the alternative technologies that were considered us-ing as part of my system architecture but in the end opted not to and the motiva-tions for such choices.

The first alternative technology considered for use was the framework to beused to build the rest API which comprises my server-side application. The tech-nology which I heavily considered using is actually a framework which is built ontop of Express.js which is currently in use in my project, known as LoopBack.io.

The LoopBack.io framework (recently acquired by IBM) abstracts much ofthe repeated work out of building an Express.js web API, by having a user de-fine the models that they will be using (as mentioned previously with regards toMongoDB), and having the framework automatically generate methods to handlecommonly used endpoints for the CRUD operations for that model (create, read,update and delete), thus “generating” an API by simply providing a few modeldefinitions and in theory reducing work by prioritising “configuration over code”[20].

Although this may sound good, I have a few reasons for choosing not to usethis framework. First of which is its age, as this is a framework that has only justleft its beta stage, and through my attempted use of the framework so far I havefound that it is still heavily riddled with bugs as well as inaccuracies in its scarcedocumentation. This is related to my second reason for choosing to forego thisframework, as when it is compared to writing a “vanilla” API using Express JSthere is far less support and documentation online for LoopBack.io than there isfor Express.js, a fact which I quickly came to realise had a huge bearing on the

18

speed at which I was able to develop my application effectively.Another technology which I very much considered using was my cloud host-

ing platform. Currently I am using the OpenShift Cloud Platform as a Service,which is simply a publicly accessible hosting account given to students for free byRedHat, the Open Source developers of Linux [21].

The alternative which I considered was the slightly more complex MicrosoftAzure Infrastructure as a Service (IaaS), which offers a rich user interface andhas far more features and capabilities. Microsoft Azure is more of a large-scale,enterprise solution which differs from a Platform as a Service (PaaS) in that piecesof code are written to work specifically with the different services and systemswhich are made available via Azure, and many of these different components areconfigured to work together using the Azure infrastructure, to form a completeserver-side solution. Conversely on the more simplistic OpenShift, my project isa more “standard” server-side application written in the usual manner and simplyuploaded to and hosted on their platform in its entirety [22] [23].

The first and foremost reason that I chose not to use Microsoft Azure was thefact that unlike OpenShift, no usable free tier was provided to me as a student, andI would have had to pay for my continued use of their services. Additionally, I feellike although I successfully managed to implement my server-side application onthis platform, that Microsoft Azure was far more of a solution that I required, withmany of its features aimed at large-scale enterprises, which were simply superflu-ous to my requirements for this particular academic project, with OpenShift beingmore than sufficient.

19

Chapter 3

Evaluation

In this chapter of the report I will be discussing how I have evaluated the qualityand correctness of the artefact I have produced, as well as how confident I amin this evaluation. As my project is primarily a software artefact, this is mainlyjudged through the use of various types of testing which are explored in the fol-lowing sections.

3.1 Backend EvaluationIn order to evaluate the quality and correctness of the server-side of my applica-tion, I made use of both unit testing and integration testing. To ensure the cor-rectness of the isolated methods written on the models in the backend, I wroteunit tests against the endpoints of the server-side API, and used libraries to create“mock” versions of any dependencies on other models.

In addition to this, I employed the use of more complex and sophisticatedintegration tests, which were testing against the more high-level use cases of myAPI, such as “one user should be able to connect to another”. Each of these testsmade use of multiple API endpoints and required the creation of test users andassociated data, and hence took longer to write. I decided to write a series ofintegration tests against my API endpoints in this way, as it constitutes the idea of“middle out” testing, whereby integration tests which are less granular than unittests are run against the “service layer API” of my architecture. This allowed me totest the majority of my so called “business logic” and data layer, whilst remainingseparate from testing via the user interface, which I do via the front-end clientapplication later on as part of my end-to-end testing. The biggest advantage of

20

this however is that it allows me to automate my testing using a series of librariesand frameworks.

In order to automate my unit and integration tests I used the Mocha test frame-work which is specifically designed for testing asynchronous Node.js code in areadable, sensible manner and was ideal for running my tests against the API formy project [24]. In conjunction with Mocha I used an “assertion library” knownas Chai, to help analyse the results of each of the calls made to the various APIendpoints. Chai allowed me to write tests and verify the responses of API calls fora number of different criteria such as status codes, data types and null checking; anexample of which can be seen in Figures 3.1 and 3.2. These figures demonstratethe expressive, readable syntax of Chai when being used to analyse the result ofan asynchronous call made using the Mocha framework [25]. I also made use ofan additional assertion library known as “Supertest” which specialises in the test-ing of API endpoints, with useful methods for making HTTP calls and facilitatingthe analysis of their responses using an assertion library (Chai here) as mentionedabove [26].

Figure 3.1: Example of independent unit tests run against a singular API endpointmethod

21

Figure 3.2: Example of an integration test which tests multiple API endpoints

In Figure 3.2 a more complex “integration” type test can be seen, which re-quires both setup and teardown methods to be run in order to create and clean uprequired data before running the tests. This integration test runs against multi-ple API endpoints to test the use case of “connecting users”, and is considerablylonger and more complex than the unit test shown in Figure 3.1 which tests only

22

a single, isolated method.In terms of how confident I am that these tests are a good evaluation of how

well the server-side of my application runs, I am fairly sure that the automatedtests I have written provide a relatively high level of code coverage although Iam sure there is always more room and opportunity for code to be tested morecomprehensively, as is likely the case with this code.

Due to time constraints and a certain number of set backs in the developmentof features which took longer to develop than I had first anticipated, some of themore simplistic endpoints are left untested via integration and unit tests, such asGET HTTP method endpoints for user data. However, such endpoints which havebeen left untested in this fashion have indeed been tested via my end to end testsof the front end application, so I am happy that they work reliably, although giventime I would test as comprehensively as possible.

23

Figure 3.3: The Mocha test runner in my IDE (WebStorm) used to test my API

I focused my attention on writing integration and unit tests on the server-sidefor the features of my application which are more complex and make more use ofdifferent users, data and other API endpoints. A specific focus was on the userconnection mechanism, whereby invites had to be sent, validated and checkedfairly thoroughly to ensure that my application was secure from the point of viewof a patient who is potentially exposing a large amount of their vulnerable per-sonal information. Figure 3.3 gives examples of ways in which I ensured thismechanism was tested using unit and integration tests.

24

3.2 Frontend EvaluationIn order to test the client side of my application, and ensure its quality and cor-rectness I did not use any automated testing, but continually ran full system “endto end” testing using a range of tools to ensure that the cross-platform applica-tion that I was developing was operating as intended on both the iOS and Androidplatforms.

3.2.1 End to End TestingIn order to perform end to end testing of my application, through seeing how anaction performed on the user interface traversed the whole technology stack of myapplication, I had to use a number of tools due to the fact that the application iscross-platform. The cross-platform nature of the application meant that I must en-sure that it behaves as expected on each different platform on which it is intendedto run.

To do this I had to make use of emulators for both the iOS and Android plat-forms as well as physical devices and a useful tool provided by the Ionic frame-work referred to as Ionic Lab, used for rendering the Angular JS application in abrowser and giving an idea of how the application looks once it has been compiledand run on each of the different platforms (see Figure 3.4).

I had to use caution when using this particular tool however, as although itallowed me to quickly and easily test a large proportion of my front end applica-tion, running the application in a browser (as in Fig. 3.4) did not allow me to testthe use of Apache Cordova device plugins which interact with device hardware,and the way in which the SASS (a CSS pre-processing framework) made the ap-plication look in this tool, was not always an accurate representation of how myapplication would look once it was running on my devices.

25

Figure 3.4: Ionic Lab browser testing tool showing iOS and Android styling

It is for this reason that I also saw fit to use emulators and devices to run myapplication code, which required the use of virtual machines to act as real devicesrunning on my development computer, and the compilation of my Ionic, Cordovaand Angular JS code base into the respective native languages for each platform.For Android this is Java, and required the use of the build tool ANT, and for iOSthis Objective C and Swift, for which I used the XCode compiler.

One issue I did experience was that the default Android emulator providedas part of the Android Software Development Kit (SDK) is incredibly slow interms of boot times and responsiveness, and my solution to this was to use a third

26

party emulator recommended by the Ionic framework team known as Genymo-tion. Although still unresponsive when compared to the iOS Simulator providedby XCode, Genymotion was far more usable [27].

Figure 3.5: Debugging my Ionic application in the Google Chrome DevTools

For each feature that was developed, I would test repeatedly through the use ofthe Ionic lab interface as shown in Figure 3.4, using the excellent Google ChromeDeveloper Console as seen in Fig 3.5 which allowed me to create and debug theapplication much similar to the way that debugging tools in a typical IDE (Inte-grated Development Environment) are used. I would then additionally ensure thateach new feature of the application was functional by testing on the respectiveiOS emulator and Android GenyMotion emulator.

27

I additionally was able to run the application on my own personal smartphone,an Apple iPhone, but did not have access to a physical Android device, so feelthat I may have been able to improve my testing in this regard had I organised theacquisition of such a device.

3.2.2 Performance TestingIn this section I go into detail as to another form of testing which I undertook formy application, which was performance testing. In particular this was mainly fo-cussed on the one aspect of the project which would was subject to delays, whichwas when the client-side application was making XHR (XMLHttpRequests) re-quests to my server-side application.

Figure 3.6: Viewing a timeline of Network packets in Google Chrome DevTools

In order to test the network performance of my server-side application usingthe latency of XHR requests I used the Network tab of the Google Chrome Dev

28

Tools in addition to the same tab in the Safari Debug tools when running theapplication in the iOS Simulator or on my iOS device. This allows me to see atimeline of the Network requests made by each angular controller and view withinmy application, as well as the response times for each of the individual calls ascan be seen in Figure 3.6

To get a good idea of the general responsiveness of my server, I took an aver-age of times for some of the most commonly made calls that my application madeto my backend server, being sure to get a measure of simple HTTP GET requestsfrom my API, as well as some of the more complex HTTP POST operations, suchas updated user locations on the server. Each of these measurements of the la-tency of the round trip time of the request has been taken over an average of threetimes to try and ensure more reliable results. The results of some of these tests aredetailed in the following table.

Server-side XHR Response Times in Milliseconds (ms)API method HTTP Method Time 1 Time 2 Time 3 AveragegetUserData GET 112 113 106 110.3

retrieveCarerLocations GET 248 104 216 189.3userSync POST 311 280 268 286.3

From the above table you can see how my server has average response timeswhich range between 100ms and 300ms which I feel are within acceptable waittimes for users in terms of being willing to wait for a web based action to complete,with 1 second being a likely upper bound to this time before users will becomefrustrated or sense that something has gone wrong with that particular request[28]. It should also be noted that this is affected by user’s connection speeds.

Although I performed this basic set of performance tests, I would have verymuch to have also liked to have stress tested my server, by having many tens orhundreds of users try to use the application in conjunction with the live server-sidecode, which is automatically scaled in terms of allocated hardware and networkresources by OpenShift. However, this has proven to be impractical to perform inreality, but would definitely be necessary if the application was to be developedfor an enterprise scale release.

29

Chapter 4

Reflection and Conclusion

In this chapter I will be exploring the ways in which I executed planning and timemanagement with regards to the development of my project, as well as how well Ithink I performed in the execution of these tasks. Furthermore, I will be analysingwhat I have actually managed to achieve as a result of the project’s development;how successful I have been in achieving these things; the knowledge I feel I havegained as a result and some of the flaws I have been able to identify with thearchitecture of my project.

4.1 Time Management and PlanningIn this section I will be taking a detailed look at the time management and plan-ning exercises I undertook for the sake of this project and how the realities of itsdevelopment compared to my initial plans. This also includes a discussion of theoriginal milestones I put in place for the project plan, and how the resulting projectdevelopment fulfilled these milestones or didn’t as was sometimes the case.

4.1.1 Original Plan and MilestonesWhen I first began this project, I laid out an initial development plan which wascentred around mapping the approximate 33 weeks of development time to whichof the features of my application I would develop in each given week. In additionto this I also laid out a series of a few important milestones, which would markthe end and beginning of significant phases of this development time. The originalmilestones which I came up with were:

30

1. Plan Deadline

2. Begin Development

3. Core Development Ends

4. Additional Development (Portal) Ends

5. Code Submission Deadline

6. Report and Screencast Submission

Although I have largely managed to adhere to the above milestones and afore-mentioned plan, there are a few important ways in which I have deviated from theabove milestones, due to the realities and unforeseen difficulties of the project’sdevelopment.

One such way in which I have deviated, is through the complete omissionof one of the features I had hoped to develop, which was a browser based webportal for carers to access in addition to the stand-alone smartphone application.Ultimately, even though this feature would have indeed been a nice addition to theoverall functionality of the project, I decided to make the best use of the availabledevelopment time and focus my efforts purely on the smartphone application,which had taken longer to develop (at least in terms of a few key features) than Ihad originally allowed for in my initial plan.

Those features which had taken longer to develop were namely the necessaryredevelopment of the server side of the project; the need to re-implement the pushnotification mechanism due to a movement from alpha to beta versions and finallythe more complex nature of implementing geo-locations and geofences within thelocator tab.

Whilst I have previously discussed the more complex than usual nature ofimplementing geofences and geolocations, in addition to the difficulties I encoun-tered whilst attempting to utilise push notification APIs, I have not discussed thedelay caused by the redevelopment of my server-side project.

The delay I encountered here, was due to originally beginning to develop myserver side API using one of the alternative technologies which I discussed inChapter 2; LoopBack.io, in which I had implemented the very first server-sidefeatures such as user registration and authentication. After reaching this stage ofdevelopment with the server side very early in the project’s overall developmentand plan, I realised that it would probably be too difficult, time consuming andcomplex to continue to use this framework and so opted for the simpler yet less

31

sophisticated Express.js, on top of which LoopBack is actually developed anyway.In doing so a delay was caused where I had to redevelop the user registration andauthentication functionality, in a less sophisticated but more effective manner.

Overall, the delay in the development of these features resulted in my plantaking around an extra four to six weeks to complete, and for me to reach the’Core Development Ends’ milestone. Luckily I had allowed time for this, with thecontingency always being the possible abandonment of the browser based portalfeature which was not a core part of the required functionality. Other than this,I was mostly on track for the remaining milestones, which were relatively accu-rately scheduled and predicted in terms of how long I thought I would take toreach these in development.

4.2 Potential Architectural FlawsThis section will cover some of the flaws I’ve come to believe are present in thechoice of system architecture that I have adopted, and potential solutions that Imight implement to remedy these flaws if I was to further develop my project.

4.2.1 MongoDBFirst and foremost, my architecture may have suffered from the choice to use theNoSQL database Mongo DB. Primarily I chose to use Mongo DB as I perceivedthe data “entities” (tables or models) that I would need to store and interact withwould be simple and only related in very limited ways. Whilst this is indeed true,the main advantage of choosing MongoDB remains the speed and its excellentability to scale with a large amount of web traffic. This speed and scalabilityhowever is a tradeoff, sacrificing relational capabilities and various data validationand verification capabilities, one which I did not necessarily take full advantageof as part of an academic project, hence potentially being at a slight disadvantageoverall [29].

4.2.2 Node.jsAlthough I enjoyed very much the ability to use JavaScript as a server-side lan-guage, this architectural choice was not without its drawbacks. As JavaScript isnot a strongly typed or even object-oriented language (although it still supports itsown flavour of object orientation), there is the danger of writing code that is of a

32

lower quality than it would be in a strongly-typed and object oriented alternativesuch as C# or Java, and such a lack of type safety did indeed lead to more than afew bugs which cost time when being fixed and removed [30].

4.2.3 Express.jsAlthough I largely enjoyed working with Express.js, and found both the docu-mentation and support community excellent, there were a few issues which I ex-perienced which were largely due to its internal architectural structure and thestructure it imposed upon the code I had to write when working with it.

One such problem was the fact that the business logic (methods connectedto endpoints) is quite tightly coupled to the “transport layer”, in that methodshad direct influence over precisely what data could be sent to client’s and when,with few validations and verifications imposed providing the ability to transmitany sequence of bytes back to a client. Although this wasn’t a problem for meparticularly, it could well lead to a codebase which is very difficult to maintain forlarger projects, and perhaps a slightly higher level of abstraction from this kind offunctionality would prove useful, even if just from a security standpoint.

Secondly, an issue I did experience was the difficulty sometimes with debug-ging Express.js applications due to the many “middlewares” which are the differ-ent methods which comprise the call stack when a client makes a request to anExpress.js API endpoint, in addition to trying to debug asynchronous functions.These however are relatively small bugbears for a very useful and easy to useframework for creating RESTful APIs using JavaScript [31].

4.2.4 Angular.jsPerhaps another flaw in my chosen system’s architecture could be found in the useof the Angular JS framework. One such way in which Angular is flawed is in thedifficultly of learning to use it effectively and mastering the proper way in whichto add data to the “model” component of this MVC framework; the “$scope”.

The proper use of this “$scope” object is important, as Angular’s “digest cy-cle” is continually and constantly monitoring the entirety of the HTML view’sDOM (Document Object Model - HTML elements) and re-evaluating every “twoway data-bound” variable which has been linked to the view, via the model, fromthe controllers. This is a very resource heavy process and actually has a recom-mended limit of around two thousand to two and a half thousand bound variables,

33

as recommended by Angular’s developers at Google, in order to ensure that pagesdo not become unresponsive and begin to experience performance issues [31] [32].

4.2.5 IonicFor all of the benefits of using the Ionic framework, such as cross-platform supportfor the project from only a single codebase, it too is not without its possible draw-backs. The main such potential drawback being that due to the fact that any Ionicapp is in fact an Angular JS web application, running within an “in-app browser”,there can be for certain use cases of the app, performance issues. These are rarelyapparent when facilitating the majority of functionality required by most modernday applications, even 2-D sprite driven games, however such issues do becomeapparent when wanting to achieve anything more advanced such as 3-D graphics.Fortunately my application was unaffected by such potential failings [33].

4.3 Knowledge GainedIn this penultimate section I will reflect on the knowledge that I have gained asa result of undertaking this project, in terms of technical knowledge as well asknowledge that I have gained pertaining to the context of the project, which isnamely medical technology and the treatment of dementia.

4.3.1 Technical Knowledge GainedBefore beginning this project I had only a limited knowledge and skill with JavaScript,having only really used it to develop the front-end of web applications, with lim-ited exposure to server side programming and mobile application development.

Since undertaking this project however, I would like to say that I have takenmy very limited knowledge and experience with JavaScript and become immersedin a much wider development community, and I am now much more comfortablewith using JavaScript for various purposes thanks to the development of this fullstack JavaScript application.

JavaScript has not been the only front on which I have gained knowledge how-ever, as I have now been introduced to and acquainted with very useful conceptsand types of tools which have various different alternatives across different plat-forms and languages. Examples of such tools with which I am now able to say Ican understand and use are:

34

• Package Managers - Specifically this project makes heavy use of the Bowerpackage manager for front end components and the Node Package Man-ager (NPM) on both the front and back end. I would hopefully be able totransfer these skills for use on another platform’s package manager, such asthe .NET platform’s NuGet package manager, on which NPM is said to bebased.

• Automated Testing Tools - Whilst I had a limited experience with suchtools in the past, having implemented my own automated tests here by mak-ing use of a framework to run the tests and libraries to mock out resources, Ihave been given a real flavour of writing both automated unit and integrationtests.

• Server Side Programming - This project is one of the first real instancesin which I have used Node.js to write a fully functional server side applica-tion, and as a result of doing so I have learned many lessons about the pit-falls and challenges involved in writing RESTful APIs which are requiredto communicate with a persistent store, execute business logic and authen-ticating users whilst managing storage and organisation of application datain a database (albeit non-relational NoSQL).

• (Cross-platform) Mobile Application Development - I have also nowlearned how to develop applications for mobile devices, which opens upa whole range of possibilities in terms of employment and for the creationof applications which I might develop personally. Additionally, I have beenmade thoroughly (and sometimes painfully) aware of the requirements ofweb applications to run on mobile devices in terms of styling; through writ-ing a lot of mobile optimised and platform (iOS or Android) specific SASSand CSS, and I have also become competently familiar with both the An-droid Studio and XCode environments.

• Cloud Computing - I have been introduced to the use of cloud computingservices in the context of application development, through the use of theOpenShift Platform as a Service as previously mentioned. Even thoughthis PaaS is still only a primitive and less advanced service when comparedInfrastructure as a Service (IaaS), my experience still serves as a valuablelesson in the setup, deployment and management of a server side applicationvia a cloud computing platform, and acts as an excellent jumping off pointfor interacting with more advanced technologies in this area.

35

The above list is just some of the main things which I have been able to takeaway from this project, and I am sure there are many more subtle, yet still just asuseful skills and practices which I have strengthened over the course of the project,which should hopefully stand me in good stead for when I come to graduate.

4.3.2 Knowledge Gained About Project ContextIn addition to a whole host of new concepts I have learnt about technically, I havealso gained some more insight into the world of medical technology, and morespecifically into the range of technological tools that is being developed to helppeople live with dementia and similar diseases.

Primarily, I have learned that there is a very large opportunity for technology toimprove the quality of life for people living with such illnesses, and that althoughcurrent solutions may be good, many, especially in the realms of helping peoplewith dementia, have a long way to go in terms of improvement before they canbecome useful on a large scale and see wide adoption by their target audiences.

Another issue with both medical technology and assistive technology for de-mentia patients and their carers is access to this technology, especially in termsof price. Whilst my project, as a somewhat underdeveloped academic tool is free,many such similar tools are not, and this is a huge deterrent for potential users whoare likely already facing huge financial stresses due to their illnesses which is per-haps another of the most striking things I have come to realise when performingresearch for this project.

4.4 Achievements and ResultsThis section is written as a means of conclusion to this report for the project, andbriefly reflects on what has been achieved as a result of its development.

On the whole, I would say I have managed to successfully create a functioningsmartphone application for both the iOS and Android platforms and have beenable to allow them to authenticate, communicate and depend upon a live serverwhich is hosted on a cloud computing platform. I have implemented most of thefeatures which I had originally set out to when creating my project plan, and I feellike the end result is both a user friendly experience and reliable, whilst hopefullybeing of some use to potential users.

I do plan to continue the development of this project, and I am currently intalks with the Manchester Royal Infirmary who have been looking for a tool sim-

36

ilar to the one I have produced here. My plan is to let the hospital continue thedevelopment of this software using their own development teams, and hopefullyremain involved to see if it is of any real use to the people it is aimed at helping,and hopefully I will see that it proves to be of at least some small value to people,as a means of improving their day to day lives as patients of dementia in additionto helping their respective carers. I have prepared an extended demonstration ofthe basic functionalities of my project, which can be seen in my screencast, andany feedback or comments are welcomed.

37

Bibliography

[1] World Health Organization. Health Technology. Accessed: 2016-04-08. 2015.URL: http://www.who.int/topics/technology_medical/en/.

[2] Alzheimer’s Society. Assistive technology devices to help with everydayliving. Accessed: 2016-04-08. 2015. URL: https://www.alzheimers.org.uk/site/scripts/download_info.php?fileID=1779.

[3] Victoria Twentyman. Medical wearables to help UK ageing population.Accessed: 2016-04-08. 2015. URL: http://raconteur.net/technology/medical-wearables-to-help-uks-ageing-population.

[4] Assistive Technology Dementia. The benefits and limitations of assistivetechnology. Accessed: 2016-04-08. 2015. URL: https://www.atdementia.org.uk/content_files/files/The_benefits_and_limitations_of_assistive_technology.pdf.

[5] Facts for the Media. Accessed: 2016-04-11. 2016. URL: https://www.alzheimers.org.uk/site/scripts/documents_info.php?documentID=535&pageNumber=2.

[6] Smartphone OS Market Share, 2015 Q2. Accessed: 2016-04-11. 2015. URL:http://www.idc.com/prodserv/smartphone-os-market-share.jsp.

[7] Anne-Marie Botek. Why a Daily Routine is Helpful for People with Demen-tia. Accessed: 2016-04-11. 2016. URL: https://www.agingcare.com/Articles/daily-routine-for-people-with-dementia-156855.htm.

[8] Jeff Anderson. How to Stop the Alzheimer?s Wandering Crisis. Accessed:2016-04-11. 2013. URL: http://www.aplaceformom.com/blog/10-8-2013-how-to-stop-the-alzheimers-wandering-crisis/.

38

[9] About Node.js. Accessed: 2016-04-11. 2016. URL: https://nodejs.org/en/about/.

[10] Carey Wodehouse. Express.js: A Server-Side JavaScript Framework. Ac-cessed: 2016-04-11. 2015. URL: https://www.upwork.com/hiring/development/express-js-a-server-side-javascript-framework/.

[11] Michael Kennedy. MONGODB VS. SQL SERVER 2008 PERFORMANCESHOWDOWN. Accessed: 2016-04-11. 2010. URL: https://blog.michaelckennedy.net/2010/04/29/mongodb-vs-sql-server-2008-performance-showdown/.

[12] Apache. Apache Cordova. Accessed: 2016-04-11. 2016. URL: https://cordova.apache.org/.

[13] Drifty Co. Ionic Framework. Accessed: 2016-04-11. 2016. URL: http ://ionicframework.com/.

[14] jdool8888. PhoneGapBuild iOS Build Fails. Accessed: 2016-04-11. 2016.URL: https://github.com/cowbell/cordova-plugin-geofence/issues/135.

[15] Tempus35. Error in new iOS code for JS function. Accessed: 2016-04-11. 2016. URL: https://github.com/cowbell/cordova- plugin-geofence/issues/122.

[16] Alberto Pose. Cookies vs Tokens. Getting auth right with Angular.JS. Ac-cessed: 2016-04-11. 2014. URL: https://auth0.com/blog/2014/01/07/angularjs-authentication-with-cookies-vs-token/.

[17] Drifty Co. Full Setup. Accessed: 2016-04-11. 2016. URL: http://docs.ionic.io/docs/push-full-setup.

[18] Drifty Co. iOS Push Profiles. Accessed: 2016-04-11. 2016. URL: http://docs.ionic.io/v2.0.0-beta/docs/ios-push-profiles.

[19] Drifty Co. Android Push Profiles. Accessed: 2016-04-11. 2016. URL: http://docs.ionic.io/v2.0.0-beta/docs/android-push-profiles.

[20] IBM StrongLoop. LoopBack.io. Accessed: 2016-04-11. 2016. URL: http://loopback.io/.

[21] RedHat. OpenShift PaaS. Accessed: 2016-04-11. 2016. URL: https://www.openshift.com/.

39

[22] Microsoft. Microsoft Azure. Accessed: 2016-04-11. 2016. URL: https ://azure.microsoft.com/en- gb/?WT.srch=1&WT.mc_ID=SEM_WS1bucqG.

[23] Apprenda. IaaS vs PaaS: Software Platforms and Infrastructures-as-a-Service.Accessed: 2016-04-11. 2016. URL: https://apprenda.com/library/cloud/iaas-vs-paas-software-platforms-infrastructuresasaservice/.

[24] Mocha Test Framework. Accessed: 2016-04-12. 2016. URL: https : / /mochajs.org/.

[25] Chai Assertion Library. Accessed: 2016-04-12. 2016. URL: http://chaijs.com/.

[26] visionmedia. Super-agent driven library for testing node.js HTTP serversusing a fluent API. Accessed: 2016-04-12. 2016. URL: https://github.com/visionmedia/supertest.

[27] Genymotion. Excretion. Accessed: 2016-04-12. URL: https://www.genymotion.com/features/.

[28] Jakob Nielsen. Response Times: The 3 Important Limits. Accessed: 2016-04-12. 1993. URL: https://www.nngroup.com/articles/response-times-3-important-limits/.

[29] UpGuard. MySQL vs MongoDB. Accessed: 2016-04-30. 2016. URL: https://www.upguard.com/articles/mysql-vs-mongodb.

[30] David Haney. To Node.js Or Not To Node.js. Accessed: 2016-04-30. 2014.URL: http://www.haneycodes.net/to-node-js-or-not-to-node-js/.

[31] Richard Clayton. MEAN’s Great But Then You Grow Up. Accessed: 2016-04-30. 2014. URL: https://rclayton.silvrback.com/means-great-but-then-you-grow-up.

[32] Mircea Moise. AngularJS: The Bad Bits. Accessed: 2016-04-30. 2014. URL:https://www.thoughtworks.com/insights/blog/angularjs-bad-bits.

[33] Pritam Bala. The advantages and disadvantages of using Ionic framework,compared to native apps. Accessed: 2016-04-30. 2015. URL: https://www . linkedin . com / pulse / advantages - disadvantages - using -ionic-framework-compared-pritam-bala.

40

[34] Google. AngularJS. Accessed: 2016-04-11. 2016. URL: https://angularjs.org/.

[35] Jakob Jenkov. Dependency Injection Benefits. Accessed: 2016-04-11. 2014.URL: http : / / tutorials . jenkov . com / dependency - injection /dependency-injection-benefits.html.

41

Appendix A

Appendices

In this section I have included some details which I felt may have been superfluousto the report proper, but still perhaps useful to gain some more insight into thetechnologies I have used and my process of development.

A.1 Application Design and Structure In Depth

A.1.1 Frontend Application Structure

Figure A.1: An example of dependency injection in Angular JS

In terms of the client side, the majority of the application code was written in theaforementioned Angular JS MVC framework for creating rich web applications[34]. Although mostly given as “good practice” when developing an Angularapplication, I made sure as to structure my application code in such a way for it tobe as modular as possible and to ensure I was practicing good design principles.

42

One way in which I did this was through the methodology of “dependencyinjection” which reduces the coupling of interoperating components of my appli-cation and improves code reusability, by having components declare their requireddependencies as parameters, and have these passed in to them upon being instan-tiated by a parent, as opposed to explicitly instantiating said dependencies withineach component itself. An example of this can be seen in Figure 2.2 [35]. In addi-tion to this, my application is structured using an MVC (Model, View, Controller)pattern, with HTML acting as the ’view’, and Angular “controllers” which are“2 way bound” using an object referred to as an Angular “$scope”, with Angu-larJS internal code to automatically update the HTML views depending on actionswhich are written in controllers.

Figure A.2: Angular project structure

Also, when communicating withmy backend REST API, I used the no-tion of a “service factory” which con-tains all of the functions to send webrequests to my server, and is instanti-ated once by the overall Angular appli-cation and then injected into any con-trollers which state it as a dependencyin their headers, this again makes useof a good design principle of a ’sin-gleton’ with a single instance reducingmemory footprint and providing a sen-sible structure to my application.

Each of these factories communi-cated with both my server and thecontrollers via the use of JavaScript“promises” which allowed me to writereadable asynchronous code, and en-capsulate any code which was to berun as the result of a web request inthe form of a “callback” to be run afterthe call to my server-side had returned,

which can take any arbitrary amount of time. This can be seen from Figure A.2,which demonstrates the structure of my Angular app.

43

A.1.2 Backend Application StructureIn contrast to the client-side of my project, the server-side of my application hasfar less of a structure imposed upon it by the framework that I have chosen to use,and so in this instance I have derived a simplistic structure of my own which issomewhat determined by the use of the Express.js framework, Node.js and Mon-goDB.

Figure A.3: Server side project structure

The main way in which I havestructured my server-side code is us-ing the idea of ’models’ which arethe basis for the organisation of doc-ument storage in my MongoDB. Eachmodel has a series of URI API end-points which are associated with it, andeach of these endpoints is linked toa specific method on its given model.For each model there is a model def-inition file to determine which fieldsand datatypes should be present ona model (in addition to if and howthese should be validated), as well asa model controller file to define anyfunctions which should belong to thismodel sensibly. This is demonstratedin the Figure A.3.

In addition to this I have a testdirectory to house my unit tests runagainst my API endpoints and onlytwo other files as used by the ExpressJS framework. “server.js” is used to in-stantiate the server and define my mod-

els and connect to the MongoDB instance, additionally this file controls the webtoken security protocal and ensures all specified endpoints are only accessible toclients providing authenticated user tokens, something I will discuss later in thisreport. Finally, “routes.js” file defines the endpoints, that are made available toany client-side applications consuming my API as can be seen in Figure A.4.

44

Figure A.4: Definition of API endpoints on my server-side application

A.2 External Libraries, Frameworks and Plugins UsedIn this section I will list other third party libraries, frameworks of plugins that Ihave made use of as part of this project’s development with links to their onlinepresence, which are additional to those already provided by the frameworks I havereferenced in the main report:

• Underscore.js - http://underscorejs.org/ - Small JavaScript utility li-brary providing useful helper functions usually found in other more sub-stantial languages such as Java, as JavaScript has not real “standard” set ofutility functions.

• Moment.js - http://momentjs.com/ - JavaScript library used for manip-ulating dates and times usefully. Again, such functionality would likely bea standard library in a more substantial language such as Java or C#.

45

• Cordova Camera Plugin - https://github.com/apache/cordova-plugin-camera- Allows a Cordova/Ionic application to interface with a device’s camera di-rectly.

• Cordova Geolocation Plugin -https://github.com/christocracy/cordova-plugin-background-geolocation- Third party plugin for retrieving geolocation on devices, had to use this asthe official Cordova plugin had open issues which needed to be resolved asmentioned in the main report.

46