Daniel Janus – iPhone

My top three iOS apps for mapping

2012-09-13T00:00:00Z

Living in London means that I now have a whole lot of new area to explore by cycling or walking. I try to take every opportunity to spend a free day or weekend out. One of the most important things when on the move is knowing where you are, where to go, and how to get there — and for that, you need a map. As I soon learned, the maps to use in the UK are the Ordnance Survey ones (either the Landranger/Explorer series, or maps by another publisher, such as AA, based on OS data). However, the Landranger series encompasses over 200 1:50000 maps, standing at some £8 each, and when that level of detail is not enough, there are more than 400 Explorer maps on top of that. Not only does this get pricey after a while, but also the sheer volume of map juggling quickly becomes impractical when you cycle a lot outside of town.

So I’ve turned to my old trusty iPhone 3GS as a mapping device instead, and set out to complete a set of mapping apps that do the job for me. In this post, I’d like to share my list.

I briefly thought of directly using OS maps on the iPhone via the Outdoors GPS GB app; it does meet my requirement of being accessible off-network, but the pricing of individual maps is on par with the paper version, so I ruled it out.

Instead, I am using this trio now:

The official National Cycle Network app by Sustrans. Beside being free, it has an advantage of detailing every numbered national cycle route, as well as most local routes (that often predate NCN or are not yet integrated into the network). At high detail, the data seem to be OS-sourced, which is good.

It downloads maps from the Internet on demand, but you can also save a map portion for future use. The app asks you how much detail you want, tells you how large the download will be, then proceeds to get the data. The nuisance here is that you can only download 40 MB in one go, which corresponds to an area stretching for approximately 50-60 km at 1:50000 (and correspondingly smaller at 1:25000), so it takes a lot of tapping and downloading if you’re planning a longer trip.

The other downsides are that the app is a little shaky at times, and GPS positioning sometimes displays your position somewhat misplaced. I mitigate this by using this app in combination with the next one…
…which is MapsWithMe. The tagline “Offline Mobile Maps” nails it down: it’s just maps, easily downloadable, covering the entire world, and nothing else. This really does one thing well. The map data source is OpenStreetMap, so all the maps are available for free as well; one ‘Download’ tap and you’ve got the whole country covered, once and for all. It also displays GPS position much more reliably than NCN. On the other hand, it can’t offer quite the same level of detail as NCN, and doesn’t know anything about cycle routes, but it’s still highly convenient.

My typical flow when cycling in the UK is: check my position with MapsWithMe, then optionally switch to NCN, locate the same position on the map by hand and see where the route goes. I’ve also done one continental three-day trip, from Dunkirk in France to Hoek van Holland in the Netherlands, using just MapsWithMe to navigate, and it worked out very well.
Unlike the other two, the last app I want to point out, GPS2OS, is paid. And it’s more than worth its meager price, despite being next to useless when cycling. But when hiking, especially in remote mountainous areas, it can literally be a lifesaver. Here’s the catch: my basic navigation tools in harsh conditions are a compass and a plain ol’ paper map, and the iPhone is treated only as a supplementary aid (you never know when the battery goes out). However, instead of indicating the latitude and longitude in degrees/minutes/seconds, OS maps use their own grid. So you cannot use the default Compass app, which tells you your position in degrees, directly with them, and you need a tool just like this one to do the coordinate translation. Works very well; it helped me find my way in dense mist down from the summit of Ben Macdui during my recent holiday in Scotland.

One final tip: when you want to conserve battery as much as possible, airplane mode is a real saver. However, GPS doesn’t seem to work when airplane mode is on. So the next best thing is to remove the SIM card (you can then reinsert it, just don’t enter the PIN), so that the phone doesn’t keep trying to connect to cellular networks. And keep it warm in a pocket beside your body: cold devices discharge much faster.

Meet my little friend createTree

2011-07-08T00:00:00Z

I’ve recently been developing an iPhone application in my spare time. I’m not going to tell you what it is just yet (I will post a separate entry once I manage to get it into the App Store); for now, let me just say that I’m writing it in JavaScript and HTML5, using [PhoneGap][1] and [jQTouch][2] to give it a native touch.

After having written some of code, I began testing it on a real device and encountered a nasty issue. It turned out that some of the screens of my app, containing a dynamically-generated content, sometimes would not show up. I tried to chase the problem down, but it seemed totally random. Finally, I googled up [this blog post][3] that gave me a clue.

My code was using jQuery’s .html() method (and hence innerHTML under the hood) to display the dynamic content. It turns out that, on Mobile Safari, using innerHTML is highly unreliable (at least on iOS 4.3, but this seems to be a long-standing bug). Sometimes, the change just does not happen. I changed one of my screens, to build and insert DOM objects explicitly, and sure enough, it started to work predictably well.

So I had to remove all usages of .html() from my app. The downside to it was that explicit DOM-building code is much more verbose than the version that constructs HTML and then sets it up. It’s tedious to write and contains much boilerplate.

To not be forced to change code, the above-quoted article advocates using a pure-JavaScript HTML parser outputting DOM to replace jQuery’s .html() method. I considered this for a while, but finally decided against it — I didn’t want to include another big, complex dependency that potentially could misbehave at times (writing HTML parsers is hard).

Instead, I came up with this:

function createTree(tree) {
    if (typeof tree === 'string' || typeof tree === 'number')
        return document.createTextNode(tree);
    var tag = tree[0], attrs = tree[1], res = document.createElement(tag);
    for (var attr in attrs) {
        val = attrs[attr];
        if (attr === 'class')
            res.className = val;
        else
            $(res).attr(attr, val);
    }
     for (var i = 2; i < tree.length; i++)
        res.appendChild(createTree(tree[i]));
    return res;
}

This is very similar in spirit to .html(), except that instead of passing HTML, you give it a data structure representing the DOM tree to construct. It can either be a string (which yields a text node), or a list consisting of the HTML tag name, an object mapping attributes to their values, and zero or more subtrees of the same form. Compare:

Using .html():

var html = '<p>This is an <span class="red">example.</span></p>';
$('#myDiv').html(html);

Using createTree:

var tree = ['p', {},
            'This is an ',
            ['span', {'class': 'red'}, 'example.']];
$('#myDiv').empty().append(createTree(tree));

A side benefit is that it is just as easy to build up a tree dynamically as it is to create HTML, and the code often gets clearer. Note how the createTree version above does not mix single and double quotes which is easy to mess up in the .html() version.