Honeycomb

Google is getting ready to launch Android 3.0, aka Honeycomb, the latest version of the Android OS that is aimed at tablets. It has a lot of new goodies that will radically change the way we will design and develop applications, especially user interfaces.

After going through some articles and documents that were sourced from the Internet, I am compiling this blog post as an overview of the main UI changes introduced in the 3.0 API. And to see how this might help application developers like you and me write applications that could potentially (nobody knows for sure whether honeycomb will run on smartphones or not. But it seems to support smaller screen sizes as well. I am been optimistic here! ) run on smart phone and tablet devices. Even if this is possible it might not be a reality in the near future. As google is yet to announce any smartphones with the new branch of the OS.

Ouch! it seems that is not going to be true anytime soon: Google Says Honeycomb Will Not Come To Smartphones.

Honeycomb is the first release of the 3.x branch. Right now, Google seems to be reserving the 3.x branch for tablets and the 2.x branch for smartphones. As for the 2.x branch, Android 2.4 (Ice Cream) will be the next release. Given that maintaining two platform-specific versions of the OS doesn't seem like a long-term strategy, convergence will probably happen at some point in the future.

Fragments

This seems to be one of the most exciting new features of Honeycomb. The API documentation defines a Fragment as “...a piece of an application's user interface or behavior that can be placed in an Activity”. Fragments are basically small units or modules that can together make up an Activity. Perhaps the coolest thing is that you can change them dynamically at runtime!

Modularity is almost always good! (caveat: only if used with some common sense). You can create different layouts by mixing up Fragments. An Activity can be broken down into different regions and then designed separately. It also allows developers to create interfaces that let users choose among different layouts at runtime. Because Fragments can be added in or removed dynamically, this should be fairly easy to do.

Google has cited another use for Fragments: changing the layout of an application depending on the orientation of the screen. So you can create UIs that will make maximum use of screen space depending on the screen orientation. For example, if a given device has a lower resolution than a tablet, a developer can decide to use a Fragment (or a set of Fragments) that are designed to better fit a smaller screen size and resolution. Or, if the device that you are using has a larger, higher resolution screen, you can conditionally use a different set of Fragments or simply a different mix of Fragments to optimize the interface. I have not really tried using Fragments in a real world application, but I think they could be very helpful in making applications more adaptable to different device form factors and somewhat independent of hardware platforms. However, we should not expect this to be a perfect solution to make apps device and resolution independent, as it will involve many other considerations such as sizing and resolution of embedded image assets and other content types.

Back Stack

Fragments that are displayed one after another can be added to a stack by modifying the Fragment inside a transaction. This will help users go back to whatever Fragment they came from by using the standard back button. Such UI statefulness can greatly improve user experience.

ActionBar

One can argue that the space taken by the title bar is a waste on small handheld devices like tablets or smartphones. The action bar replaces the title bar and displays the title for a window while harbouring various other widgets, menus, and tool buttons.

Browsing through the API documentation for ActionBar, you can see some interesting classes and constants like ActionBar.Tab and NAVIGATION_MODE_LIST that suggest the ActionBar can be used for navigation and can contain embedded menus, buttons, and tabs. When used with methods such as setCustomView() to set a custom view to appear inside the ActionBar, this can be used to implement things like a search function for an eBook reader app.

A breakdown of some other highlights:

• Multi-select, clipboard, and drag-and-drop
• Richer notifications
• Live HTTP streaming
• New APIs for Bluetooth A2DP and HSP

• Hardware accelerated rendering
• New animation framework (new android.animation package)
• Hardware-accelerated OpenGL renderer for 2D graphics
• A new 3D rendering engine called Renderscript (new android.renderscript package)
• Ability to leverage multi-core processors
• DRM framework (new android.drm package)

Playing with the SDK
There is no substitute for playing with the SDK yourself. You can get it here. If you already have a previous version of an Android SDK installed, you can install Honeycomb via the Android SDK manager. Look for Android 'Honeycomb' Preview SDK along with the documentation bits. Have fun!

Sources

• Android 3 Highlights - Google
• First look: Honeycomb APIs power tablet-friendly Android apps - Ars Technica
• Google posts Android 3.0 Honeycomb SDK preview - intomobile