Alternative Access Project: Mobile Scoping Study Final Report
A Phone Gap for a Map App
Download 6.11 Mb.
|
- Navigate this page:
- 2.1.9 HTML5 Cache
- 2.2 Summary of Technical Evaluation Strand Key Recommendations
- 3 User engagement
- 3.1 Field study
| 2.1.8 A Phone Gap for a Map App
Summary - Work in progress. A very early version of PhoneGap [3] was evaluated to obtain a geo fix ( as an alternative to the geo location API) which could then be used in web based mapping client. We successfully deployed an app to the Android simulator. Reviewing PhoneGap eight months later we note significant changes in the framework so we are planning to do some further work on evaluating the PhoneGap solution. Early in 2008 (prior to the project kick-off) we did an evaluation of a very early version of PhoneGap [3] framework, which provides a mechanism for developers to access native gadgets and sensors such as GPS, accelerometer and camera using familiar JavaScript rather than native languages normally required (e.g. Objective C). The framework provides a skeleton code base for each of its supported platforms ( Android, iPhone, Blackberry) that implements access to various sensors and gadgets in the device using a standard interface that is accessible in a special embedded browser. This means that developers can write code for the embedded browser that can be deployed without change in each of the supported PhoneGap platforms. While the developer needs to know enough about the platform specific development environment to compile and deploy (publish) an application, he does not need to learn a new programming language. In our evaluation we used PhoneGap [3] to obtain a geo fix from the GPS (this was before widespread adoption of the geo location API) and used the fix to centre a web based mapping (OpenLayers) client. At the time, we found the PhoneGap documentation for Android patchy and difficult to follow. We did eventually manage to get the application working on an Android simulator but only after considerable tweaking of both the JavaScript and native code base. Reviewing PhoneGap more than a year later we note significant changes in the framework and solid documentation including several books. So we are planning to do some further work on evaluating the PhoneGap solution as it clearly has moved on considerably since our first look. Similarly it may be worthwhile to evaluate W3C Widgets [17] that work in a similar way to PhoneGap but is based on an industry consortium standardization process rather than grassroots support. One thing we have learnt is that there is some developer resistance to using a hybrid framework such as PhoneGap. To deploy a PhoneGap based application on the iPhone, the developer has to sign up as a registered Apple developer, pay a license fee for the XCode development environment, learn how to compile and deploy an application and submit it to the AppStore for review. Given all this, many developers feel tempted to learn something about native development techniques and as the occasional “tweak” of the PhoneGap skeleton code will be necessary every now and then, the developer may soon become frustrated with the constraints of the framework and insist on developing an app from scratch, defeating the point of the exercise. As well “tweak creep” another non technical issue that emerged is the danger of the Developer License terms and conditions restricting use of frameworks such as PhoneGap. Recent changes to the Apple Developer licence agreement throw into question whether applications based on 3rd party APIs such as PhoneGap will continue to be accepted by the Apple App Store vetting process. A similar framework that Adobe released for Flash developers has been rejected by Apple and although PhoneGap appears to have escaped similar treatment, the risk remains that Apple may not allow applications to be published unless Apple approved coding libraries are used. Already only specific versions of PhoneGap are permitted and this may reduce a developers ability to take advantage of new functionality (e.g. front facing camera) being released in the latest version of the iPhone OS. 2.1.9 HTML5 Cache Summary - Experiment showing how HTML5 cache might be used to create an offline version of a mapped area. While mobile device is connected through a strong network such as WIFI or 3G the user requests a cached version of the map which is downloaded and stored in the device browser application cache. The map can later be accessed offline when 3G connectivity is not available In this evaluation we investigated how HTML5 Cache [1] might be used to create an offline version of a mapped area. We attempted to implement this using the OpenLayers mapping framework [5] with mixed success. The experiment demonstrated that in principle this technique would work but a number of restrictions would be placed on the service and some technical issues would need to be resolved to put the solution into a production service. The first restriction is that the map area has to be organized into a fixed set of tiles. This is because the HTML5 specification relies on URLs to locate the cached resource (in this case a map image) in the browser application cache. If the parameters in the URL specifying the geographic extent (bounding box) of the map are allowed to vary freely then the URL would be different even for very similar maps. Having a fixed set of map tiles to choose from resolves this problem. A second effect we noticed is that once the map has been cached only the cached version is used from that point on even when the device resumes its online data connection and the page refreshed. In the OpenLayers experiment this meant that no new requests could be obtained even when the user panned to a non cached area – essentially once offline you stay offline. Finally we noticed that the location fix obtained from the Geolocation API [2] failed when the browser was in offline mode. This is because the browser defaulted to use Wi-Fi or cell triangulation to obtain the location fix before attempting to access the device GPS. In the Firefox desktop browser and Safari mobile browser we were testing on this caused an unexpected error and the location fix failed. Clearly some more investigation on different configurations of mapping APIs (e.g. OpenLayers), the geolocation API and HTML5 Cache is needed to resolve these issues. Nevertheless, we think this is a mechanism that would work given some tweaking. One way to implement this on Digimap would be to integrate caching into the “MyMaps” function on ROAM and other desktop clients. When a user saves a map the details of URLs for all tiles within a 1km area of map are recoded and saved. While still connected to a high bandwidth data connection the user can retrieve the “MyMap” bookmark from the mobile device and the mobile browser will automatically download and cache all the map images for later use when the device has no data connection. 2.2 Summary of Technical Evaluation Strand Key Recommendations EDINA should take a leading role in providing an Open Source browser based mapping solution for mobile. Optimize HTML5 canvas image processing techniques further and open source the JavaScript to wider AJAX development community to maximize impact of the technical evaluation phase of this project. For the time being we believe it is more cost effective for EDINA to build relationships with external contractors and small software companies to outsource development of native applications rather than invest in training and maintaining native app development skills internally. 3 User engagement The aim of the user engagement activity was to find out how people are using Digimap already for creating location based services, what they would like to do in future and what we could do better to support their activities. We held interviews with people working in a range of academic and teaching disciplines to ask them about their experience and expectations. In addition, we gathered information from papers and conferences and review these below. While by no means an exhaustive, we demonstrate the range of uses that Digimap data has been put to use on mobile devices for teaching and conducting research. We also identify gaps where we think there is potential for greater use of Digimap and make recommendations on improvements. We would like to thank the many people who took time to speak to us and explain their work during the course of the project. 3.1 Field study Perhaps the most obvious use of Digimap on mobile is for field trip work, particularly where the subject matter is relevant to opaque aspects of the target site, such as its history, geology, social and political characteristics, flood levels, the built environment and land use. Pioneering work in this area has come from the SPLINT programme [18], where researchers have explored 2D and 3D tools for a range of learning and teaching tasks. For example, Priestnal [19] describes a first-year undergraduate geography field trip course near Keswick, Cumbria where 3d digital models were deployed to mobile devices to augment real scenes with hidden (geological) and past (glaciated) landscapes. A key teaching objective was for students to think more critically about the accuracy of 3d digital models and by seeing the digital model imposed on the real world view they were able to acquire a better appreciation for “ground truth”. The JISC funded “Walking Through Time” project [20] also demonstrated how Digimap and mobile can reveal the hidden features of place by placing historic maps “under your feet”. Dr. Ian Stimpson [21] reported informally on using Digimap data on PDA device for geology field trips. Claire Jarvis and Gemma Polmear [18] have used Digimap as background maps to provide context for students and school children taking part in field exercises, and integrated Digimap data with the popular mediascape authoring tool [22]. Researchers at the University at Nottingham developed a system that enables mobile phones to query web services offering metadata of geoscientific datasets [23], including resources exposed by the EDINA GoGeo portal. Augmented reality view of past glaciated landscape from Priestnal et al. [11] A Kingston University group led by Ken Field report on using Geology data along with OS topology and terrain data during a Geology field course in Ullapool, Scotland, where students were able to develop data collection skills for marking geological boundaries [24]. The Kingston group also report on a fieldwork trip in Malta where students were able to deal with problems identifying terms for features by uploading pictures from mobile devices to Twitpic [29] where others could comment creating a shared understanding of terms and improving the consistency of data collection between groups [25]. Similarly the Kingston group have experimented with Flickr [26], 3banana [27] and MyTracks [28] for sharing pictures, notes and location trails between students. As well as providing a mechanism for delivering and uploading data the Kingston group have focused on using mobile to support collaborative analysis of findings. In the past the analysis of findings, reflection and sharing of data between groups occurred after the fieldwork exercise rather than during it. The Kingston group found that the immediacy afforded by mobile added significantly to the educational impact of the field exercise. Some tutors however raised concerns that replacing the analogue notebook and sketchpad with instant data capture tools might reduce the opportunity for reflection and mental abstraction. There may be a role for Digimap in bringing together some of the features needed for students to share and comment on their findings replacing the eclectic collection of tools employed by the Kingston group with an integrated application for gathering data, recording trails, taking notes, annotating and sharing pictures and communicating in the field with students and tutors. Or it might be more pragmatic to simply integrate with the tools already available. We have not reached a clear position on this and perhaps the best option for now is to monitor activity of Kingston and others. While these examples of the use of Digimap in mobile is encouraging, the overall use of Digimap to support field exercises is perhaps a little disappointing given the potential educational applications for Digimap in field work. Based on discussions with individual academics we believe that a major barrier to adoption is the technical expertise required to port Digimap data sources to mobile applications. The relative success of more accessible technologies such as the HP’s Mediascape [22] (now Calvium [30]) and FutureLab’s school version “Create-A-Scape” [31] suggests that if barriers are removed educators will exploit mobile for supporting field trips far more readily. The concept of location triggered media is an interesting prospect for EDINA as we are in the process of geo coding some of our media collections that could be incorporated along with maps into a Mediascape style application. The success of institutional podcasting initiatives such as the Oxford Steeple project [32] suggests there is strong demand for delivering educational content such as lecture audio podcasts to mobile. An interesting prospect for EDINA is to explore is the potential for geo coding audio material using speech recognition technology. So for example an architecture student walking in a city could be alerted to part of a podcast of lecture that mentions a building in the vicinity. Speaking to Simon King at Edinburgh’s Centre for Speech Technology Research, the state of art technology may well be able to achieve a reasonable first parse, allowing the podcast author to correct an automated transcription of places mentioned in the audio file. However King stressed that a small scale research project would be necessary to find out how well speech technology could perform in this context. 
Directory: 2010 2010 -> Through the Roof 2010 -> 2004 ieee international topical meeting on microwave photonics technical digest 2010 -> The petition and case system 2010 -> Hr 116 Application for Employment with Hills and Dales 2010 -> Polimaster ltd V. Rae systems inc polimaster ltd.; Na&se trading co., Limited, Plaintiffs-Appellants 2010 -> The tandem project 2010 -> Cape Lookout National Seashore Historic Resource Study By 2010 -> Cape Lookout National Seashore Historic Resource Study By 2010 -> Ap u. S. History presidents list the Young Republic, 1788-1815 George Washington, 1789-1797 Download 6.11 Mb. Share with your friends:
|