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.
There is one point, though, where iPhone and Android diverge. While Objective C is similar to Java for many intents and purposes, it is a dynamic language. Some Java programmers report that they are much happier to let Java take care of the memory management and catch bugs at compile time. Other Java programmers point out the usefulness of still thinking like a C programmer, because memory is at a premium on a smartphone and garbage collection can cause hiccups.
I have noted some divergences that might rankle people. Why did Google build its own framework instead of using something a bit more standard, like the Java Micro Edition or plain old Swing? Neither has a wonderful reputation, but it might have made sense to rework them instead of starting anew. I'm not sure I can even guess except that it wanted to do things the Google way. Anyone who's used other Google tools -- such as the Google Web Toolkit or the App Engine -- will recognize the spare, no-nonsense aesthetic immediately.
It's worth noting that the Android platform is significantly more open than Apple's. If you want the documentation, it's available for you without clicking through some gateway. The discussions about the platform are open and encouraged. All of this should be a big advantage to enterprise developers who want to ship something to everyone in an office without jumping through the hoops from Apple.
"When I was writing a chapter on sound for 'Hello, Android,' I found it useful to study the source for the media player to clarify a few things that were not covered well in the documentation," says Ed Burnette, the author of the Hello, Android tutorial.
Still, there are limits that may be practical but won't please the faithful followers of Richard Stallman. Android may be all open source, but not everything in the Google phone is part of Android.
There are some loopholes. Google is now selling developers a completely unlocked phone for $400. This is an excellent option that will attract many programmers who long for the joy of logging into the phone as root and of flashing the ROM with as much modified code as they want. I have a hard time imagining how end-users will ultimately benefit from developers having more access, but that doesn't matter. It's a nice option that will encourage more creativity.
When a friend of mine moved to Washington, D.C., he was told he needed to get a smartphone because that's what one did. There's plenty of spare time between meetings and more than enough nervous energy to be turned into thumb taps. The new apparatchik, a longtime Mac lover, wanted to get an iPhone, but his new colleagues set him straight. The iPhone would flag him as an artsy trend chaser, but a BlackBerry would establish him as a bona fide member of the group serious enough to run the country. So he chose a BlackBerry.
BlackBerry developers will quickly learn how well the company knows that people choose the BlackBerry because they're dedicated team players. RIM's market is the enterprise developer. Within a few seconds of starting to create an application in the BlackBerry MDS Studio, I put up a form wrapped around a Web service. The tool's software wizards took the URL for the Web service, popped up a list of public methods, then designed a form for me once I chose a method. Boom. The BlackBerry has a front end that funnels input from the keyboard directly to a Web service call, then formats the result. It's not pretty. There are no flashy OpenGL graphics or flippy cards warping through multiple dimensions -- just a form, a Web service call, and the answer.
This example comes from the Rapid Application Development collection of classes and tools, built as plug-ins for Eclipse or for Microsoft Visual Studio. This collection of tools lets you build a set of forms by dragging little widgets to a page. In the background, the tool bundles all the descriptions into an application that's loaded on to the screen of the simulator. You don't really write Java code at all for this level.
There is another level that's open to the developer if you feel the need to write Java applications. The BlackBerry system is a proper version of the Java Micro Edition, something that makes it easier to migrate to the platform from some of the other phones. You run into javax.microedition classes frequently, and they become part of your code. The GPS functionality is based on JSR 172, and the multimedia follows JSR 135. In other words, BlackBerry looks like a closer partner to Sun than Google does.
"We created our own proprietary APIs," explains Mike Kirkup, a manager of developer relations at RIM. "You can write a pure MIDP [Mobile Information Device Profile] application, and it can work independently across a variety of platforms, or you can write only using BlackBerry-specific APIs, or you can mix and match."
The BlackBerry-specific APIs open up more access to the BlackBerry's hardware controls and don't abstract them like the Java MIDlets.
There are some other features that aren't as available on other phones. RIM is quite proud of the fact that the applications don't have to die when a user switches to another application. Your code can start up threads that watch for incoming messages pushed from the server. That's a nice feature for desktop and Web programmers who are used to a looser sandbox and also one that makes the platform richer and more useful.
Game programmers used to spitting out OpenGL won't be happy with the BlackBerry OS, but it's still possible to do a perfectly good job with animated SVG (Scalable Vector Graphics) files and many other forms of video codecs available with the JSR 135-compatible media programming framework. Those may be enough because many BlackBerry users spent their teen years with Nintendo games, and some were even born before Pong came along. Cool graphics may not be necessary to pique their interest.
The simulator lets the programmer experiment with what happens when the user reacts to events by answering a call, ignoring it, or placing the handset in a holster. There are also options that simulate moving the phone to any coordinate.
"The simulator is way better than the Windows Mobile emulator," says Jay Flick. "They really put a lot of work into simulating the incoming calls, simulating the GPS. For delivering a quality product without having the device in your hands, RIM has that down pat."
BlackBerry's software distribution model is also more of a throwback to the days when you installed software by copying files, not by syncing with some iTunes store. You can even use a command line to load the software over a USB link. Java MIDlets can be downloaded from Web sites out there. All of this makes the BlackBerry world a bit more familiar to desktop programmers. Nevertheless, the success of Apple's App Store hasn't been lost on RIM. The company recently began accepting submissions to the BlackBerry Application Storefront.
One of the trickier conundrums facing the BlackBerry programmer is supporting the installed base. The new BlackBerry Storm comes with a bigger touch-sensitive screen and an accelerometer, two features that make it more like the iPhone. Longtime users love the old-style thumb boards, and their visceral reaction to change may mean that the old screen sizes and layouts will be with us for some time to come. This shouldn't be much of an issue for enterprise programmers and others who want to write serious software for serious people who want to plow through some serious data.
It's easy to forget about Nokia and the Symbian platform after wading through the hype about iPhone and the Google phone. As I'm writing this, AT&T is selling a Nokia 2610 for $10 with no two-year contract. An iPhone might cost you several thousand dollars over two years, but the Nokia will do the job for $10 and 25 cents a minute. The low-end phone might not offer a great Web browser, GPS, OpenGL graphics, or other tools, but it runs Java ME (Micro Edition) applications and delivers the packets for a dramatically lower price point.
The good and bad news is that this is far from the beginning or end of the Nokia line. The company just introduced another phone, the N97, which comes with a touchscreen, GPS, Bluetooth, and too many other acronyms to list. One devoted fan writes on Engadget, "One has copy and paste, A2DP, a QWERTY keyboard, and a screen resolution which is 1.5 times larger than its rival. Meanwhile, the rival has a (inconsistently) walled garden and a smug bastard swimming in sacrificial fanboy donations from Cupertino." The Nokia phones are good enough to attract their own fanboys.
The challenge of developing for Nokia and Symbian is working with such a wide range of platforms. There are phones that cost hundreds of dollars and show video at 30fps, and there are others with black-and-white screens with big fonts, features that incidentally play well in markets like Florida, where older people with poorer eyesight need to look at the screen in bright sunlight.
The good news is that the Symbian world is much closer to the desktop world than are some of the bigger phones. If you want to download someone else's software for your phone, you don't need to ask "Mother, may I?" or search very far. Shareware and freeware are everywhere. Dozens of people seem to offer download sites with open and not-so-open packages for Nokia phones. Academics like Stefan Damm, Benjamin Gmeiner, and Andreas Jakl post their semester projects on sites like symbianresources.com, where anyone can download their software, including gBoarder, a package that uses the accelerometer to measure the jumps of a snowboarder descending a slope. It's not a walled garden, but just another corner of the chaos of the Internet. There are safer harbors, though, because Nokia runs its own Download Store filled with applications that range as widely as Apple's.
The development tools reflect the breadth of this world. The latest batch is almost 500MB, and that doesn't include an IDE. Some Symbian developers use Microsoft's Visual Studio, others turn to Eclipse or Carbide. I think some even use GCC (GNU Compiler Collection) with a command line.
If you want to write to the Java ME, you're encouraged. If you want to write C++, you can. In fact, there are three different flavors of C and C++ to muddle your choices: standard C++, Symbian C++, and Linux C for platforms like the 810. The Symbian version of C++, the preferred solution for most phones, adds features that help the programmer live with the small screens and limited memory by offering tighter exception handling, a certain amount of garbage collection of objects, and some network tools for handling asynchronous calls. These limitations are fading, though, because Nokia is proud that the newest version of Symbian C++ includes standard C++ exceptions too.
If that's not enough, there's also a nice implementation of Python and a good community built up around the platform, and Nokia's research group also delivers an open source version of Perl. Adobe Flash Lite is an option too. My favorite choice may be called PAMP -- short for Personal Apache, MySQL, and PHP -- for your phone, a tool that lets the Web developer create personal applications without learning C++, Java, or those other icky languages where instructions are written without HTML tags. Don't ask me if it really works -- just the fact that it exists says a lot about the platform. While the iPhone brought a real Safari browser just like a desktop, Nokia is delivering all of the crazy extremes we've come to expect from the Internet.
The world of development for Palm and the Treo is pretty similar to the world built around Nokia phones. The Palm OS is one of the original handheld operating systems, and its world is broad and deep. When I was poking around for weird languages that run on handhelds, I found the most for the Palm. One version of Python, called Pippy, was last updated in March 2003, long before the iPhone and even before Apple rolled out the first really successful iPod, the 3G. The Palm OS is sort of a museum, in a way, but one that comes with a broad and deep collection of software.
This is changing now that Palm officially announced its new webOS. I wasn’t able to work with it at all, but it sure looks promising. It takes some of the great ideas from the iPhone and seems to extend them further. The Web and HTML promise to play an even bigger role in the new Palm OS than in the iPhone, and that's bound to be useful for everyone except game programmers looking for maximum performance.
The old OS will continue to be important in the short term because other products like the Treo and the Centro will use it. I hope some of these roots make their way to the Pre because there are many advantages to working on a platform with such a long history. Open source coders have built tools for working with 2-D text in PDF forms, audio files in a variety of formats, and even video. All of these are available for you with open source licenses if you choose to wade in. If you like working with a command line and your favorite editor, there's a good version of GCC available with many of the favorite Linux world tools. (See prc-tools.sourceforge.net.)
If you want more than freedom, Palm itself offers the PDN (Palm Developer Network) with all of the tools and a long user agreement full of noise about confidential information.