22nd May 2015

Android Development

Project CI360 – Mobile Application

Development

Luke Willmer UNIVERSITY OF BRIGHTON JUST DINE APP

pg. 1

Table of Contents List of Figures .................................................................................................................................................................... 2

List of abbreviations .......................................................................................................................................................... 2

Introduction ...................................................................................................................................................................... 3

Rationale and Purpose .................................................................................................................................................. 3

Background Research and Implementation .................................................................................................................. 3

Optimisation ..................................................................................................................................................................... 4

Compatibility ..................................................................................................................................................................... 6

Gestures ........................................................................................................................................................................ 6

Mobiles in Context ............................................................................................................................................................ 7

Screen Captures ................................................................................................................................................................ 8

Evaluative Summary ........................................................................................................................................................ 12

Critical Evaluation ....................................................................................................................................................... 12

Methodology ............................................................................................................................................................... 12

What I Have Learned ................................................................................................................................................... 13

Problems Encountered ............................................................................................................................................... 13

Future Extensions........................................................................................................................................................ 14

References ...................................................................................................................................................................... 15

Appendix ......................................................................................................................................................................... 16

Appendix A Original Time-Gantt Chart ................................................................................................................... 16

pg. 2

List of Figures Figure 1: Android Version Distribution (Mick, 2015) ........................................................................................................ 6

Figure 2: Gestures within Google Maps (Scilligence, 2015) .............................................................................................. 6

Figure 3: Just Dine Landing Page ....................................................................................................................................... 8

Figure 4: Nearby results for 'Chinese' ............................................................................................................................... 8

Figure 5: Extended radius and hybrid map type ............................................................................................................... 9

Figure 6: Settings Activity .................................................................................................................................................. 9

Figure 7: Advanced search result .................................................................................................................................... 10

Figure 8: Advanced search predictions ........................................................................................................................... 10

Figure 9: The About page for this app ............................................................................................................................ 11

Figure 10: Graphical Time-Gantt Chart ........................................................................................................................... 16

List of abbreviations

ADT Android Developer Tools

API Application Programming Interface

APP Application

CPU Central Processing Unit

GPS Global Position System

HTTP Hyper Text Transfer Protocol

JIT Just In Time complier

JSON JavaScript Object Notation

JVM Java Virtual Machine

MBR Master Boot Record

RAM Random Access Memory

SDK Software Development Kit

SHA Secure Hash Algorithm

XML Extensible Markup Language

pg. 3

Introduction

This project was undertaken to provide a user-friendly app that could direct its users to restaurants nearby, by using

Google APIs and the users GPS location. This section will be used to identify the reasons for selecting this Android app

idea, the app’s use within a real-world environment, the background research required to complete this project and

the decisions made throughout this app’s development.

Rationale and Purpose

This app idea was chosen to satisfy the need for an effective restaurant location app, with a brief search on the Google

Play Store only finding restaurant- styled games, and with a minimal number of apps actually providing these necessary

locations. In addition, these restaurant-styled apps seem to be growing in popularity with apps such as ‘BookATable’,

and voucher-styled apps including ‘Groupon’ and ‘VoucherCloud’. This app was developed to provide a more user-

friendly app to use than the main competition: ‘Restaurant Finder’, by identifying any issues with usability or

functionality with the competition which could then be used as part of the development for my app. In addition, my

rationale for developing this app idea was to enable me to gain valuable experience of using APIs, along with different

layouts and structures within the Android development stage.

Background Research and Implementation

This segment covers all of the required research which allowed me to interact with the Google Maps and Places APIs,

along with the Android developing environment. This will be discussed chronologically to help portray the steps taken

from the initial app development stage through to its completion. The entirety of this section covers research that has

been gathered since the project conceptual documentation. To begin, the functionality of spinners had to be

researched, including how they are displayed, and how multiple entries can be added. During this research, it became

evident that using spinners for changing options was more efficient and more effective for conserving space on an

options screen. This is primarily because all of the available options are nested on top of each other, rather than being

displayed sequentially. The implementation of a spinner was crucial for this app as it is used to identify which cuisine

the user is looking for.

This implementation led onto needing to investigate how a button can load a new activity along with a critical piece

of information. The information needed to be sent to the new activity as the user’s chosen cuisine. This investigation

would contribute to the rest of the app’s development as there are multiple activities that need to be loaded within

the app and have important information fed from one activity to another. This research also yielded crucial information

on intents, which calls a new activity to be brought to the front, and ‘putExtra’ which is used to send a piece of

information by attaching a key to it. This key would then be used in the new activity to receive the original piece of

information.

The exploration into the Google Maps API enabled the new activity, which takes in the chosen cuisine type, to integrate

a Map Fragment which the Google Maps API would interact with. Further research detailed that this would require

updates to the Android Manifest, along with the activities’ layout XML file. During this exploration of the Google

documentation, it unveiled valuable information on troubleshooting the Google Maps API if any unexpected errors

should occur. In addition to this, it was revealed that personalised API keys were necessary to help Google identify

which app was attempting to send requests, and receive information. These API keys were generated by combining

the SHA-1 hash value, with the Android apps’ package name.

The integration of Google Maps within the Map Fragment encourages research into creating identifiable markers

which will be used cumulatively with the Google Places API. The desired result would therefore be to create a new

pg. 4

icon, or change the colour of the default markers fashioned by Google. This directed research into

‘BitmapDescriptorFactory’ which can be used to adjust the visuals of a Google Maps marker icon. However, this

research was not deemed a high priority as it only enhances the aesthetics of the app, along with only been usable on

one activity. In addition, this different marker was implemented to help the user identify themselves and their current

location, to all of the result markers sent from the Google Places API.

The following step was to analyse the Google Places API documentation to identify how this can be integrated to work

in synergy with the Map Fragment, and the Google Maps API. This analysis covered how to implement the Google

Places API code into the relevant class, how the HTTP request was constructed, and possible means of filtering the

results that were received back from Google. The code used which executed the Google Places API call was copied

across from an online tutorial which detailed each step necessary to complete this section of my app (Smith, 2013).

The next investigation was to check how the ‘AutoCompleteTextView’ could be implemented into the app, which

would allow the users to search for a specific restaurant by name, rather than by proximity to the user’s location. This

tool would be beneficial to a user as it allows them to show a friend a restaurant that they visited recently. This was

achieved by using a ‘GooglePlacesAutoCompleteAdapter’ which provides a list of predictions based on what the user

has entered in to the text field. This research has identified that for this service to work, the user must have typed at

least three characters before the predictions start populating results. This research also brought to light how these

predictions can be filtered based on the type of results that the app is looking for. The types of filters that can be

applied can be found on the Google Places API Types webpage (Google, 2011).

Optimisation

The Android Lint is a new tool introduced in ADT 16 which scans Android project sources for potential bugs. These

potential bugs may include missing translations, performance problems, unused resources, inconsistent array sizes,

and usability problems (Google - Android, 2012). This tool which is integrated into the Eclipse development

environment was used within this project which identified multiple bugs such as missing translations, and

inconsistencies with icons and images within the drawable files.

Other attempts of optimisation have included using certain data structures over others, removing any unnecessary

objects or instantiated variables that weren’t in use, using static and final parameters where available, attempting to

avoid internal ‘Getters/Setters’, and using known libraries. The importance of using the correct data structures is that

each instantiation may require unnecessary objects being created. An example of this would be between creating a

Map object when compared to creating a SparseArray. The difference between these two objects is that the Map

object creates an Integer value which may not even be used within an Android app.

Map<Integer, String> map = new HashMap<Integer, String>();

SparseArray<String> map = new SparseArray<String>();

map.put(1, "Hello");

(Vogella, 2014)

pg. 5

The use of removing any objects that are created is an obvious way which can be used to increase the performance of

an Android app. This is because it prevents the need for an object to be created which saves memory from being

unnecessarily allocated. Any variable or object that is instantiated will take up valuable memory space even if the

object or variable has not been assigned a value yet. This can be identified by looking at the stack print out from the

JVM or Android device (Kiparsky, 2014).

The next optimisation to attempt is to use the static and final parameters on an objects creation. The use of static

should be used when an object is not accessed from outside of this scope. This can be seen as increasing performance

of an Android app up to 20% faster whilst also indicating from a methods signature that the method cannot be used

to alter an objects’ state (Android, 2012). The use of the final parameter is to indicate that a variable is constant,

meaning that the value of that variable or object is unchanging. This is because all constants are stored within a dex

file1 which will save constant values directly instead of using a field lookup (Android, 2012).

//before

int a = 3141; //Value a can be changed

//after

static final int a = 3141; //Value a is constant and cannot be changed

These constant variables are necessary to be regarded as static otherwise the Java compiler will allocate memory for

a constant in every object of that class: if there are multiple instances of a variable or object, then it can’t be constant.

This can be followed by avoiding the use of ‘Getters/Setters’ which can be a very expensive process within an Android

device. This is because these are classed as virtual methods2 which are even more expensive then instance field

lookups. As these are so expensive, it is much better to directly access the variable or object then attempting to access

through virtual methods. The developers’ page on the Android website indicates that these calls could be up to seven

times quicker accessing a value directly rather than through these virtual methods.

The last potential optimisation is to favour the use of libraries since the JIT may not be able to produce as efficient

code than a library call can. The examples of this provided to Android developers are the use of String.indexOf() with

the related APIs which Dalvik replaces with inline intrinsic and the use of System.arraycopy() (Android, 2012).

1 A dex file is the compiled Android application code (Dalvik Executable). 2 A virtual method is when a Java application executes a method which is determined by the object type in runtime

pg. 6

Compatibility

This section highlights how aspects of this app has been designed for various devices, which may be running different

versions of the Android operating system, and screen sizes. The most notable feature and implementation of this app,

in terms of dealing with different screen sizes, are that any icons used within this app have been created within all of

the drawable folders which are designed to contain these icons. The difference about each folder is that the images

contained in each folder are scaled differently depending on the

size and resolution of the Android device on which this app is

being executed on.

The chosen platform version for this app was Android 5.01, API

21, with the release name of “Lollipop”. This version was chosen

because it is the second latest API version which will mean that

it will contain the most up-to-date features, whilst being

released long enough to have most of the bugs and issues with it

to be patched already. Since the Android market has a varied

audience with a recorded consensus of only 0.4% of Android

users running Froyo and 7.4% running Gingerbread (as seen on

the left), the opted minimum target SDK version was set to API

14, Android 4.0 Ice Cream Sandwich. API 14 was chosen since it

will enable the vast majority of users to be compatible with this

app, whilst not restricting the app in terms of usable code and

style too much.

Gestures

This app does take advantage of the use of gestures within the ‘GoogleMap’ activity which the vast majority of users

will be familiar with, and be happy to use. These gestures include rotating the map, zooming in and out, and changing

the pitch of the map (these can be seen below). These gestures are available from the Google Maps API which provide

the same usability and function that someone would have when using Google Maps on a desktop or laptop machine,

or via a browser.

Figure 1: Android Version Distribution (Mick, 2015)

Figure 2: Gestures within Google Maps (Scilligence, 2015)

pg. 7

Mobiles in Context

This section focuses on how this app was developed with the mobile constraints considered to ensure that the user

would be able to use to app and use all of its functionality. These constraints include screen size, along with reachable

areas, performance, and time and place. This section will also include how certain functionality is implemented and

what requirements need to be met for them to work.

The importance of screen sizes has already been identified within the Compatibility section of this report but this can

be furthered to identify what constraints this will have on the app. Screen sizes can vary a lot for Android devices

which makes the effective use of text to be crucial, the amount of text needs to be kept to a minimum otherwise the

user will have to keep on scrolling, or for the text font size to be smaller. This would not be good in terms of accessibility

for any user with any kind of visual impairment. In addition, the interfaces would have to be kept simple so the user

can quickly identify how each activity works, and that these activities focus on a single function. The simplistic design

required for an Android app is required so that it follows the Android ‘Standards and Convention’ which will allow any

user to be able to this app with minimal experience with it due to the interoperability of these ‘standards’.

The amount of resources available for any given Android device can be regarded as limited when compared to the

quantity of resources available on a desktop or laptop machine. The development of any Android will need to have

this as a crucial consideration as this performance criteria can affect the overall use of the app. This will require the

programmer to take into account the amount of memory allocation that their app will require, overall performance3,

layout performance, battery life, use of multiple threads and app responsiveness. Memory allocation works differently

within the Android operating system than that of a Windows operating system. This is because within Android, ‘any

memory you modify—whether by allocating new objects or touching mmapped4 pages—remains resident in RAM and

cannot be paged out. So the only way to completely release memory from your app is to release object references you

may be holding, making the memory available to the garbage collector’ (Android, 2012). In terms of battery life, the

app needs to be able to run multiple times for short activities, or a long-time for a single activity without having any

major input on the deprecation of the Android devices’ battery life. In terms of ‘Just Dine’, the app will be ran multiple

times in short bursts, as its main function is to identify what restaurants are nearby which won’t take a lot of time to

achieve, unlike a gaming-styled app used to waste a bit of time. The benefit of multi-threading an Android app is that

the CPU provided on Android devices have a slower clock frequency than that of desktop and laptop machines, but

still contain multiple cores. For an app to achieve its performance potential it is imperative to take advantage of multi-

threading which will increase the performance and responsiveness by allocating processes onto multiple cores.

3 This has been covered within the Optimisation 4 Abbreviation meaning memory-mapping

pg. 8

Screen Captures

Figure 3: Just Dine Landing Page Figure 4: Nearby results for 'Chinese'

pg. 9

Figure 6: Settings Activity Figure 5: Extended radius and hybrid map type

pg. 10

Figure 8: Advanced search predictions Figure 7: Advanced search result

pg. 11

Figure 9: The About page for this app

pg. 12

Evaluative Summary

This section covers my personal reflection on the progress and overall outcome of this project, along with any

improvements or changes that I would make if this project had to be repeated. This evaluative summary will begin

with critically analysing the main aspects of this project, which is followed by the Methodology of the project. This will

progress into what has been learned throughout the duration of this project, and any issues that have been

encountered and how they have been overcome.

Critical Evaluation

This section will cover the critique of all the significant portions of my project, including the reason for choosing this

project over other ideas. This idea was chosen as it involved implementing multiple APIs into this project which is

incredibly beneficial for learning how different APIs work and function. The first main important fragment undertaken

was the necessary research required to get the basis of this project functioning. The necessary research required

researching the basics of using Google APIs and integrating this functionality into this app. The next critical section

involves the implementation of the Google Maps API into this project along with the Map Fragment: this will be

followed by the evaluation of the Google Places API implementation. The last critique will be made of the GPS tracking

service used within this project.

The next main important undertaking was to research the implementation of the Google Maps API. This included

reading through the Google Maps documentation and following a video tutorial which provided a step-by-step guide

for adding Map Fragments and linking it to the Maps API. The video tutorial that was used was uploaded by a user

named ‘DrBFraser’ and can be found at this link: https://www.youtube.com/watch?v=awX5T-EwLPc.

The next two aspects of this critical evaluation involves the Google Maps and Places API. These APIs were the first

choice as they have greater supporting documentation, plus a larger community base. The other possibility was to use

the OpenStreetMap API which is a free geographic data service similar to the Google Maps API. The decision to choose

the Google API over OpenStreetMap was based on multiple factors including the prominence of Google over

OpenStreetMap, and the similarity of the Google Maps API and the Google Maps service online which will increase

usability. In addition, the Google Maps API allows integration into the Maps application on any Android device which

will plot out the necessary route from the user’s location to the restaurant’s location.

The GPS tracking service used in this project was implemented from a tutorial which will be placed within the

references section. This tutorial was selected as it provided step-by-step instructions for fully implementing this class

into your current project. The lint process identified that this activity was incorrectly marked as this class is deemed a

service rather than an activity. This would have been better if the implementation of GPS tracking was not sourced by

someone else, but it is common for code to be re-used, if proper reference and accreditation goes to the right people.

Methodology

The methodology used within this project has produced a working app that successfully shows the user’s position

along with the responses from the Google Places API service. As well as this, the user can successfully search for results

by a restaurant’s name instead of performing a standard nearby search. The main downfall of this project is that a

route could not be generated on the Map Fragment since this service is not provided by the Google Maps nor Google

Places API. On the other hand, the Map Fragment has an integrated function to feed the coordinates of both the user

and the chosen destination into the Google Maps app installed on an Android phone which successfully plots out the

route on to the Map Fragment. In addition, this functionality allows the user’s position to be updated which will also

update the route required to reach their destination. This functionality has been implemented using the

pg. 13

‘LocationManager’ which will attempt to update the user’s position based on two different factors, these being

distance or time. This means that the user’s position would be updated if they travelled enough distance or enough

time has passed since the last previous update.

The planning stage for this project produced a Time-Gantt chart which was primarily created for tracking the progress

of this project, to determine if the project is running on-time, ahead, or behind schedule. As expected for the initial

plan, the schedule was not kept to, and changes were necessary to produce a more realistic time frame that could be

kept to. The main issue with the initial Time-Gantt chart is that the main development along with the sections for

implementing improvements were too short which did not provide enough time for these stages of the project to

completed successfully. Furthermore, the initial plan had many detailed steps but the actual schedule was much less

detailed. This simply resulted from the development schedule taking up the vast majority of this project’s duration.

What I Have Learned

This section covers the main learning aspects of this project, including the implementation of code but also information

that have been gathered through research, but not necessarily added into this project. Below is a list of all of the main

learning points that have been identified during this project:

How to create multiple intents and feed through information by using putExtras

How to implement a Map Fragment that interacts with the Google Maps API

How markers can be placed onto the Map Fragment, both dynamically and statically

How Google Places can be used to provide a nearby or detailed search

The benefits of using SharedPreferences over variables

Problems Encountered

There were a number of challenges that were necessary to overcome, both in terms of the research required and the

limitations based on the Google APIs, and unforeseeable events such as system crashes and corruption. The first

challenge that was necessary to overcome was to enable any Android device to connect to the Eclipse IDE. This issue

was caused by every Android device having a different device driver, and identifying the correct driver which is

compatible with the Google USB driver downloaded from the Android SDK. This resulted in all testing being performed

on an LG Nexus Android device as this device’s drivers were compatible with this Eclipse environment and more

reliable than any other devices.

The next problem faced was establishing how the Google Places API integrated into the development of the app. This

was an issue because the two API services Maps and Places require different types of API key for the Map Fragment

and the Places integration; the Maps API requires an Android specific key whereas the Places API requires a browser

specific key. These different keys also require a different form of implementation, as the Maps API key must be

implemented within the Android Manifest, whilst the Places API key needs to be implemented within the java code.

The next issue was very fatal which was caused by corruption of the MBR which required a format, and fresh install of

the Windows Operating System. This setback caused delays within the development of the app along with the research

required to succeed in each part of this project. This issue caused the same driver compatibility issue to be faced, and

the attempt to recover any lost information. The Eclipse workspace was being automatically uploaded onto cloud

storage to mitigate any loss of information caused by hard drive failure, or corruption.

Another complication that had to be dealt with was caused by issues with the Google APIs connected with the Google

Mail account linked up with this project. The reason for this is still unknown as the valid API key was working initially

pg. 14

but its status changed from ‘Active’ to ‘Activation end-date’ which seemed to occur unprovoked. This was corrected

by removing all of the API keys that were linked to this project, and re-instantiating a new key for Android devices and

Browser access, which created new generated keys.

Future Extensions

This section covers any future extensions that would be beneficial to the users of this app including improved

accessibility for visually impaired users, detailing more information on the places search, and to increase the

responsive feedback to the user.

The need for more accessibility options are necessary to ensure that everyone can use this app comfortably and

without any strain on their eyes. The potential improvements that will be focused upon are allow the user to increase

and decrease the size of all fonts within this app, add in a colour-blind option that will attempt to provide an easier to

view colour scheme. These extra options could be added into the settings activity, or could be separated into its own

accessibility tab to help the users identify that this app takes accessibility as a consideration. This can be regarded as

a high priority extension as it will allow a larger audience to use this app, along with being seen as considerate within

the mobile app development community.

The next extension that is being considered is to provide more details for each place marked out on the ‘GoogleMap’

activity. This extra information would include a rating, photos as well as Google’s summary of the restaurant which

will be obtained via the Google Places JSON response. The rating will be useful for users of ‘JustDine’ as it will detail

what other customers have said or felt that restaurant which may affect the users’ decision of going to that selected

restaurant. The use of the photos will help allow the user to identify the restaurant that they’ve selected, whilst the

Google description can give a brief overview of what the restaurant is actually like. This extra information could be

provided to the user through the use of ‘OnInfoWindowClickListener’ which is a listener provided by the Google Maps

API. This can be used by calling a new activity which will be used to dynamically change its text, rating and images

depending on the location that the user has selected. When the user first selects a restaurant marker, a little

information window is shown detailing its name and address. The user can then press it again which will call the

‘OnInfoWindowClickListener’ which can either pass all of the information as a ‘putExtra’ or by recalling the Places API

response for the individual location based on its id. This should be manageable as the ‘AdvancedSearch’ activity

performs a search on ids to locate the specific restaurant being searched for. This extension would be given a medium

priority as the implementation of this would provide more useful information to the user, but the extensions that

increase usability should be prioritised higher than other extensions. In addition to this, the app works perfectly

without this extension, as all of the necessary information for a user to find this restaurant is provided, and the user

can feed the restaurants’ location into the Maps app provided on every Android device to plan out the quickest route

to the restaurant.

The ‘JustDine’ app does provide feedback to a number of issues that may occur during the use of this app such as

having no internet connectivity or the Android device needs to update its Google Play Store. However, this app doesn’t

provide any responsive feedback to the user when its’ processing the Google Places API response, meaning that on a

slow Wi-Fi connection or having a poor mobile data signal, the app may appear to be unresponsive. This issue has

been provided a low priority as, in the vast majority of cases, the location markers have been placed instantly or within

a negligible amount of time. A feedback mechanism could be put in place, such as a spinner or a loading bar, which

will aid the app in portraying that its processing information, whilst indicating that the app isn’t unresponsive. The way

that this could be achieved is by placing an overlay on the ‘GoogleMap’ activity which will cause this loading spinner

or bar to be shown until the activity is ready for both nearby searches or an advanced search.

pg. 15

References Android, 2012. Managing Your App's Memory | Android Developers. [Online]

Available at: http://developer.android.com/training/articles/memory.html

[Accessed Friday, 22nd May 2015].

Android, 2012. Performance Tips | Android Developers. [Online]

Available at: http://developer.android.com/training/articles/perf-tips.html

[Accessed Wedensday, 20th May 2015].

Google - Android, 2012. Android Lint. [Online]

Available at: http://tools.android.com/tips/lint

[Accessed Monday, 11th May 2015].

Google, 2011. Places Types - Google Places API. [Online]

Available at: https://developers.google.com/places/supported_types#table3

[Accessed Monday, 30th March 2015].

IQ Agency, 2012. Mobile Web vs. Native Apps. [Online]

Available at: http://www.slideshare.net/IQ_Agency/mobile-web-vs-native-apps

[Accessed Thursday, 21st May 2015].

Janssen, C., 2011. What is the Mobile Web? - Definition from Techopedia. [Online]

Available at: http://www.techopedia.com/definition/23588/mobile-web

[Accessed Thursday, 21st May 2015].

Kiparsky, J., 2014. Do unused local variables in a method acquire memory in JVM?. [Online]

Available at: http://stackoverflow.com/questions/26632799/do-unused-local-variables-in-a-method-acquire-

memory-in-jvm

[Accessed Wednesday, 20th May 2015].

Mick, J., 2015. DailyTech - Android Lollipop Has Less App Creashes Than iOS8, Says Study. [Online]

Available at:

http://www.dailytech.com/Android+Lollipop+Has+Less+App+Crashes+Than+iOS+8+Says+Study/article37158.htm

[Accessed Wednesday, 20th May 2015].

Smith, S., 2013. Android SDK: Working with Google Maps - Displaying Places of Interest - Tuts+ Code Tutorial.

[Online]

Available at: http://code.tutsplus.com/tutorials/android-sdk-working-with-google-maps-displaying-places-of-

interest--mobile-16145

[Accessed Monday, 23rd March 2015].

Vogella, 2014. Android memory and performance optimization. [Online]

Available at:

http://www.vogella.com/tutorials/AndroidApplicationOptimization/article.html#androidperformanceandmemoryop

timization3

[Accessed Wednesday, 20th May 2015].

pg. 16

Appendix

Appendix A Original Time-Gantt Chart

Task Name Duration Start Finish Predecessors Milestone

Phase One 0 days Mon 01/12/14 Mon 01/12/14 Yes

Feasibility Check 3 days Mon 01/12/14 Wed 03/12/14 1 No

Identify Requirements 5 days Thu 04/12/14 Wed 10/12/14 2 No

Phase Two 0 days Thu 11/12/14 Thu 11/12/14 1,3 Yes

Create Wireframes 5 days Thu 11/12/14 Wed 17/12/14 4 No

Research Implementation Techniques 10 days Thu 18/12/14 Wed 31/12/14 5 No

Identify APIs required 5 days Thu 18/12/14 Wed 24/12/14 5 No

Submit Conceptual Report 17 days Thu 01/01/15 Fri 23/01/15 6,7 No

Implement First Draft Design 30 days Mon 26/01/15 Fri 06/03/15 8 No

Testing functionality and usability 3 days Mon 09/03/15 Wed 11/03/15 9 No

Add Improvements 10 days Thu 12/03/15 Wed 25/03/15 10 No

Phase Three 0 days Thu 26/03/15 Thu 26/03/15 11 Yes

Ensure working functionality 3 days Thu 26/03/15 Mon 30/03/15 12 No

Phase Four 0 days Tue 31/03/15 Tue 31/03/15 12,13 Yes

Create First Draft Report 10 days Tue 31/03/15 Mon 13/04/15 14 No

Create Second Draft Report 10 days Tue 14/04/15 Mon 27/04/15 15 No

Submit Finalised Version 20 days Tue 28/04/15 Mon 25/05/15 16 No

Figure 10: Graphical Time-Gantt Chart