Android programming's ups and downs (Q&A)

As smartphones using Google's Android operating system become mainstream, James Steele and Nelson To are in a pretty good position.

As authors of The Android Developer's Cookbook, they're a step ahead in a growing market, apps for the mobile device OS. Andy Rubin, the Google vice president of engineering overseeing Android, said earlier in December that 300,000 Android phones now are activated each day.

But one major issue facing programmers hoping to reach those phones today is that they have different hardware and software--a problem called Android fragmentation. Programmers must adapt their software as the operating system spreads not just to significantly different mobile phones, but also to tablets with even larger screens and to other devices including televisions, cars, and music players.

Fragmentation can be a problem. But Steele also sees fragmentation from the other side: the breadth of the Android market means programmers can tackle many devices that otherwise would be far away in some other coding ecosystem.

"The structure of the Android OS helps minimize the changes required for an app to work across these platforms. It is great for a developer to have such a low threshold to be able to take advantage of this diversification," Steele said.

Steele and To chatted with CNET's Stephen Shankland about what Android coders can expect with Android. Here is an edited version of the conversation.

Q: Why publish an Android development book now?
Steele: Both Nelson and I have been working on Android for over two years now and we have seen the continual growth. Even more so, 2010 has been a breakout year for Android across the world. The OS and hardware have both matured with rich features, but some are still not documented well. There are many resources for learning Android but few full working examples. Our goal with the book is to provide a developer with self-contained working examples in as modular a form as possible, so they can be incorporated as-is into someone's code.

What are the most compelling things about programming on Android?
Steele: Android is an embedded platform which has potential and momentum to go well beyond just smartphones and tablets. Being open source, it is compelling for a variety of different hardware manufacturers, for example set-top boxes and automobiles. Also, almost the entire OS is open for usage and extension. This opens the possibility for sophisticated changes as needed.

And on the flip side, what are Android's biggest warts?
Steele: As for the biggest difficulties in creating Android applications today, we mention in the book it is the need to ensure apps work on multiple platforms and multiple code versions. Therefore, we dedicate a few sections to writing general enough code as well as discuss methods of testing...Hardware manufacturers tend to try to differentiate themselves, which makes it hard to write an app that is applicable to all platforms. We provide some advice and important techniques to minimize issues with cross-platform usability. Google is always improving feedback, now providing stack trace results [a look at what a program was doing just before it crashed] from users on applications that failed after they downloaded them from the market. Also, we are seeing many markets for applications, which could be a good thing but for now is confusing to the end user as well as developer.

How hard is it to deal with the varying screen sizes, physical buttons, processing power, and other hardware of the profusion of Android phones today?
Steele: It is a challenge Android developers should be aware of, but it is surmountable. In the book we provide concrete examples on how to ensure code is robust across multiple platforms for all the above cases.

You mention processing power, which is less of an issue now given processing power is within a factor of two, but newer devices will start to take advantage of hardware accelerators which might differentiate performance using SMP or SIMD ["symmetrical multiprocessing," which for Android means chips with multiple processing cores, and "single instruction, multiple data," chip features that accelerate multimedia and other processing]. This will lead to a factor of ten difference for some applications (such as 3D gaming for example), and that needs to be considered.

Also, sensors such as accelerometers and magnetometers (compasses) have various different specifications now, as we discuss in the book, but there is a push to improve the quality of these sensors and hopefully we will soon see a convergence in this regard.

How suited to multicore mobile processors is Android? Dual-core Android devices will start arriving soon. Will that be a boon for multitasking, background apps, performance of foreground apps, or other specific scenarios?
To: I am really excited about that. I think this definitely will take the Android to another level in terms of the responsiveness and the ability to handle the application switching. However, I have another concern, the battery power lifetime, considering this will consume battery power even faster than what we have. I think in the long run the battery power is something that all the device manufacturers should really focus on. In the current market, I still haven't found any devices that can sustain power as long as the iPhone.

What features is an iOS programmer going to miss most on Android? And what about vice-versa?
Steele: I'm not sure what they will miss, but the open APIs [application programming interfaces], ability to leverage the cloud, and more computing power are things they will enjoy.

How come games on Android are so weak compared to Apple's iOS? Processing power, APIs, developer tools, market size, developer interest, or what?
Steele: The iPhone, being introduced first, had an early lead in games and apps. But now the quality of Android apps is maturing well.

The Native Developer Kit lets programmers write software that runs at a lower level than the usual Java-like environment for Android apps. What NDK changes come with Android 2.3, aka Gingerbread?
Steele: There are more hooks for native code to manage events and surfaces. For the end user, this provides an even faster gaming experience. For the developer, it also enables a more natural port of existing C/C++ applications. Also, note more processors are coming out that support the parallelism that the NDK can offer, which will also provide large benefits.

[Surface management] applies to 3D graphics in Android. Drawing an object so that it looks three-dimensional on the screen requires building it up from simple shapes such as triangles and squares. These two-dimensional shapes are called surfaces.

If you're writing a game, how big a deal is the fragmentation? You say that there are steps you can take for generalization, but is that something that takes 3 percent of a developer's time? 50 percent?
To: Android provides different mechanisms for developers to leverage different kind of screen sizes. That includes providing the different picture quality [options] inside an application, which allows it to run on the different screen [sizes], and providing layout format mechanisms. As a good Android developer, this work has to be taken as part of the their fundamental design spec. This can take up to 5 percent to 10 percent of the whole project effort.

What features within Android 2.3 are likely to be most interesting to programmers?
To: I think one of the most significant improvements in 2.3 is they provide a way to access the native code without going through the JNI [the Java Native Interface mechanism for linking Java programs to other software]. Another feature provided in 2.3 is the SIP [session initiation protocol] stack and framework API [application programming interface] which allow developers to develop the SIP application (Internet telephony application) a lot easier.

If you're a Java programmer, how hard is it to learning to code for Android?
Steele: We wrote the book assuming the user has a basic familiarity with Java. However, a programmer with no background in Java will pick things up very quickly. On the flip side, as mentioned in the book, Android is not Java. Someone very familiar with Java and especially J2ME [Java 2 Mobile Edition] may feel frustrated to realize things are sometimes done differently, but still it will be easier than learning a new language from scratch.

What are you going to do with your book now that Gingerbread is out, presumably with bigger changes coming in Honeycomb?
Steele: The feedback has been very positive so far on the Android Developer's Cookbook. People really like the format to allow them to jump in and start using recipes in their own apps and also on how current it is compared to other books available. There will always be changes to the OS, but this book provides the foundation to utilize the incremental updates.

In your conversations with developers, have you heard complaints that the 24-hour return period for paid Android apps is a problem? Google is changing it to 15 minutes.
To: I happened to talk to a couple Android developers about the return policy on the Android Market. They feel frustrated that the return rate on the applications is extremely high. One of the reasons is the way the Android Market allows users to return [apps] is way easier than the return policy on the iPhone.

One neat thing about Android is the ability to hand off a task to another app on the phone--for example, clicking the share button can plug into Facebook, Twitter, and Gmail, or tapping a link can launch a choice of browsers. But can this turn into an ugly mess, where there's a huge list of applications all trying to vie for the user's attention. What's the best way for programmers to help keep things tidy?
Steele: This is a great feature of Android. Virtually any function served by the OS can be replaced by a third-party application. We mention in the book how to do this using intent filters. Then when users are provided the choice, they are offered a chance to choose a default method of servicing such intents in the future.

How truly open-source is Android? It seems like it's written in-house at Google for the most part, with periodic code dumps when the new versions are released. If you're a manufacturer, do you have better access to the planning and code under development? Do you have to join the Open Handset Alliance to get that influence and access?
Steele: Manufacturers do make their own changes on top of Android to differentiate themselves. These benefits of open-source will also be a benefit to Google TV when it is made available.

How good is Android today for tablets? What changes do you think would make Android better for tablets?
Steele: Android already works well for tablets. The HD video and large-screen support are key.

Will we ever see the fragmentation issue ease with Android? Is there anything that can be done about it? I see games with lists of which devices they'll run on (confused greatly by the different device names in different countries), discussions about testing on multiple devices, and Rovio Mobile planning to release two separate versions of Angry Birds to deal with low-end and high-end processing abilities. So clearly it's an issue, even if it's not enough of an issue to stop Android growth.
Steele: The Android Developer's Cookbook provides some important examples of how to generalize apps to multiple platforms. As a developer, I would rather spend a little extra time to take care of the different devices out there and reap the benefits of the larger distribution of my apps.