TourTracker: A tour recording and sharing application for Android

Julius Bartkus, Alvis Davidavicius, Roland Beta IT University of Copenhagen Rued Langgaards Vej 7, 2300 Copenhagen. Denmark {julb,adav,rolb}@itu.dk
ABSTRACT

Most tour guide applications do not allow their users to create and submit their own tours, but only provide the possibility to choose between the available ones. As the phones are becoming more powerful and get more abilities to sense the environment it should be easier to create tours using mobile phones than stationary computers. This can add a new experience for creating guided tours and following the ones which were already taken by someone. Those might even come with pictures shot during the trip. This paper describes the TourTracker mobile application that enables its users to create digital versions of their own tours and share it with the public. That is why users of the application can be both contributors and consumers of this service. The application is a part of a client-server system, where the client application runs on the mobile devices, collects the tour coordinates by continually checking the path the user has done. At the end of the tour the user can upload the tour to the server with some additional information. In the paper we present the design, implementation and evaluation of the TourTracker system. Our intention was to investigate that the nature of this application it is more appealing to the users because the tours were suggested by other tourists.
Author Keywords

and pre-congured tours, where the presence of real tour guides was no longer necessary. These device-guided tours provide more freedom to the users, but are still lacking on the social part of the experience. Most of the services are onesided, meaning that users can choose fom predened tours, but cannot share their own. The success of most social sites lies in allowing the users to share experiences, memories, thoughts, photos, notes, etc. Sharing trips with others can be a new, rewarding experience for contributing to the tourist society. Choosing a tour from such a service is also more interesting, since the tours are contributions from people who have completed and posted the tour themselves. The technology needed for a tour sharing application is not much different from mobile tour guide devices. They are both able to detect the location of the user by using positioning systems, however, with our solution the recorded path can be uploaded to a central server. Therefore the tour can be made permanently available and public. The application presented is created with robustness in mind, meaning exible design that allows relying on more ways of determining the users location in case one would not be available. The report starts with introducing the main idea. Section 2 presents the related work and products available for tour and path tracking purposes. In section 3 we use these examples to dene a number of key design principles, requirements and evaluation methods for our system. Section 4 presents the results of our evaluations and ndings. In section 5 we discuss design decisions, their limitations and possible solutions for them. Finally, the report is concluded in section 6.
2. RELATED WORK

Android, Tour Tracker, GPS

1. INTRODUCTION

Tourism and visiting new places has a long tradition in every culture and with the evolution of technology the way people plan their tours has changed too. People have different preferences about exploring new areas, cities or nature. Some like the security of organized tours and tour guides who can provide information about the specic location, others prefer being their own guides and planning the tour themselves. In this report we present a solution which combines the previously mentioned two approaches. As positioning technologies became mainstream, new services were introduced, which offered mobile device-guided

A survey [5] states that 93% of the tourists in Heidelberg explore the city by foot on their own, without a guided tour. That also means that they move within a limited area, mostly in the Old Town and miss all other places of interest which are further out the town. From this we can also conclude that a guided tour application would solve this problem as it is for free and leaves the same freedom for exploring as before, except that the tourists know where to nd the sights. A number of systems have been developed which provide an ability to record trips onto external system (server) for later retrieval of information and replay on the mobile phones. A Mobile Tourist Companion [4] is one of them. This application is a context-aware system for mobile phones using

Paper submitted for evaluation in the Pervasive Computing Course, Fall 2010. The IT University of Copenhagen.

location-based tracking system GPS. That system focuses on the gathering user specic data such as gender, occupation, interests and afterward fetching relevant information from different sources which could be in the interest eld of the user. A commercial system called Trip-Journal has a set of features allowing the user easily document travel experiences using picture, note taking and route tracking. Trip-Journal1 is an example of the systems which is built for a specic case - creating trip journals. Unlike our system, however, Trip-Journal focuses on creating visually attractive memories, journals of trips and sharing it with relatives, friends. There is no possibility for other people to download these as guided tours to follow. The team working on the Cyberguide mobile context-aware tour guide [1] took a different approach for dening how such a system would work and look like. They prototyped the device for different scenarios, requiring different hardware, user interface, and communication technologies. The guide provided information according to the users location or what the user is looking at. The different iterations of the system either worked indoors or outdoors but not both, because of technology limitations. At the time of their experiments the available wireless technologies were very limited so they had to rely on alternative ways of location tracking, such as infrared transmitters. Also, because of low bandwidth, the creators were forced to store data heavy informations, such as pictures locally. A major difference compared to our focus is that all information was provided for the user by the tour guide and the user had no possibility of altering or sharing the perceived information. The usefulness and popularity of providing information about nearby objects was investigated in the GUIDE project [3]. They compared two methodologies. The rst using the Lancaster GUIDE system, which works by identifying the users location and asking for specifying the distance of the object from their current location. By the location and distance data the system can guess what the user sees and provides relevant information. The other approach was to take a digital image of the object and run it through an image recognition software and identifying the object that way. They found out that a signicant number of users embraced digital image recognition despite it required more effort and had signicant disadvantages compared to the dialog based system. We found providing information about nearby locations a highly attractive feature in tour guide applications and it could be implemented in future versions of our application. Mobile applications requiring network connection have to be robust, reliable and have to handle network or even power outages naturally. Developers of the ContextPhone ContextAware mobile platform [6] achieved handling these situations by storing all the outgoing data locally on the device until it has been successfully uploaded after recovering from an outage. This is a fairly straightforward approach and it could be very well used for our application. Another inter1

(a) Menu

(b) Add note

esting concept they mention is the eXtreme Programming2 paradigm: Build the simplest thing that could possibly work. Considering our previous development experience and this papers ratication we decided to apply this in our design. Some of the presented related work in the mobile tour guide eld has similar characteristics to our system, e.g. the TripJournal application, however the purpose of sharing is different, it is about sharing memories, not providing guidenance to others. Other, like the ContextPhone and Mobile Tourist Companion focus more on providing information according to the sensed context which is not our focus. The survey conducted by Freytag shows that there is a need for mobile tour guide systems and other papers e.g. ContextPhone gave us ideas for the design of the system and possible additional features for future versions.
3. 3.1 THE SYSTEM Demo of the application

We start presenting the system by going through the main features of the application and show how they look on the screen. On the rst start of the application the user is shown his location if GPS is enabled on the phone, otherwise requested to turn GPS on. In the menu select Record new to start a new trip. Enter the name of the trip. (Figure 1(a)). The path is drawn if the user is moving. A label is showing the name of the trip and selected provider (GPS) used to get location updates. In the menu Pause/Stop buttons become active. For adding notes double tap on the desired location on the map and enter the note. (Figure 1(b)) The added note is diplayed with a small blue speech bubble. On double-tapping the note again we can edit or remove the note. When selecting Trips from the menu the user is shown a list of locally stored trips with a green Load ag, meaning its ready to be shown on the map. Download Trips will get a list of available tours from the remote database. The remote trips are marked with red Download note. They can be downloaded by tapping on them. (Figure 1(c) The downloaded trip is
2

http://www.trip-journal.com/

http://www.extremeprogramming.org/

As soon as the user gets to a location where internet connection is available the map is drawn and the path can be better visualized. The issue of storing images in persistent memory is further addressed in the subsection 5.1 of the discussions section.

3.2

Design considerations

(c) Local and Remote trips

(d) Trip loaded

Applications on different devices should be developed with different considerations in mind. These are determined by the factors like power resources, computing power, portability, connectivity, robustness, etc. Despite the rapid evolution of handheld devices they are still lacking computational power, connectivity is uncertain and devices run from a battery. With these constraints in mind we came up with the following design guidelines that we should follow: KISS3 - only the necessary features are needed to be implemented in a lightweight and efcient way Exception handling - network connection outages should be handled as natural events, the application should continue to work in ofine mode Extensibility - as we rely on different providers of location determination and maps the design should allow for easy implementation of new providers
3.3 System concept

added to the top of the list and marked with green. When tapping on a local trip it is loaded to the map with all its notes. (Figure 1(d)). The applications key focus is tracking the geographical location of the user and keeping a history of visited points. This is done by subscribing to the system location services and storing the records in a local database. A path is being tracked when the user selects the record function and is composed of users locations since the user started recording. A new location is set to differ from the previous one by specic distance in space and time. When the application receives a new user location, it processes the data and updates the local database. All of the saved points in one recording make up the path. When recording, the user can add pin-point notes to the map by double tapping a location on the map and entering some text. In this case the tap location on the display is converted from screen pixels to the geographical location and is stored in the database along with the text. The recorded path and pin-point notes make a tour that the user saves locally and can upload to the remote database server. The other way of using the application is downloading the tour from the remote database. The tour is displayed on the map and the user can follow its path and read location relevant notes. The target device of the application is mobile and has a limited amount of energy. Location receiving consumes a lot of battery power, so we took resource efciency into consideration. Tracking is done only when the application is in foreground of the screen in the viewing mode and is always on when recording. The system lifecycle API helps achieving the goal and we also use a custom state object to manage the application. Wireless connectivity is yet another valuable resource, which is recognized, but not addressed fully in the program - internet connection is needed in order for the application to display the map images. A tour can be recorded if internet connection is unavailable as the GPS coordinates are received regardless of the fact if the user has access to a map or not.

Apart from the mobile device there are more elements which have an important role to make the system work. The application gets location data from the GPS satellites. The periodic location updates are saved on a local database and on the request of the user it is uploaded to the central database. Tours are also retrieved from the same server. The communication is establish with a RESTful manner, specically by HTTP POST and HTTP GET queries. The location data sent to the server and the reply is parsed into JSON format. Communication with the GPS satellite is handled internally by Android OS. We specied in the application how often to get location updates and the minimal distance from the previous location to be notied about. These settings are necessary for the WiFi based providers too. After a trip has been uploaded from one device it is possible for other devices to download it. A conceptual diagram of the system is depicted in gure 1
3.4 System architecture

The architecture of the mobile application follows the three layered (gui, model, service) approach and follows our rst design consideration, KISS. The complete Class diagram is depicted in gure 2.
Service layer

In the Service layer two singleton service classes provide methods to connect to either local or remote database. The local is the Android provided SQLite database, which is a lightweight, but has all the necessary functionality needed in this case. The class allows for adding, retrieving, updating
3

Keep it Short and Simple

Figure 1. Conceptual diagram

Figure 3. Database scheme

and removing the locally stored trips; adding and retrieving trips points and note; additional helper methods for maintaining the state of the application. The service class for the remote database has methods for uploading, downloading a trip and getting a list of available trips.
Database architecture

The remote database is based on MySQL and its scheme is depicted in gure 3. The local database has the same structure as remote database except that it also holds a remote trip id in order to keep track of remotely stored trips. The design of the database supports extensibility in case more data needs to be attached to a specic table or eld. In order to avoid inconsistencies and improve database performance the database model has been normalized i.e. all non-key attributes became fully dependent on its primary-key. Moreover database structure implements foreign key constraints what makes the application more reliable in case of failure.
Model layer

of the path. CurrentState captures the state the application is in and it is an Observable class which is used to notify the Observer classes when a change occurs in the state. The LocationManager provides access to system location services to obtain periodic updates of the users location. The Client class provides the static method to send HTTP requests to the remote server. Requests are sent by the AsynchronousSender in a new thread to avoid hanging the application. When sending the request we provide the request and a class which implements the ResponseListener interface for receiving and handling the response from the server when it is available. The stability of the application in this way is greatly improved. JSONServerResponse is a helper class to extract and parse the response from the server. These are usually downloaded trips, list of available trips or notication messages if an action was successful on the server or not.
GUI layer

On the GUI layer we dene the applications activities, the map, overlays on the map, menus and other helper classes to provide the user with the necessary feedback. The central class is the Map. It is a MapActivity provided by Android for managing Activities which display a MapView. To be able to draw items on the map we need to extend the Overlay with our custom items such as the Path, current location indicator, pinpoints for notes and other information to display. These are captured by the DisplayOverlay and PathOverlay. The LocationOverlay and PinOverlay classes extend the ItemizedOverlay class which is similar to the base Overlay class but contains a list of OverlayItems. PinOverlayitem is an extension of OverlayItem with added PointId attribute. There are several other Activity classes which represent features of the application. CreateTripActivity is used for creating a new trip and giving it a name. CreatePinActivity en-

The Model layer captures the domain classes of our system, the asynchronous sending mechanism and other helper classes. The domain of the system is captured by the classes Trip, Point and CurrentState. NotePoint combined the Point and Note classes which is needed to add notes to a certain geographical location on the map. PointType is a simple enumeration which tells us whether a point is a pinpoint or part

Class Diagram1

GUI Activity

MapActivity

CreateTripActivity

TripLoadActivity

Map -currentState -locationProvider -srvc_local -srvc_remote

UploadActivity

PinActivity

CreatePinActivity

LocationManager

1 LocationOverlay -location

1 PinOverlay -geoPoints 0..* PinOverlayItem

1 PathOverlay

1 DisplayOverlay

ItemizedOverlay

Overlay

MODEL <<enumeration>> PointType <<Constant>> -PATH <<Constant>> -PIN Point -latitude -longitude Trip -name -remoteId -description CurrentState -state

SERVICE ServiceLocalSQL +getCurrentState() +setCurrentState() +addNote() +addPoint() +addTrip() +deleteTrips() +deletePoint() +getNotes() +getPoints() +getTrips()

Note

NotePoint

AsynchSender

Client

JSONResponse ServiceRemoteSQL +getTrips() +downloadTrip() +uploadTrip()

CallbackWrapper

<<Interface>> <<ResponseListener>>

Figure 2. Class diagram

ables adding note pinpoints to a trip. PinActivity shows pins of loaded trips. UploadActivity is used for uploading the trip to the remote database. TripLoadActivity handles downloading remote trips and loading local ones.
3.5 The Source Code is Open

The most important observations about the TourTracker system are summarized in the following paragraphs: Practical and easy to use; The participants for testing all agreed that the application is easy to use and practical in many situations besides creating tours. One participant appreciated the pause/resume functionality especially and all of them were satised the with the way of up/downloading tours. Feature suggestions; Two of the test persons suggested to implement counting the recording time, distance and current speed parameters. We think that these features could be part of the next iteration of the application, however recording time and speed does not necessarily have an impact on the tour. Problems encountered; One of the participants encountered problems when trying to record a tour. The icon showing his location kept dissappearing. We suspect the problem occured because of the poor weather conditions (clouds) and so poor GPS connectivity. Since this factor is out of our control the solution could be in using different location provider (mentioned earlier) relying on a different technology. Current limitations; Using Google Maps requires an active internet connection to redraw the map to the actual location. Most of out testers did not have an active internet connection so in case they went out of the temporarily cached map area the map was not shown. The solution to this is further discussed in the next section.
5. 5.1 DISCUSSIONS Caching map images

The applications source code is kept open, therefore anyone is able to contribute to the project or use the code for non-commercial purposes. The source can be downloaded at http://code.google.com/p/tourtracker/ webpage.
4. EVALUATION

The development time of the TourTracker system took approximately 1 month. In this period we started out by creating prototypes of the user interface on paper and a video of a typical use case scenario. During the development the system was continuously tested by us and the user interface rened to meet todays standards. At the end of the development phase we created a plan for evaluating if the application fullls its purpose, whether it is easy enough to use and handles contingency well. We had 4 people testing the application for specically 90, 60, 30 and 30 minutes period. Each test person was asked to record a trip and upload it. The mobile phones used for testing were: HTC Legend, HTC Desire and HTC Desire HD. Testers were presented to the features of the application, however not to every detail in order to test how intuitive the application is to use. After the testing each participant was interviewed individually with the following structured set of questions: a) Did you succeed to record a trip? b) If yes, did you succeed to upload the trip? c) Did you experience any problems while using the application? d) Was is intuitive to use the application? e) Tell what features you liked the most in the application f) Do you have any suggestions how to improve the system? Here is a summary of answers we received: a) 4 out of 4 succeeded to record a tour b) 2 out of 4 managed to upload the tour c) 1 out of 4 experienced the application close unexpectedly d) 4 out of 4 found the application intuitive to use e) answers were: nice UI; precise navigation; pause / resume feature; sharing the trip; easy to use f) 2 out of 4 had suggestions to improve the system, these were: showing the speed, distance, time taken to record a trip; customizing color of path shown

At the start of the project we have chosen to use Android MapView from Google Maps API for the map as the main part of user inteface. During the development cycle we have learned that the MapView does not provide the ability to cache map images. This is stated in the Android Maps API Terms of Sevice (section 8.2) 4 . What this means for our application is that it has to always have internet connection available in order to update the images of the map. The application will run and use in-memory images if they where loaded when internet connection was available, but not allowing to cache images in persistent storage delivers great restrictions. Hence, as we want our application to be used out in the wild, in the future we would investigate using OpenStreetMap 5 , as it does not have the mentioned limitations.
5.2 Proccesing path points

When using the application it is noticeable that the recorded path is crooked and not as smooth as desirable. This is a result of location providers imperfection in accuracy and precision. One approach to help solve this issue would be applying some algorithm on the point sequence that denes
4 http://code.google.com/android/add-ons/google-apis/maps-apisignup.html 5 http://www.openstreetmap.org/

the path. The path trajectory could be aligned and smoothed by using i.e. discrete Fourier transform for complex number sequence [2] by ltering out high frequencies. In general, processing against the points would not only have an impact on the appearance of the path, but would also optimize the data, because it would reduce the size of point sequence that denes the path.
5.3 Extending location providers

7.

REFERENCES

1. H. L. K. P. Abowd, Atkeson. Cyberguide: a mobile context-aware tour guide. Graphics, Visualization and Usability Centre, College of Computing, Georgia Institute of Technology, Atlanta, 1997. 2. E. O. Brigham. The fast Fourier transform and its applications. Prentice Hall, 1988. 3. M. Cheverst, Davies. Experiences of developing and deploying a context-aware tourist guide: The guide project. Distributed Multimedia Research Group Lancaster University, 2000. 4. B. Echtibi, Zemerly. Murshid: A mobile tourist companion. Khalifa University of Science, Technology and Research, 2009. 5. Freytag. Stdtetourismus in heidleberg ergebnisbericht zur gstebefragung 2003. Geographisches Institut der Universitt Heidelberg, 2003. 6. P. T. Raento, Oulasvirta. Contextphone: A prototyping platform for context-aware mobile applications. University of Helsinki and Helsinki Institute for Information, 2005.

The application could be extended to have more location providers rather than using only one. While developing we have tried out GPS, built-in Wi-Fi positioning system and a phone independent SkyHook 6 positioning system. There is an implementation example in the project using the later one as location provider. The single GPS provider was chosen due to rapid development needs, but more providers could be added for supporting location precision and accuracy or - as alternatives to one another. The system provided Wi-Fi location provider can be used directly in the project. To use SkyHook, one should extend the LocationProvider class.
5.4 Integrity and assurance

The application provides the ability to exchange trips data between client and server. However, the communication in mobile environment is very volatile, therefore application should have more focus on data integrity and assurance. In order to ensure that the data is exchanged properly without any losses or corruption the md5/sha data hashing could be introduced in particular data exchange phases. In our case when a user uploads a trip, server stores trips and returns mapped remote trip ids to local ones stored on the phone, so that the phone can update its local database and link local trips to the remote ones. However, in case the server has stored data successfully but the response is never returned to the client, the user might try to upload the data again. Therefore to assure the integrity, the server needs a hash of data to compare with and positively continue previous communication - respond to the client and return needed data.
6. CONCLUSION

The paper has discussed how the users of mobile phones can use the TourTracker application to create digital versions of tours and share the records with the public. Further, related work broadly reports on the current situation within the tour guides application area and discribes the similarities and differences between the TourTracker and already existing systems. Moreover, the paper ilustrates in detail how the application is built: what is the concept and architecture of the system, how location tracking is performed, the communication with external devices is implemented and how the data is stored on the device. In addition to that, the evaluation presents the results of interviewing people who tested the application. Based on these results we conclude that the application is benetial to most of the users and brings a new experience for creating guided tours, sharing as well as using downloaded tours from the remote public storage.
6

http://www.skyhookwireless.com/