tralfamadore.com

Turf Bombing on your iPhone

noreply@blogger.com (Wesley) — Tue, 23 Dec 2008 01:49:00 +0000

The creator of Turf Bombing emailed to let me know this creative web application now supports iPhones with Locatable installed. This is a great concept that blends real locations with a virtual game that can be played on both laptops and mobiles. (And you'll probably have an advantage playing on an iPhone with GPS, as WiFi-based locations are often far less accurate.)

Here's a brief description of the concept:

Turf Bombing is a location-based turf battle game which rewards and encourages traveling and learning about different neighborhoods.

Gangs are assigned by the zip code of your home address. The goal of each gang is to gain as much territory as possible.

Territories are acquired as players plant time bombs at different locations in physical space. If the bomb is not diffused by a local gang member in time, the bomb will explode and the territory will be turned over to the gang that planted the bomb.

FireEagle + Relocatable

noreply@blogger.com (Wesley) — Tue, 23 Dec 2008 01:32:00 +0000

Last month I was fortunate enough to see a presentation at Google headquarters UK from Yahoo!'s FireEagle team, part of the inaugural location-based developer meetup session. (That's right, not only did Google let Yahoo!s in the building, they even gave them food and drink -- of course, we all had to sign an NDA to get into the meeting room, presumably so we wouldn't wander about jotting down random scrawlings on people's whiteboards). As you might know, FireEagle is a permission-based location storage service. It's sort of like a depot where you can save your most recent location, and allow other (FireEagle-enabled) web sites and services to access it. They are apparently close to launching a Facebook application, for example, that lets you locate anyone in your friends list who has a FireEagle account.

There are several FireEagle-related apps in the AppStore but they also suffer from the Apple restriction of not being able to run in the background, a condition that can only be avoided on a jailbroken phone. This is exactly the scenario that got me to write the Relocatable application in the first place, and sadly, it's not one that is likely to be resolved soon.

For those of you who are interested in always-on updates to FireEagle via your iPhone, Robbie over at BaseX.be has a recipe for you. He goes through the full process, including jailbreaking, installing Locatable/Relocatable, and setting up some python scripts to send your location data to FireEagle automatically. Good stuff!

Speaking of FireEagle, I'd love to see a web-only solution also, using the W3C API and Locatable. This would be more of an on-demand app, e.g. a bookmark for iPhone Safari that when loaded would save your current location. Any takers? Let me know and I'll put a link up here.

Schema migration with Safari's Javascript Database

noreply@blogger.com (Wesley) — Mon, 22 Sep 2008 21:37:00 +0000

Locatable relies on Safari's SQLite-based Javascript database implementation for its client-side data storage. As anyone who has worked with Gears or similar technologies can attest, this is pretty slick stuff. The only thing that's been hard for me to get used to is the callback/closure paradigm for dealing with asynchronous query results (really? they couldn't make a synchronous method for selects?) Coming from a more linear JDBC (and before that, though it pains me to say it, ODBC... and before that, Oracle Pro*C... the list goes on...) aesthetic, I have to say the code ends up looking a bit pasta-ish. But it works.

What Safari has not yet provided, though, is any semantics around schema migration. It's easy to create and drop tables from code, and to add (but not delete) columns from existing tables (subject to the usual constraint checking). The openDatabase command lets you specify a version number, but it's not particularly useful; its only impact is to throw an exception if you try to open a database while specifying a different version than then one it was created with.

Which means it's down to application code to handle upgrades that require schema modifications. One way to do this would be to have a table with a row that specifically tracks the version number or code. I'm guessing this is how Gearshift works for Google Gears. When starting up, you could query this; if it doesn't exist, you're running for the first time, otherwise you could apply the right schema mods.

But that's too much work (for someone as lazy as me). Fortunately, JSDB does include transactions, and of course a transaction will bomb out if it gets an error. So if all you want to do is make sure you get the user upgraded to the latest schema, an easier way looks something like this:
in your initialization function:

var db = openDatabase('mydb', '1.0', 'mydb', 65536);

db.transaction(function (transaction) {
    transaction.executeSql(
      "CREATE TABLE version001 (id integer primary key)",
      []);
    // Do table creation required for version 001
   transaction.executeSql("CREATE TABLE mytable ...", []);
});

db.transaction(function (transaction) {
    transaction.executeSql(
      "CREATE TABLE version002 (id integer primary key)",
      []);
    // Do schema migration to version 002
    transaction.executeSql("ALTER TABLE mytable ..."), []);
});

And so on.

When this runs, the create table statements for dummy tables version001 and version002 act like assertions: the transaction fails (and the rest of the SQL statements within it are skipped) if the table already exists. (It's not strictly necessary to have the version001 table in this example, as the create table line for "mytable" has the same effect; it's just there for clarity). If a user has a version001 table, the code skips to the version002 piece. You can put inserts, updates, and so on in there, none of which will have any effect unless it's the first run through (be careful of other side effects, though; Javascript variables have no transaction boundaries).

Doubtless there are other (and perhaps better) ways of doing this; this one certainly has the time drawback of testing against each version dummy table, which could get slow if you have a lot of versions to check through. If you only have a few, it's probably just as fast as (and a lot less complicated than) asynchronously handling a callback that tells you what version number you're at, and going from there (in which case you'd need all the same code, just broken into a bunch of different functions).

(And yes, this does mean that altitude, horizontal accuracy and vertical accuracy will be part of the schema in the next release of Locatable!)

Locatable roadmap and feature planning

noreply@blogger.com (Wesley) — Mon, 01 Sep 2008 17:41:00 +0000

I thought I'd give an update on where I'm going with Locatable and I'd love to hear feedback or suggestions for new functionality.

I've just tested a better technique for saving data to the client-side database from the Locatable application which means that the app itself should not need any network connectivity. This is good news as there's a risk of settings becoming unsynchronized between the app and the database the way it's working right now (e.g. if the connection fails). This means rewriting all the preferences-saving and preferences-loading code and won't have any visible effect on the UI.

Preferences anyway are about to get more complex. Now that Locatable is tracking per-site preferences (so you can choose to only be prompted once or twice per site to share location), there needs to be a UI to see what sites are currently in the list and manage their individual settings. I'm thinking of it a lot like the cookie manager in Firefox — you should be able to blacklist and whitelist individual sites that you visit, as well as alter their settings individually. So that's the task for Locatable 0.4.

The other item on the TODO list requires a schema upgrade, which is why I've been procrastinating on it. It would be good to store the horizontal accuracy of the reading so this can be shared (via the W3C API and redirector). It would be nice to have altitude and vertical accuracy as well, though I'm not sure if these even work (certainly not on an iPod Touch!).

Once those are in there, the plan is to submit to the AppStore. If accepted, the only difference between the jailbroken version and the AppStore one will be the inclusion of Relocatable, which of course won't work. (I won't be discontinuing development on it, but it may become its own package in Cydia.)

In the meantime I'm open to suggestions on other functionality that should be included. Primarily what I've been hearing about is people using Relocatable to do their own lojack-type apps. I'd really like to get some feedback on using Locatable on your web sites to integrate positioning data, do maps mash-ups, and so on. Private feedback is fine, public is even better (and I'll be happy to put links on the Featured Sites page).

The plunge

noreply@blogger.com (Wesley) — Fri, 29 Aug 2008 22:54:00 +0000

... I've taken it. Over the next 18 months, I will pay O2 UK £664 (plus the £159 I laid down at the Apple Store today) for the privilege of owning an iPhone 3G. When I look at it that way it seems, um, a lot, but as I can remember the time when I was paying £15/mo. for a bundle of 5 megabytes of data access (that was 2002, on Orange, if memory serves), I guess I can see the bright side of an unlimited data plan.

As you might expect, the first step before syncing music and photos was Pwnage. Can't wait to try some of the iPhone-specific apps out there, particularly Saurik's new video recorder. Oh, and to see how Locatable works in the field using actual GPS.

One annoyance: I couldn't get PwnageTool (the latest, 2.0.3.1) to add in a custom boot image. I wanted to get the classic multicolor Apple image on there, but every time I went to add it, the tool crashed. Oh well — next upgrade.

The W3C Geolocation API on iPhone with Locatable

noreply@blogger.com (Wesley) — Thu, 28 Aug 2008 00:43:00 +0000

I've ported the W3C's draft Geolocation API so it can be used from an iPhone with Locatable installed (my Javascript skills are far from elite, but with enough prodding and old-school alert() debugging, I got there). This means that in addition to the redirect API (which is nice for embedding static links to pages that can take lat/long coordinates), you can now get at location information on demand via Javascript, through what is likely to become the standard API in future browsers.

To use it, just include this in your HEAD:

<script type="text/javascript"
src="http://lbs.tralfamadore.com/w3c-api.js">
</script>

You can download and install the script locally if you like (but please check back for new versions from time to time).

Then, to use it, just use the standard W3C-prescribed approach via a global object called Locatable, e.g.

// Callback handler
function gotLocation(position) {
alert('You are at (' + position.latitude + ','
 + position.longitude + ').');
}

// Use this anywhere you like
Locatable.getCurrentPosition(gotLocation);

The only addition to the W3C API is an isEnabled() method. This will attempt to figure out if the API will work on the current browser. Right now this merely checks if someone is on an iPhoneOS device, but might be more sophisticated in the future.

There's a test page up at http://www.tralfamadore.com/test-w3c.html that demonstrates this functionality.

Some implementation notes:

The same logic applies when sharing location as with the redirector. Depending on user preferences, an alert will ask them to confirm if they want to share their location. If they decline, you'll get an error callback if you provide the second argument to getCurrentPosition.
If the location needs to be refreshed, the app will launch, update the reading, and then return to Safari. This can take some time (in Locatable 0.3, up to 20 seconds, depending on the user accuracy setting). On jailbroken phones with default Locatable settings this is unlikely to occur as the daemon will be updating location in the background, but an AppStore version will not have this advantage, so be mindful of this.
W3C PositionOptions (the accuracy hint) does nothing at the moment.
watchPosition() is "implemented" (that is, the function exists), but you'll only ever get one reading, so it's not entirely useful.
The accuracy reading in the position object is currently the user-set minimum accuracy level (a round number like 10, 100, or 1000 meters), not the device-reported accuracy of the reading itself. This is likely to change in future versions.
Altitude and velocity are not implemented yet and yield null values.
w3c-api.js will attempt to detect if you're running an iPhone or iPod Touch and not install itself otherwise. It also won't overwrite navigator.geolocation if it's already implemented (non-null).
It probably goes without saying, but you should include the w3c-api.js script on every page you want to use it in.

I'd consider this a beta version — I've done some basic testing but haven't tried too many use cases. Let me know how it works for you in the comments.

Update (31 Aug 08): Upon some reflection, I decided it's best not to try to automatically install as the navigator.geolocation global, so the script has been updated to use a global called Locatable (capital L) instead. You're free to assign it to navigator yourself (i.e. navigator.geolocation = Locatable). Also added the isEnabled() method.

Changelog for Locatable 0.3

noreply@blogger.com (Wesley) — Wed, 27 Aug 2008 00:06:00 +0000

I'm just about to submit the new version of Locatable. Here are the changes:

Locatable

More accurate GPS readings. When retrieving a location, wait until the accuracy is within the specified range, or 20 seconds, whichever comes first (i.e. if you set it to "Best", it'll spend the full 20 seconds).
New option "Expire after" specifies how stale of a location is allowed to be sent to web sites. Default is 10 minutes. If you set this to "each request", Locatable will pop up every time a web site wants to read your location.
New option "Ask permission" defines if and how many times you'll be prompted to allow a site to see your location. Default is to always ask. Set this to "Twice per site" to mimic the behaviour of iPhone native apps.

Relocatable

Relocatable is now a daemon process. You can control how often and how fast it runs by editing /System/Library/LaunchDaemons/com.tralfamadore.locatable.plist.
You can also run it from the command line (it now lives in /usr/libexec/relocatable), which gives you the following options:


~ root# /usr/libexec/relocatable/Relocatable -h
Usage: Relocatable [-v] [-t SECONDS] [-d SECONDS] [-e CMD]
-d SECONDS      run as a daemon, delay specified seconds between fixes
-e CMD          execute given program (with args) after each location fix,
                 can include @lat@, @long@, and @hacc@ tokens
-t SECONDS      spend specified seconds waiting for a fix, default 30
-v              turn on verbose logging

Let me know if you encounter any issues.

Update (30 Aug 08): A few people had questions about getting the command execution piece to work. Here's an example — the important bit is to wrap the whole command in single quotes, otherwise the shell gets confused.

First, if Relocatable is already running as a daemon (it will be by default), you need to stop it:

~ root# launchctl unload /System/Library/LaunchDaemons/com.tralfamadore.locatable.plist

Once that's done, you can run Relocatable as a one-off from the command line:

~ root# /usr/libexec/relocatable/Relocatable -v \
> -e 'curl "http://my.site.com/savepos.pl?lat=@lat@&long=@long@&acc=@hacc@"'
Opened LBS database for read...
Started updates...
newLocation: <+51.xxxxxxxxx, -0.xxxxxxxx> +/- 93.21m @ 2008-08-30 13:17:44 +0100
newLocation: <+51.xxxxxxxxx, -0.xxxxxxxx> +/- 93.21m @ 2008-08-30 13:18:29 +0100
Stopped updates
Opened LBS database for write...
* About to connect() to my.site.com port 80 (#0)
*   Trying xxx.xxx.xxx.xxx... connected
* Connected to my.site.com (xxx.xxx.xxx.xxx) port 80 (#0)
> GET /savepos.pl?lat=51.xxxxxxxxxx&lng=-0.xxxxxxxxxxxx&acc=93.21 HTTP/1.1
> User-Agent: curl/7.17.1 (arm-apple-darwin9) libcurl/7.17.1 OpenSSL/0.9.8g zlib/1.2.3

Note the use of the single quotes (to bracket the command passed to Relocatable) and double quotes (to bracket the URL, so it can contain characters that would otherwise confuse the shell, like the ampersand).

The same rules regarding quoting apply to editing the daemon plist. Once you're happy with your settings and have edited the plist to your satisfaction, remember to start it back up:

~ root# launchctl load /System/Library/LaunchDaemons/com.tralfamadore.locatable.plist

Xsstc: Cross-site scripting through CSS

noreply@blogger.com (Wesley) — Tue, 26 Aug 2008 03:19:00 +0000

I've been doing a lot of reading on cross-domain scripting approaches. Generally speaking, the browser is sandboxed by the same-origin policy, and mashups that want to incorporate data from external sites, even if those sites are cooperating, need to provide server-side proxies. There are a couple of popular workarounds: (1) using the hash (#) portion of the URL, which can be read between frames, and (2) cross-domain JSON, or in other words, directly importing live scripts from a third party site into your own. Other more fanciful techniques include using the Flash plugin; obviously this fails if you try to run the code on any device without Flash installed, regardless of its Javascript capabilities (the iPhone comes to mind).

Ideally, a client script just wants to directly invoke a server-side method and get a response back. Due to popular demand, there's work underway in the standards bodies to make this happen, but it will be a long while before it reaches ubiquity.

I started to wonder about other pieces of data in the browser that might enable the basic use case, and after some long hours of experimentation, I finally found a way in: externally loaded cascading style sheets (CSS).

It turns out CSS leaks data in a very subtle way. Properties set by an external stylesheet (that is, one that is loaded using a LINK REL="STYLESHEET" tag) are used to style the elements of the host page, and at runtime the page can introspect itself to see what styles have been applied. Most of these tend to be strictly prescribed data, such as background colours for block elements, or some multiple choice items, like left/center/right alignment for text. While you could conceivably come up with a binary (or ternary) system based on that, it would be a pretty nasty job to try to make those into a general-purpose data channel. Fortunately, there are a few places where CSS lets you specify essentially free-text attributes: image URLs.

n.b.: I did a lot of searching on the topic but it was only after I got this technique working that I found the proposal posted by Gideon Lee on the OpenAjax mailing list, advocating much the same approach. I'm not sure if that work is still in progress as the last message on the list dates from October '07, but Gideon deserves credit for coming up with the basic idea.

I chose to work with the background-image attribute, and verified that a location hash for an image URL set in the CSS, though meaningless to the browser, is still visible by introspection via the getComputedStyle() method (currentStyle attributes in IE). There's some complexity in reliably reading this value, and in dynamically loading stylesheets, but the long and short of it is that on top of this system I've created a cross-browser Javascript library for cross-site requests.

First, check out the test page I've set up. You might want to view source, and also check out the two CSS "response documents" it references. Then read on for how to do it yourself.

The Client

Using the library is straightforward. You can get the current version at http://www.tralfamadore.com/xsstc.js, or a minified version that's a mere 777 bytes at http://www.tralfamadore.com/xsstcx.js. Stick it on your server somewhere or feel free to link to the copy here directly.

On your page, you need the following:

A SCRIPT tag in the header referencing xsstc.js (or xsstcx.js)
An empty DIV tag in the body with id="Xsstc". No other attributes required.
Javascript that calls Xsstc.exec(functionURL, callback). This method loads the specified URL and expects it to be formatted as described below (The Server). Once it has finished loading, it calls the specified callback function, which takes one argument, the string containing the parsed response.

The simplest HTML page looks something like this (using the HelloWorld example from the test page):


<html>
<head>
<title>Xsstc Sample</title>
<script type="text/javascript" src="xsstcx.js"></script>
<script type="text/javascript">
function showResponse(retval) {
alert('Return value: ' + retval);
}
</script>
</head>
<body>
<form>
<input type="button" value="Test Me"
onClick="Xsstc.exec('http://lbs.tralfamadore.com/test.css', showResponse)" />
</form>
<div id="Xsstc"/>
</body>
</html>

The key pieces are bolded above. In this example, http://lbs.tralfamadore.com/test.css serves as the server-side endpoint. Now let's look at...

The Server

The server's job is straightforward. It receives a normal HTTP GET request, that might have various arguments (these can be encoded in the usual way, via query string parameters, pathinfo, or whatever you like; Xsstc doesn't prescribe the notation), and must respond with a valid CSS stylesheet document.

The trick is in embedding the method response in the CSS background-image value. I've found that "about:blank" (which causes the browser to show a blank screen) is a good placeholder value for a background image that the response can then be appended to after the hash (#) character. If you use a real image URL, it will most likely get loaded by the browser, which isn't really what we want. The response proper needs to be URL-encoded, as it's, well, part of a URL.

In order for the client side to read the value that gets set by the stylesheet, it needs to attach to an actual element in the HTML document. That's why we added the do-nothing DIV called Xsstc. The CSS simply targets this DIV by its ID, and sets its background image. So a response document that wanted to embed "Hello World" would look like this:

#Xsstc {
 background-image: url('about:blank#Hello%20World');
}

Because this response format is so simple, it's easy to create in just about any server-side programming language. And because of the data seepage inherent in stylesheets, the server can be any site on the Internet that has chosen to expose its services in this way — you're not limited by the same-domain policy the browser applies to other external requests.

Xsstc and JSON

There's a natural fit between Xsstc and JSON, as one of the examples on the test page alludes to. I've taken a sample JSON response straight off of www.json.org/example.html, URLencoded it, and slapped it into the Xsstc response format. This is not to say that Xsstc is dependent on JSON in any way: the Xsstc.exec() method generates a callback that returns whatever string is in the response, however it's formatted. But JSON is a nice compact way of representing datasets that can be easily worked with in Javascript, so a JSON library on top of the Xsstc communications channel seems like a natural fit.

Compatibility

This is the first release and while I'm sure there will be something broken, I've tested the examples (minimal though they are) on recent versions of Mozilla, Safari and Internet Explorer (IE is of course the worst to work with, but with a little bit of switching logic it seems to be doing well). It should also work on modern versions of Opera, and hopefully anything else that's W3C compliant.

Limitations

There are a few limitations that are worth being aware of. The first is that because the response string needs to be embedded in a URL, some browsers (you know which) are likely to cap the possible length of a response. While there are ways to work around this (for example, you could split one response into several consecutive method calls), it might mean that Xsstc is overly painful for implementing methods that have a bulky response.

At the moment the library is also single-threaded, though this can be remedied in time. This means that only one Xsstc.exec() method can be in progress at a given time, or you're likely to have untoward side effects. In a similar vein, there's virtually no error-handling going on in the current version, and the script will happily wait until the end of time for a response from a server that might be down.

Finally, because there's no onLoad event for stylesheet loading, the script is set up to poll for the availability of the response. In my tests this hasn't caused significant problems (there's a 50ms pause between each check), but sites that have a lot of other activities going on may want to look at how to best tune the performance of the timers.

Security

My understanding is that you cannot specify javascript: URLs for CSS background-image attributes and expect them to execute, which should mitigate any concerns of remote scripts stealing data. In the OpenAjax discussion, it was mentioned that on FF2 you can apparently execute javascript in this mode but it runs in a very sandboxed manner, without access to the document object. Taking a broader view, if there is a vulnerability here, it exists already with the ability to load foreign stylesheets, and will not be something new exposed by Xsstc.

Because both the client and server systems must cooperate on the request/response cycle, and the Xsstc DIV element is the only item singled out for data transfer, there's very little likelihood of "rogue" code. In addition, Xsstc doesn't rely on script loading and is therefore naturally immune to the trust issues that plague cross-domain implementations of JSON.

License

Xsstc (pronounced, if you'll indulge me, "Ecstasy") is licensed BSD-style. The relevant text is in the xsstc.js file. I'm happy to incorporate worthwhile changes and additions — just reply in the comments or email me (my address is wes at this blog's domain).

As always, happy hacking!

Locatable: Some stats

noreply@blogger.com (Wesley) — Sat, 23 Aug 2008 23:07:00 +0000

Locatable has been on Cydia for about a week now, and thanks to BigBoss I can see that there have been over 5,000 downloads (some of these are people upgrading from 0.1 to 0.2, of course).

I've also done some analysis of the visitors to the Featured Sites page. First of all, I'm impressed by how far around the globe the jailbroken iPhone has traveled. Within just the last 12 hours there have been visitors from over 50 countries -- here are the top ones:

1. U.S. (18%)
2. France (7%)
3. Mexico (7%)
4. Brazil (6%)
5. U.K. (6%)
6. Spain (4%)
7. Canada (4%)
8. Slovakia (3%)
9. Italy (3%)
10. Norway (3%)

Traffic is overwhelmingly (95%) coming from iPhones as opposed to iPods Touch, as you might expect for an app that is most useful with GPS when you're out and about; on the other hand, so far usage is still fairly evenly split between WiFi and mobile networks.

In other news: I've got a heavily reworked version of Relocatable just about ready to go that makes it very easy to do the location tracking hack posted previously. It also does a far better job of getting accurate GPS readings, though it takes a little longer. I'm working on incorporating the same technique into Locatable and I'd like to start adding some more management preferences, such as the ability to have trusted sites that you aren't continually prompted for (much the same as the way the iPhone works for applications that request to read your location: after a couple of checks, it assumes you're fine with it). If you have other feature ideas please comment!

n.b. If you have a working iphone-gcc toolchain installed, the Makefiles are set up so you can build your own copies of Locatable and Relocatable from source now, and the changes mentioned above for Relocatable are checked in.

iPhone MIDP status

noreply@blogger.com (Wesley) — Sat, 23 Aug 2008 09:53:00 +0000

I haven't had much time to hack on the MIDP project lately but did put everything I've got in the svn repository now, including the files needed to put a MIDletRunner app on SpringBoard. The README file that's included should be self-explanatory if you'd like to get a little GUI Java running on your own (jailbroken) device, and it can execute the included HelloWorldMIDlet. I should note that this is pretty much the only MIDlet that is expected to work at this stage. See previous posts for svn info.

Location tracking using Relocatable

noreply@blogger.com (Wesley) — Thu, 21 Aug 2008 16:52:00 +0000

"Relocatable" is the location-gathering daemon add-on to "Locatable" (currently they're bundled together for distribution purposes on Cydia; an AppStore version will only contain Locatable as it's not permissible to install daemon processes through the official program).

Relocatable is set up to run at 10-minute intervals and gather location data in the background. This means location data is typically available to the browser on a jailbroken phone without having to launch the Locatable app proper.

Several of you have asked if there's a way to do a scheduled publish of your location to a destination server of your choice based on the data that Relocatable collects. The answer is a definite yes, and Mike Carambat emailed me the following solution:

Requirements
1. Jailbroken iPhone
2. Install "Locatable" from Cydia
3. Make sure you have "SQLLite" from Cydia
4. Make sure you have "cURL" from Cydia
5. A server based facility to store the data captured from your phone

Concept
Basically, "Locatable" is a springboard app which uses Core Location to capture GPS coordinates. The cool thing about it, is that it stores them in a SQLite database which is then easily accessible. You query this database via the sqlite3 command and pipe its results to cURL which forwards the data to your server.

Instructions
1. Create a shell script called "pushgps" on your iphone which you will invoke on a periodic basis. Put it in the /usr/bin/ on your iphone.

This shell script looks like this:

---------- start ----------

#! /bin/sh

curl -d POS="`sqlite3 /var/mobile/Library/WebKit/Databases/http_lbs.tralfamadore.com_0/*.db 'select latitude, longitude from location where tag = "Current"'`" http://www.yourserverhere.com/path_to_gps_recorder

----------- end -----------

(replace the "yourserverhere" and "path_to_gps_recorder" with YOUR server and recording software. (see below for ideas on doing this)

Don't forget to: chmod 755 pushgps

2. Next, create a plist file

/System/Library/LaunchDaemons/com.whatever.pushgps.plist

which contains:

---------- start ----------

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>com.whatever.pushgps</string>
<key>ProgramArguments</key>
<array>
<string>/usr/bin/pushgps</string>
</array>
<key>StartInterval</key>
<integer>600</integer>
</dict>
</plist>

----------- end -----------

(replace the "whatever"s with your name, company name, domain, or whatever. This is just an identifier. the 600 refers to every 10 minutes. change if needed. Locatable's interval defaults to 10 minutes, but can be changed as well in its plist file (same directory))

3. Create software to record the GPS data

You'll need to post the coordinate data to *somewhere* online. No, I'm not gonna do it for you. Get your own server ;) Maybe the folks at www.instamapper.com would be open at some point to do this for us.

I wrote a simple perl script called gps.pl which runs on my server which simply records and time/date stamps the data. Something like this:

---------- start ----------

#!/usr/bin/perl # GPS Recorder $maxhistory=1000; # Total number of locations to store if ($ENV{"REQUEST_METHOD"} eq 'GET') {$buffer=$ENV{"QUERY_STRING"};} else {read (STDIN, $buffer, $ENV{"CONTENT_LENGTH"});} @vars=split(/&/,$buffer); foreach $var (@vars) { ($name, $value)=split (/=/,$var); $name =~ tr/+/ /; $name =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg; $value =~ tr/+/ /; $value =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg; chomp($name); chomp($value); $stuff{$name}=$value; } if (exists ($stuff{'POS'})) { ($lat,$long)=split(/\|/,$stuff{'POS'}); chomp($lat); chomp($long); &GetDateTime; open (STUFF, "gpslocation.txt"); @lines=; close (STUFF); $numlines=@lines; $sp=0; if (($numlines-$maxhistory)>-1) { $sp=$numlines-$maxhistory; } open (STUFF, ">gpslocation.txt"); for ($i=$sp; $i<$numlines; $i++) { chomp($lines[$i]);
print STUFF "$lines[$i]\n";
} print STUFF "$date\t$time\t$lat\t$long\n"; close (STUFF); print "Content-type: text/plain\n\n"; print "Latitude: $lat\n"; print "Longitude: $long\n"; exit(0); } print "Content-type: text/plain\n\n"; print "ERROR"; exit(0); sub GetDateTime { ($second, $minute, $hour, $dayofmonth, $month, $year, $weekday, $dayofyear, $isdst) = localtime(time); $year=($year+1900); $month++; $date=sprintf("%02D",$month)."/".sprintf("%02D",$dayofmonth)."/".sprintf("%04D",$year); $time=sprintf("%02D",$hour).":".sprintf("%02D",$minute).":".sprintf("%02D",$second); }

----------- end -----------

Thanks Mike!

Update (1 Sep 08): While this method still works (and it provides a good example of a server-side script to handle the data), as of version 0.3 Relocatable allows you to specify a command to execute each time a location fix is acquired, so there's no need to use the pushgps part. See this post for details.

Locatable 0.2 + source release

noreply@blogger.com (Wesley) — Tue, 19 Aug 2008 19:48:00 +0000

Locatable 0.2 should be out on Cydia soon. Release early, release often, as they say. It's a minor release that fixes an issue and adds a feature:

Locatable and its daemon process (Relocatable) would get stuck if the device couldn't get a location fix. Now it dies gracefully (though this can take a few seconds).
New option in preferences panel to specify how accurate of a location reading to get.

I'll also be adding some more options to the redirector, including the ability to test for a Locatable-enabled device without needing to prompt the user to share location. Stay tuned and your feedback is welcome.

Also, in the practicing-what-you-preach department, the Locatable and Relocatable applications are available in source form under the GPL in the svn.tralfamadore.com repository. To check them out using Subversion, try svn co http://svn.tralfamadore.com/repos/iphone/locatable (or relocatable). I'm not exactly proud yet of my Objective-C skills, so your critiques are probably warranted and indeed you're welcome to contribute!

Howto: Developing with the Locatable redirect service

noreply@blogger.com (Wesley) — Mon, 18 Aug 2008 16:28:00 +0000

For the first release of Locatable I've stuck to a very basic HTTP (REST) API. The idea is that you have a page that can take latitude/longitude coordinates in its URL. This might be an existing page, or it might be an iPhone-specific entry page that sets up some other variables or session cookies or whatever you might want to do.

Template URLs

The basic URL to perform a redirect to your location-enabled page is as follows:

http://lbs.tralfamadore.com/r?u={myURL}

For this to work, {myURL} needs to be a full absolute URL (including http://) to your page.

Locatable looks for some special sequences in the URL you provide.

@lat@ will get replaced with the user's latitude, as a floating point number
@long@ will get replaced with the user's longitude, as a floating point number

If the user hasn't installed Locatable, they choose not to send their location to your site, or the mobile device can't read an accurate location, the template parameters will be replaced by the empty string (that is, they will be stripped out of the URL before the redirect occurs). You should code your page for this condition. (Note: I'm looking at adding a parameter so you can check whether the service is enabled to make it easier to detect when you'll have a valid location, but that's not there yet; see below for a way to set a default value.)

To take an example, the Geocaching web site expects a URL that looks like this:

http://www.geocaching.com/seek/nearest.aspx?origin_lat=39.549167&origin_long=-94.329722&dist=100

To make this into a template URL for Locatable, we simply replace the numbers with the macros described above:

http://www.geocaching.com/seek/nearest.aspx?origin_lat=@lat@&origin_long=@long@&dist=100

Encoding the URL

Because we're going to use it as a querystring parameter to the redirector, make sure to properly encode your templated URL. Here's how to do it in various languages:

PHP: urlencode($myURL)
Java: java.net.URLEncoder.encode(myURL, "UTF-8")
Javascript: encodeURIComponent(myURL)

You get the basic idea. There's also a little encoder you can cut and paste from on this page.

After doing that step on our example URL, it looks like this:

http%3A%2F%2Fwww.geocaching.com%2Fseek%2Fnearest.aspx%3Forigin_lat%3D%40lat%40%26origin_long%3D%40long%40%26dist%3D100

Then we just need to add this to the redirector URL, and we're off and running:

http://lbs.tralfamadore.com/r?u=http%3A%2F%2Fwww.geocaching.com%2Fseek%2Fnearest.aspx%3Forigin_lat%3D%40lat%40%26origin_long%3D%40long%40%26dist%3D100

Take that URL, put it in a HTML href, and you're ready to go!

Defaulting the Location

If you'd rather have some value for latitude and longitude rather than none, you can use the following syntax:

@lat:defaultValue@ gets replaced by the latitude, or defaultValue if none is available
@long:defaultValue@ gets replaced by the longitude, or defaultValue if none is available

For example, if we were to start with the same Geocaching URL, but want to default to Charing Cross in London (latitude 51.509, longitude -0.125), we'd use the following template URL:

http://www.geocaching.com/seek/nearest.aspx?origin_lat=@lat:51.509@&origin_long=@long:-0.125@&dist=100

Happy (geo)hacking!

Geohacking with Locatable

noreply@blogger.com (Wesley) — Mon, 18 Aug 2008 08:36:00 +0000

Locatable has had well over a thousand downloads in the first 12 hours, so I've just been updating the featured sites to give everyone something to play with. I haven't yet heard of any "made for iPhone" sites that can take advantage of the latitude/longitude sharing feature of lbs.tralfamadore.com, so for now the links you'll find there are publicly available web sites and services that take lat/long coordinates.

I used some of the more common online mapping services to test during development, but now that I have a little more time to browse around, I'm finding a lot of interesting things that can be done already:

Geocaching. Use your iPhone to participate in local treasure hunts.
GeoNames. Find and identify nearby landmarks.
Panoramio. Look at photos that have been taken near your location.

Here are some things I'd love to see but haven't tracked down yet (even if they don't yet exist as lat/long-enabled URLs, the mashup would be easy to do): movie listings, traffic reports, friend finder, turn-by-turn spoken driving directions, emergency services finder, shop finder (Apple store, anyone?), and so on.

Maybe I'll hunt around a little later. In the meantime, let me know if you have any links to post.

Locatable 0.1

noreply@blogger.com (Wesley) — Sun, 17 Aug 2008 21:46:00 +0000

Locatable 0.1 is out on Cydia! If you have a jailbroken 2.0 iPhone, you'll find it in the Utilities section of Cydia. For more info, check lbs.tralfamadore.com.

I wanted to take a minute to give a quick thank you to some of the people and resources that have helped me get this up and running.

Jay Freeman, a.k.a. saurik, who has built and written more and better software for iPhone development than possibly the collective staff at Apple.
BigBoss, for hosting the package gratis -- many thanks and highly recommended!
The community at iPhoneDevSDK who post tons of useful examples and answers to coding questions.
Some useful blog entries that helped get me past a few tricky issues: Handling Date With Google Gears (Cafe Babe), iPhone App Development for Web Hackers (Dominiek.com)

Thanks!

Sneak peek

noreply@blogger.com (Wesley) — Fri, 15 Aug 2008 04:42:00 +0000

I'm close to a beta release for Locatable, and I'm excited enough about it that I wanted to give a quick preview, from a tech-centric point of view.

Locatable is an application and geolocation federation service that let you share your location (GPS coordinates, or any decent facsimile thereof) from your iPhone or iPod Touch to any web site, via the built-in Safari browser. It takes advantage of the new client-side storage capabilities of Safari to allow some very nice anonymity and privacy features -- notably, the user's location is never stored on the server side, with the service at lbs.tralfamadore.com acting as a gateway to storage on the device.

There's a lot to say about this and its relationship to similar services such as MyLoki (Skyhook) and FireEagle (Yahoo!). Both of those could be integrated, as can just about any existing location-based service.

Anyway, check out the concept and check back for more updates soon.

Reading location

noreply@blogger.com (Wesley) — Wed, 13 Aug 2008 22:26:00 +0000

The API to read location data from an application is nice and easy.

However, to help the user know what's going on, the iPhone will prompt for the user to allow an application to see location data, at least the first couple of times it runs. Interestingly enough, this also happens if an otherwise non-GUI application attempts to read the location.

The application name it puts in quotes is taken from the "CFBundleIdentifier" string in the local directory's Info.plist file. The program will basically freeze until the alert is dismissed by the user (if the user hits "Don't Allow", the program receives an error on the callback).

It seems that most location-savvy apps will only cause the OS to prompt the user on the first two consecutive runs. For a while I thought this wasn't happening for my jailbroken app, but the trick was to ensure that you tell the location manager to stop sending updates.

The apps that locationd (the system process that exposes location services) has seen seem to be stored in /private/var/mobile/Library/Preferences/com.apple.locationd.plist, though this doesn't seem to store the information about when they can be run without prompting the user.

Jailbroken iPhone logging basics

noreply@blogger.com (Wesley) — Wed, 13 Aug 2008 21:59:00 +0000

Graphical apps on iphoneos 2.0 can't be started from the command line, which makes using stdout and stderr for logging a bit difficult. Or, more to the point, useless. You also can't see any messages that might occur if any app, GUI or non-, crashes.

There are a couple of tips being passed around to address this. This one I've copied from the technique used to run Java apps. To get stdout logging, simply rename your executable and replace it with a wrapper shell script whose output you can pipe to a log file of your choosing, like this:

#!/bin/bash
exec "$(dirname "$0")"/MyRenamedExecutable &> /tmp/myapp.log

That gives you printf() (or System.out.println() if you're so inclined). To get error messages, you can set up syslogd to run: straightforward instructions here.

Note that after configuring syslogd, you'll need to reboot. You could do this the hard way, by holding down the power button for a few seconds and then sliding the touchscreen prompt. Or if you're impatient like me, you could just type reboot from the command line.

Now to figure out why none of my apps are working...

I'm losing my memory

noreply@blogger.com (Wesley) — Tue, 12 Aug 2008 22:10:00 +0000

A brief aside to the folks who invented PC2 5300 DDR2 RAM DIMMs, and then decided that they'd apply that same exact name to both a desktop and a laptop configuration, which are completely different form factors: Your ways are indeed mysterious, and no doubt you take pleasure in confusing mere mortals like myself, yet you shall be punished for your cruelty when the wheel of fortune turns.

In other words, I hope I can get a refund or an exchange. Sigh.

iphone-java: Get subverted

noreply@blogger.com (Wesley) — Sun, 10 Aug 2008 21:52:00 +0000

To catch you up with our story: Between his work on Cydia, Winterboard, and getting a full gcc toolchain to run on iphoneos, the indefatigable Saurik has also created jocstrap, the amusingly named Java to Objective-C bootstrapping library. Jocstrap enables Java code running on jailbroken iPhones to access most (and eventually all) of the iPhone SDK APIs, meaning Java applications can use the native look and feel widgets and participate in the windowing and event system on the iPhone*. All this runs on top of the jamvm bytecode interpreter and GNU Classpath system libraries. So Java on the iPhone is getting more and more stable by the day, and while it's limited to jailbroken devices at this point, there's a hope that the GCJ ahead-of-time bytecode compiler can be ported to work on the platform, meaning apps written in Java could potentially get around Apple's restriction on interpreted programs being sold on the AppStore.

Of course there are a lot of missing pieces still, and one of my major goals is to get a more intuitive API working for Java that abstracts away the messiness of bridging to the native functions. To this end I've been working on a MIDP implementation that is roughly based on the GPL PhoneME project. At the moment it does little more than run a HelloWorld MIDlet, but it does that with gusto. And having converted it over to use the 2.0 SDK APIs, it's about time the source saw the light of day on its own little subversion server. So here it is:

svn checkout http://svn.tralfamadore.com/repos/iphone

There are three directories here:

midp - containing the work-in-progress MIDP implementation. This all builds to a midp.jar file, but includes a main class (currently javax.microedition.midlet.Runner) that acts as a MIDlet chooser and can be wrapped into an iPhone .app bundle (currently this is left as an exercise to the reader, but I'll add it to the build script soon).
jocenum - a small shell script to generate Java constant (public static final ints) declarations from the enums in the iPhone SDK headers
share - containing jocstrap and other JAR files for MIDP (and any other projects that might live here) to link against.

If you're interested in helping out, please join us at the iphone-java mailing list or email me privately (wes at tralfamadore.com).

* Even though I have an iPod Touch, the SDK is the same for both the Touch and the iPhone, and as the latter is shorter to type and more prominently marketed, I'm just going to refer to it that way (after all, Apple calls it iphoneos in the internals).

Tip: ssh autologin on the iPhone

noreply@blogger.com (Wesley) — Sat, 09 Aug 2008 22:09:00 +0000

If you have a jailbroken iPhone or iPod Touch and an inclination to hack and/or just poke around, you've probably ssh'ed into it as root (the password, if you haven't reset it, is "alpine"). Oh, the heady rush the first time I saw that shell hash prompt.

Anyway, after getting highly skilled in quickly typing "alpine" (muscle memory is a beautiful thing) it occurred to me I could eliminate that step by using ssh's autologin feature. Because it configures the session setup aspect of secure communication, it also applies to other secure connections you might make to the iPhone, like those via scp. And really, if you've got ssh and scp, what else do you need?

There are plenty of howtos out there that go into a lot of detail on the subject, but the basics are:

On your PC:
1. Run ssh-keygen from the command line. This will generate a public key and put in your home directory in a hidden subdirectory named.ssh.
2. Go to your .ssh directory and scp your id_rsa.pub file to your iPhone.
3. ssh to your iPhone.

On your iPhone
4. Create a ~/.ssh directory and set its mode to 0700.
5. Move the id_rsa.pub file you copied over to ~/.ssh/authorized_keys.

Voila, no more alpine. You can repeat the process from more PCs by appending each public key file to the authorized keys file (i.e. cat id_rsa.pub >> .ssh/authorized_keys).

Note that this doesn't actually disable you or others from logging in to your iPhone if you or they know the root password, and in any case you might want to consider changing it (in the usual way, with the passwd command).

Hacklog.start()

noreply@blogger.com (Wesley) — Sat, 09 Aug 2008 19:43:00 +0000

Let's talk iPhone programming. I've got a few interesting projects coming up that I'll share through these pages, along with various tips and tricks that I find useful.

A quick note on my development environments:

iPod Touch 16GB
Apple firmware 2.0
Jailbroken with PwnageTool 2.0.1
Full iphone-gcc toolchain installed

Mac Mini 1.42GHz (PPC)
OS X 10.5 Leopard
512MB RAM (I ordered the upgrade to 1GB)
Aquamacs Emacs 1.4
XCode (when I have to)
Interface Builder (if I must)