Mobile Tourism

Designing and Developing a Location-Based Mobile

Tourism Application by Using Cloud-Based Platform

Maziyar Shariat Panahi

Faculty of Creative Multimedia

Multimedia University

Cyberjaya, Malaysia

[email protected]

Peter Woods

Faculty of Creative Multimedia

Multimedia University

Cyberjaya, Malaysia

[email protected]

Harold Thwaites

Centre for Creative Content and

Digital Innovation

University of Malaya

Kuala Lumpur, Malaysia

[email protected]

Abstract— This paper describes the design and development of

a location-based mobile tourism application for cultural

tourism in Malaysia by using a cloud-based platform. The

architecture consists of three levels, front-end, middle-ware,

and a back-end level that is built on Amazon Web Services

(AWS) cloud platform. The front-end level is a location-based

mobile tourism application for Apple mobile devices, to

explore nearby cultural tourism places. The middle-ware level

provides a Web service to generate eXtensible Markup

Language (XML) output from the relational database to

exchange data between the mobile application and servers in

the cloud. Finally, the back-end level that is built on AWS

cloud platform provides services such as Apache Web server

on Amazon Elastic Computing Cloud (EC2), MySQL database

server on Amazon Relational Database Service (RDS), and a

cloud storage that uses Amazon Simple Storage Service (S3),

giving flexible, auto scalable, and secure servers to provide

required services. The application is also caching images on the

local storage and storing some data in SQLite database on the

mobile device itself to provide some offline activities, and also

decrease the number of sending requests to the servers, in

order to save some data traffic.

Keywords- mobile tourism, location-based application, cloud-

based platforms, web services, XML.

I. INTRODUCTION

Mobile tourism is relatively a new trend in tourism and involves mobile devices as electronic tourist guides. While most of the technology is already available there are still some issues to be considered such as design, usability, and functionality [1]. Mobile tourism has attracted much research interest, resulting in many mobile and web-based applications. There are still some restrictions and weaknesses to be addressed [2].

This research covers some of these weaknesses, for instance, to solve restricted energy capacity a method was implemented that turns on the GPS when needed and turns it off as soon as application gets the tourist current location. It also uses Wi-Fi and cellular networks to monitor any significant change in tourist current position when the GPS is off and it will turn on the GPS again to have more accurate

coordinates and then it will be turned off to save battery life. By managing expensive resources like GPS that drains the battery the device lasts longer while user is using the application.

The computing processes are managed to solve the limited computing power of some mobile devices. Appropriate frameworks were chosen and best third-party libraries avoid any unnecessary processes. A multithreaded model is used to put some heavy and time-consuming tasks into the queue of tasks to be executed in the background. The processor executes the tasks in the background when it is free and it prioritizes the main queue to execute user interactions first.

Mobile devices have also limited amount of memory [3]. By monitoring memory peak usage during the development stage memory usage efficiency was improved. The application downloads an XML file and parses the file in the memory. A library that is the fastest of all of the current methods and efficient in memory usage was chosen.

The last limitation is bandwidth and high cost of wireless connections [1]. A small-embedded database on the mobile device was designed that stores data to use when it is necessary, for instance when tourists are not connected to the Internet. A caching system and image store was developed for local storage of a mobile device to reduce the number of requests to the back-end level and save data traffic. It costs less from users perspective when they try to access to the same images by their own 3G/LTE network. This approach also gives a better functionality when tourists are in slow public networks and offline mode.

A location-based mobile application for cultural tourism in Malaysia was designed and developed by using a cloud-based platform to find out where the tourists are, where they are looking at by using heading technology or digital compass, calculate distances between current position and places, display only nearby attractions, give direction to tourists, and let them share visited places with other people.

978-1-4673-5817-0/13/$31.00 ©2013 IEEE

TIMEe 2013, Bandung 23-26 June 2013

152

II. DESIGN AND DEVELOPMENT

The front-end level was designed and developed for the end-user mobile devices, which are the Apple mobile devices programmed on iOS platforms, and it displays nearby cultural tourism attractions in Kuala Lumpur the capital of Malaysia. The middle-ware level provides a Web service to generate XML output from the relational database to communicate with the mobile application.

Finally, the back-end level that is built on AWS cloud platform to provide three services, Apache Web server on Amazon Elastic Computing Cloud (EC2), MySQL database server that is deployed on Amazon Relational Database Service (RDS), and a cloud storage that uses Amazon Simple Storage Service (S3), to have a flexible, dynamically scalable, and secure network infrastructure.

A. Front-end Level

A location-based mobile tourism application was designed and developed for iOS platforms to be able to run on Apple mobile devices such as iPhone 3GS/4/4S/5, iPad 2/3/4, iPad mini, and iPod Touch 4/5. In order to create an application for these devices, developers have to use an Integrated Development Environment (IDE) named Xcode [4], which includes several tools for software development. As it shown in Fig. 1, the application displays nearest cultural attractions on a map within 1 km radius from the tourist’s current location.

There are two elements in this view, the first is the map and the second one is the annotations on a map that represent the nearest places. Fig. 1(a) shows how application displays

those nearby places within 1 km and tourist current location with a blue circle. Also as it can be seen in Fig. 1(b), if the tourist taps on each of one these annotations on the map, it shows some information in annotation callout such as name of the place, category of the place (we defined three categories: museums, natural parks, and historical places), calculated distance between the tourist’s current location and the selected place on the map, and a photo of that place.

As it shown in Fig. 2, there are three steps to retrieve the required information from the servers. At the first step the device will send a simple request via http to the back-end level that hosts the content on the servers. At step two, the back-end level and middle-ware level will be responsible to create a response by generating an XML output from the stored records on the relational MySQL database server.

After generating XML response by Web service the application in step three downloads the file into the memory and reads it by parsing the file. An XML parser is used to parse the downloaded XML file from Web service and create Document Object Model (DOM) elements, which later can be manipulated by the application. As seen in Fig. 2, at the last step those elements are ready to be used and displayed, calculated, and stored in device local SQLite database.

Choosing an XML parser is a serious challenge when it comes to parsing a document on mobile devices with limited hardware capabilities. There should be a parser that can parse fast, with no errors, and use an efficient amount of memory. Based on an experiment Wenderlich did on XML parser performance with eight most popular XML parsers for the iOS platforms [5], TBXML [6] was considered as the fastest of all of the methods and quite efficient in memory usage. TBXML library was used, as it is an open-source and lightweight XML document parser, written in Objective-C language especially for Apple iPad, iPhone, and iPod Touch devices.

(a) (b)

Figure 1. (a) Displaying cultural tourism places within 1 (km) on a

map. (b) Displaying retrieved information in annotation callout

Figure 2. Frontend level workflow and its relation to the other levels

978-1-4673-5817-0/13/$31.00 ©2013 IEEE


153

Fig. 3 shows the crated DOM elements from XML parser to be stored in an array to be used later. There is dynamic content that need to be calculated and generated once the XML file is entirely parsed and all the DOM elements are created. Before filtering nearby places, should all the distances between all the places and tourist current location should be calculated. This is considered as real-time computing as each time the results of these calculations will be different because of different tourist location and different situation. Therefore, these results will not be stored into the SQLite database and are calculated each time.

The distances are calculating by using an algorithm that Apple has in its core location framework, which measures the distance each time between two geolocation points by drawing a line between them and following the curvature of the Earth [7]. Each time the algorithm calculates the distance between tourist current location and the latest retrieved element from parsed XML file, and stores it in an array to be used for filtering when the parsing process is finished.

As it can be seen in Fig. 3, the calculated distances next will be used to filter the places that are out of 1 km radius from the tourist by putting each distance in a decision making structure and using conditional operators to check whether the stored distance is in the defined radius. It also will be displayed inside the annotation callout when the tourist taps on the annotation on a map to find out more information about that place. In this way, tourists can find out about their distance between their locations to the desired place by one action.

When the application displays the places on the map the title, description, photo URL, latitude, and longitude are already in the memory and stored in the SQLite for further offline usage. Although calculating the distances between the current location and the DOM elements and the filtering operations are done, still one more operation is needed so when the tourist taps on an annotation the photo of a place inside the annotation callout can be seen. By using “img URL” from each DOM element the image can be downloaded from the given URL to display it inside the callout.

Before simply requesting the data from the stored URL address, there are some concerns that should be considered. The actions that need to be computed by mobile processor and files that need to be downloaded from Internet are the most expensive acts that can lead to poor functionality by being slow, not responsive to the user interactions, and also unexpected crashes. To avoid this, images are downloaded from the online cloud storage server every time a tourist taps on any annotation on a map, instead of downloading the images all at once at the outset.

However, downloading needs to be in the way that waiting time does not block any user interaction or Graphic User Interface (GUI) on a device. A multithreaded model was used to put some heavy and time-consuming tasks into the queue of tasks to be executed in the background. Therefore, the processor executes the tasks in the background when it is free and it prioritizes the main queue first to execute user interactions first.

Additionally, this method of only downloading the selected place makes the application launch faster by reducing the initialization time. There is another benefit that data traffic is saved on both tourist’s side and our side. Tourists who are not using public Internet need to buy a package plan or other services in order to connect to the Internet. Downloading so many images knowing that tourists may not use them all is wasting data. Downloading unnecessary content is not an efficient usage of the cloud storage.

To keep requests as efficient as possible and avoid unnecessary request to the cloud storage server a cache system was used where the downloaded image will be stored on a local storage on mobile device. Next time the tourist requests that image by tapping on an annotation, it first checks the disk to see if there is any image is saved with the same name, if so will load the image from local storage and not request to the cloud storage.

As it shown in Fig.1, there is a detail disclosure button with blue color that navigates tourists to the next view where they can find more information. Perhaps repeating some information from previous view such as a same image but enlarged to be more visible, a distance to that place, and category of the place would be helpful just in case if they missed it or they need to see again.

Figure 3. Storing data on SQLite database, caching images on local

storage, and computing some processes

978-1-4673-5817-0/13/$31.00 ©2013 IEEE


154

As it shown in Fig. 4(a), there are new features in detail view such as address, sharing option, getting direction from current location to the selected place, and getting direction from selected place to the current location.

The address calculates by using a process named reverse geocoding when the application sends a place’s coordinates (latitude and longitude) to Apple servers and Apple in response returns a Placemark object. The Placemark is an array of country, state, city, and street address related to the given coordinates. By using returned items the readable address for the place is made and helps tourists to find out the address and use it later if they want to take a taxi or ask local people.

As it shown in Fig. 4(b), tourists can share the place with others through a variety of services such as social networks (Facebook and Twitter) or other communication tools (Mail and Message) in order to either plan the trip with each other or just share a visited place with their friends.

Directions from the current location to the selected place are most important from a tourist perspective. Getting to the place without getting lost is a goal achieved by getting direction from Apple Maps application. The application sends the place’s coordinate (latitude, longitude) to the Apple Maps application in order to get directions. The reason for using Apple Maps application is that it has many features. A useful feature in Apple Maps application is Turn-by-Turn navigation option as it can be seen in Fig. 5(b). There are other features that might be helpful to the tourist by using Apple Maps application such as displaying buildings in 3D or satellite view.

A GPS sleep mode was developed to solve restricted energy capacity that turns on the GPS when it needs it and turns it off as soon as application gets the tourist current location. It also uses Wi-Fi and cellular networks to monitor any significant change in tourist current position when the GPS is off and it will turn on the GPS again to have more accurate coordinates and then turn off again.

The other addressed issue is the lack of evaluation of the value of location-based platforms. Evaluating the real value of location-based mobile applications is only possible by evaluating it on a real device. Therefore, after one month of testing on simulator it was tested on a real device for five months in a variety of situations that cloud happen in a real world for users with mobile devices.

We have done many field tests in different places such as subways stations and some popular train stations to see if the application is still able to know where the tourists are, where they are looking by using Apple heading technology or digital compass. It was responsive and fast even over 3G networks because of the caching and data traffic saving, easy and clear navigation while walking, and presented content effectively.

B. Middle-ware Level

This level is responsible to exchange data between the location-based mobile tourism application in front-end level and the relational database server deployed on Amazon RDS. As it shown in Fig. 6, the application sends a simple request via http and the middle-ware level tries to query the data from the MySQL database server and after reading the data from database, it generates XML output so later front-end level can parse and make DOM elements.

(a)

(b)

Figure 4. (a) Displaying some details about the place. (b) Displaying

sharing options

(a)

(b)

Figure 5. (a) Displaying direction from tourist current location. (b)

Displaying turn-by-turn navigation

Figure 6. Data exchange model provided by web service written in

PHP framework

978-1-4673-5817-0/13/$31.00 ©2013 IEEE


155

Communicating and exchanging data by using Web service in XML format not only makes it possible to access the stored content on MySQL database server, but also it is publicly available for other developers to use it in their own applications. By using Web service some processes can be run privately in both sides of front-end and back-end level. It is more secure to have a read-only connection to the MySQL database and make developers only deal with the web service by requesting the data and have an outcome in XML format just like an Application Programming Interface (API).

The content for this project was gathered from related websites and other official documents. A Web-publishing platform named Omeka [8] was used to store data and make them accessible from Internet domain name address http://www.culturaltoursim.info. Omeka is an open-source Web-publishing platform used to managing the digital content on a Web. The Omeka platform has its own output in different standard format such as XML and JavaScript Object Notation (JSON). This project used a plugin named Geolocation [9] and was customized to query more related data from relational MySQL database.

C. Back-end Level

In back-end level the servers and the network infrastructure were built as seen in Fig. 7 by using Amazon Web Services (AWS) cloud platform. Amazon Elastic Cloud Computing (EC2) is used as a virtual server in the cloud to run the Apache Web server with resizable compute capacity. Amazon Relational Database Service (RDS) was used to have a relational MySQL database server in the cloud to host the database. Finally the content was hosted on Amazon Simple Storage Service (S3) to provide fast and scalable storage in the cloud for storing the media files.

All of these services are accessible in one of several regions, Asia Pacific (Singapore) was chosen because the location-based mobile tourism application will be used in Malaysia.

The Apache Web server hosted the Web-publishing platform Omeka and provided other services via http requests such as exchanging data via http. The reason for choosing Amazon EC2 was a bigger capacity than a data center of computers [10], a virtual private cloud with secure environment, auto scaling ability, able to handle high I/O, and available in different regions.

One of the most important parts of this project is the database server that stores all the content. Amazon RDS was chosen to take advantage of features such as being isolated and secure, auto backups, auto host replacement in case of hardware failure, easily scaling up, and available on multiple zones. The performance of MySQL database server could affect the performance of the mobile application because of the need to connect to MySQL database server and execute queries to generate the XML file to be downloaded and parsed by application.

Amazon S3 was used for storing media files instead of using other online cloud storage or own storage with public access. Storing files on Amazon S3 reduces the cost of transferring data [11], which is the primary cost in cloud storage and make the performance much better [12] by having scalability, protection, and accessibility among several regions cloud storage. Amazon S3 also supports Representational State Transfer (REST) and Simple Object Access Protocol SOAP standard to able to work with any Internet-development toolkit. As it can be seen in Fig. 7, MySQL database server backups are also stored into Amazon S3.

The difference between using shared Linux Web-hosting solution like GoDaddy and using Web services in the cloud like AWS is visible to the naked eye and there is no need to use any instruments to see the different. The application took 10sec to 20sec from sending a request to the server, connecting to the MySQL database, executing the queries, and having an XML file ready to be downloaded and parsed when it was hosted on GoDaddy. The number changes and it may get worse because it is a shared Web-hosting solution and other people are using the same resources (CPU, database, memory, etc.).

However, as designed and developed the Web services in AWS cloud platform, only took 536ms to make SQL queries by PHP framework in Amazon EC2, requesting the queries from Amazon RDS, and generating the XML file to be downloaded and parsed later by the application. It also downloads images from Amazon S3 faster than GoDaddy File Transfer Protocol (FTP) and it makes the application fast and smooth even on slower networks.

Figure 7. Back-end level architecture on Amazon Web Services cloud

platform

978-1-4673-5817-0/13/$31.00 ©2013 IEEE


156

III. CONCLUSION AND FUTURE WORKS

We designed and developed a location-based mobile tourism application for iOS platforms as a front-end level, which displays nearby cultural tourism attractions in Kuala Lumpur, the capital of Malaysia. We used a Web service to generate XML output from our relational database Amazon MySQL RDS to exchange data with our mobile application in middle-ware level. We also built our servers in the cloud by using Amazon Web Services cloud platform to take advantage of cloud computing and cloud storage. The potential advantages in presented architecture are:

1. We designed an architecture based on a cloud-based platform to get closer to the reality of location-based applications. The demand for location-based services is increasing everyday and number of users is increasing by time. Having a stable, flexible, secure, and scalable application is required these days.

3. We managed to lower the pressure on our servers by using mobile computing in order to provide services for more users with the same resources.

4. By using caching system and storing images on the local storage of mobile device, we made the application reduce the number of request to the back-end level and saved data traffic. In AWS we pay as we go and less traffic data we have the less it costs and also saves some costs for users when they try to access information by their own 3G/LTE network. This approach also gives a better functionality when tourists are in slow public networks and offline mode.

5. Using the middle-ware level approach helps to have a simple request by http and a result in XML format so not only mobile devices can communicate with the back-end level, but also the other machines like desktop applications or other mobile platforms like Android, Windows Phone, and BlackBerry can take advantage of this openly accessible file and access to our content.

In future works we consider using personal information to filter our content not only based on the tourist’s current location, but also based on personal information and tourist’s interests. We are also interested to integrate our application with some of the existing social networks such as Facebook, Google+, and Foursquare in order to request users’ personal information and communicate with their API to display other point of interest. Finally we need to evaluate our mobile application usability by field experiments with tourists to find out about users’ satisfaction about interface, learnability, and functionality.

ACKNOWLEDGMENT

This work was supported by Development of Malaysian Culture and Heritage Digital Bank project in the Faculty of Creative Multimedia, Multimedia University, under a Telekom Malaysia (TM) Research & Development grant.

REFERENCES

[1] M. Kenteris, D. Gavalas, and D. Economou, "An innovative mobile electronic tourist guide application," Personal and ubiquitous

computing, vol. 13, pp. 103-118, Feb 2009.

[2] G. Chen and D. Kotz, "A survey of context-aware mobile computing

research," Technical Report TR2000-381, Dept. of Computer Science, Dartmouth College2000.

[3] M. Ebner, C. Stickel, and J. Kolbitsch, "iPhone/iPad human interface

design," HCI in Work and Learning, Life and Leisure, pp. 489-492, 2010.

[4] Apple Developer, (2012). Xocde IDE, [Online], Available:

https://developer.apple.com/xcode/,

[5] R. Wenderlich, (2010). How to choose the best XML parser for your iPhone project, [Online], Available:

http://www.raywenderlich.com/553/how-to-chose-the-best-xml-parser-for-your-iphone-project, January 2013.

[6] T. Bradley, (2009). TBXML, [Online], Available:

http://www.tbxml.co.uk, August 2012.

[7] Apple Developer, (2012). Core Location Framework Reference, [Online], Available:

https://developer.apple.com/library/ios/documentation/CoreLocation/Reference/CoreLocation_Framework/CoreLocation_Framework.pdf,

September 2012.

[8] Omeka, (2012). Omeka: Serious web publishing, [Online], Available:

http://omeka.org/about/, Spetember 2012.

[9] Omeka, (2009). Geolocation plugin, [Online], Available: http://omeka.org/codex/Plugins/Geolocation, September 2012.

[10] R. L. Grossman, "The case for cloud computing," IT professional,

vol. 11, pp. 23-27, 2009.

[11] G. Juve, E. Deelman, K. Vahi, G. Mehta, B. Berriman, B. P. Berman, and P. Maechling, "Scientific workflow applications on Amazon

EC2," in E-Science Workshops, 2009 5th IEEE International Conference on, 2009, pp. 59-66.

[12] M. R. Palankar, A. Iamnitchi, M. Ripeanu, and S. Garfinkel,

"Amazon S3 for science grids: a viable solution?," in Proceedings of the 2008 international workshop on Data-aware distributed

computing, 2008, pp. 55-64.

978-1-4673-5817-0/13/$31.00 ©2013 IEEE


157

Mobile Tourism

Documents

Transcript of Mobile Tourism