[Programming] A developer’s-eye view of smartphone platforms


An interesting article of same title has drawn a great comparative sketch of smartphone platforms.

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.

I am going to include details of 2 smartphone platforms here in this post. To see other, visit infoworld.

Apple’s 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.

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.

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’s 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.

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.

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.

Advertisements
%d bloggers like this: