Mark Damon Hughes iPhone vs. the Mobile World [Parental Advisory: Explicit Lyrics] [about]
iPhone vs. the Mobile World
Mon, 2008Apr28 16:14:25 PDT
in Mac by kamikaze

I've made some good progress on my iPhone game, and I've been thinking about how it compares to previous mobile platforms.

I've done mobile development with C on Palm, Java on a couple of J2ME devices, and now Objective-C/Cocoa on iPhone.

Mobile development is about limitations. Mobile devices have incredibly limited memory, often 64K RAM (yes, kilobytes, just like the Atari 800, Apple ][, and Commodeodor-64 (sorry, old habits die hard). They have incredibly limited CPU power; rarely more than 100MHz CPUs, often not even true 32-bit CPUs. The screen size itself isn't that bad; I was quite happy on my 320x192 (monochrome) or 160x192 (4-color) Atari 800. But that was on a 15+" TV screen, not a 2" phone LCD.

The iPhone's specs are significantly higher than those: a 300MHz CPU, 64MB user application space, and nigh-unlimited storage in a real filesystem (albeit a sandboxed filesystem), as well as real SQLlite databases. The screen is relatively huge: 320x480, with 256K colors, and 160DPI (nearly print quality). I'm not particularly enamored of the on-screen keyboard, or lack of a stylus for precision touch, but it's still a good device.

PalmOS was kind of awful even back in the '90s. 16-bit memory space, paging data in and out, a totally weird and alien non-file-based filesystem, and a flaky set of tools (anyone who liked CodeWarrior was insane). Every OS release broke most of the apps, often in data-destroying ways. Not a happy place. But the GUI was fantastically easy to program for, and the devices just worked right. If only Palm hadn't gone into a coma for the last decade, they could still be #1.

J2ME is actually kind of okay. Java's GUI support is pretty lame, but the language is nearly as efficient as native code, especially in the form used by mobiles. If you don't make gigantic trees of objects, and pay attention to memory use, you can make interesting stuff in 64K or 128K. The problem is that almost every phone is slightly incompatibility with the standard.

Android has some chance of doing well with their approach, which is to use Java to compile to "native" code (actually an intermediate bytecode that gets compiled to native later), and provide common APIs which hopefully will be implemented the same way everywhere. Hope. That's the word, because there's no real Android phones yet, and the demos have not shown attractive work. Android's OS is pretty weird, and pretty awkward to use. A lot depends on whether any of the phone vendors can do something attractive and useful with it, and they don't have a good track record of making pleasant devices.

A few people have suggested using Python, Ruby, .NET, and other scripting languages on mobile, which is so ludicrous I can hardly believe my eyes when I see it. I'm a gigantic fan of using Python for system scripting, but its speed and memory consumption are abominable, there are few GUI libraries worth using on any platform, and none appropriate to a mobile device. Python's a totally inappropriate choice for mobile. Ruby's performance is significantly worse than Python's. .NET is tied to Wince devices, which are one of the worst failures ever in the mobile space.

So compared to all that, the iPhone's been the only one that isn't awful. It does require learning Objective-C and Cocoa, which are daunting to the uninitiated, but any halfway-competent Mac developer can learn the Touch API quickly.

← Previous: Shell + Whitespace = FAIL (Software) Next: Swords and Sorcery (Roleplaying) →
Feedback  | Key: ] =local file, * =off-site link  | Copyright © 2003-2010 by Mark Damon Hughes | Subscribe with RSS 2.0