Several weeks ago, developers were treated to an early preview of the next Android platform: Honeycomb (Android 3.0). Almost a month later, the final Honeycomb SDK was released, followed by the first commercial Android 3.0 device: the Motorola Xoom tablet. We’ve had some time to look at the SDK, new tools, and the new device. Here are our first impressions of the platform updates and changes. We’ll cover user and developer items alike, but as always from the developer’s point of view.
Android 3.0 Features and APIs That Excited Us
Android 3.0 provides a variety of new features and APIs. We’re particularly excited about many of these, as their addition further expands the types of applications that are feasible on the platform.
The Fragment API makes it far easier for developers to create dynamic user interfaces and use screen real estate more effectively. Although initially considered primarily a “tablet API,” the Fragment API can be used with all user interfaces to simplify design and share more code and layouts between different orientations and screen sizes, making it an essential API to use when targeting various device types.
A common problem developers have to deal with is downloading data for display within an Activity and then managing this data acquisition process when the configuration changes. Honeycomb introduced the concept of Loaders to solve this problem. By handling the retrieval of data asynchronously and automatically reconnecting to the data to avoid querying it again, we can expect the special new Loader API to improve the performance of the average data intensive screen.
Android Action Bar
Google introduced the notion of Action Bars last year at Google IO 2010. Several flagship Android applications incorporated the Action Bar concept, providing real world examples of this new user interface paradigm. Now, however, the Action Bar concept is built into the platform and have several new features, including drop-down menus , instant access to option menu items, and tab management. Look for more consistent and easier navigation in applications that use the Action Bar well.
RenderScript is a system that promises to provide a means of writing graphics and computational code in the C programming language and having it execute either on the native CPU or GPU, allowing for increased compatibility across multiple CPU and GPU types. This system reminds us of OpenCL or CUDA, in that performance critical computations may run on the GPU hardware and receive acceleration beyond what can be accomplished by the CPU. Although usually used in the context of graphics programming and games, the computational abilities could allow for other interesting uses.
Android 3.0 Tool Updates
Several tools were updated around the release of Android 3.0. The Graphical Layout designer has, once again, improved by leaps and bounds. It now shows a much more accurate preview of what a layout will look like on multiple Android devices, screens and SDK versions. It’s also easier to drag widgets over and place them accurately without resorting to XML editing. Still, it’s not perfect and we find ourselves in XML frequently to fine-tune user interface controls.
The emulator has received an improvement in the form of the snapshots feature. Snapshots allow the state of the emulator to be stored upon exit and later reloaded, cutting the startup time down to just a few seconds from what was often a several minute boot cycle.
Static Libraries for Android Backward Compatibility
Perhaps right now you’re thinking: This is all great, but I need some of these features now, with existing devices that aren’t running Honeycomb. Well, you’re in luck! The Android team has just released a static library that contains some of the most sought-after Honeycomb features, making these features available for applications targeting Android 1.6 through Android 2.3.3. Right now, the primary two features this library encompasses include the Fragment API and the Loader API. Personally, we wish the Action Bar had been included from the start, too.
However, the statement the Android team is implicitly making with this release is great. There’s an implicit dedication to existing versions of Android — even old ones. They — and their users — are not being left in the dust.
A Few Honeycomb Disappointments
As sweet as Honeycomb is, it’s not perfect. There are some changes to the Android SDK that we don’t particularly like and wonder why they changed — for the worse.
Honeycomb SDK Emulator Performance
The emulator performance for Android has never been particularly good. This is especially true as screen resolutions of the emulator have increased. With the Honeycomb SDK, we now see emulator resolutions as high as 1280×800. The end result is that even on our relatively speedy development machines, the emulator performance is only barely good enough to see what an app will look like, but not how it will likely behave. Even seeing how the application will appear takes some patience. We’re developers, we don’t have a lot of patience for tools that slow us down. Right now, we have resorted to primarily debugging our apps on the physical device. The Android team recognizes this problem and claims to be working on this issue. We wish them speed in improving the emulator performance.
Lost Dedicated Buttons
For years now, developers and users alike have gotten used to and even enjoyed the functionality of the four primary dedicated buttons found on all Android devices: Back, Context Menu, Search, and Home. These are gone now. Back and Home have been replaced by on screen buttons. The Context Menu is being replaced by an Action Bar menu, although there is a context button that appears on the bottom bar for existing applications. The Search button is also gone; search will now normally be found on the Action Bar. This is quite a shakeup from a user interface design perspective.
While these changes are arguably improvements for the long term — after all, the buttons will now be in the same place regardless of the device or screen orientation, these changes necessitate some retraining of developers and users alike. And since all of the existing devices still have those buttons, we also have a case of both hardware and software fragmentation that developers will have to deal with for some time to come.
Missing Android 3.0 Features and Apps
We’ve never expected perfect forward compatibility, despite the fact that it was promised. (See the Android Developer’s Blog, “While it’s true that devices without the latest software can’t run some of the latest apps, Android is 100% forward compatible — apps written properly for older versions also run on the newest versions.“) We can’t help but notice when features are no longer present at the platform level or at the “core” application level. For instance, new changes to the Android Market no longer provide a way to review apps. Are developers who ask for reviews supposed to send their users to the online Android Market? Was this just an oversight?
Some platform user features have also changed. Users can no longer create folders to hold applications as an organizational method. Live folders can still be created. Where did this feature go? As users, we relied on it to have apps closer at hand. As developers, we want my apps to be closer to the user.
These types of changes — where we lose features but no comparable features are added instead — lead us to question, “Why fix it if it isn’t broken?”
Growing Pains for Android
Even Google’s own applications aren’t immune to some upgrade issues with regard to Honeycomb: for example, Google Voice no longer works. (See Google forums for acknowledgement that it’s unavailable and this article for info on it crashing.) Google Voice is not present on the market for Honeycomb devices. Reports show that those who try to side-load it find that it crashes. If Google’s own apps don’t work without modifications, then the argument that the platform is truly forwards compatible doesn’t hold water, and leads to doubt and developer anxiety over the stability of the platform. Does this mean my apps will crash, too?
Platform instability is not good for users or developers, especially when it attracts negative media attention. It makes us wonder: Was Honeycomb — and the Xoom — rushed to the market simply to get out there before the competition? (You know what we’re talking about, right?)
Honeycomb Supports Phones… or Not.
Reports have been all over the board on whether or not there will be smaller screen devices (aka phones) based upon Honeycomb. Initially, it seemed like there might have been a split in the operating systems but thankfully, this doesn’t seem to be the case. With many of the Honeycomb features already available on phones via the static library, it’s very possible that the next platform version will simply be available before the smaller screen hardware comes out and phones will skip from Android 2.3.3 to Android Ice Cream Sandwich (nom, nom).
All in all, Honeycomb delivers quite a lot of exciting new features and generally improves the platform in a variety of ways. Yes, with these improvements come changes, and developers, application publishers, and users alike are going to need some time to adjust. Not everyone likes or appreciates change, but in the long run, these changes help ensure the future success of Android as it continues to eat up market share and make the other competing platforms sit up and pay attention.
About the Authors
|Shane Conder and Lauren Darcey—Contributing Editors, Mobile Development–have coauthored two books on Android development: an in-depth programming book entitled Android Wireless Application Development (ISBN-13: 978-0-321-62709-4) and Sams Teach Yourself Android Application Development in 24 Hours (ISBN-13: 978-0-321-67335-0). When not writing, they spend their time developing mobile software at their company and providing consulting services.|