A preview of Android 3.0 (Honeycomb) has finally been released. Developers can download the new platform and updated SDK tools and play around with it before devices such as the Motorola Xoom hit the market in February.
First rumored at Google I/O 2010, and later demoed at CES, Honeycomb was designed from the ground up to support Android-based tablets. Does that mean it won't run on smartphones too? Is it a fork, as suggested by Steven J. Vaughn-Nichols? Not according to the man behind the overhaul, Matias Duarte.
You may remember Duarte as the designer of WebOS from his days at Palm. In an interview with Engadget earlier this month, he said:
What you see in Honeycomb is absolutely the direction for Android... We have to serve all of Android's needs. [For example,] If Android shows up on a car, you're going to see the same kinds of improvements, the same design philosophy, the same usability improvements, the same new paradigms, new tools, they're all going to be part of that.
Indeed, with relaxed minimum requirements on buttons and other features, Android 3 may ultimately find itself on more types of hardware than earlier versions did. And unlike previous versions, you can expect to see official Google-branded apps like GMail, Maps, and the Android Market approved for use on more of those devices.
Existing apps will work on Android 3, but the developer can take steps to make the user interface fit in with the new design. These steps range from a simple 5 minute tweak to a more significant redesign.
The first step is to update your AndroidManifest.xml file to add a line like this:
<uses-sdk android:minSdkVersion="7" android:targetSdkVersion="Honeycomb"/>
Specifying targetSdkVersion="Honeycomb" tells Android to use the new Holographic UI theme instead of the older defaults. Once the new version of Android is finalized and goes into production you will use "10" instead of "Honeycomb". Specifying minSdkVersion="7" indicates you can run on devices that have Android 2.1 and higher. Currently that's over 87% of all devices in the field. You can use a lower value if your app supports older versions.
Next, you can provide alternative layouts for tablet-sized screens. Android 2.3 and above supports the "xlarge" resource qualifier that is activated for tablets. Let's say you're writing a twitter application. On a phone you want the twitter stream to occupy the whole screen, but on a tablet you have room to show the stream side-by-side with embedded pictures or conversations or the list of people you follow. To do that, you would put one layout definition (an XML file) in the res/layout directory, and a different one in the res/layout-xlarge directory.
See: Hello, Android! for to learn more about supporting a variety of Android versions, screen resolutions, and API levels in your programs.
With the easy stuff out of the way, you can then use the new APIs in Android 3 to extend your app to take advantage of some of the new user interface paradigms. For example, you could use the brand new Fragment class to define reusable panes within your app, and you could use the new android.animation package for animating the properties of Fragments, Views, or anything else. There's also a new 3D framework called Renderscript that lets you build 3D scenes and write OpenGL shaders in a platform-independent language. Naturally, the more Honeycomb-specific eye candy you add to your app, the harder it will be for you to back-port it to earlier versions of Android. Be sure to test on all the platforms you support, and support only the platforms you test.
With careful design your programs can look fabulous on all Android versions, screen sizes, and form factors. So in that sense, Android 3 is an evolutionary release just like Android 1.6 or 2.0 was before it. However, the new tablet focus and APIs could enable new types of apps that we haven't seen on the platform before. You might choose to take advantage of this opportunity to create revolutionary apps that are optimized specifically for Android 3 on tablets. It's entirely up to you.