Another FP product slips out of its berth and into an app store today - we've just launched "AA Breakdown & Traffic", a product for the AA targeting modern Nokia devices (N8 and similar).

It's a straightforward app to get you help when you're on the road. So there's a few use cases we cover:

1. If you've broken down and you're not quite sure where, the app will report your location into the AA before you call them - so they know exactly where you are, and can get a patrol to you as quick as possible. This is a great reassurance if you're an AA member;
2. The AA publish a pile of authoritative traffic information, which you can see overlaid on a map, or browse by road name; so before you set out on a trip, or during your journey, you can see where incidents are and avoid them;
3. Owning a car involves keeping track of due dates for your MOT, insurance, and (if you're a member) your AA membership. The app has a handy little reminder feature, to make sure you don't miss any of these... and links through to the AA mobile site to help you buy insurance if you need it;

You don't need to be an AA member to use the app, and it's a free download from the Ovi store.

We built it using Qt and QML; it was actually the first Qt app we worked on at FP, but the Glastonbury app we launched earlier this month made it into the store quicker. You can see a lovely video about Roadwatch - starring Jeff Triner of the AA (and our customer) and Doug Hoskins, the Lead Developer from FP, over here.

Also from FP: John Revill and James Hugman worked on building the app, Trevor May designed it, Ben Carias and Paul Welsh tested the beast, and I acted as Product Owner (doing a little bit of discount usability testing in the process, which I might write about separately). A team at the AA provided the back-end services which we tied into.

• Transitions: The Nokia Way vs. The Microsoft Way: "Microsoft knows better than to osborne itself. The company has consistently stuck to its “Windows Everywhere” mantra and, no less consistently, has made sure that every new version of Windows offers strong backwards compatibility... For Microsoft, there is no Post-PC market". The more I see of the Microsoft/Nokia tie-up, the more interesting I think it could be. Go look at the VisionMobile report and look at the figures for device shipments and numbers of apps. iOS has the highest number of apps/device, WP7 is second, Android third. If Nokia can deliver volume shipments - and it's the thing they've been consistently good at - this'll be interesting.
• What To Do When A Tech Giant Decides To Eat Your Lunch: "Platforms are channels not businesses. Don’t confuse the two. If you put all of your eggs into one platform shame on you, not them. If their business torpedoes you, you should have been diversified". I've not understood the beef some people have with companies that provide platforms at no cost. If it's commercially funded you're not paying for it, what right do you have to demand service - as a developer, or a user?
• Thinking Outside The Browser Box: Why Should Apple Play By Current Internet Rules?: "Apple is not anti-Internet, they just believe that they can serve it to users better as a backend to their native apps rather than through a frontend in the Web browser". A few conversations have me personally more fired up about the Internet than the web. The web's starting to feel old, creaky to me. The forgiving parsers of human-readable markup and the duct-tape languages we used to bind and style them have accumulated cruft. It feels biological, a beautiful breathing wonder with vestigial organs, ripe for a fall from the top of the food chain.
• How to Build Location-Based Apps That Don't Suck: "High latency and a lack of offline support in location-based mobile apps is a blight that must be cleansed". That offline use case keeps hanging around, and rightly so. The sooner we stop users from worrying about signal strength, the better.
• Why mobile apps suck when you're mobile: "(another) reason to build a great offline / flaky mode for your app so that users aren't quite so frustrated by those spinners". Plus great reasons to understand more of the stack than an HTTP library: businesses that take responsibility the end-to-end experience produce products that are all the better for it.
• Pew: Adoption Of E-Readers Doubles In 6 Months, Bigger Than Tablets: "The ownership of e-readers doubled from six months prior when it was 6 percent... Only 8 percent of respondents said they [own] a tablet, compared to 5 percent six months earlier. "

I thoroughly enjoyed Mobile 2.0; you can see the slides from "Why the Web Won't Do", the talk I did on the second day, here. To summarise what I said:

1. We treat web sites and apps differently and adopt different mental models when discussing them (geographic and toolish, respectively);
2. It's not like fragmentation is going away; in the last 2 years we've seen Nokia/Qt, Windows Phone 7, WebOS, Bada, etc. all emerge.
3. The web is great for serving media across devices, but...
4. End-users expect apps to make efficient use of battery life and network. Apps should cope with lack of connectivity and their UI should be consistent with the rest of the device (in appearance, behaviour and responsiveness). The web falls short here.
5. If you try to build a native app with HTML5 and friends, you're using a stack of web technologies (OS, browser, JavaScript library, your app) to emulate the thing at the bottom of that stack. Performance will suffer; you're at the mercy of this intermediate layer. It won't feel "right". You'll likely end up fixing or working around platform-specific oddities anyway.
6. So to satisfy users, make best use of the medium, and for technical reasons, you need to do something else to reduce the effort of delivering apps across platforms.

The approach we've come up with looks like this:

We bridge from each platform into an embedded JavaScript interpreter; write application-specific shared code in JavaScript, and share this code between platforms; and write the user interface natively. This gives us code reuse between radically different platforms (Android/Java, iOS/Objective-C, Qt/JavaScript) and a UI which is responsive, and can take advantage of every feature that Apple, Google or Nokia offer.

Once you've written the bridging code, the application code to do this is quite straightforward; and this is the approach we used on the Nokia and Android versions of the Glastonbury app.

There's a recurrent debate in the mobile industry right now, "native apps vs web". You can see plenty of wishful thinking in this debate ("the web will save us!"), and it's unhelpfully black-and white. There are other ways to combine the best of native and web, beyond sticking a web-view into PhoneGap. And there's nothing to stop you using a web-view as a presentation layer onto the structure described here, of course...

For Glastonbury we did the Qt version first, then Android. Android took about half the time of Qt and about half the time of a full-native iOS port, using the approach detailed here. The shared code had plenty of scrutiny (as it was examined during testing of both Android and Qt builds), and we could focus development effort on the UI in both cases - which we think paid off.

I started playing with the Songkick APIs a couple of weeks ago. Songkick is a lovely service I've been using for a couple of years, that tells you when your favourite artists are touring nearby. In much the same way as Nike+ and Kindle, it's made a big difference to my life by stimulating a specific behaviour: getting out to see live music.

The API lets you query their mahoosive database of gigs and artists fairly simply - I've open-sourced a Java library which I've written to access their REST API, and wanted to use it on a Real Project to prove to myself that it actually worked for something useful.

I've rarely gone to gigs by myself. It's always been a social experience for me, and nowadays in my late 30s I quite enjoy catching up with an old friend by heading out to see someone from Our Youth play live. A couple of long journeys and a lazy Saturday in Barcelona gave me a chance to finish SongkickFor2, a little web app which helps you find a gig to go to with a friend. It's pretty simple: tap in your and your friends' Songkick usernames, and get back a list of upcoming concerts you both might like. I link through to the Songkick pages for these concerts, where you can buy tickets.

The sole reason this app doesn't look dreadful is the markup, CSS and aesthetic mastery of Dom, whose flat I'm staying at and who I worked with in the early years of Good Technology.

A follow-up on my tale of two operator app stores from a couple of weeks back:

Operator A has clarified (in an email to many developers) that when they said apps had been "published" they actually meant that the apps had been approved for sale, and were waiting for an individual country manager to select and launch them.

My take on this is that Operator A has managed to combine the worst of the old "operator portals" and the new app stores: an approval process for apps which is opaque, followed by an manual curation process with little external visibility. I would expect this to deliver the same level success that operator portals have delivered over the last 10 years.

Operator B, in the meantime, have contacted me directly by a couple of routes (one direct, one indirect) and, in between facepalming themselves, advised me to upload the app by an alternative site. I'll be doing this in time and will write up what I learn here.