Symphonious

Living in a state of accord.

Revisiting Java on the iPhone

Around the time of the iPhone’s initial release, I wrote:

It's this popularity of Java in the mobile phone world that makes the lack of Java on the iPhone seem so odd to me. I can understand Apple wanting to have complete control over the iPhone interface, and I'll concede that most of the existing games for mobile phones probably wouldn't translate very well to the keypadless iPhone, but it will be interesting to see if Apple can satisfy the great desire for cool little mobile games that today's teenagers, a key market segment for the iPhone, without leveraging the existing knowledge mobile games developers have in Java.

Turns out I was completely wrong. Teenagers don’t give a damn about those gimmicky little games on their mobile phones, they just use them because they’re there. The iPhone’s coolness factor and the built in iPod is all that matters. Even wandering around Australia (where iPhone’s aren’t yet available) with my iPhone, lots of people asked about browsing the web, the iPod etc but not a single person asked about games (and yes, I do know quite a few teenagers who were doing the asking but still nothing about games).

There’s two other aspects of that post that are quite interesting in hindsight:

If the iPhone takes off it won't be a problem, similar to how there are a huge range of iPod specific accessories, there will be – if and when Apple make it possible – a huge range of iPhone specific games and add-ons.

This one is panning out exactly as expected. People will make a lot of money selling games for iPhones – not because they’re essential things to have, but just because they’re there. It should follow roughly the same pattern as the rest of the market for mobile phone stuff where people make a killing selling high volumes of little stuff. That said, the iPhone application store should change the market place a lot – suddenly it will be easy to find the good stuff. It will avoid the scams where they advertise one game for $1 but it really signs you up to a subscription that adds up to $50/month.

Turns out I was also dead wrong about ring tones:

The other part that may be interesting is what happens to the ring tone market as more and more phones use standard MP3s for the ring tone and make it easy to load them onto the phone. The iPhone should nail this and Nokia and Sony-Ericsson are pushing their MP3 player capabilities. Nokia's even going so far as to note how easy it is to get music onto the phone in their Australian marketing.

Turns out the iPhone has the worst ring tone capabilities of any phone I’ve used in the past 2-3 years mostly because it doesn’t allow you to use any old MP3 you happen to have (and because the volume is way too quiet). The saving grace is that the iPhone happens to have the best default ring tones of any phone I’ve used – but still way too quiet. I’d be quite interested to find out how many ring tone sales Apple is doing through the iTunes Music Store given that it also avoids the subscription scam that most ring tones are sold through.

Droplets With Automator

Automator is a cool little app that comes with OS X that makes it much, much easier to programmatically control the various applications on your computer (all the good ones anyway). It’s all done by dragging and dropping actions into a workflow – the output of one leads to the input of the next. In Leopard, Automator got a big upgrade so it can now handle loops and variables but most of the time you don’t need them.

One handy feature that’s not obvious though is that if you save your workflow as an application (File->Save then select Application instead of Workflow) you can drag and drop files onto it and they become the input to the first action. So to create a droplet that resizes images to 50%, just drop the resize image action into a workflow and save it as an application. Any image you drop onto it will be resized to 50% (overwriting the original – you might want to take Automator’s advice and add a copy task too).

This proves particularly useful when combined with the wireless printer/scanner I have since it can automatically open the scanned file in any application you specify. I now have a “Process Receipts” workflow that copies the file to my Ephox Receipts folder, adds the date to the filename, resizes it to 25% (seems to be the right balance of file size vs readability) and opens a new email in Entourage with the file attached and template text, ready for me to send off to the magical fairies that know what to do with that stuff (we call them Irene, Therese and Michelle). In the time I saved, I wrote this blog post…

iPhone SDK

So the iPhone roadmap looks very promising. The enterprise functionality is really impressive and places the iPhone extremely well as a mobile device for corporations. The SDK has a lot of power and seems to have access to pretty much everything you'd need (there's already an SDK for access to the dock connector). Even things like instant messaging and VOIP will be allowed, though obviously the carriers don't want to deal with all the traffic from VOIP so it's just wireless but that seems quite reasonable to me. I'm not sure I'd want to try VOIP over an edge network anyway…

The biggest problem I see with the SDK is the $99 entry fee. $99 is nothing to anyone with a decent idea for an iPhone app and the skills to develop it. Heck, if you don't have $99 to spare how the heck did you manage to afford an iPhone?? Still, once you plonk down that money you're very unlikely to release your application for free which means just about all the iPhone software is going to be payware. I like the concept of selling software and thus paying developers, I earn my living that way, but it's just so nice to have a bunch of freeware or opensource that you can just grab and try out and maybe it'll be great maybe not. Little ideas released for free make an awful lot of sense and make the world a better place (in a very techno-geek way). That's unlikely to happen with the iPhone.

That said, how hard would it be to set up a donation pot to buy access to the iPhone SDK for open source projects? Not sure how it would all work but it would be a great idea and if you don't donate enough the software really does go away so there's more than just altruistic incentive.

Bottom line for me, I can't wait to get the exchange functionality because I've been wondering what the best way to get my exchange calendar synced with my iPhone (I use exchange for work and iCal for home but iPhone for both) and I'm really keen to get an instant messaging client on the iPhone as well. I can live with AIM if that's all I get though most of the people I know are on MSN. Beyond that it's just a bonus so I'm really quite happy with what's come out.

Doable vs Shippable

All the hubbub about flash support on the iPhone highlights an interesting "gotcha" that many people fall into: there's a world of difference between having something running and having something you can actually ship. The funny thing about software development is that it is generally much quicker and easier to solve all the "hard" problems and create the software you need than it is to polish off all the little loose ends that turn code into an actual product. It's also surprising how many ideas that sound really good on paper turn out to actually make things worse.

For example, recently I spent an evening and developed a fairly basic image editor that could plug into EditLive!  Just the basic operations like crop and resize that people want to quickly do without switching to a separate program. It took all of about 3 hours work and dealt with error conditions, was well coded etc etc etc. Of course, the UI was hideously ugly because I didn't have any icons to use and it wasn't my primary focus but it was an impressive, if ugly, little program. The trouble is, it will take a month or two of full time effort to bring that program to a point where it can really be shipped to our clients. There are just so many little details you need to consider that aren't obvious until you've gone through the process a few times.

There are also times when you develop something, sort out all the loose ends and are really ready to send it out to the market, until you realize it sucks. I spent some time a while back improving the standards compliance of the caching we do in EditLive! It basically cached everything and ignored even the basic Pragma: No-Cache directive which does cause issues for a number of our clients so it seemed like a no-brainer to fix. The trouble is, far too many servers and developers default to disallowing caching even when the content isn't going to change. This has a fairly minimal effect on browsers because you don't go back and forward through pages all that often so the site feels a bit more sluggish but it's not too distracting. In a HTML editor, you want the images to be cached, no question. The number of times the document changes around, when you cut and paste that image etc etc you really don't want to have to download the entire image again – even more so if the image size isn't specified in the HTML since then the document content jumps around when the image finally does download. It turns out you have to be pretty clever in how you apply the caching standards in a HTML editor – they do work, it's not that the standard is wrong, it's just that it takes a lot of careful thought to get it all right.

So how does this relate to Flash and the iPhone? There's a couple of ways – firstly, let's say Apple has the full Flash running on the iPhone with no bugs etc. How fast is it? If it's too slow, users might be better off with the non-flash version that any decent site should provide. How much battery power does it drain? This is your phone we're talking about, having it run out of battery during a day is a major inconvenience. How well does it interact with the iPhone's touch screen input method and the on-screen keyboard? I keep hearing people argue that the iPhone needs flash so it has access to all those little flash games around the internet. You know, the ones where you move with the arrow keys…. oh wait. Sometimes things aren't as straight forward or as cool as you think and you probably won't know until you've actually tried it.

The second question is whether these rumours of Apple having flash running on the iPhone are actually people seeing the mobile version of flash which Jobs mentioned and discarded as too simple for the iPhone. Mobile flash isn't being kept off the iPhone because of technical limitations, but because, at least according to Jobs, it's simply not good enough to handle the real internet. It's also not necessarily a step forward to add mobile flash, even if it can't handle everything. All those sites that do the right thing and provide fall back content automatically if flash isn't available work just fine on the iPhone right now. If you have mobile flash though, suddenly they'll be showing you the flash content and if mobile flash isn't up to scratch it just won't work. Sometimes adding features winds up making things worse.

What's the bottom line? Whenever you hear someone talk about how easy it would be to do something, ask them if they've actually done it. If not, there's a very good chance they're wrong, regardless of their qualifications and experience. Really, really smart people hit unexpected roadblocks every day so unless you've actually achieved something you should be expecting unexpected trouble. Secondly, even if they have proven it can be done, check that it actually works out as well as you'd expect in real world testing. The real world is full of surprises and some of them will almost certainly apply to what you're working on so be prepared.

Of course, this doesn't just apply to flash or the iPhone, it applies to all engineering work that tries to achieve something new. Just remember, if it were simple, someone else would have done it by now.

Kudos To Landon Fuller

With all the complaining about Apple not having shipped JDK 6 with Leopard it's nice that someone has actually stopped whining and started coding. So kudos to Landon Fuller for actually doing something useful. Of course, he hasn't really gotten anywhere because porting Java is an awful lot of work, but if nothing else he'll understand why it takes Apple so long.

It also means we can start the timer to see if the open source model can actually bring Java 6 to OS X faster than Apple can.