locative media, literature and the mobile internet

cross-platform locative media

i have just figured out how to make locative media applications that work across different mobile platforms. that is, one application that works both on the iphone, android, maemo and probably soon any other mobile platform. how? through the browser-based w3c geolocation api. i briefly mentioned this in yesterday’s post, but was suffering under the misunderstanding that this was somehow still a vision for the future. it is not! the geolocation api is currently supported by the iphone os (3.0), android (2.* – gears geolocation works in 1.6), and anywhere you can use firefox (on mobile, that is currently only nokia’s maemo and the upcoming MeeGo, but the android version is on its way).

here’s a good overview, which introduces a third option (geo.js) which claims to support several other platforms such as blackberry, nokia n97, windows mobile, palm pre and more.

here’s a test script that should work in the standard browsers on iphone, android 2 and android 1.6 (using gears). (info about the script.) to try it out myself i put together my own simple dummy in a few moments yesterday (norwegian only). it works both in an iphone and in firefox on my laptop, but i have not been able to test it myself in android 2.0 (and haven’t implemented a gears fallback on 1.6).

so all the details are not fully clear yet, and of course total cross-platform outreach is still elusive – but the point should be very clear: it is possible to create locative web applications that reach out much further than just to the 9% of the world’s smartphones (that is, 1% of all mobile phones) which are iphones. as long as one doesn’t need the full capabilities of a native app – and if you’re not designing a 3D computer game, do you? – then a web application using html5, javascript and css can be a good way to reach an audience twice the size of the limited group that has access to the app store.

update 7 may: allright, so of course there was a catch. the google maps api terms of use has a clause (10.9) that restricts real-time positioning. specifically, it prohibits:

real time navigation or route guidance, including but not limited to turn-by-turn route guidance that is synchronized to the position of a user’s sensor-enabled device

so, it seems that if one wants to use google maps to create a browser-based web application, one cannot have real time positioning. one CAN have real-time positioning though, as long as one skips google maps – and probably there is some way of geocoding. but i guess a location-based app without maps is not very good. open street map would be a solution, if there is a good way to use osm in a web app – but doubt that is as easy as using the google maps api. the other alternative, of course, would be simply to forgo real-time positioning, and instead put a button in front of the user saying “find my position”. for the purposes of the textopia project, i am actually going to consider this. it will not be perfect, but that’s the price of cross-platform programming i guess…

update 18 may: found another limitation worth mentioning: safari on iphone does not allow embedding of media in webpages. it also does not support autoplay, and as far as i understand you also can’t receive media events in javascript, since playback is outside of the browser. these are significant limitations of course, however they apparently do not apply to the ipad. haven’t found good documentation on these issues for android, but as far as i can see from playing around with it the same limitations apply, except that you can actually start playback automatically.