Alocola works with Safari. With Alocola, web developers need not create their own iPhone apps. Users simply browse in Safari the way they normally would; when a site asks for location information Alocola pops up, asks permission to give the location to the site, returns to Safari and passes the location along as part of the URL.
Motivation and Approach
It’s always bugged me that location services aren’t available in Safari.
Applications like Phone Gap deal with this limitation by wrapping websites inside a custom browser that includes location (and other) services. A PhoneGap application is installed like any other standard application. It’s a good solution for developers whose goal is to build an installable application, but not for websites that want to easily and simply add location to their sites.
Instead of wrapping an application in its own browser, Alocola works alongside Safari. Once the Alocola app is installed, it works with any site. The sites needn’t create or ask their users to install any other software. There are no platform, language, framework or other tech-choice limitations.
How It Works/Upcoming Articles
I’ll be writing a pair of follow-up tutorials demonstrating how Alocola works. For now, here’s a quick synopsis:
Alocola registers a protocol handler with the iPhone. Whenever the iPhone encounters a URL beginning with alocola:// it passes the URL to Alocola for processing.
Website authors either ask users to click on alocola:// links or redirect them to alocola:// URLs. These URLs cause Alocola to be launched. Alocola will then gather the location information and then send the user back to a URL inside the originating site. The return-trip URL is embedded/included in the alocola:// URL.
Using Alocola With A Website
Because Alocola has to be opened every time a site asks for its users’ locations, Alocola is best for sites that need an occasional location coordinate, but not for those that generate breadcrumbs or tracks. For example, a site that tracks deliveries could have the couriers check in when they make a delivery, but monitoring them en-route wouldn’t be practical.
Also, a roundtrip from Safari to Alocola and back to Safari results in two open browsers windows, one for the page that launched Alocola, and a second for the page that Alocola returned the user to. I’d hoped to avoid this by including HTTP POST data when launching the return URL, giving the appearance of starting and returning to the same URL. Unfortunately, you can’t include POST data. A future version will have an optional workaround where Alocola issue an HTTP POST itself and then return the user to the same apparent URL they started from. This will introduce some complexity, including more integration work for the website.
Alocolola’s source is available under GPL2.