Smartphone programming is booming. The little leash that lets your boss reach out and ruin your time off is turning into a platform of seemingly infinite possibilities. It's more than just iPhone applications that simulate a glass of beer that drains as the accelerometer measures the amount of tilt. The new smartphones can act as a wallet, a personal shopper, a personal trainer, and a source of endless amusement.
The bad news is you're going to need to cool your jets and take a few breaths. While every good programmer looks at a smartphone and sees a machine that can run rings around yesterday's desktops, not everyone has the same vision. The phone companies, the ones that own the towers and deliver your inspired bits to the general Internet, don't see your dreams. They worry that your totally awesome idea is going to totally flood their network with packets and shut out everyone else. They know that the infinite loop you forgot to debug is going to drain batteries. They're afraid that you'll find some clever way to cut them out of text-message profits. They're sure that you just want to spam someone, anyone, because now you can do it with a cell phone while you buy milk.
[ See InfoWorld's guide to the best mobile devices and Test Center reviews of the iPhone 3G, T-Mobile G1, BlackBerry Storm, BlackBerry Bold, Palm Treo Pro, AT&T Fuze, and HP iPaq 910c. ]
There's no point in thinking about it too much. If you want to write code for the iPhone and enjoy the wonderful playpen that Apple built for us, you're going to have to play by their rules. If you want to write for the Google phone, your life will be a bit freer, but you'll need to remember that they've got a kill switch and the power to destroy your dream. The good old days of peeking and poking around in memory are gone. The word "root" won't come through your fingers unless you decide to run up the pirate flag, void the warranty, and live forever outside the civilized world, where updates are supposed to work.
Strategies
To understand the world of smartphone programming, I waded up to my ankles into six major platforms: the iPhone, Google Android, RIM BlackBerry, the Palm OS, Windows Mobile, and Nokia Symbian. I downloaded the development kits, wrote a few lines, and spoke with some programmers who have waded in a bit deeper. Limiting this survey to six platforms was still difficult because it leaves out some good opportunities, like the very open OpenMoko and the cross-platform power of the Java Micro Edition, a version of Java that runs on a number of phones.
The ankle-deep survey left me in awe of the wide-open competition and opportunity for everyone. Unlike the desktop world, there are more than a few players, and the niches are evolving, merging, and splitting. Some of the platforms are better for tightly integrated enterprises, while others offer much better opportunities for gamers and experimenters. Some require the highest-end hardware with the most expensive contracts, while others work well with cheap phones too.
Jason Flick, president of the Ontario-based Flick Software, a mobile solutions company, says he pushes his clients to identify the most important demographic group that will be using the software, then target the phone that's most popular for that group.
"On the business side, those guys are into BlackBerrys," he says. "All of the executives are using them. If you have a business app, that's what you want. But it's hard to do sexy and exciting."
Other applications fit better with low-end platforms because the users don't own the high-end phones. The groups usually don't intersect, but that's changing. Apple is working hard to attract business customers, and RIM wants to add more flash to the BlackBerry platform. The Nokia Symbian and Windows Mobile worlds live on phones with a wide range of IQs, display sizes, and features.
"To build a one-fits-all is very difficult right now," Flick explains. At least, it's very difficult if you insist on using native code. Using HTML, JavaScript, and CSS, you can often come surprisingly close to native look and feel while covering all of the top phones. See the companion article, "The cross-platform option: Building Web apps for smartphones."
But only native apps make full use of the accelerometer, GPS, and other prize features. And if you want to build native apps, you'll have to make a choice regarding audience, devices, languages, tools -- in other words, the entire ecosystems of the major smartphone vendors. With that choice in mind, here's a snapshot of where those ecosystems are right now.
Apple iPhone
The roots of Apple's success with the iPhone are easy to see. Every part of the development chain, from the initial Xcode application to the final store, is polished and polished again. The programmers at Apple sweat the details and spend their time trying to make things simple, elegant, and intuitive. Programmers get to bathe in the same production values as the end-users because the tools are polished, with almost as much care as the main interface. The documentation is great, the instructions are copious, and there are plenty of examples.
The main tool, Xcode, has been a staple of Mac programming for some time. While I continue to like Eclipse for many reasons, the speed and polish of Xcode put it to shame. There's no need to stop and get coffee while Xcode starts up. And there's no need to hide your eyes.
The iPhone's main language is Objective C, and the main framework is Cocoa. If you're still in doubt as to whether NeXT took over Apple or Apple acquired NeXT, the iPhone should end it. It's an updated NeXT machine that fits in your pocket. You can stitch up your application and thread the widgets together just like it's 1988. The same names and concepts, like "Interface Builder," are still around even though the implementations are enhanced.
I think it really helps to have some history programming the Mac if you take up the iPhone. While much of the work is threading together widgets, just as with all of the other frameworks, there will be moments that remind you why C is called machine-independent assembly code. Java programmers will need to remember that the data is dynamically typed, then spend a few minutes relearning how to allocate and free memory because it's their job.
Samuel Kass, a programmer who created a Chess Clock for the iPhone, says, "There are lots of little gotchas, and as someone who's used to Java, it's frustrating to have to go back to worrying about explicit memory allocation." There are major APIs for all of the cool features. If you want a picture, you can grab an image from the camera. If you want to know which way the device is moving, you can query the accelerometer. These APIs are pretty low-level, and it's a long path between getting the acceleration vector and any usable UI. One programmer joked that once you find out the acceleration, it's a snap to write Super Monkey Ball.
Developers are also chafing at Apple's decision to allow the iPhone to run only one application at once. If you're used to relying on the operating system to swap out your application and keep it out of the way while someone starts up another one, you can start learning what life was like before the Mac came with MultiFinder. This rule probably has some utility because it forces developers to consciously give up control and save their work -- something everyone should be doing already. But it means more coding for developers, and you won't be able to blame someone else when your app crashes. The competing platforms, though, can sense the vibe flowing through the community, and they're emphasizing the fact that their phones can handle more than one task at once.
It's worth noting that there's a great deal of confusion over the breadth of Apple's nondisclosure agreement. One developer who was offered a chance to talk about his iPhone software wanted to check with a lawyer. Some of the development documentation that used to be more public is now locked behind a wall that requires you to log in.
All these hurdles are manageable for those who want to make cute applications and sell them through Apple's store. As long as you cross your fingers and avoid the big landmines -- porn, bandwidth hogging, competing with Apple -- you'll probably be fine. But nothing is certain because even Google saw its iPhone application delayed at birth.
The iPhone marketplace is a great innovation -- if your end-user is a customer who will use iTunes to download it and install it. The sales numbers are phenomenal, and Apple's done a nice job making it easy for developers to push a button and watch the money roll in. Some wonder if the flood of applications is driving prices to zero because many developers seem to cut costs frequently, but that's life with a free market.
Everyone else, though, is going to jump through some hoops that will seem odd to everyone who is used to sharing binaries without saying, "Mother, may I?" The Developer Enterprise Program is "available to companies with 500 or more employees." All registered developers can "share your application with up to 100 other iPhone or iPod Touch users with Ad Hoc distribution." But what if you want to mail it to between 101 and 499 friends? Or what if you're a restaurant owner who wants to build something for the iPod Touch? It's all rather dicey. There are reports of new developer codes for the iTunes Store that make everything much simpler, but it's still not like the good old days when you could just hand a floppy to a friend. After a few days of trying to get all of the cryptographic certificates correct, I started cursing the people who developed public key cryptography. This isn't what the cypherpunks imagined way back when.
A number of developers use the h-e-double-hockey-stick word to describe the process of actually testing code on an iPhone. Xcode lets you do anything with the simulator, but using an actual device means filling out forms on the Apple Web site. Someone somewhere is clearly worried that something will be done without permission from the mothership, and boy, does it cut into development time.
There's some indication that Apple has heard these pleas. Apple has improved the provisioning process and it will probably spend more time improving it again. But you can pretty much forget about using the word "my" in front of the word "iPhone" because it's Apple's sandbox, Apple’s App Store, and Apple’s code stack. Apple just lets you play in it -- and it kicks back 70 percent of the revenues from the store too.
Google Android
Google's Android is remarkably similar to the iPhone in many ways. Accelerometer? Check. Camera? Check. Application store? Check. OpenGL for graphics? Check. GPS? Check. Sure, the first Android phone comes with a keyboard, but that's not really a concern for you. You'll still get your keypress events just like an iPhone programmer.
There are some differences under the hood, but they're not as big as might be expected. Both the iPhone and the first Android phone use OpenGL to render the graphics and the UI, but Apple's can take the lead with floating point values. The iPhone's processor is better suited to floating point math.
The deepest differences may be in the language itself. Google chose Java, a language that's well understood by many new graduates. Then it built special plug-ins for Eclipse, so all of the lovers of programming Java with Eclipse can write code, push a button, and simulate running their app on the phone in a separate Java process. The tools are all available for free, and it takes only a few minutes to get the Hello World application up and running, most of which is spent waiting for Eclipse to create a bazillion objects of its own as it starts.
Java programmers who don't use Eclipse can still get it all to work, but it seems to be a bit rougher. The framework for projects are built with some Python code, a perfectly logical choice, but one that seems a bit discordant. Much of the other work can be handled by Ant plug-ins.
It's a bit of a misnomer to say that Google chose Java because much of the actual work can be done with a maze of XML files. Anyone who writes this code should get used to typing the word "Android" because all of the XML files use the word for the namespace specifying the attributes for the nodes. Programmers -- or maybe I should say XML form-filler-outers -- can build up all of the user interface and some of the details with a maze of XML nodes all tagged with integers. It's been a long time since I wrote down unique ID integers instead of unique ID strings when I tried to work through some code, but I did when I looked at some Android apps.
After getting lost in these files filled with options for localization and UI widgets, I gave up and started writing pure Java code. It's actually possible to create Java objects directly and link them up with other Java objects instead of sketching this out in XML and waiting for some Java code to parse the XML, create the objects, and link them together. The direct approach worked much better for me.
After wading through this, I began to see the same basic widgets and ideas that are common in the iPhone and, for that matter, many UI frameworks. There are TextViews, TableLayouts, and MapViews just like on the iPhone. These platforms really are small desktops with rejiggered proportions for the windows.