A historical audio and video guidebook for an Android smartphone/tablet John Reid September 2011 Dissertation submitted in partial fulfilment for the degree

2.5A Comparison of the guidebooks

The table in Figure 4. shows a comparison of the reviewed historical guidebook applications for mobile devices. As seen from the table, none of the other guidebook applications reviewed had the more diverse features of this application: the use of offline historical maps, the ability to lock the guidebooks to an area, the use of sign language videos and the use of text to speech technology. In addition to this, none of the others had the ability to change the content of the guidebook based on the weather.

4. 
   A comparison of other historical guidebooks
   

Several features which were not implemented in this application but were on some of the others included the use of a slider to fade between maps and the ability to draw paths on the map for the user to follow (a very practical and helpful feature).

In the HGuide application the text was separated from the images by placing them into different pages. The advantage of doing that was the images could be shown at almost full screen; an important benefit for users with small screens on their mobile devices. It should also be noted that a disadvantage of using guidebooks on a mobile device was that the application could drain the device’s battery (especially if GPS was being used).
During the development of the application, some of the tour guides at Edinburgh castle were asked if they used any mobile devices to help them present their content during tours of castle but none were being used. However, it later seemed that mobile devices were being used at the Culloden battlefield near Inverness by the National Trust for Scotland. The “Battlefield Guide” software was available in different languages and was used to describe the history of the site using multimedia content [10]. Unfortunately it was not possible to review this application since, at the time of writing, it was only being used at that particular site.

3Tools and Design Guidelines

3.1Technologies Used

3.1.1Development Environment

Since the program was being developed on a Microsoft Windows machine, it was necessary to join the Samsung developer network (innovator.samsungmobile.com) [11] to be able to download the device driver for the smartphone that was being used for development (a Samsung Galaxy Europa). Once this was done, the application could then be downloaded and run on the smartphone.

The “Tortoise” subversion client was downloaded and installed to get access to open source, revision controlled software (to check out the latest versions of code to work on). Periodically through the development process a difference would be performed to see if any files had changed. “Tortoise” was a package that had been used by myself on other projects successfully and was reliable as well as free to use.

The application was normally targeted to run on Android 2.1 (update 1) since that was the version of Android being used on the two development smartphones. Additionally, the application was run on different Android emulators so the application could be tested on several versions of Android. This included the Samsung Galaxy Tab emulator and the Honeycomb emulator.

One problem encountered with the Android emulator was how to send multiple files to its pseudo SD card. It took a while to discover how this could be achieved since in Eclipse only one file at a time could be transferred to the device in the DDMS (Dalvik Debug Monitor Server) file explorer window. The solution was to use the “adb” command which it was discovered could send directories as well as individual files to the target device. On real hardware, files were copied to the device’s micro SD card simply by using an SD card to USB converter.

3.1.2Software Packages used

3.1.3Android Technology

Several technologies particular to Android were also used in this project. The “Text To Speech” Google component was used to convert written text into audio in the application. This fitted in well with one of the aims of the project in supporting the audio features of the application as well as making the application more flexible (audio would not have to be re-recorded if content text was changed).

Several third party Android widgets were investigated and included in the application since they were judged to offer something of value. The osmdroid “MapView” component [32] was used and extended by myself to allow offline maps to be used (and the displayed maps to be customised). The “WheelView” widget [28] was used to make the selection of the guidebooks look more professional.

Another technology that was used extensively was XML both for storing data and in the weather check feature of the application (as described in Section 5.6 and section 6.5 respectively). The latter aspect relied on the parsing of XML data from a weather service to tailor the content of the application to the current weather conditions.

3.1.4XML Guidebook Files

Data used in the application was stored in XML format rather than in a database. There were several reasons for this: not a lot of data needed to be stored and, as mentioned in section 3.2.3, XML was a good choice for cross platform development. Indeed the same XML files could be used.

Other reasons for choosing XML for the guidebook included:

• 
  Android already included a (DOM) XML parser
  
• 
  XML used Unicode for Multi-Language support
  
• 
  Flexible
  
• 
  It was human readable and easily editable in a text editor
  

Using XML files in the application gave a flexible way to store guidebook data; it was easy to add additional attributes into the elements (if an extra item needed to be stored, it could be simply added in without affecting the rest of the data in the file). In the application code, the “MPU” class contained the code to parse XML guidebook files.

5. 
   An example XML guidebook
   

As shown in the (modified) XML file in Figure 5., each XML file described a different guidebook. To make the application more flexible, these files were made as independent as possible from the code itself so that, it was hoped, new guidebooks could be added without having to update the software (giving a clear separation between the application and its content). This also helped to make each guidebook independent from the others, so changes in one would not affect another.

The text displayed on the page was either stored in the XML file (as described in section 4.6) or stored in its own text file. Initially one XML file was created for each guidebook language supported, (for example “oldedinburgh_EN.XML” for English and “oldedinburgh_IT.XML” for Italian) but this meant that every time a change was made in one file the same change had to be made in all the other files. This proved to be time consuming and error prone so the idea was abandoned and instead one XML file for each guidebook was used with that guidebook containing all the text for all the languages the application supported. Similarly, the file also stored the title of each guidebook (again for all the languages supported) rather than it being embedded in the application code.

Directory: courses -> ITNP99 -> PastDissertations -> 2010-2011 -> Dissertations
courses -> Ieor 4600 Mixed-Integer Rounding Inequalities
courses -> San José State University Social Science/Psychology Psych 175, Management Psychology, Section 1, Spring 2014
courses -> Kennan's Telegram (Excerpt)
courses -> The university of british columbia
courses -> A hurricane track density function and empirical orthogonal function approach to predicting seasonal hurricane activity in the Atlantic Basin Elinor Keith April 17, 2007 Abstract
courses -> Cover page need figure & title by Proposed Table of Contents
courses -> Objectives
courses -> Dr. Jeff Masters' WunderBlog

Download 239.28 Kb.

Share with your friends: