A historical audio and video guidebook for an Android smartphone/tablet John Reid September 2011 Dissertation submitted in partial fulfilment for the degree
Download 239.28 Kb.
|
- Navigate this page:
- 5.3Videos
- 5.4Audio
- 5.5Weather Check
- 5.6Geo-Locking
5.2EngravingsIn addition to the historic maps, there was an engraving that it was hoped could be added into the application. Since it was a large image, it was unsure if it would be seen well on a mobile device. Initially, two methods were considered; creating a new Android component that could show an image and be easily zoomed into or to use the free “one-finger zoom” component developed by Sony-Ericsson [61]. However, once the osmdroid “MapView” component was working, it was seen that this could also be used to show the engraving. The benefits of doing this were that users would already be familiar with its operation and this component already supported panning and zooming. To achieve this, the image of the engraving was tiled in a similar manner to the historic maps (using the MapTiler software) but it did not need to be georeferenced. 5.3VideosOne of the aims of the project was to allow video content to be displayed in the guidebook. It was felt that doing so would make the application more interesting. There are several standards for the encoding of video material and Android 2.1 could officially support three of them: MPEG-4, H.263 and H.264 [62]. A program called “handbrake” [37] was used to re-code video files into the H.264 format suitable for playing on the Android platform. A video of Edinburgh castle was coded in this way and added to the application. 
An Android activity called “VideoViewActivity” was created to display these video files. It was designed so that when video playback was finished the activity was automatically closed and the user returned to the previous activity/screen. If a video file could not be found then a suitable error message was displayed and logged. The sign language videos were handled in the same way. 5.4AudioOriginally when the user pressed the audio play button, an mp3 encoded audio file was played using the “MediaPlayer” component in Android. However, for the user trials a system menu option was created in the application to give users the ability to use the "Text to Speech" feature in Android [70]. This feature allowed text to be converted into audio, offering a quick and easy way to let users hear the text as well as reading it. The advantages of using “Text to Speech” were that it took up less space (no audio files would have to be stored) and if the text content was changed, the audio would not need to be recorded again. If the Google Text to Speech resource files were not installed then the application would attempt to fetch and install them from the Android marketplace. At the time of writing, a downside to it was that it only supported 5 languages. If the option was not enabled, then a single audio file would be played (the actual name of the audio file being stored in the guidebook XML file). When the audio was played or paused, a message would be displayed to visually confirm to a user (who may be hard of hearing or the volume control being set too low) that audio was being played. 5.5Weather CheckThis feature was added to make the guidebook application more interactive by allowing the content displayed to be changed based on the current weather conditions for the area covered in the book. The idea behind this was that if, for example, it was snowing in Edinburgh then the guidebook would display wintry images to match those conditions. Additionally, the application could show different locations based on the current weather conditions (for example listing indoor places first). To test this out, the introduction pages in the “Edinburgh Castle” guidebook were modified (Figure 26.). If the weather conditions were unfavourable then the image in the centre was shown, if the weather was wintry then the right hand image was displayed otherwise the image on the left was shown. Rather than storing three filenames in the guidebook XML file, the images displayed all had the same filename with the exception of the last 3 letters (the image for wintry conditions was “ The code to check the weather condition was only run if there was an active data connection. When there was, the application connected to the weather server, downloaded the data and then stored it. Originally several weather information providers were considered; the METAR data stream from the NOAA looked promising [63] but it was seen that many developers were using a weather service provided by Google. This had the advantage of being a simple XML based service and example code was already available on several websites on how to use it [52]. A downside of using this service was that it was not officially supported by Google and there was no certainty that they would continue to maintain it.
5.6Geo-LockingWhen the list of guidebooks was displayed to the user, a lock symbol could appear next to a particular book’s title. The lock symbol signified that a guidebook would only be viewable if the user was in a specific geographical area (typically the site the guidebook was about). This feature was included for several reasons: many properties make money from guidebook sales and so a mechanism to protect this could make the transition from paper to electronic format slightly easier. Additionally, it could also be used as a mechanism to encourage people to visit a place (to see the content within a geolocked guidebook). For ease of testing, the specific location (lock point) of a geolocked guidebook was embedded in the application rather than being encrypted in the guidebook XML file. Figure 27. shows the message that would appear to a user if a guidebook was geo-locked. When this appeared the user could either wait until the application had found their current location or they could press the Back button to stop waiting. When the user’s location was known, the application would then check if the user was within one kilometre of the guidebook’s lock point. If so, then the guidebook would be activated and the chapters displayed; otherwise a message would be displayed to the user (Figure 28.) informing them of their position, how far they were away from the location and an explanation of why they were not allowed to see the guidebook. This “distance from location” information was originally added for testing purposes but it was kept in as it was useful for letting the user know how far away they were from the location.
A dialog box class called “HGuideGeoLockDialog” was created to display the message using the Android location manager to request location information. It was important to note that when the dialog window was closed (either by the user pressing the Back key or the device being rotated) that the location manager be notified to stop receiving location updates. This was done not only to save power but also to avoid the location manager calling a dialog that was no longer visible (which could cause an exception in Android). Since the location code could take a long time to fix a user’s position, in common with many other applications, the code also checked the last known good location. If this last known location was available and it matched the guidebook location, then the application would let the user view the guidebook. As mentioned in the Android documentation [26] this location information could be inaccurate (out-of-date) for example if the device was turned off and moved to another location but it was a worthwhile check to minimise the delay to the user. A downside to this was that the guidebook could still then be used even after they had left the site but it was considered the fact that they had been there to be more important. The first attempt at implementing this feature used a simple bounding box algorithm (to check the user was within a given area) but this was later changed to use the distance between two points (the user’s current location and the specified lock point). The distance between two points on a globe can be calculated using the “haversine” formula [64] and that was the algorithm used in the application. For simplicity, the user was considered to be at the location if they were within 1 kilometre of it. Originally Wikipedia was used to find the GPS co-ordinates of locations but then it was discovered that a website called “www.getlatlon.com” [65] could be used to get the latitude and longitude of a particular location anywhere on the planet. For the user trials, an option was added in the settings menu to disable the geolocking so the guidebook(s) could be viewed anywhere. 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:
|
