When Apple announced iPhone's Core Location a lot of people got really excited. Since then, I've heard from any number of developers who would like to use core location and other iPhone-specific features in web-based applications and were wondering how to approach this. This has got me to thinking for a few days, especially since I'm not much of a web developer.
There are two ways I've pondered that web developers might access features that are exposed to the SDK and not to Safari. They are by embedding and outsourcing.
By embedding, I mean building a normal Safari-based website but embedding it into a native application. If you've used Installer.app, you've seen web views in action. Application listings link to provider pages without leaving Installer.app and going back to Safari.
Web views are a standard user interface element that offers all the power of web kit in a native class. What you'd do is this: build any extra functionality natively and then have it interact directly with the web view source material, presumably through javascript.
The downside of embedding is that it requires native programming. This is not usually an area of comfort for many web developers. The upside is that once developed and standardized, it could be used for nearly any web-based app.
Hopefully, when AppStore launches and the NDA goes away, we'll see open source embedding skeletons emerge that assist javascript and provide a way to plug in web source and have it run with access to native features.
The other approach I thought about is outsourcing. By this, I mean creating a stand-alone application that serves native data like location information to Mobile Safari based webpages. The way I imagine it is like this. Assuming Apple delivers custom URL schemes like those mentioned here, your Safari page generates a special link like (for example) erica://. When clicked, it launches a local application, which performs the location data gathering.
The passed URL would need to contain enough information to return to control to your web site, i.e. some sort of embedded scheme that links back to the referring page. When the native outsourcing expert finishes gathering the requested data, it opens that URL and appends the data to it.
Both of these approaches seem like they'd be trivial to write and if they don't show up on their own in the weeks after the SDK goes public, drop me a line and maybe we can hack them together live on this blog.
©2009, O'Reilly Media, Inc. (707) 827-7000 / (800) 998-9938 All trademarks and registered trademarks appearing on oreilly.com are the property of their respective owners. |
About O'Reilly
Academic Solutions Authors Contacts Customer Service Jobs Newsletters O'Reilly Labs Press Room Privacy Policy RSS Feeds Terms of Service User Groups Writing for O'Reilly |
Content Archive Business Technology Computer Technology Microsoft Mobile Network Operating System Digital Photography Programming Software Web Web Design |
More O'Reilly Sites
O'Reilly Radar Ignite Tools of Change for Publishing Digital Media Inside iPhone O'Reilly FYI makezine.com craftzine.com hackszine.com perl.com xml.com Partner Sites InsideRIA java.net O'Reilly Insights on Forbes.com |
Erica -
Very interesting. We've be talking about doing the embeddable 'SDK wrapper' option over at Pinch Media - it's somewhere down the list of a million things we'd like to do. An open-source version would be awesome.
A question, since I haven't investigated this personally, and you may have - does Mobile Safari support HTML 5 client-side SQLite storage, and if so, could a webview in an SDK application and the SDK application itself access the same SQLite database? If so, this might be a more elegant way of passing SDK information to the browser.
Another, less orthodox, solution is to do a Safari plugin. I had a little play with this a short time ago - see www.lyonanderson.com. I need to migrate the work to the new SDK and also probably move to a more standard API such as the new gears location API.
@Greg: I'm not a Safari expert by any stretch of the imagination. I know a lot of people are hoping for client-side data storage and SQLite. This isn't an area I'm well versed in.
@Christopher: Safari plug-ins in the Jailbreak world are similar to standard plug-ins on the Mac. I'm not sure how the 2.0 Safari will work and whether Apple will allow Safari plug-in development at all for the iPhone
@Erica I don't think Apple will support them as it effectively creates another platform. I would love to see location exposed in Safari though. I've not had a chance to play with any of the 2.0 betas, but as soon as I do I'll port the plugin. Fingers crossed it will work, it's pretty simple. I'm also hoping that when gears builds for Safari again it can be ported over to iPhone :-)
@Erica I don't think Apple will support them as it effectively creates another platform. I would love to see location exposed in Safari though. I've not had a chance to play with any of the 2.0 betas, but as soon as I do I'll port the plugin. Fingers crossed it will work, it's pretty simple. I'm also hoping that when gears builds for Safari again it can be ported over to iPhone :-)
A developer called Phillip Furlan has developed an native iPhone app that can be called via url from safari and which will return the location data.
I believe the product is called SearchQuest and will be available free of charge as soon as the App Store goes live.
Further details from here:
http://locationweb.org
The other way you mentioned is the way I've gone about it. Basically a native app with a single view that just launches a webkit browser window. This way I can expose my app to the Core Location data if I choose to.
M.