Salvaging a failed iPhone app

The first of my ‘being productive at the weekend’ projects was something I’d actually started over the Christmas holidays – a pretty simple iOS app for checking domain name availability. The few apps I’d found all had the same restriction – they could only check .com/.net/.org domains. At a guess, they were just making a standard ‘whois’ request and parsing the results. Because every TLD/ccTLD formats their results differently, they just stuck with the main TLDs. (For those that don’t know their domains: the ‘TLD’ is the ‘.com’ part of a domain name. A ‘ccTLD’ is a country-specific TLD, like ‘.uk’ for the UK or ‘.ca’ for Canada.)

So I thought I saw a gap in the market: an iOS app that could check almost all TLDs/ccTLDs. I knew there was a Ruby gem which had parsers for most ccTLDs so I decided to make a really simple web service, and write the app using one of the mobile webapp frameworks, and then use PhoneGap to turn it into a native app that I could submit to the App Store.

Last weekend I decided to scrap this idea, because I realised that I’d managed to miss iOS apps from all the major domain name registrars, including GoDaddy, which did what I wanted to do and were better in every way. Oops.

I don’t count this as a complete failure. As well as learning to do more thorough market research I also got to play with several new technologies, and put an actual app on my actual phone (and through the power of TestFlight on a few other people’s actual phones, too).

And since, at its heart, this was just a webapp, I can strip out the PhoneGap-specific code, chuck away some parts of the API that don’t matter now, and put the final thing online. So I did: DomainIsFree should work on iOS devices, it might work on Android 2 (or your browser might crash), and in theory it should work on WebOS, but who really knows?

I’m not going to spend time debugging the jQTouch problems on platforms other than iOS – it works for me, and if you have an iPhone it’ll almost certainly work for you. It doesn’t do anything you couldn’t find a website to do, but if you save it to your homescreen on your iPhone it’ll be conveniently available for when you wake up at 3am and wonder if ‘enwriten.com’ is available. (Hint: it was when I checked, it won’t be if you check.)

So what have I salvaged from this otherwise failed project? I’ve got some product development and technical experience, and ultimately I’ve scratched the itch that started me on this project in the first place. It’s not as good a result as it could’ve been, but it’s far from as bad as it could’ve been too. I’ll call this one a minor victory and move on.

iOS webapp frameworks roundup

With a workable beta version of my first ever iPhone application sent out to the few brave souls who volunteered to test it, I thought I’d quickly go over my technology choices for this app.

The core of the application is basically a mobile webapp, wrapped in PhoneGap to make it a native application. I could just as easily distribute it across the normal interwebs, but I specifically wanted to distribute it as a ‘native’ application. A native application lets me more easily sell it for cash money, and distribution via the App Store makes it slightly easier to find than via any clumsy attempts at online marketing I were to try.

It also gives me some experience in the iOS app build process, which is always good to have.

The application is, from a technical perspective, quite simple. It’s a front-end to another simple JSON web service I’m running (on Heroku, as an experiment in trying Heroku, and using MongoDB as an experiment in figuring out how you actually use ‘NoSQL‘ databases). I actually wrote 90% of it three times using three different mobile webapp frameworks.

Attempt one: Sencha Touch

I’d been wanting to try Sencha Touch since I saw Drew Neil, the voice behind the superb Vimcasts, had done a series of screencasts on this framework. The Sencha Touch version was the more developed of my two false starts, and actually more-or-less worked. I gave up on it after losing a day to trying to make the ‘enter’/'go’ button on the iPhone keyboard submit a form, as I realised that Sencha’s entire approach was wrong for the small and simple application I was making.

Sencha Touch works by doing everything as a huge blob of JavaScript functions that are only minimally related to the DOM. Your objects don’t directly match the DOM objects, and it all got confusing and frustrating for me. It has the look of something that’s really powerful for larger and more complex applications, but it just got in my way and annoyed me. I think I’d go back and try it again if I was developing an iPad app, but I don’t think I’d use it for an iPhone app.

Attempt two: DashCode

Almost no one seems to talk about DashCode online, ignoring it to talk about Sencha Touch, jQTouch, and jQuery Mobile. But it’s actually pretty neat, providing an IDE that’s specifically designed for small and mobile web applications. It provides a ton of UI widgets that, being made by Apple, look really good.

I only gave it a very quick try this time – I realised that I didn’t have time to learn the IDE and conventions of DashCode since I’d already lost so much time on Sencha Touch – but it was fun to fiddle with. I reckon that it could actually be a killer tool for rapidly knocking up a rough/not-functioning prototype before passing it over to a ‘proper’ iOS developer to do in ObjectiveC and InterfaceBuilder.

Final choice: jQTouch

In the end, I came back to the framework I’ve used before. jQTouch’s last release was quite a long time ago, but the maintainer is still working on it and I used HEAD from GitHub and was (mostly) fine, with just a little tweaking to get the ‘apple’ theme working properly.

jQTouch’s HTML approach has less mental overhead for me than Sencha Touch and I was able to get it working in much less time. The framework is showing its age: there’s no ‘retina’ resolution graphics and it’s really not suitable for iPad applications, but for what I was doing this time the simple direct approach was the best.

But! jQuery Mobile!

The elephant in this blog post would be jQuery Mobile, the new mobile webapp framework from the jQuery team themselves. All the other frameworks are aimed specifically at mobile webkit browsers, and the most attention is given to iOS and Android. jQuery Mobile’s supported platforms is truly impressive, and if I was making an application intended for more than just iOS, I’d seriously consider it.

But I’m not – I’m making a ‘native’ app, and having native-feeling widgets is really important. jQuery Mobile is also still in the ‘alpha’ process, and probably shouldn’t be considered ready for production.

My ‘backlog’ of side projects includes one that I’m hoping to try jQuery Mobile with, and I think they’ll be close to ‘version 1′ releases by the time I’m ready to start on that project. That particular project is number four in my mental list, and as a teaser, here’s what the four projects represent to me, technologically:

  1. Making a ‘native’ App Store app using web technologies.
  2. Client-side screen-scraping using JavaScript.
  3. iOS notifications, and the first piece of a project I’ve wanted to put together for a very long time.
  4. Accessing native hardware components in a PhoneGap application.

I’m not giving myself any deadlines on these projects, and I’ll probably come up with other stupid ideas in the meantime, but I’m hoping I’ll get all four of those out in the world this year.

The details on number one will follow, once it’s ready for release!

Promoting Personal Productivity Plan

So, pretty much every year I decide that I’m going to be more consistent about working on my side projects, updating this blog, and generally not spending my non-work time staring vacantly at either my TV or my computer. Then it descends into half-hearted hacking on toy projects that never really achieve anything, and I’m back to wasting my weekends playing Minecraft or Fallout.

I think the problem is that I’m a bit undirected. It’s simple to determine what’s ‘productive’ for work – it’s whatever the boss tells you to do. When you’re making it up yourself it’s easy to get distracted and confuse ‘fiddling aimlessly’ with ‘being productive’ and then end up with no motivation because you don’t see any results.

So to kick start this year’s attempt at bettering myself, I’ve got a Plan.

This plan is fairly simple: each weekend day I’ll spend two distraction-free hours (no Twitter, Google Reader, email, IM, Facebook, LiveJournal, or anything) working on things. To help encourage me to do this I’ve roped in the wife, who’ll be working on her own projects during the same two hours. To keep myself focussed I’m going to use a three-point guide on what I can work on during this time. It’s pretty simple:

  1. Anything that directly relates to making money. This could be an iPhone app I plan to charge money for, or something I can put adverts on with a realistic expectation of seeing people click them, or an improvement to an existing venture (like my web hosting). My long-term goals require getting a lot better at making money this way, and in the short term it’ll help to increase my savings, clear debts, and help deal with my annoying mortgage.
  2. Anything that helps develop new usefully marketable skills, or directly helps me market myself. This would be an app using CouchDB, which I’ve not used before, or learning ObjectiveC for iOS development. It wouldn’t be writing another toy Twitter bot – but rewriting @scotfail so the code is clean and then publishing it on GitHub would count (and I do in fact plan to do this).
  3. Any blog post. I don’t post here enough, so time spent writing about anything relevant counts.

I’m feeling pretty confident – the first session on Saturday went really well, with a lot of progress made on the iPhone app I was fiddling with over the Christmas holidays. Since I’m now working from home primarily, I’m all set up to keep working at the weekend. Previous attempts failed because I tended to try and work while sitting on the sofa instead of sitting at my desk – but I’ve got my working environment sorted out now and I think that might actually be the most important change.

If this works, you should see more posts here – as well as counting blog posts as ‘productive’ work, I should just plain have more to write about since I should be doing more stuff on my own time. I might also be able to write about some of the stuff I’ll be doing for SourceRail, although that obviously depends on the boss saying okay!

In fact, the next post should be about my iPhone app, but I’ll talk about that once it’s ready for testing.

jQTouch over Dashcode?

I’ve been on a mobile/iPhone webapp kick lately. It seems like a nice area to work in, and it’s forced me to pick up a lot more JavaScript than I had before which is good.

There are some amazing frameworks for making iPhone webapps. The first one I came across was jQTouch, which is a jQuery plug-in and is really really awesome. It makes it straightforward to make an app that looks and behaves pretty much iPhone-native, without learning ObjectiveC or signing up for an iPhone dev key. jQTouch’s future is a bit uncertain right now – it’s being merged in with a company that apparently has a bit of a bad history for changing licences and leaving people in the lurch. The jQuery guys have said that if it looks like jQTouch might be ‘lost’ they’ll either fork it or develop a replacement, so I’m not terribly worried. There’s a demand for this kind of framework, so someone will fill it.

After playing around with jQTouch a little, I discovered Dashcode lurking away in my Mac OS X developer tools. And then I discovered that it provides an Interface Builder-like interface for designing your app. And then I raved about how awesome this was to everyone at work, even though no one cared because we don’t do mobile development at all in any way.

It seemed so much better to me to be able to specify the layout in a visual drag-and-drop way, especially since this kind of webapp is really targeted at a single platform with a single screen resolution. You can take liberties that you’d never get away with on a traditional app. Dashcode also provides a lot of really good widgets and code snippets that could make apps look a lot slicker and speed up development.

So if Dashcode is so awesome why have the only two real mobile webapp projects I’ve done/am doing used jQTouch?

Part of it is familiarity. jQTouch works using normal HTML and JavaScript files which I can edit in TextMate. Dashcode is an entire IDE and it would take time to learn how to use it effectively. I struggle to find time and energy to work on this stuff as it is, and the extra overhead from learning an IDE might kill my wee projects before they even get started.

But I don’t think that’s the main reason. Both jQTouch and Dashcode have a high degree of magic to them – they both just work to produce slick iPhone webapps, but jQTouch’s magic is more accessible. You have to create the view structure and links yourself out of HTML and this gives you a handle on how jQTouch is doing what it does. The GUI approach taken by Dashcode hides that and makes it less immediately obvious.

Part of the reason I’m doing these projects is to learn new skills. jQTouch exposes more traditional JavaScript than Dashcode does. By using jQTouch I’ve been able to grok unobtrusive JavaScript, a skill that will be useful on my next non-mobile web project. The extra magic in Dashcode might be awesome and shiny and wonderful – but it gets in the way of learning how it all really works.

I think Dashcode can serve some people really really well: people who are experienced JavaScript developers and don’t need to take time to develop their skills, and people who are very inexperienced and don’t want to take time to develop their skills. If you just want to drag-and-drop an iPhone webapp together without learning how to use JavaScript properly, it’s definitely a viable option. If you’ve already been doing JavaScript development and want to learn a new IDE and use a graphical UI builder, it’s pretty awesome.

As for my new projects: one is a private app, but the other one will be getting a beta release soon. Expect more posts on that and the technology used, including client-side SQLite databases, which are both awesome and frustrating.

Updates

A couple of progress updates on things I’ve written about previously.

First up, my ‘MacBook Mini’ is coming along excellently. I’ve been using it at work and to write some short stories, the battery life is brilliant and the keyboard is nearly as good as the one I use with my iMac.

I’ve got speaker/headphone switching working, by installing the Azalia Audio drivers (downloaded from here) and first using a shell script to switch sources and now using the modified version of Audieee that Stuart Shelton has made available here. I’ve still not got around to setting up key shortcuts for controlling brightness – frankly, the system defaults to a perfectly acceptable level when it’s running on battery and I don’t often bother to change it when it’s on mains power.

Bluetooth worked before I got wifi working, but now it doesn’t. I’ve not had time to look into that yet – it’s not a priority for me. The module is supported, so it should be fixable.

This last weekend Stuart Shelton posted a fantastic guide to the ‘proper’ way to install Mac OS X on the NC10, using a retail Leopard DVD. If you’re starting from scratch I’d definitely recommend doing it that way – I think I’ll be looking for a replacement (larger) hard disc and then I’ll go down that route.

All-in-all, after about a week of living with it I’m really happy.

Sort-of related, I’ve signed up for a 60 day trial of Apple’s Mobile Me service (previously known as ‘.Mac’, and as ‘iTools’ before that). The synchronisation between iMac and NC10 is awesome, and using iDisk to store my short stories means that it’s automagically kept up to date on both the iMac and NC10 – and thanks to MobileFiles I can even view (but not edit) them on my iPhone.

I always resisted .Mac because I just didn’t think it was worth the money – now I think it might be. I’ve got the best part of two months to make my mind up, though.

Next up, my plan to defeat failure – this is a bit more mixed. Virgin 1, clearly desperate to retain my eyeballs between eight and nine in the evening, have switched Star Trek Voyager for Deep Space 9, and the best part of DS9 too. As a result, we’ve reverted back to watching TV, which is disappointing.

However, thanks to the NC10 I am able to get some stuff done during that time, and while I’ve not done much on my own projects recently I have been helping my wife (who has no software development background at all – she has a degree in English literature) write a simple web app for her fanfiction story archive. With about 6-8 hours of work we’ve turned out a basic deployable application and have some sketched out ideas for what she wants to do next.

It’s been really interesting to see a complete noob develop a Rails app, albeit a simple one. It shows just how powerful Ruby and Rails are – the language ends up being meaningfully readable by someone who’s not familiar with the conventions of programming languages. While the Rails framework is undoubtably awesome and provides a huge amount of help and tools, what this has highlighted for me is just how good Ruby itself is. Once someone figures out how to replace the C/Javaish language used by Processing and Arduino with Ruby I can see Physical Computing becoming even more accessible for a greater range of artists.

Edit: Craig has pointed out RAD – Ruby Arduino Development, which I had forgotten about. All the bits are there to make it really easy for artsy types to make interactive art. Go to it!

But as awesome as it is helping the missus with her application, I really need to get my head down and work on some of my own ideas. What I really want right now is to have a live web application that’s really being used by actual people that I can talk about when I go to Scotland on Rails next year. (Sadly won’t be attending this year due to not being able to justify investing the attendance fee given my current level of involvement.)

So while I’ve not advanced any of my own projects, I do feel that I’ve been doing stuff and not just sitting vacantly watching TV – I’m still defeating failure, but perhaps not quite grasping success!

Mobile Technology

Prior to my current day job I spent just over a year working at one of Nokia’s outsourced call centres, first doing general support (how to use the phone and explaining that only the network can get it unlocked) and then technical support (mostly supporting Nokia PC sync software, and some other horrors).

I’m interested in most forms of technology, but this job gave me a specific interest in mobile phone technology. In recent months that’s kind of been fading in favour of a new shiny (virtualisation), but a couple of weeks ago I picked up an iPhone 3G and it’s been interesting to really interact with mobile technology again.

My previous phone was a T-Mobile branded Windows Mobile thing. It was very good, as far as Windows Mobile things go, but it was in no way pleasant to use. I bought it mostly because it wasn’t a Nokia (at the time I had the use of a Nokia through work) and because I’m a sucker for a sliding QWERTY keyboard.

The poor user interface on the Windows Mobile device really put me off using it for anything fun. On my really old Sony Ericsson phone I was regularly SSH’ing to places and playing around with it. It was good fun. For some reason SSH on Windows Mobile was always a chore. A superior keyboard and display resulted in an inferior user experience.

The iPhone does not officially support SSH (at least not yet in the UK – I’ve heard rumours of a port of PuTTY being made available in the US), but I jailbroke mine within 24 hours of buying it. The Mobile Terminal app isn’t awesome, although a recent update fixed some bugs. It’s not really practical for any sort of significant use – but it seems fun to use. I want it to get better so that I can use it more. Even on a third-party Hack, the iPhone has a great user experience.

There’s a lot more to this than just the shiny, shiny user interface, though. Nokia’s S60 handsets had a relatively low barrier to entry for development, in the form of a port of Python. Python’s a good solid scripting language that’s easy to pick up and enforces good coding style. There’s some hoops to jump through to make apps with it for S60, but it’s a hell of a lot easier than developing a full-blown C/C++ application if you’re not already familiar with C. It also provides a more cross-platform solution – Python’s been ported to pretty much everything.

The iPhone’s native development environment is ObjectiveC and Cocoa which if you’re going to develop in C is probably the most pleasing way to do it. I’ve been watching John Dow‘s experiencing in learning Cocoa and it doesn’t seem evil at all. Even a really nice set of frameworks doesn’t make iPhone development anything special – there’s frameworks (of varying quality) for every platform.

When the iPhone was first released, Apple didn’t want to allow native applications at all. They said that you could do pretty much everything most apps want using Safari and web apps. Mobile Safari is by far and away the best mobile browser on any platform. I’ve used Nokia’s S60 browser with MiniMap (which is based on the WebKit rendering engine), PocketIE, and Opera, and none of them render as well as Safari and none are as easy to use to navigate real-world web sites. Cocoa is nice and all, but Safari is the iPhone’s real strength, and that’s where my interest in development for the iPhone is.

After doing end-user support for mobile phones and then suffering with Windows Mobile for another year the joy had gone out of mobile technology for me. At the start of the year an Eee PC helped to rekindle it, but the Eee PC really is just a small laptop and not what I think of when I think of ‘mobile technology’.

The iPhone has brought the joy back. I want to make things for this little device. Mine’s jailbroken and I can install lightttpd and ruby on it if I want. I can SSH into the phone, as well as from it. It’s like when I got my first Mac OS X machine and I realised that all the GUI joy of Mac OS 9 was still there, but it had been joined by the command-line joy of unix. (And that’s when I stopped dual-booting Linux – I’d pick a jailbroken iPhone over a Linux Google Android or OpenMoko phone any day.) Most importantly, I can develop for it without learning ObjectiveC by just relying on that wonderful, wonderful rendering in Safari and producing a normal web application (with, maybe, some iPhone-specific UI tweaks using iUI).

The iPhone won’t change the world, it won’t even change the total phone market. It might change the smartphone sector, but probably not. It’s too pretty and too trendy, and that puts off the suits who order 50,000 phones for big corporations, and that’s where the big money is in the smartphone market. It won’t even dominate the consumer smartphone market because all of Nokia’s best general-purpose phones are smartphones and Nokia’s devices have much wider availability.

But it’s going to make my life a bit nicer, and it’s brought a little technojoy back into one area that I thought had had all the joy squeezed out.