dissertation (f21mp) - hw · this dissertation project aims to develop a location-based game for...

MASTERS DISSERTATION (F21MP)

TITLE : A location-based orienteering game

MATRICULATION NUMBER:

H00116535

DATE: COURSE CODE: COURSE NAME:

16.08.2012 F21MP Masters Project and Dissertation

PROGRAMME: PAGES / ATTACHMENTS: BIBL. NR:

Advanced Internet Applications /

SUPERVISOR : Hamish Taylor

ABSTRACT:

Location-based games (LBG) are popular today with increasingly more advanced mobile hardware and software technologies. But they still face unresolved challenges with high battery consumption, inaccurate location updates, and location-based cheating; to name a few.

This dissertation project aims to develop a location-based game for Android mobile devices that will support recreational use of maps, a digital compass and location sensing hardware to create an appealing location-based game that will face some of the mentioned challenges.

Table of Contents

1 INTRODUCTION 6 1.1 INTRODUCTION 6 1.2 OBJECTIVES 6 1.3 PROBLEM STATEMENT 8 1.4 RELATED WORK 9

2 LITERATURE REVIEW 10 2.1 LOCATION-BASED MOBILE GAMING 10

2.1.1 Location-based Mobile Games 11 2.2 CLIENT-SIDE TECHNOLOGY 11

2.2.1 Activity Lifecycle 12 2.2.2 A user interface that promotes careful battery usage 14 2.2.3 The user interface 19

3 REQUIREMENTS 22 3.1 OBJECTIVES 22 3.2 FUNCTIONAL REQUIREMENTS 24 3.3 USER REQUIREMENTS 25

4 ARCHITECTURE AND DESIGN 26 4.1 CLIENT ARCHITECTURE OVERVIEW 26 4.2 DISTRIBUTED MULTI-LAYER ARCHITECTURE 30 4.3 DESIGN 32

4.3.1 User interface design 33 4.3.2 Class design 35 4.3.3 Deployment diagram 38 4.3.4 Database design 39

5 IMPLEMENTATION AND RESULTS 41 5.1 CLIENT SIDE 41

5.1.1 Database implementation 42 5.1.2 Creating and storing a route 42 5.1.3 Route selection for orienteering 48 5.1.4 The background Service 49 5.1.5 Main Fragment 56 5.1.6 Navigation Fragment 59 5.1.7 Events Fragment 65

5.2 SERVER SIDE 66

6 EVALUATION 67 6.1 EVALUATION RESULTS 69 6.2 ANALYSIS OF RESULTS 71

7 CONCLUSIONS AND FUTURE WORK 73

8 REFERENCES 75

Abstract Location-based games (LBG) are popular today with increasingly more advanced mobile

hardware and software technologies. But they still face unresolved challenges with high

battery consumption, inaccurate location updates, and location-based cheating; to name

a few.

This dissertation project aims to develop a location-based game for Android mobile

devices that will support recreational use of maps, a digital compass and location sensing

hardware to create an appealing location-based game that will face some of the

mentioned challenges.

List of Figures

Figure 1. The system architecture of an Android device. Figure 2. The lifecycle of an activity. Figure 3. Showing the coordinates axes on an Android device.

Figure 4. Showing a simple mark-based gesture. Figure 5. Displaying relevant architectural layers. Figure 6. Activity lifecycle. Figure 7. Distributed architecture Figure 8. UI activities and fragments

Figure 9. Class diagram. Figure 10. Package design Figure 11. Deployment diagram Figure 12. SQite database Figure 13. MySQL database Figure 14. Radio button tools Figure 15. Save route dialog

Figure 16. User registration Activity Figure 17. User login Figure 18. Route selection Figure 19. Movement data collector app Figure 20. Main/first UI fragment Figure 21. Navigation UI fragment Figure 22. x-y sceen coordinate angles Figure 24. Sketch of angles problem and solution Figure 25. Events UI fragment

Source Code Listing Listing 1: Projection and drawing overlay on map Listing 2: Geocoding Listing 3: Adding proximity alert (LBS) Listing 4: Collect movement data and analyze Listing 5: Conditions for stopping/resuming LBS Listing 6: Proximity alert broadcast Listing 7: Sensor event and movement processing Listing 8: Calculating orientation angles

1 INTRODUCTION

1.1 Introduction In my dissertation I investigate the use of a wider range of embedded mobile computing

hardware relevant for supporting the development of a location-aware orienteering

application, similar to traditional orienteering, where physical maps, a magnetic compass

and a stop watch will be replaced by technologies that are available on most

smartphones today.

The goal is to make an appealing location-based game (LBG), mainly built around the

Search-and-Find game pattern that will be evaluated by other students. The success

story out there for location-based games is primarily Geocaching, and this project takes

some inspiration from it and attempts to provide the ground work for developing a full-

fledged Search-and-Find LBG.

Relevant mobile computing hardware, as mentioned before, refers to embedded sensors

and tracking technologies, such as: GPS, accelerometer and geomagnetic field sensors.

These hardware technologies will be utilized in order to integrate compass features for

aiding in navigating different terrains, conserve battery power, and help users with the

essential task of finding control points, which are not displayed on any map.

Another important requirement that the success of this project rests on is how angles

(directions) are calculated and presented to users; informing them of where to turn to in

order to face in the direction to their target location. The Google Maps API turns out to be

useful in this task.

Promoting physical activity with entertainment, outdoor social interaction and

competition adds to the motivations behind the development of this LBG. As obesity rates

are high in Europe and other parts of the world (Bassett, Pucher, Buehler, Thompson and

Crouter 2008), location-based applications can promote the adoption of a more healthy

and active lifestyle. A study has already shown the potential of this (Lin, Jessurun, Vries

and Timmermans 2011).

1.2 Objectives The main objective of this thesis is to develop an interactive navigation system in a

location-aware application for mobile Android devices. This is accomplished by utilizing

the Google Maps API, location sensing services and embedded sensors.

Users will be able to create routes by using Google Maps to set the start location, one or

more control point locations, and the end location before being able to store them in a

local database. Geographical coordinates (longitude and latitude) are retrieved from this

interaction with a map, and proximity alerts are registered to them during a race (one by

one based on route progression) in order to receive call-back alerts from the location

service on when users find themselves within the proximity of a targeted location.

The product resulting from this development project aims to promote outdoor physical

activity and entertainment with recreational use of the navigation system in timed

events. An evaluation will be performed in order to quantify the level of success attained

through design and implementation decisions, but also to uncover weaknesses that led to

some dissatisfaction with users’ experience; and make informed decisions on

improvements based on the criticism.

The primary objectives for this thesis are summarized as follows:

• To provide tools and methods for creating and storing routes by interacting with

Google Maps and placing markers representing the different types of locations

that are required for users to go through, from start to finish.

• To apply the benefits of using an Android Service thread to separate from the

main UI thread and do different calculations in the background (geocoding, server

communications etc.). The main objective is to enable users to interact with other

application UIs on top, like answering phone calls or replying to an email, without

interrupting the computing necessary to operate FootO while its UI thread is

paused. Increasing the performance of UI interaction is another benefit of using

another thread for more intensive computing, thereby increasing task

parallelization.

The local database and storage of key-value pairs are taken advantage of by the

background Service to store data necessary to update the UI with information

whenever it is resumed from a paused state.

• To utilize embedded sensors to create an accurate magnetic compass.

• To use the x/y on-screen pixel coordinates taken from the object representing a

user’s position on a map; to accurately calculate the geographical angle to a

targeted location object. The objective is to inform users of which direction to

rotate the compass, and is therefore crucial for the project to succeed.

• To use the implementation of proximity alerts to inform users when they have

arrived at a targeted location. There are currently two purposes for this:

1. Not allowing users to start a race if they are outside the proximity of the

start location. This is to prevent attempts at cheating by not allowing users

to get a significant head start.

2. Automatic registration with control points when users have found the

correct locations and are within their proximity. And using the same

method to stop a race automatically at the end location.

• Taking advantage of the accelerometer to gather movement data and determine

when the mobile device is not moving much, in order to disable the use of

wireless radios for location-based services. Main purpose is to extend battery life

when GPS is not required.

• To provide a foundation for future work by implementing user registration and log

in features, and route uploading to user accounts.

• To score high on user satisfaction in general, but notably with the use of swipe

gestures for navigating between the three game-active views when using a route.

And to discover if it is also preferable to add soft buttons for navigating the views.

• To implement text-to-speech notifications of events; immediately when they

happen. For example, of when arriving at a control point and what the next target

is. This feature is included in the evaluation and the aim is to achieve success with

users on the practicality of having text-to-speech as a tool for notifying.

1.3 Problem Statement The founding idea behind this project was develop a type of orienteering application for

recreational sport and exercise purposes, similar to traditional orienteering, where

physical maps, a magnetic compass and a stop watch would be replaced by technology

available on a single mobile computing device.

With the availability of such advanced technology, and in addition using location-based

services, it is possible for the application to perform calculations to further support users

in navigating from location to location by presenting useful information in a usable UI.

The primary challenges where solutions are provided for this thesis are summarized in

the following list:

• Developing methods for creating routes that do not require users to travel outside

and collect the geographical coordinates at the positions where they apply.

• Preventing cheating on timed events by not allowing users to begin far ahead

from the start location. This requirement needs to be implemented and ready for

deployment in future development on distributed, downloadable routes where

users publish competing results.

• Being aware of the end location for the purpose of not allowing users to

successfully finish a race long before they have reached the end point. This is also

to prevent cheating from making a significant impact on results.

• Using x/y on-screen pixel coordinates on a north-based map to find the angle

between two location points, where the first is a user’s position and the second is

a target position (e.g. a control point), and be able to use these values for

rotating the device in the right direction by reading from the compass.

• Implementing the compass by using a combination of available sensors. It is not

enough to only use the magnetic field sensor.

• Using the accelerometer to detect when the device is most likely not moving

forward, providing little movement data. With this kind of capability, wireless

radios can be used less in communication with location services, and thereby

extend battery life.

1.4 Related work Geocaching today is a popular multi-user, high-tech “hide and seek” LBG that encourages

participants to explore locations in a search of one or more caches. It is an activity that

combines the use of handheld devices with GPS receivers, and map skills, and problem

solving abilities in order to successfully find caches. Caches are “real world” containers,

usually waterproof, containing a logbook where participants enter their code name and

the date when they found it. They can also contain items for trading, usually toys or

gadgets of little value. Participants compete to find and log their names to as many

caches as possible (Dyer 2004).

Geocaching.com, owned by Groundspeak Inc., has what can be considered the largest

geocaching community worldwide. They have mobile applications available for Android,

IPhone and Windows Phone. Their website lists more than 1.6 million caches in over 200

countries.

Geocaching is related to the orienteering LBG in the following way.

Using problems solving, or interpreting given directions, to find the unknown

location of an object or place. With geocaching the object is always physical and

the current implementation of the orienteering application use location points as

the end objective of searching for something.

Both follow a search-and-find game pattern.

2 LITERATURE REVIEW Continuing with what the introduction chapter presents on this topic; the software

development behind the thesis aims to create a location-based orienteering game for

Android smartphones, which takes advantage of a wide range available mobile hardware

for this purpose, and web server technologies to create a distributed internet application.

For future reference in this chapter; the main ideas behind this thesis will be listed below

by first describing challenges to location-based.

2.1 Location-based mobile gaming A location-based game (LBG) is typically defined as a form of game play that is designed

for a handheld device in motion, where the gaming experience progresses via a player’s

location. Location-based services with a map API are essential to creating a LBG, and are

usually backed by a third-party server to connect users/players with each other’s

locations, and to publish new and changing game content.

The essence of location-based gaming is to move computer gaming away from behind

the PC and into the “real world” of cities, parks, forests and other locations.

Search-and-Find game pattern

Search-and-Find is a popular game pattern where each player has to find a certain

geolocation (Lehmann 2012). The relevant method of finding a location is based on

directing, or guiding, players using a navigation system within the game. The locations

are always static/unmoving points in the game world, meaning that the location does not

change while playing.

With the orienteering application there are plans to change the location of control points

to add unpredictability to routes when a user is already familiar with the various locations

from having run the same route on a previous occasion. This makes routes more

reusable and navigation mechanisms more meaningful when they have to be relied upon.

The locations will not change during game play.

2.1.1 Location-based Mobile Games Lehman’s seminar paper (Lehmann 2012) describes and discusses game patterns and

game types that are possible with location based games, and the different usage

possibilities (entertainment, education, physical activity and advertising).

In section 6 of Lehmann’s paper there are discussions on future challenges facing LBGs,

which have not been fully solved. Some of these challenges are tackled in the

dissertation project in order to try and improve the LBG experience for all. The

challenges mentioned, that will be tackled in the dissertation, are as follows.

1. Energy consumption. Frequent location updates over time are known to

consume a lot of battery power. GPS is not the only target for power

management, but also in combination with an accelerometer, and magnetic field

sensors. This is addressed in section 2.1.2.

2. Location-based cheating. The dissertation tried to tackle cheating on timed

events by not allowing users to start outside the proximity of the start location,

and have to step inside the proximity of the end location to finish a race.

3. Inaccuracy of positioning systems. Perhaps the most negative effect of

inaccurate location positioning for the orienteering application is that angles to

target (directions) becomes inaccurate as well. One discussed solution is forego

the use of LBS for a while and instead enable users to take charge of placing

themselves on the map, and thereby get the correct calculations.

2.2 Client-side technology This section will introduce the topics concerning client-side development before going on

to discuss and draw support from relevant documentation, and critiquing available

research material and papers on selected topics to form the necessary background for

further elaboration on the challenges to come.

Material on the user interface (UI) will only focus on the screen views shown in an active

orienteering event, and not on views that does not provide a challenge to the

development project, such as a registration form or the main menu.

The Android operating system will be the platform for mobile devices used in this

development project. Android is developed and supported by Google and it has its own

bytecode Virtual Machine (VM), by the name of Dalvik VM, to run application that has

been developed with the Java programming language. Dalvik VM relies on the underlying

Linux kernel for low-level functionality such as threading and memory management.

Competing technologies to the Android OS are Apple’s iOS and Windows Phone.

In the figure below, the major components (also called the system architecture) of the

Android operating system is presented. The most relevant components from this

architecture are the Location Manager (for location-based service functionality), the

SQLite database system and Content Providers.

Figure 1. The system architecture of an Android device.

2.2.1 Activity Lifecycle Before continuing further with discussion on the user interface; it is essential to

understand what an activity is in this context, and to understand its lifecycle.

An activity is a focused screen that users can interact with by touch input. In every

application there is a main activity and each activity can start/launch another and

thereby creating a “back stack”.

When a new activity is started, the previous activity is paused and preserved in the back

stack, which means that the in-memory states are kept but not persisted beyond the

lifetime of the application. One method is guaranteed to be called by the system before

the given activity goes into the back stack, and that is onPause().

In onPause() critical data can be persisted on the local storage through various means.

And if the activity is registered to receive data from a location service, or from some

sensor hardware, then these needs to be unregistered and deactivated in onPause() to

free up resources and avoid runtime errors and battery draining.

When the user goes back to the main activity with the “back” button or by some other

means of navigation, then the activities that were in the back stack will be destroyed

along the way, but not before calling the onDestroy() method where data-persistence

and freeing up of resources can be performed as well. The same applies to the onStop()

method which sometimes can be called (Activities 2012).

Each time an activity becomes active from the back stack; the onResume() method will

be invoked and it is there that the application can register and become active with a

location service again, and enable sensors, to take two examples.

If the activity was destroyed then onCreate() is called to do the same as with

onResume(), but also to initialize and draw up the user interface again .

The following diagram shows the different states of an activity in its lifecycle.

Figure 2. The lifecycle of an activity.

2.2.2 A user interface that promotes careful battery usage The main issue facing the game-active UI is the combination of usable interaction design,

and battery conservation when taking advantage of embedded sensors for the digital

compass, and GPS. Power management and the UI need to accommodate each other

while keeping in mind the different states of an activity as presented in the section 2.1.1.

If sensors are not used carefully used on an Android device, by failing to disable them

when they are not needed, then the battery will be drained relatively quickly

(SensorManager 2012). Listening for GPS location updates over an extended period of

time adds significantly to the battery consumption as well (Lin, Jessurun, Vries and

Timmermans 2011), and sensors will therefore play a role in informing of when to use

location updates.

The remainder of this section contains analysis and evaluation of the literary material

found to support solutions to the challenges mentioned in the paragraphs above. Starting

with the literature on different sensor technologies that are available on the vast majority

of Android devices today, before moving on to topics regarding the UI and how it relates

to the use of sensors.

For sensors, the focus will be on how they can be used to develop digital compasses and

inform of when location-based updates are not required in a standstill situation, by

measuring movement sensory data. The goal is to attain effective power management.

2.2.2.1 Using sensors Sensors in smartphone devices are small hardware components that are embedded into

the larger device; designed to supply data to applications from the physical world.

In Android you register a listener to receive sensor data and use it for processing each

time it comes in (Satya, MacLean and Hashimi 2011).

Examples of sensors are:

Gyroscope sensor

Accelerometer

Magnetic field sensor

Orientation sensor

Gravity sensor (since Android 2.3 API release)

Linear acceleration sensor (since Android 2.3 API release)

Rotation vector sensor (since Android 2.3 API release)

Near Field Communication (NFC) (since Android 2.3 API release)

The sensors relevant to this thesis are the accelerometers and magnetic field sensors.

Accelerometer

Accelerometers can be used to determine the physical orientation of a device in space

relative to the gravitationally pull down a straight line, and at the same time register

forces pushing on the device.

These features opens up opportunities for applications to do a variety of things, such as:

steering racing games by rotating the device, navigating with location based games, and

augmented reality. Perhaps the most used implementation in the Android OS is the

ability to change orientation of activities in to landscape and portrait modes.

The coordinate system of an accelerometer has an x-axis that originates in the bottom

left corner and goes across the phone/tablet to the right. The y-axis originates in the

same place as the x-axis (and z-axis) and goes up along the left side. The z-axis goes

straight up in space, away from the device.

Figure 3. Showing the coordinates axes on an Android device. Acceleration is measured in meters per second squared, and keep in mind that the

gravitation on earth is measured at 9.81 m/s² in a downward pull against the center of

the earth.

If the device is not moving on a perfectly flat surface, the values of x and y will be 0 and

the z value will be 9.81. The only force acting on the device at a flat and standstill state

is thus gravity with small variations in the x and y values when it is not perfectly flat.

The z value can become greater than +9.81 when the device is being lifted up, and if the

device is moved left along the x-axis, then we will get a negative value of x.

Android applications can, by using these values, measure if the device is relatively flat

while reading a digital compass, to take one applicable example. Walking and running

patterns (bouncing up and down) may also be detected by reading the quick variations of

the z-axis values.

This will be useful for detecting movement to satisfy requirements for battery

management in the orienteering LBG for the master thesis, by unregistering for location

updates when the device is most likely not moving forward, and registering for updates

again when more movement data feeds in to the application; predicting that the device

has travelled some distance after, eg., 10 to 20 seconds).

Magnetic Field Sensors

This sensor is also called a compass (android.hardware.sensor.compass), and is used to

measure the ambient magnetic field in the x, y and z axes. It uses the same coordinate

system as the accelerometer, and it can detect the earth’s magnetic field and therefore

inform applications where north is.

There is one caveat to accurately detecting where north is, and that is that the device

has to be held perfectly flat in relation to the earth’s surface, which is bound to fail in

most cases. To compensate for this the compass sensor can be used with the

accelerometer to find north with better accuracy, since accelerometers can inform

applications of the orientation of the device relative to the earth’s surface (Satya,

MacLean and Hashimi 2011).

The accelerometer and compass sensors will therefore be essential to develop the digital

compass for the LBG application.

2.2.2.2 CompAcc: Using Mobile Phone Compasses Accelerometers for Localization

CompAcc utilize the accelerometer and magnetic field sensors to detect movement and

compass orientations, for determining the user’s location by counting steps in a direction

on a map that the software has knowledge of by reading orientation values of an angular

degree with respect to magnetic north (Constandache, Choudhury and Rhee 2010).

The paper does mention that complexity in human movement patterns, like jumping and

walking up and down hills (incline movement), makes the step counting often inaccurate

for measuring distance in meters. Using sensors in an attempt to measure distance as

timely replacements of a LBS will therefore not be considered for the master’s thesis.

However, the interesting part is in the detection of movement and how this data can be

used to determine if a user (device) is standing still. This ties in with the theory in

section 2.1.2.1.

When a user is standing still, providing little movement data, the application can remove

location updates for a period of time in order to save battery power by decreasing the

use of GPS and wireless radios. For this to be successful with the orienteering application,

users should be at a certain distance from nearest control point in order for the

application to have enough time to reregister for location updates before passing by the

control point that they seek.

The sensors documentation stresses the requirement for developers to disable sensors

when they are not needed, to save power. Failing to do so will drain the battery in matter

of a few hours (SensorManager 2012). But the documentation does not specify which

sensors drain the most, or if one or more sensors have far less battery usage.

The Android OS takes advantage of the accelerometer all the time to detect if the device

has been rotated and if activities should then be displayed in landscape mode or portrait

mode. With that in mind, and the fact that CompAcc successfully utilize the

accelerometer to minimize the use of LBS for the purpose of battery conservation, it

suggests that accelerometers consume substantial less power than the use of GPS and

WiFi/3G radios in relation to a LBS. In the next section, this will be explored further.

Tests will be conducted at some stage in the development process to compare the

battery usage of the following two models:

• Pure LBS – using only location based services with no optimization for battery

conservation other than what the delay between two location updates should be.

• Power management – taking advantage of the accelerometer to receive

movement data, for the purpose of removing location updates on a standstill,

thereby potentially increasing the battery life by a significant amount in cases

where GPS updates are superfluous to requirements.

The results from this comparison may demonstrate that the gains in battery life is

minimal, which favors the pure LBS model. To increase the chances of success of a power

management implementation, it needs to be applied where a game/competition last

several hours, and in cases where users begin with 80% battery level or less. It cannot

be assumed that users will have fully charged batteries each time.

2.2.2.3 Location-Based services on Mobile Phones: Minimizing Power

Consumption

In a survey of mobile hardware done by Kjærgaard; profiling were carried out on how

much power different phone hardware consume in an application using a LBS, and

discusses further different designs to improve power management (Kjærgaard 2012).

The most valuable observation taken from this study of the EnTrack LBS application, on

page 72, is that the accelerometer consumes a sixth of what the GPS use on power. With

this data, the decision to use the accelerometer as a way of temporarily removing

location updates upon little movement (indicating a standstill), is further supported. It is

worth noting that this data is collected on a Nokia N95, but should conceptually be

similar enough to the hardware on Android devices to give a fair indication/estimate of

expected power consumption.

Below is a table, taken from the study, showing the power consumption of different

hardware features on a Nokia N95 using location-based services and sensors.

2.2.3 The user interface Before delving into the literary material relevant to the UI, let’s first identify the tasks

users will be faced with while using the LBG outside in the field.

Using a Google Map activity

Reading directions from a navigation view to help discover the locations of all the

control points they need to visit, in a specific order.

Using a compass in order to change the direction they need to go based on the

information presented in the navigation view.

One of the main reasons why the compass should have its own activity is that when

users navigate away from it; for any of the other two, the onPause() method will be

called and the compass can stop listening for sensor data by invoking a deregister

method inside onPause() (Meier 2010). The sensor listener will be registered again with

the onResume() callback, by navigating back to the compass activity (see section 2.2.1

on the different states of activities).

Fragments will also be used for the user interface in a tab-like implementation.

Fragments are parts of an Activity and they share its state, meaning that they can be out

of view but not necessarily paused. A compass Fragment can be out of view, and

therefore useless, but remain active. There is one method that can be overridden; that

detects when a fragment is not visible (e.g. swiped away), and that is:

@Override public void setUserVisibleHint(boolean isVisibleToUser) { super.setUserVisibleHint(isVisibleToUser); if (isVisibleToUser == true) { } else if (isVisibleToUser == false) { } } As can be seen from the code above, simply read true or false on Fragment visibility to

disable compass, and enable again.

By encouraging users to use the compass only when necessary, and not have it running

in a multi-pane layout with a direction helper, there will be more calls to compass

onPause() and deregister methods that serve the purpose of better battery management.

The two paragraphs above address the claim, made in the introduction of section 2.1.2,

on how the UI design and battery conservation relates to each other.

2.2.3.1 Gesture Designs in Mobile Environments The reason why the gesture design publication (Bragdon, Nelson, Li and Hinckley 2011)

was studied and selected as relevant literature for this research; is to address situations

where users are outside orienteering with their handheld devices, and they are finding

themselves in a non-ideal environment where environmental factors can inhibit their

ability to perform tasks on the device. In orienteering, while running, pressing a button

can potentially require more time than it should by the decreased accuracy of aiming at a

smaller object on the screen.

The hypothesis behind this study is, therefore, that performance will decrease with the

use of soft buttons, which are relatively small visual object, in non-ideal environments

where users are required to pay more attention to their surroundings (compared to, e.g.,

sitting on a park bench) while using their mobile device. Finger gestures were used as

the alternative solution to improve user’s performance, measured in required attention to

the device and speed/accuracy of the gestures versus buttons.

Users can use the entire screen size, or large parts of it, to perform gestures, instead of

aiming for a small button, and thus requiring less attention to the device.

The conclusion behind the study is primarily that gestures can be used as shortcuts to

the same functionality as buttons offer. This conclusion was supported by usability

testing, where the users responded favorably to the use of gestures in most cases, but

would prefer having both buttons and gestures available. Only one participant spoke in

favor of using only buttons.

The use of gestures in the orienteering application can be fairly basic by swiping directly

left and right between the three activities (map, directions and compass). One

disadvantage with this appears when a user wants to go from the compass activity to the

map activity, which requires two swipes. With buttons you can go directly to any activity

with one press. Two solutions are proposed below to this problem:

Being able to swipe continuously left or right in circles, encountering no end to

how many swipes you can do in either horizontal direction. What this means is

that user have the ability to do a single swipe to the left from the map activity,

ending up in the compass activity on the right side, and vice versa.

If the solution above should conflict with the intuition of the users, then mark-

based gestures can be taken advantage of. Mark-based gestures are gestural

patterns that differ from simpler gestures by not following one straight line. For

example, to skip the middle activity and go directly from the third to the first

activity, the following swipe pattern can be used (going up and left on the

screen):

Figure 4. Simple mark-based gesture.

This gesture study found that mark-based gestures were preferable over free-

form gestures. Free-form gestures are performed in a more complex movement

pattern that sometimes use multi-touch, like drawing a “V” downward with two

fingers, or the letter “S” with one finger.

However, a study done by Jia, Lee and Suk (2011), found that users preferred

new free-form gestures over standard phone gestures. In conducting usability

testing for the dissertation, there will be standard left/right swipe gestures, mark-

based gestures and free-form gestures available to record user preferences and

see if there is a type of gesture that clearly stands out as the winner.

The part of the conclusion in this gesture study, that recommends using both buttons

and gestures, will be challenged in the master dissertation by attempting to eliminate

functional buttons (only between the three activities under active gameplay/workout),

aiming to achieve user satisfaction with this decision. By doing so, tab buttons that

indicate where the user is situated in the application can be made smaller since there is

no requirement to press them, and more space becomes available in each activity for

mission critical information, benefiting the smaller screens most.

The simplicity of the available gestures will also be crucial in order to eliminate button

pressing successfully.

A paper by Hummel, Hess and Grill (2008) support further the findings that tasks are

increasingly difficult to perform under environmental distractions, increasing delays and

error rates. This study lacks depth in their results by having done their monitoring and

testing of users in a laboratory instead of a comprehensive field study, and they intend to

extend their preliminary results to outside field study. They do, however, provide

valuable insight into the significant increase in error rates under environmental

disturbances, which will considerably be taken into account when adapting the

orienteering application to mitigate outside distractions.

3 REQUIREMENTS Objectives need to be stated first in order to formulate the different requirements

necessary for delivering solutions to the problems facing the dissertation project.

3.1 Objectives

Compass navigation

Implement a magnetic compass that takes advantage of combining the accelerometer

and the magnetic field sensor.

The user interface

Focus will be on successfully implementing the game-active UI with three screen

views/fragments: a map, navigational information with a compass, and an overview list

over progression events.

Success is measured in the subjective satisfaction of users in an evaluation.

Aiming for satisfaction in following areas:

• The usability of creating routes.

• The division of tasks into three screen views/fragments.

• Using gestures instead of soft buttons to make it easier to navigate between the

screen views, while being on the move in a non-ideal environment.

• Getting through control points based on information the application feeds them,

which should not be too hard or too trivial.

• Using Text-To-Speech for immediate notification of events.

• Not having to worry about the battery draining to zero before passing the finish

line.

Location-based cheating

Utilize system location services to register proximity alerts on start/end locations. For

start locations, this is to require user to be within the proximity of it before starting a

race, preventing anyone from getting a significant head start. And for the end location,

user cannot successfully end a race long before the finish line.

Power management

Using the accelerometer to register movement data in order to determine when the

device is not moving, and thereby temporarily unregistering for location updates from a

LBS, which are superfluous to requirements in such situations. The application will

register for location updates again when more movement data comes in. The purpose is

to consume less power and increase battery life.

Web-service(s)

The objectives for the use of internet technology are as follows.

• Supporting multi-user accounts with registration and log in.

• Implementing functionality for users to upload their routes

3.2 Functional requirements Functional requirements describe the behavior of the system, expressed as properties

and functions.

Web services

Launch an Amazon Elastic Compute Cloud solution (virtual machine) to provide services

for the Android application. Expose user and route resources in a RESTful web service for

the purpose of: registration, log in authentication, route uploading.

The data/content type used as HTTP payload between the web services and the mobile

application doesn’t need to be more complex than JavaScript Object Notation (JSON) for

current requirements.

Registration and log in

On attempting to do something that requires user authentication/identification (like

uploading a route); users will be presented with a dialog box asking them to log in,

register or to cancel. After registration, where all input fields have been validated,

automatic log in will be performed and the user taken back to the previous Activity. The

registration data is persisted both locally and on the web. Automatic log in will always be

performed unless the user unselects the option for this (by unticking a checkbox).

From the main menu

The main menu will initially present five options:

• Orienteer/Workout. This will take the user to the orienteering

activities/fragments with three tabs for mainly accessing a stopwatch, a target

angle value, map and compass, and a tab with an overview of progression events.

A dialog will pop up requiring the user to select a created route.

• Create route. Select and place markers on the map representing either the start

location, one or more control points, or the end location. Perform geocoding in

this interaction to gather address data to be stored with the specified route name.

If users need help finding the right place to create a route; then a location search

function must be provided.

In addition to save route locally in the SQLite database, a menu item must also be

available for uploading routes to the server.

3.3 User requirements User satisfaction must be achieved through various forms of testing and evaluation of the

application in the field.

The application will strive to achieve success in the following areas:

• User interface. The focus will initially center on how well they perform when

they are active with orienteering. Error rates and delays increase when users are

working under environmental distractions, which will be the case when they are

outside running in a non-ideal environment (hills, obstacles, hurdles etc.). Gesture

swipes with the entire screen at their disposal, is a requirement for attempting to

mitigate this, instead of pressing soft buttons.

• Location-based services. There must not be a significant delay from location

services to register a device in the proximity of a location, so not to waste time.

• Navigation. Users should expect to be given correct information to each control

point, and that the accuracy of the compass is sufficient.

• Application responsiveness. Users should not experience lag spikes as a result

of unnecessary use of resources. If a networking operation is performed, which

can take some time, then the application must inform that a bit of waiting is

required; through showing a “Please wait ..” dialog. This fulfills one of the first

usability principles (heuristics), which states: “visibility of system status”. Keeping

users informed of what’s going on. This applies mainly to occasions when routes

are created.

• Battery. Draining the battery in matter of a few hours should not be an issue.

• Text-to-Speech notifications (TTS): TTS must notify users of when something

significant has happened, immediately. Without TTS users have to check the UI

regularly, perhaps so often that they rarely turn off the screen, which will

consume a lot of battery power.

4 ARCHITECTURE AND DESIGN This chapter covers system architecture, user interface design and software design.

4.1 Client architecture overview The software implementation of this project is better understood by presenting and

explaining models of the system architecture. Android, like many other development

frameworks, has application components conceptually divided into three layers:

presentation, code logic and data storage.

Benefits of using a three-layered separation include:

• Modifying and tuning the user interface without having to touch the program

code, and will therefore avoid accidently affecting data processing, causing bugs.

• Modular software with well-defined interfaces.

• Make significant changes in code logic, in scale or redesign, without affecting

structures for the UI and data storage.

Figure 5. Displaying relevant architectural layers and components of an Android device.

As seen in figure x, the code logic layer lists Activities, Broadcast receivers, Service,

Location Manager, SQLite and SharedPreferences (Data Storage) as essential application

components for the project. In the following list these components will be more carefully

explained.

• Activity. An activity is a focused screen that users can interact with by touch

input. The design content of an Activity is set by referencing a designated XML

layout file, where the root element is of type ViewGroup and contains UI elements

that all inherit from the View class.

Each activity can start/launch another and thereby creating a “back stack”. And

when a new activity is started, the previous activity is paused and preserved in

the back stack, which means that the in-memory states are kept but not persisted

beyond the lifetime of the application. One method is guaranteed to be called by

the system before the given activity goes into the back stack, and that is

onPause().

In onPause() critical data can be persisted on the local storage through various

implementations. It is also used to unregister them from receiving data from

other application components to avoid runtime errors.

Whenever an Activity gets destroyed on the back stack, the onDestroy() method

will be invoked by the system and, as with onPause(), necessary data can be kept

using a persistent data structure, like SQLite, before finally closing.

Each time an activity becomes active from the back stack; the onResume()

method will be invoked and it is there that the application can register to receive

data again, be it from a broadcast receiver or a location service.

The following diagram shows the different states of an activity in its lifecycle.

Figure 6. Activity lifecycle.

• Broadcast receiver. A broadcast receiver is a component that can be registered

to receive system-wide messages from broadcast Intents. An Intent is an abstract

structure for an operation to be performed, defined by an action string describing

the purpose of it; and data consisting of key-value pairs. In this project Intents

are most widely used to broadcast data between a background Service and

various Activities that register broadcast receivers for particular sets of actions.

But is also used to start other activities and pass data from one to the other in the

Intent as it is being started.

• Service. The Service component runs in the background and does not fall under

the life cycle of any Activity, meaning that it can never be paused; only

destroyed. It performs longer-running operations while not interacting with the

user. A Service is not a separate process from the application that started it;

therefore a thread must be instantiated to separate the Service from the main UI

thread, which will increase performance by preventing user interaction getting

entangled in CPU intensive calculations or blocking operations (such as

networking).

• Shared Preferences. SharedPreferences provides the ability to store and

retrieve any primitive data in key-value pairs: booleans, floats, ints, longs and

strings.

• SQLite. SQLite databases are fully supported in Android. As the name suggests;

SQLite is a software library that implements a self-contained, zero-configuration,

transactional SQL database engine.

• Location and Maps. LocationManager is the central component of the location

framework, which provides access to location services for obtaining periodic

updates of the device's geographical location, or to fire application-specified

Intents when the device enters the proximity of given geographical locations.

MapView is the main View class in the Google Maps package for Android. A

MapView displays a map with tile data received from the Google Maps service, and

data received from location services is further used to add objects on to a

MapView.

4.2 Distributed multi-layer architecture This section will focus on the application’s distributed client-server architecture with the

use of a cloud virtual server and location services in addition to the client technology, as

illustrated in the figure below.

Figure 7. Distributed architecture.

This distributed architecture follows the design principle of separating the different

computing technologies into three layers/tiers where, the client device, business logic,

data access and storage are developed and maintained as separate modules with well

defined interfaces. Using this pattern of organizing and thinking about an internet

application results in the following benefits:

• Any of the three tiers can be upgraded or replaced independently in response to

changes in requirement or use of technology. IPhone clients can easily be added

as long as platform independent, and standardized protocols and data structures,

are used for communication and as content types, like HTTP for request/response

communication, and XML or JSON as interfacing content-types in HTTP payloads.

If database technology were to be changed to another RDBMS brand, some minor

tweaks in configuration would need to be done in accessing the new database

from the GlassFish application server, but would not require any change to the

Java source code as the Java Persistence API and the Java Persistence Query

Language (JPQL) abstracts all the complexity of dealing with different relational

database engines and provides the same classes, methods and query syntax to

deal with them all in a object-oriented fashion.

• If the server operating system had to change from Ubuntu to Redhat Linux,

nothing would need to be done in the client tier or data tier in response to this

change. The Amazon AWS cloud platform has storage solutions, where one is

called Relational Database Service (RDS), which have life cycles independent of

the server instance(s) that access them. This enforces the three-tiered

architecture more firmly than the previous point when dealing with the server

hardware setup and OS.

• When needing to scale up CPU cores on the server, and amount of memory,

independently of the two other tiers. Again with the cloud solutions in the Amazon

AWS; one can make an image of the server instance that will be terminated, then

generate a new server instance with more computing resources and restore the

image there, before finally associating the public IP address with the new and

improved server instance. This upgrade of resources allows the number of clients

to scale up also without making further changes.

The remaineder of this section will go into more details about the different architectural

layers that apply to server/service technology.

Location Services

Google gives Android devices access to location services supported through classes in the

android.location package. LocationManager is a system service for applications that

wants to become location-aware, and is the most central component of the location

framework, providing APIs to determine locations and bearing of the underlying device.

Once an instance of LocationManager has been obtained, through calling

getSystemService(Context.LOCATION_SERVICE), the application is able to do two things:

• Register and unregister for periodic updates of the user's current location from a

location provider. A location provider can come from one of two sources: GPS or

networks. GPS uses satellites to position a device on the surface of the earth, and

is in most cases the more accurate provider. The Network Location Provider

determines a user’s location using cell towers and Wi-Fi signals.

• Register to receive one or more Intent broadcasts that are triggered if a device

comes within a given proximity (specified by radius in meters) of a given latitude

and longitude.

Cloud server

The Amazon Elastic Compute Cloud (EC2) provided a quick and affordable way to set up

a server for this project. It is made up of a web service that gives access to configuring

and instantiating a virtual machine in the cloud with a specified (bare) operating system.

The chosen OS is Ubuntu and SSH is further used to log in and install new software for

setting up an application server and a RDBMS.

GlassFish is the application server for this project, and is the reference implementation of

the Java EE specification, and sponsored by the Oracle Corporation.

MySQL is the chosen RDBMS to store registered users and their generated content.

4.3 Design This section takes a closer look at user interface and software design. More details about

implementations will be provided in chapter 5.

4.3.1 User interface design

From the main menu to starting an orienteering race; there are six screen views that

users will encounter. Two of these are visible activities, and one is a Dialog view, and

three are Fragment views:

• Activity. The main menu and the window for creating routes both extend Activity.

There is a base class that extends FragmentActivity for activities that use support-

based Fragment APIs.

A Fragment represents a behavior or a portion of a user interface in an Activity,

and this application has three classes that extend Fragment. All three cover the

whole screen but can be swiped between with finger gestures. The

FragmentActivity is not visible but acts as the base/master Activity for

instantiating and managing these fragments.

• Dialog. The Dialog has a selection of routes in a ListView that is populated by

querying and getting row data from the database. By clicking on a route from the

list will first cause necessary route data to be saved in SharedPreferences; for

easy access from fragments and the Service in their startup, and when that is

done the FragmentActivity will be started where the three fragments will be set up

for orienteering.

• Fragment. As stated before there are three fragments. The first one is called

“Main” and contains the following: what the next target type is, remaining

distance to target, GPS accuracy, duration with a stopwatch, and the start/stop

buttons.

The second Fragment is called “Navigation” and it has the calculated angles to

targeted locations, and there’s a compass and a Google MapView. The third

Fragment is called “Events” and contains a ListView of progressions details from

when the race started, and from going through all the control points before finally

reaching the end location.

This UI design is illustrated in figure 8, and can be seen through the application flows

from the main menu, to creating a route and using it for orienteering.

Figure 8. Showing the main user interface activities and fragments.

4.3.2 Class design

The class diagram displays the relevant classes that interact during an orienteering race.

Broadcast receivers from proximity alerts are the only central classes that did not fit into

the diagram. Two-way communication is indicated in the lines where there are no arrow

heads.

Here are some key observations taken from the diagram on software design:

• It shows how the Service and UI fragments communicate through broadcast

receivers and SharedPreferences.

• Background Service and the events Fragment are the only two accessing the

database. The database is used by the events Fragment to get (potentially) multi-

row event data when it returns from a paused state, having missed all

broadcasted intents. And the Service uses the database to load all the control

points into a hash map, store a race as history, and events as they happen.

• Navigation Fragment and the MotionDataHandler class both implement the

SensorEventListener interface. The Fragment use it to implement a magnetic

compass, and the Service use MotionDataHandler to gather movement data for

the purpose of reducing battery consumption by removing location-based updates

when the device is not moving much.

Figure 9. Class diagram showing the most central classes active when running a route.

There are about 40 classes in total that constitutes the Android application, not including

the XML and image files that support the UI design. To get an idea of how many classes

had to be created to get a manageable code base, a screen shot is provided in the

following from the IDE showing the classification of packages for the program code. Only

the service package is expanded to display the classes (not enough vertical space to

expand them all).

Figure 10. Screenshot of the package design, where the service classes can be seen.

4.3.3 Deployment diagram

This deployment diagram describes all the major hardware and software components of

this distributed application and how they are connected through different APIs and

interfaces.

Figure 11. Overview over how client components relate to server/service interfaces.

As can be seen in the figure above, the RESTful web service can be accessed by different

URIs in order to:

• Registering users and verifying them in subsequent use by pointing to the login

URI, which returns either the OK response or CONFLICT response based on

database query results on whether the username and password is valid.

• And to upload and store routes, which in later increments will be used as

distributable content.

From the client side the HttpURLConnection class is utilized in combinating with the URL

and OutputStreamWriter classes for sending HTTP requests to the server, and capture

the response in the output stream and write it to a String object to verify if the request

was successful or not.

Further, the MapView in every MapActivity is used by the Maps API to get map tile data

from Google servers, and the Locations API serve the purpose of getting

longitude/latitude values (and addresses) from locations, and register proximity alerts.

4.3.4 Database design

There are two databases in use for this application: one SQLite database on Android

clients and a MySQL database on the server side. Both follow the same basic design, but

the SQLite database has two more tables where history and events records go.

A history entry is created every time a race is started and subsequent events are

inserted with a reference to the history id column.

Another thing to keep in mind is the use of Long and Bigint types for date times. Java

Date objects can be created from long values that was returned from invoking

dateObject.getTime(), and formatting of date strings can be done on the client in case

they need to be presented differently some other time.

Figure 12. EER diagram of the SQLite database on the client side.

Presently the server application supports registration and log in of users, and uploading

routes with a reference to the relevant user id; associating routes with their authors.

In chapter 5 there will be more on the implementation of uploading a route, which

requires a list or a set data-structure to store several control points that reference the

same route.

This provides ground work for future development on more distributed content.

Figure 13. EER diagram of the server side MySQL database.

5 IMPLEMENTATION AND RESULTS

5.1 Client side This part documents what has been done and achieved on the Android application, to

satisfy stated objectives and requirements, starting with the essentials of having a

database, and how a route is created, followed by demonstrating how to select a route

for orienteering. Chapter 2.3.1 has an overview over all the user interfaces and how they

relate, which can be helpful to keep in mind to get a better understanding of how the

application works.

5.1.1 Database implementation

SQLite databases are fully supported in Android and provide useful classes and methods

to simplify how they are created with tables and columns, and how CRUD operations are

performed. The database for this application is called “footodb” and is first used to store

routes, and further to store history and events from orienteering runs. Events are

actively used while orienteering by the events Fragment when it returns from a paused

state. A pause in the user interface thread is typically caused by powering off the screen,

and if a proximity alert fires during that time then, on resuming from the paused state,

the event will be read and displayed in a ListView after querying the database.

Create statements are set up as String constants and the SQLiteOpenHelper class

determines when the database is constructed under first use of the application.

One method of inserting values into tables is consistently used in this application, and

that is by taking advantage of the ContentValues class found in the android.content

package. This class takes simple key-value pairs; where columns are selected as keys.

What remains after adding values from supplied objects is invoking the insert method on

the database object, which returns the primary key of the row id.

In order to retrieve stored data from a database; the Cursor interface is used to provide

random read access to the result set returned by a database query. The database is, in

this implementation, queried for results by using raw SQL statements in the first

parameter of the db.rawQuery(..) method, and WHERE clause value(s) (an array of

Strings) is passed in as the second parameter. There are other ways of doing this without

explicitly using SQL, but by having experience with using SQL I found it easier to be in

control of the SELECT statements. Once a Cursor object is returned, the results can be

read by either going through a for-loop or a while-loop.

All methods of interacting directly with SQLite are encapsulated in the

RoutesDBAdapter.java class.

5.1.2 Creating and storing a route

Data from routes that have been stored from the creation process serve the purpose of

aiding users to navigate from the start location, to one or more control point locations,

and finishing at the end location. Longitude and latitude values retrieved in this process

are used to register proximity alerts on locations to inform users of having arrived at

them.

There are basically two methods of creating a route, and the first is to use location-based

services with GPS to get updates on the relevant positions of a device where users want

to place a starting point, control point or end point. This requires users to go outside and

capture these locations, which is time consuming and impractical compared to the

alternative.

The other method is to utilize the Maps API and parts of the Location API (the Geocoder

class) provided by Google to get addresses and longitude/latitude values from interacting

with a MapView, which is the option that has been implemented for this project,

providing a more convenient way of creating routes.

5.1.2.1 Geocoding, map overlays and Projection

To understand the implementation of creating routes; the concept of geocoding needs to

be elaborated upon. Geocoding is the process of converting an address to a

longitude/latitude pair and vice versa; supporting forward and backward conversion. The

Geocoder class provides this facility and each time a user taps on a MapView; a GeoPoint

object will be passed in to the onTap(GeoPoint, MapView) method in an Overlay object

that overrides it. A longitude/latitude value pair will then be extracted from the GeoPoint

object and used by a Geocoder to get addresses for that location point.

To receive the onTap event a master Overlay object must be instantiated and added to

the MapView, and override onTap(GeoPoint, MapView). Overlays are objects that can be

drawn on top of a map at specified locations; by converting a GeoPoint object to on-

screen pixels. The MapView class maintains overlays in an accessible list

(List<Overlay>).

The master overlay used in this implementation does not refer to any drawable image for

graphical display, and is only used to catch tap events on the map and use them for

placing other overlays as markers on the map. There are three types of markers and

they represent the start point, control point(s), and the end point of a route.

The master overlay is set up during the initialization of the MapActivity by first calling

getOverlays() on the MapView object to get the list secured for overlays, and the

mapOverlays.add(masterOverlay) method is called for adding the overlay. The core logic

of creating a route is implemented in this Overlay object.

MapView is defined in an XML file and is set as the content view of the MapActivity. The

MapView XML requires an apiKey attribute to contain a valid hash value in order to

access Google’s Maps services. This hash value is easily obtained by following online

sign-up instructions for getting the API key, and requires the use of Keytool which can be

found in the bin folder of the Java Development Kit (JDK).

5.1.2.2 Toolbars and menu items

Going back to the user interface, there are tools developed to aid users in placing

markers on the map. To place a marker; one of three radio buttons must be selected

first, which determines the type of marker, as seen in the following screenshot.

Figure 14. Screenshot of radio buttons as tools for placing markers.

And once a new control point is placed; a radio button is created for that control point

(abbreviated as cp), appearing in a second panel below the first one, serving the purpose

for users to go back and move specific control points; should they be misplaced. The

start and end marker can also be moved around by simply having the related radio

button checked. There is a hard limit of 10 control points for a route, filling two panels of

radio buttons.

The following code displays what happens when the radio button (startRadio variable) for

the start marker is selected before a tap event. If the marker has not been placed on the

map before; then a new overlay will be created and a GeoPoint object gets passed in as

the second parameter, before being added to the list of overlays for the MapView. If the

start overlay already exists, determined by a boolean value, then a new GeoPoint object

is associated with it to update its location on the map.

A GeoPoint object contains basically a longitude/latitude pair. How does that translate to

x and y screen coordinates on a MapView? The solution to this question is implemented

by the Projection class, which is a part of the Maps API.

The following code is taken from inside the StartOverlay class and demonstrates how to

convert a GeoPoint to screen pixels. It includes also three lines of code at the bottom on

how to draw the start image (a drawable resource) on the maps canvas; by using the

pixel Point object created by a Projection object.

Listing 1: “Converting a GeoPoint to screen pixels for drawing bitmap on overlay”

//---translate the GeoPoint to screen pixels---\\ Point screenPts = new Point();

Projection projection = mapView.getProjection(); projection.toPixels(geoPoint, screenPts); //---add the marker---\\

Bitmap bmp = BitmapFactory.decodeResource(main.getResources(), R.drawable.altstart); canvas.drawBitmap(bmp, screenPts.x-20, screenPts.y-20, null);

To gain access to more functions the menu button can be pressed and four more options

will appear from the bottom of the screen:

1. Save Route. A small dialog will appear when pressed, asking to supply a route

name before pressing the save button. The route is then inserted to the database.

2. Upload to Server. If logged in, then the route will be uploaded to the server

application after specifying a name.

3. Find Location. This part takes advantage of geocoding by taking a search input

to find a matching location with the longitude/latitude values, and centering that

location on the screen.

4. Undo Last. This option removes the last placed control point marker by simply

removing the overlay from the list that maintains them and updating the MapView

state.

The remainder of this section will go into further details about the first three menu items.

Save Route

On pressing the “Save Route” menu item a small dialog box appears, requesting that a

route name is specified before pressing the “Save” button to insert the route in the

database by using methods documented in section 3.1.1 on databases.

The route could just have been saved automatically under an address name, but studies

show that users are more satisfied by being able gain more control over content creation

in an application/LBG (Neustaedter, Tang and Judge 2011).

Figure 15. Screenshot of the dialog to save a route.

User registration

The user registration form requires currently only a username, password and an email

address. This information is sent over to the server in a JSONObject with the correct URI

(passed into a URL object).

In the current implementation the registration is accessed via login dialogs. When the

register button is pressed; the values from the input field are validated before shipped

over in a HTTP request. The password is hashed with MD5 and takes the place for the

plaintext password. Hash values are authenticated on the server.

Figure 16. Screenshot of the registration screen.

User login

Whenever users tries to do something that requires server access, like uploading a route,

the login screen will appear if they haven’t previously checked for “Sign in automatically

in future”. MD5 hash value is used as password in order to match with the registered

hash value.

Figure 17. Login screen.

Find Location

If the MapView is centered on a location far away from where the user wants to create a

route, then it can be tedious and time consuming to use finger gestures (swiping, pinch-

to-zoom etc.) to focus the display on the desired location, especially if the user is not

completely sure on where to go from current location. The solution to this is to have a

search function to help users animate the MapView to a requested location.

So this part performs geocoding to get a list of addresses where the first entry (index 0)

is the best match for the search phrase. The location search method takes a string as

input (from the text box), which can be the name of a city, an airport code or just a well

known name of a location (like a campus), and passes it in to the

getFromLocationName(input) method on a Geocoder object.

Listing 2: “Geocoding to get location data from an address string”

private void searchLocation(String input) { searchGC = new Geocoder(this); try { List<Address> addressList = searchGC.getFromLocationName(input, 5); if (addressList != null && addressList.size() > 0) { int lat = (int) (addressList.get(0).getLatitude()*Constants.OneE6); int lng = (int) (addressList.get(0).getLongitude()*Constants.OneE6); GeoPoint pt = new GeoPoint(lat, lng); mapController.setZoom(15);

mapController.animateTo(pt); // More code..

} catch (IOException e) { e.printStackTrace();

}

If the address list is not empty then the MapView will center in on the first/best location

match, with the help of a GeoPoint object, as seen in the code listing above.

5.1.3 Route selection for orienteering Back on the main menu Activity there is another button, named “Workout”, and it opens

a dialog with a ListView containing routes, populated as a result of querying the database

for a Cursor of all routes. This ListView is interactive on touch and provides users the

option of selecting a route, which will fire an event that puts necessary data associated

with the selected route in key-value pairs, and commit them to SharedPreferences,

before finally starting the FragmentActivity.

The reason for storing selected route details in SharedPreferences is primarily for the

background Service to query the database with correct route id, and load all the locations

for that route, and to create Location objects with latitude/longitude pairs.

The master Overlay object for the MapView in the navigation Fragment also use

SharedPreferences to create GeoPoint and Overlay objects for the start and end location,

which will be addressed in more detail later on.

Figure 18. Screenshot of the routes list prepared for orienteering.

5.1.4 The background Service The Service class serves the purpose of being a long-running thread that communicates

with outside services and receives data/alerts that help users to progress in orienteering.

Additionally it is responsible for doing the following:

• Requesting and receiving location updates from location services.

• Register proximity alerts on locations where the user needs to navigate to.

• Performing various calculations, like finding the distance between two locations,

geocoding and analyzing device motion data.

• Communicating location update/proximity events, with related data, to the

fragments in the UI thread; through broadcasting intents, database inserts, and

committing data to SharedPreferences.

• Using text-to-speech (tts) to notify users immediatley of an event.

Before going further, it needs to be said that LocationManager is the central class to

access the systems location services, which makes the application location-aware.

Using the location services

One of the first things the Service does is registering a proximity alert on the start

location. And the reason for that is to satisfy the requirement to prevent users from

cheating on where they start, should they attempt to get a head start. Upon receiving

the alert callback for the start location; the Service broadcasts an Intent to the relevant

Fragment to enable interaction with the button that starts a race. There’s more on that in

section 3.1.5 regarding the main Fragment for starting a race.

Each proximity registration is associated with a broadcast receiver, where the alert intent

is passed in. These broadcast receivers have a reference to the Service object where

methods are invoked in response. The proximity alerts use three broadcast receivers for

the following location types: the start location, control point location and the end

location.

Listing 3: “Registering a proximity alert for the start location”

// Broadcast receiver below proxStart = new StartProximityReceiver(BackgroundService.this); Intent startIntent = new Intent(STARTPOS_PROXIMITY_ALERT); startIntent.putExtra("startkey", "start"); startProxIntent = PendingIntent.getBroadcast(this, -1, startIntent, PendingIntent.FLAG_CANCEL_CURRENT); // And adding the proximity alert using the LocationManager reference locationManager.addProximityAlert(startLocation.getLatitude(), startLocation.getLongitude(), 50f, -1, startProxIntent); IntentFilter sfilter = new IntentFilter(STARTPOS_PROXIMITY_ALERT); registerReceiver(proxStart, sfilter);

There is another broadcast receiver that the Service registers, and that is for intents sent

from the UI thread. One of these Intent types is sent by the “Main” Fragment when the

user presses the start button, which means that the next target is first control point, and

the Service then registers the proximity alert for that location. Whenever the proximity

alert for a control point fires, then the broadcast receiver calls the moveToNextTarget(..)

method on the Service, and the next control point is set. This continues until the

application knows that the last remaining control point is set, after which the end location

is registered. And finally when the proximity alert for the end location goes off, then an

Intent is sent to the main Fragment that will stop the race automatically.

The other use of location services, which is essential to this application, is getting

updates on the location of a user’s device. Updates come in the form of a Location

object, and they contain longitude/latitude pairs, the GPS accuracy in meters, and

provide the functionality for calculating the distance to other Location objects. The

longitude/latitude pair received from location updates is broadcasted to the navigation

Fragment to place the user Overlay on the MapView, which is the basis for the

requirement to calculate the angle to a target location.

Accuracy and the distances calculated by Location objects are broadcasted to the

first/main Fragment. The resulting distances are often very inaccurate and were always

taken with a grain of salt during testing. I informed the participants in the evaluation of

not taking the remaining distances too seriously, since they were often exaggerated.

Using space on a small screen to display accuracy is perhaps not necessary. One concern

with developing a mobile application is to use available UI space intelligently, and follow

the principle of not presenting users with too much information. The accuracy value is

also used to prevent processing of Location objects where the accuracy is over 100

meters.

Such inaccurate updates can misplace users on the map by a great amount, which can

cause problems for users to navigate to certain locations. The same problem appear

when not processing or receiving Location objects for a while, causing the position of the

user to be misrepresented in the same way an inaccurate location update will.

Text-to-speech (TTS)

The implementation of TTS is aimed at satisfying the requirement of notifying users when

something significant has happened, immediately. When there is varying accuracy in

sensing the location of users; then there is no way for them to know exactly when they

have reached a targeted location. Without TTS users have to check the UI more

regularly, perhaps so often that they rarely turn off the screen, which will consume a lot

of the battery power.

The main purpose of using TTS is then to remove the dead time between the occurrence

of an event and when the user is informed of it.

Android provides this functionality in the android.speech.tts package. After some

initialization of a TextToSpeech object (setting language is one of them), then it is ready

to receive text input and output a speech by invoking the speak(string) method. TTS is

called directly from broadcast receivers of proximity alerts on the Service instance.

This feature was a subject in the evaluation, and was well received by participants,

primarily because it was the first source to inform them of an event. Even if they didn’t

always hear exactly what was said, they knew something happened and could check the

UI for more information.

Collect movement data and disable/resume LBS

On researching issues related to location-based games for the dissertation; the problem

of battery consumption kept coming up and plans were made to use the accelerometer

sensor for determining when to remove location updates and proximity alerts.

Papers that were studied documented that the use of GPS and WiFi/3G radios were the

biggest consumers of battery power, and it should be minimized in applications that can

be used for hours before being able to recharge the battery. In these studies the

accelerometer were shown to not consume a significant amount of power. GPS/LBS will

activate WiFi/3G radios more by being used to create GeoPoint objects for the Google

MapView, containing longitude/latitude pairs that will animate the map to a new location

and more map tile data gets downloaded.

The accelerometer is covered in greater detail in section 4.1.6 regarding the compass

implementation. Basically the accelerometer has a coordinate system where movements

are detected and quantified along the x-axis (moving left or right), y-axis (back and

forward) and in z-axis (up and down).

Android applications can, by taking these movements values, measure if the device is

relatively flat while reading a digital compass, to take one applicable example. Walking

and running patterns (bouncing up and down) may also be detected by reading the quick

variations of the z-axis values.

This will be useful for detecting movement to satisfy requirements for battery

management in the orienteering LBG, by unregistering for location updates when the

device is most likely not moving forward, and registering for updates again when more

movement data feeds in to the application.

A separate application was developed dedicated to collect movement data over specified

time periods. Float values coming in from the x, y and z axes were summed up in a

variable over scheduled time intervals of 15 seconds. And by moving around a little, not

much, while standing still I was able to get the approximate amount that would indicate

that the handheld device is not moving forward. This was compared to the values I got

by walking and jogging, to be sure that there is a substantial difference. Typically, values

under 60 indicated that the device was most probably not moving forward, and values

over 80 were normal for light walking.

Figure 19. Screenshot of movement data collector app

The following listing displays the central the code for this part.

Listing 4: “Collects movement data for analysis purposes”

// Schedule run() in class MovementDataCollectionTimer to be called after 15s // movementTimer is a Timer object movementTimer.scheduleAtFixedRate(new MovementDataCollectionTimer(), timeout, timeout); class MovementDataActivity extends Activity implements SensorEventListener { private SensorManager mgr = null; private Sensor accelerometer = null; private float[] gravity = new float[3]; private float[] motion = new float[3]; // More code... @Override public void onSensorChanged(SensorEvent event) { // Use a low-pass filter to get gravity. // Motion is what's left over for (int i = 0; i < 3; i++) { gravity[i] = (float) (0.1 * event.values[i] + 0.9 * gravity[i]); motion[i] = event.values[i] - gravity[i]; } // More code... float x = Math.abs(motion[0]); float y = Math.abs(event.values[1]); float z = Math.abs(motion[2]); xCounter += x; yCounter += y; zCounter += z; totalCounter += (x + y + z); // totalCounter gets all the movement data for 15s

The implementation in the orienteering application follows the same pattern of collecting

movement data and checks the totalCounter variable if its value is below 70. And if it

isn’t then location updates will continue on.

Listing 5: “Unregisters LBS updates if there is not enough movement data”

// Above minMovement is acceptable to keep LBS active, under indicates little movement if (totalCounter <= 70 && isLbsUp == true && started == true) { service.sendThreadMessage("unregisterLBS"); isLbsUp = false; } else if (totalCounter > minMovement && isLbsUp == false && started == true) { service.sendThreadMessage("resumeLBS"); isLbsUp = true; }

5.1.5 Main Fragment This Fragment, most notably, contains the stopwatch for displaying the duration of a

race, which is one of the main requirements for implementing an orienteering application.

The stopwatch is actually an object of the Chronometer class, a part of the

android.widget package. It can be started and stopped by pressing the “Start” and “Stop”

button.

Figure 20. “Main” Fragment UI with some essential information, and the stopwatch.

There are two characteristics that all three orienteering fragments have in common,

which is crucial for keeping the user interface up to date. The first is having a broadcast

receiver and the second is the way in which fragments check for updates when the UI

thread is resuming from a paused state (after powering screen off/on most likely).

Since the Service handles all interaction with Google location services, broadcast

receivers are used to receive intents from the Service when new location updates comes

in, and when proximity alerts fire off. These intents carry information that are used to

calculate distances to targets, read GPS accuracy, get device latitude/longitude pairs,

and much more depending on which broadcast receiver they are sent to, defined by the

action parameter in the given Intent.

The UI cannot receive these intents if it is in a paused state, SharedPreferences is

therefore utilized after being resumed to get the latest information; if the relevant pieces

of information have been updated since last time, since last check.

When the Service gets a new location update or receives a proximity alert intent from the

location service, then the information triggered by these intents are both broadcasted

and committed to SharedPreferences. There are two keys associated with each

information value: the first one is a Boolean value that is flipped to true each time the

Service updates the related value, and the second one is the actual value for the UI.

When the UI then resumes and finds one or more of these Booleans to be true; then it

knows that the Service has updated them, and after updating values in the UI from

SharedPreferences then the Boolean values are set back to false. Should they still be

false after resuming a second time, then it indicates that no new value have been

committed since.

The reason why there are “Updated” timestamps on values in some fragments is because

there can be delay in updates from location services, and when users see remaining

distance to users; they must take into consideration when that value was updated so

that they don’t go by old values.

Another requirement to this application is not being able to start orienteering outside the

proximity of the start location, to prevent cheating on time performance. Right from the

beginning the Service requests a proximity alert on entering the start location, and when

it fires the Service will send an Intent to this main Fragment that leads to the start

button being enabled for touch input. A proximity alert can also fire again if users leave

the proximity, in which case the start button will be disabled again to prevent users from

beginning.

The following listing shows how the proximity alert is received in the broadcast receiver,

with the class name StartProximityReceiver, and various calls are being made to the

Service instance before sending an Intent to the UI Fragment that leads to the start

button being enabled, if the entering Boolean is true.

Listing 6: “Code shows how the start proximity alert is received and further broadcasted”

@Override public void onReceive(Context context, Intent intent) { Bundle extras = intent.getExtras(); Boolean entering = extras.getBoolean(LocationManager.KEY_PROXIMITY_ENTERING); // true if entering, false if leaving String startKey = extras.getString("startkey"); if (startKey.equals("start") && entering == true) { service.setIsInStartPos(entering); Intent startIntent =

new Intent(BackgroundService.STARTPOS_PROXIMITY_READY); startIntent.putExtra("entering", entering); service.saySomething("You are ready to start"); // Text-to-speech notif. service.sendBroadcast(startIntent); // Ready to start the race, update UI // The following shows the start Intent being received in the UI BroadcastReceiver @Override public void onReceive(Context ctx, Intent intent) { Bundle extras = intent.getExtras(); String action = intent.getAction(); // Many action checks are performed, but will show one the relevant one else if (action.equals(BackgroundService.STARTPOS_PROXIMITY_READY)) { boolean entering = extras.getBoolean("entering"); if (entering == true) { // Etc etc…

The orienteering begins when the user presses the start button, which is followed by an

Intent being sent to the broadcast receiver registered by the Service for receiving intents

from the UI. Since the Service can never be paused, only destroyed, then all these

intents will arrive. What happens next is that the Service adds a proximity alert for the

first control point, the next target. More details on the implementation of the Service

class will be provided in chapter 3.1.7.

All the values seen in the screenshot, in figure 20, taken from the main Fragment are

either received by the broadcast receiver, in the same fashion as demonstrated in the

previous code listing, or from SharedPreferences. These values inform of what the next

target is, distance to target, accuracy, and what happened in the previous event.

5.1.6 Navigation Fragment

This Fragment is made up of three components to aid users in navigation to targets:

• An “Angle to target” value calculated to find the angle between the user location

point and the target location point.

• A magnetic compass used to find the direction that the “Angle to target” value is

indicating.

• A Google MapView with overlays showing the current user position, and the

position of the start and end location. Control points are intentionally not made

visible so that users will rely more on using the compass to head in the right

direction.

Figure 21. Screenshot of the navigation Fragment.

Being able to navigate from target to target is the most crucial part of the application,

and success relies upon a good implementation of the planned features for this

Fragment.

Compass implementation

As have been stated before; the compass is used in combination in the “Angle to target”

value to help users face towards the direction where the next target location is. This can

be achieved with the use embedded sensors that feed the application data from the

physical world.

In Android you register a listener to receive sensor data and use it for processing each

time it comes in (Satya, MacLean and Hashimi 2011). The relevant sensors used develop

a compass are:

Accelerometer

Magnetic field sensor

Orientation sensor

There is a third sensor that’s in the list: the orientation sensor. The orientation sensor is

in actuality just a combination of the accelerometer and magnetic field sensor at the

driver level of Android, and addresses the issue mentioned in the previous paragraph.

There is no extra hardware for the orientation sensor, but the Sensor API in Android

exposes the accelerometer and compass sensor as the orientation sensor.

Orientation data feeds in through a SensorEvent object and is passed as paramater to

the onSensorChanged(event) method; for further processing before the angle value is set

to a text view. The following listing has an excerpt of this process.

Listing 7: “Orientation values are passed in SensorEvent object for further processing”

@Override public void onSensorChanged(SensorEvent event) { // Need to get both accelerometer and compass // before we can determine our orientationValues switch (event.sensor.getType()) { case Sensor.TYPE_ORIENTATION: for (int i = 0; i < 3; i++) { orientationValues[i] = event.values[i]; } break; case Sensor.TYPE_ACCELEROMETER: for (int i = 0; i < 3; i++) { accelValues[i] = event.values[i]; } if (compassValues[0] != 0) { ready = true; } break; // More code .. public void doUpdate() { if (ready) { int angle = Math.round(orientationValues[0]); compassTextView.setText(angle+Constants.DegreeSymbol+" "+getMagneticAngle(angle)); } }

The getMagneticAngle(angle) method takes the angle integer and returns a string value

on whether the angle is north, north east, south and soon, based on checking which

defined value range the angle is in; anywhere from 0 to 360. This string is appended to

the angle value.

Calculating angles from on-screen pixel coordinates

This part does the job of calculating the “Angle to target” value seen in the screenshot

for this Fragment, and is the only piece of information that tells users in which direction

to go.

Google Maps is north-based and the direction going straight up on the map is therefore

towards north, and east is right, south is down and west is left, as displayed in the figure

below.

Figure 22. North-based Google Maps with overlaid compass values for illustration.

With this in mind it is possible to use trigonometry between two x/y pixel points to

calculate angles. The first requirement to accomplish this is to get a Projection object

from the MapView whenever the draw method gets overridden as a result of having to

draw or redraw Overlay objects as the MapView changes its state. A Projection object

serves to translate between the coordinate system of x/y pixels and that of

latitude/longitude points on the surface of the earth.

To place an Overlay object on the map where the location of a user is, a

longitude/latitude pair will first be sent from the Service thread to this navigation

Fragment where the Maps API operates, in order to create a GeoPoint object for that

location point. This happens every time the Service gets an update from the location

service. Projection then takes the GeoPoint object as a parameter and converts the

geographical location to screen pixels.

Early on in the development phase; the angles returning from my trigonometry method

did not always match the compass orientation values, by going counterclockwise from

zero degrees down south, to 180 degrees on top, and down again to 360 degrees, as

illustrated in the figure below.

Figure 23. Illustrating north angles returned from pixel point math.

I knew that the values I got wasn’t always opposite, meaning a difference of 180

degrees, as it was between north and south. I found out through calculating the angle

between my position and a target north of me, which returned a value equivalent to

south, that zero and 360 degrees were down south, which should have been 180 based

on the compass I was reading from. But east and west values were calculated correctly

compared with the compass, which told me that the angles are calculated

counterclockwise from south.

To map this in my head, in order to develop the logic to correct this so that it aligns with

compass values, I had to sketch it on a piece of paper, as can be seen in the following

photo.

Figure 24. Photo of sketching the angle problem, and the solution logic on the bottom.

I worked out that if the degree is more than 180 (degree > 180) then (180 – degree) +

360 had to be computed to get the correct output. If less than 180 degrees; then simply

subtract it from 180 (180 – degree). And this corrected implementation worked greatly

to my satisfaction and to the satisfaction of users I tested this application on, meaning

that the output angle pointed in the correct direction.

The following listing displays the code which calculates angle to target values based on x-

y pixel points that resulted from performing projection on GeoPoint objects representing

device location and target location.

Listing 8: “Algorithm for calculating orientation angles from pixel points”

// me = my x and y position on screen private float getAngleToGo(int targetX, int meX, int targetY, int meY) { double angleAtan = Math.atan2(targetX - meX, targetY - meY); // Not having minus values, need a 360 compass, // e.g. a -5 will be 5 degrees away from 360, meaning 355. if (angleAtan < 0) { angleAtan += 2 * Math.PI; } // Get angle in degree from radian supplied in parameter float angle = (float) Math.toDegrees(angleAtan); // Next the xy coord. angle is translated to compass geo. angle if (angle > 180) angle = (180-angle)+360; else if (angle < 180) angle = 180 - angle; else if (angle == 180) angle += 180; return angle;

5.1.7 Events Fragment Since it is possible to use up to 10 control points; users may want to get an overview

over all the events up to a certain point, and on when they occurred. Events, as the

current implementation defines it, are divided in three parts: a start race event, control

point proximity events and end of race event.

This Fragment consists of a ListView that is populated by event results returned from

database queries. It receives intents from the Service on whenever they occur in order to

update the ListView. SharedPreferences is also used after returning from a paused state

check if the ListView needs to be updated.

Figure 25. Screenshot of the events Fragment (all locations were on the same spot).

5.2 Server side To get an overview over what will be presented in this part, it is worth noting that

chapter 3.2 has detailed models and basic information on the server technologies used in

this project.

An AWS virtual machine, with the Ubuntu OS installed, has been created with Amazons

cloud solutions and hosts an instance of the GlassFish application server, where the

application is deployed. A RESTful web service is exposed and can be accessed by various

URIs where POST and GET requests can be directed to resource representation for

performing user registrations, log in authentications, and uploading of routes. JAX-RS

(JSR 311) is the specification of this web service and is implemented by the Jersey API.

These types of web services are stateless and minimalistic, meaning they do not keep

data in memory between two requests, and there is also no tool-created interface that

defines a contract.

The term Representational State Transfer (REST) was introduced in the year 2000 by Roy

Fielding in his PhD dissertation. In the REST architecture; data and functionality is

defined as resource accessed by URIs. On being stateless; Fielding wrote the following in

chapter 2.9.1.5 of his dissertation: “each request from client to server must contain all

the information necessary to understand the request, and cannot take advantage of any

stored context on the server.” (Fielding 2000).

A request must thus contain all information necessary for the server to process a

request, and eventual states must be kept on the client side. Fielding’s dissertation goes

on to argue that these stateless constraints increase reliability and scalability of the

server hosting the web service. Reliability is increased because it is easier to recover

from minor system errors, mainly because no business-critical in-memory data is lost.

The scalability is improved because data is not stored in variables for each individual user

between multiple requests, which allows hardware components to free up resources.

This architecture thus suits the orienteering application with room for scalability.

The different URI addresses used in the implementation are as follows:

http://23.21.40.57:8080/FootOServer-war/resources/users/login -- Takes login

requests and performs a query on the database with the username and password to see

if there is match. JSON (application/json) is the content-type, which works well, but it

should be more convenient to just have username and password defined as key-value

pairs in the URI, requiring less code than using a Json object.

http://23.21.40.57:8080/FootOServer-war/resources/users/registration -- Takes

registration values from a JSONObject and creates a user object that gets inserted in the

database.

http://23.21.40.57:8080/FootOServer-war/resources/users/routes -- This part is more

complicated. It is a HTTP multipart mode POST and has four content parts in the body:

• JSON object with route name and amount of control points.

• JSON with start location data.

• JSON with end location data.

• A valid JSONArray format string (text/plain) with the control points.

The passwords used in login and registration are hashed on the client side with MD5

algorithm before being transferred to the server. The passwords are then hidden and

authentication is performed on the hash values.

6 EVALUATION The objectives of the user experience evaluation are to gather enough data to observe

what has been achieved from the development project, and in addition make informed

http://23.21.40.57:8080/FootOServer-war/resources/users/login

http://23.21.40.57:8080/FootOServer-war/resources/users/registration

http://23.21.40.57:8080/FootOServer-war/resources/users/routes

decisions about design improvements, and future development, based on the level of

satisfaction users achieve with creating a route and navigating it from start to finish.

To begin with users will be given practical information about how the application works

and what kind of experience it wants to provide, and what the tasks are that will be

subject to evaluation. A questionnaire will be provided and filled out to gather data about

the experience users had with various aspects of the application. The questionnaire will

have a five point rating system to quantify the level of satisfaction on most tasks, and

use simple true or false (yes or no) options on other questions.

The questionnaire is structured as a summative evaluation to find out what has been

successfully achieved throughout the development process. Parts of the results that

receive low rating will be taken to serve formative functions, and be used to inform

future improvement. Further reinforcement on why improvements should be made; will

be taken from various literatures on the relevant topics.

The complete list of what to evaluate is presented below. It is two-fold where the first

part is about creating and saving a route, and the second part is about using a route for

orienteering.

Creating a route

• On using the search function to find the Heriot-Watt University campus.

• On using available tools on the screen to place markers on the map representing

the start location, control point locations and the end location.

• Moving an existing marker to the appropriate location if it has been misplaced on

the map.

• Saving the route to the local database.

Using a route

• Choosing a route from the main menu and opening it for an orienteering lap.

• Finding out if the navigation between the three tabs is satisfactory. Do the swipe

gestures work well? See if someone would prefer press tab buttons in combination

with gestures.

• Did users always know what was going on at any given moment, and what the

next objectives were? A valuable usability heuristic applies here: the visibility of

system status.

• On using the compass and given directions to find targeted locations: are they

accurate and usable?

• On the usefulness of the automatic voice notifications to alert users of when a

new event has taken place, e.g. change of target location or having finished a

race.

• Confirm that the application was able to guide users from the start location, to

control points and to the end location.

• Issues’ regarding inaccurate location updates and if there are times where there is

no response from location-based services for an extended period of time.

6.1 Evaluation Results For the evaluation I was only able to get hold of three people that wanted to do a 20-30

minute test of the application. All three rated questions and assertions similarly and

consistently on most questions, which indicate a pattern of agreement on what works

and to what degree.

The following table contains the results of the evaluation where participants were asked

to rate from strongly disagree to strongly agree on assertions/fact statements about how

well parts of the application worked for them in given tasks. The number under these

columns states how many chose which level of agreement or disagreement of an

assertion.

Assertion Strongly agree

Agree Uncertain Disagree Strongly Disagree

Identifying and using the search function was helpful in finding the location where I wanted to create a route

1

2

Using the markers was effective in selecting locations for a start point, control points and the end point

1

2

Changing the location of a misplaced marker performed satisfactory

2

1

Finding the “Save route” menu button, and saving the route under a specified name, performed satisfactory

2

1

In general I found the radio

buttons to be useful for placing markers on the map in setting up a route

2

1

I found the swipe navigation between the three screen views (Main, Navigation and Events) to be intuitive and satisfactory

2

1

The swiping wasn’t always optimal, I would also like the option of using press buttons to select a screen view

1

1

1

I always knew what my current objectives was, based on the information that the user interface provided me

2

1

The compass was useful in combination with the “Angle to target” value to accurately find targeted locations

1

2

I found the automatic voice notification to be useful in alerting me instantly of when a new event occurred

1

2

This location-aware application did, to my satisfaction, registering me at the start location, and at control points and where I reached the end location

3

There were two true/false questions, and the results are represented in the table below.

Assertion True False

Did you have any issue with navigating to one or more locations as a result of being positioned inaccurately on the map? (GPS inaccuracy). This affected remaining distances and the “Angle to target” values.

3

Were voice notifications at some point the first source to inform you of a new event? (Like arriving at the intended destination, and of what the next target was)

3

6.2 Analysis of results This part will look at each assertion/question and examine what the successes were and

where there is room for improvement.

1. Create route. In this task they had to use the search feature to find the Heriot-

Watt university campus. This went generally well but two of the participants did

not register at first that the search performed successfully, and that was due to

not grabbing their attention with feedback from the search. The map did animate

and center in on the location, but no information popped up for a brief period of

time saying “success” or displaying the full address return from the search, which

is not true to the usability principle (heuristic) of “visibility of system status”. This

got corrected before the third participant by using Android Toast popup

messages.

2. Using marker to set locations. All participants were able to set the start

location, control point locations and the end location successfully. The radio

buttons are large and clear in their purpose.

3. Changing misplaced marker. One of the participants checked “uncertain” on

this task. He did not notice that an extra panel of radio buttons appeared where

he could select already placed markers to move them around. More can be done

to get the attention of users when this new feature pops in to the UI. Animations

on appearance, fading in and out of colors on the panel etc. will be options to

consider for informing users of new additions to the UI.

4. Save route. This part performed well for all participants also. They were able to

find it from the menu and enter in the route name before pressing the enter

button.

5. Create route overall satisfaction. The same person that had issues moving

existing control point marker were not satisfied overall. I did forget to connect

the phone to the WiFi network and he used 3G or edge inside a building to make

create the route, and it was slow and time consuming.

The appearances of new radio buttons for each control point placement can be

more obvious to reduce the error rate. The two others did see it, but not

instantly, there were some hesitation before they got it.

6. Swiping between fragments. This part was received well also. The person that

checked “agree” noted that it wasn’t easy to navigate the map because it would

swipe to other fragments instead. In other words the gesture of swiping and

navigation/dragging the map overlaps. There should be some way to make the

map respond to gestures first, which will be considered for future improvement.

7. Press/touch option to change fragment. One person agreed that he wouldn’t

mind being able to press a button or text label to change fragment. This is not

enough to consider implementing it, although there is no penalty in add a touch

listener on the text label referring to other fragments.

8. Informative user interface on objectives. Two participants were satisfied

with receiving information from the UI. The third participant had some valid

points in that, from the “Main” fragment, reading the GPS accuracy and the latest

event label wasn’t useful, and filled the Fragment with too much information.

These two pieces of information are likely superfluous to user requirements,

especially when there is a Fragment dedicated to events, and can be removed.

9. Compass and “Angle to target” value. This part performed successfully as

well, as it should for enabling users to find their locations. The participants were

always able to turn in the right direction and find their target locations. But this

depends fully on acceptable location/GPS accuracy, which the test locations had

for the evaluation.

I have personally encountered problems with the application when inaccurate

location updates misplaced me over 100 meters away, which affect the “Angel to

target” value by pointing away from where I need to go.

For these scenarios; the application should have a feature for enabling users to

set their own location by simply using a tool to touch the map at the point where

they are standing. Participants in traditional orienteering does this is in a similar

way by inferring exactly where they are by studying the map and their

surroundings to pinpoint their position, and measure the angle to their target

correctly from there. As long as users actively use this feature, location updates

will be disabled so that their positions doesn’t repeatedly get misplaced, which

also will save battery life.

For the most part, on today’s mobile hardware, location accuracy is not a big

issue. But if many users used the application, there would be problems with GPS

inaccuracies.

10. Automatic voice notification (TTS) usefulness. This feature was along with

compass and directions fragment, perhaps the most successful implementation

subjected to evaluation. The voice grabbed the attention of users immediately

and informed them of new target locations. They were also informed when they

were in position to start, and when the race ended. It wasn’t always clear to hear

the words, but severed as great notification tool regardless. There may be room

for improvement to optimize the voices sound.

11. Overall satisfaction navigating from start to finish. All participants either

agreed or strong agreed to being satisfied on this part. I purposely shifted to

another route on the third participant, hoping to get poor location accuracy. The

accuracy was decent, but not as good as on the other route with the first two

participants, and this caused proximity alerts to go off from a farther distance.

Two targets were perhaps 150 meters away from each other and the third

participant did not have to go far from one to other before the proximity fired off.

What this means is that this application is currently not suited on routes that

have relatively short distance between targets (and short routes in general),

since in worst case scenario two proximity alerts can and will go off within few

seconds if they are too close (less than 100 meters ca.). It is better suited for

longer runs that stretch beyond typical campus sized.

12. Voice notifications first information source. This question goes back to TTS

and whether voice notifications were first to inform them of an event. All three

responded with “true”.

7 CONCLUSIONS AND FUTURE WORK The resulting orienteering application from this development project managed to

implement features that enable users to create routes and use them to navigate from

start to finish. In more detail this includes:

• Using proximity awareness to implement features that can be used to combat

cheating, by requiring users to start inside a specified proximity measured in

meters, and disallowing them to start outside it by disabling the start button.

• Implementing a compass that takes advantage of both the accelerometer and the

magnetic field sensor.

• Swipe gestures between the game-active fragments.

• Utilizing the Google Maps API and location services to calculate geographical

angles from a user’s handheld device to a target location, and use the resulting

value in combination with the compass to navigate successfully.

• Implementing a Service in the background that works uninterrupted until the user

enters the finish location.

• Collect and analyze movement data in the Service and determine when location

updates should be disabled when the device is most likely standing still, providing

little movement data.

• Using text-to-speech notifications on important events.

• Implement a web service that can register users and perform basic

authentication, and be able to upload routes to it.

The current state of the application does not include features on the server side that

make it possible for users to compete. But in preparation for that; challenges were met

that allow for fair competition, like the anti-cheating feature with proximity awareness.

This works only on longer distance since the proximity radius can be big, or displaced

because of inaccurate location updates, which were demonstrated to cause problems

when two or more proximity alerts fired in matter of few seconds because they were

relatively close.

Future work

One of the regrets after this stage of the project was not having enough time to make it

more like Geocaching by adding more challenges to find a physical object in a location.

The current implementation of proximity alerts on control points works well for

navigating to areas where a physical object can be, and the software are thus prepared

for further extensions.

Originally there were plans to make users find posted QR codes and scan them in order

to move on to the next control point. A better idea emerged later, where users can find

objects that would not require the use of paper material or cache containers; that can

potentially pollute the environment.

The new idea involves using real-time object recognition with embedded mobile camera

technology to verify users with control points. This is done by using feature detection to

detect distinctive, invariant image feature points, which can be matched between images

to perform object detection and recognition. OpenCV (opencv.org) is a library that

enables the development of object detection on Android devices, and other platforms.

The purpose of object detection, as mentioned earlier, is to create a more immersive

application with environmental surroundings. When users create a route; they take a

picture of a static object inside the proximity of every control point, and make it a

requirement for other users to find the object they see in the picture. And when they find

it; they use the camera to perform object detection, which (if successfully recognized)

will verify users with the given control point and point them to the next one. Examples of

such objects can be graffiti on a wall and park/traffic signs.

The goal of this feature is to make this location-based application more of a Search-and-

Find game, like treasure hunting or Geocaching. Using proximity alerts with this new

modification will serve the purpose of informing users that they are within proximity of

the object they see in the picture for the relevant control point, and they need to infer

the precise location themselves (they will be presented with a more precise address, e.g.

a particular road, gate or avenue if it was successfully gathered from geocoding in the

route creation part).

I did start working on this and planned to have it in a chapter on experimental results,

but it turned out to be more complex than anticipated; so it is a good topic for future

development.

There is room for more server development also where users can share routes, and

distribute more content.

8 REFERENCES

[1] Bassett, Pucher, Buehler, Thompson and Crouter (2008), “Walking, Cycling, and Obesity Rates in Europe, North America, and Australia”, Journal of Physical Activity and Health, pp. 797.

[2] Lin, Jessurun, Vries and Timmermans (2011). “Motivate: Context Aware Mobile Application for Activity Recommendation”, Springer Berlin / Heidelberg, pages 213-214.

[3] Dyer (2004). “The Essential Guide to Geocaching: Tracking Treasure with Your GPS”, Alpha Books.

[4] Neustaedter, Tang and Judge (2011). “Creating scalable location-based games: lessons from Geocaching”, Springer-Verlag London.

[5] SensorManager (2012), Battery Draining, http://developer.android.com/reference/android/hardware/SensorManager.html

[6] Activities (2012), Lifecycle, http://developer.android.com/guide/topics/fundamentals/activities.html

http://developer.android.com/reference/android/hardware/SensorManager.html

http://developer.android.com/guide/topics/fundamentals/activities.html

[7] Android Architecture (2012), “What is Android?”, http://developer.android.com/guide/basics/what-is-android.html

[8] Lin, Lymberopoulos, Kansal and Zhao (2010), “Energy-Accuracy Aware Localization for Mobile Devices”, MobiSys '10 Proceedings of the 8th international conference on Mobile systems, applications, and services.

[9] Satya, MacLean and Hashimi (2011), Pro Android 3 (1st Ed.). APRESS. Chapter 26: Using Sensors, page 892.

[10] Constandache, Choudhury and Rhee (2010), “CompAcc: Using Mobile Phone Compasses Accelerometers for Localization”, INFOCOM.

[11] Meier (2010), Professional Android 2 Application Development (2nd Ed.). Wrox. Chapter 14: Sensors, page 460.

[12] Bragdon, Nelson, Li and Hinckley (2011), “Experimental Analysis of Touch-Screen Gesture Designs in Mobile Environments”, CHI '11 Proceedings of the 2011 annual conference on Human factors in computing systems.

[13] Jia, Lee and Suk (2011), “Considerations of Applying Surface-Based Phone Gestures to Natural Context”, UbiComp '11 Proceedings of the 13th international conference on Ubiquitous computing.

[14] Hummel, Hess and Grill (2008), “Environmental Context Sensing for Usability Evaluation in Mobile HCI by Means of Small Wireless Sensor Networks”, MoMM '08 Proceedings of the 6th International Conference on Advances in Mobile Computing and Multimedia.

[15] Fielding (2000), “Architectural Styles and the Design of Network-based Software Architectures”, Dissertation PhD University of California, Irvine. http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

http://developer.android.com/guide/basics/what-is-android.html

http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

dissertation (f21mp) - hw · this dissertation project aims to develop a location-based game for...

Documents