Note to Readers: Saumitra is one of the newest members of our smartphone team. He has contributed to articles in the past but we'd like to formally welcome him to the AnandTech team. Saumitra will be focusing on everything Android and iOS. Welcome Saumitra!

The tablet market today is a far more interesting place than it was just over a year ago. Since the launch of the iPad, there hasn’t been a real competitor to iOS in the tablet space. We’ve seen customized versions of Android for larger devices like the Galaxy Tab, but they’ve all had their fair share of limitations. In fact, Android releases up to Gingerbread were never really designed to be used on larger screens. But Honeycomb has the potential to change all that and it could be just the catalyst manufacturers need to come up with the next iPad-killer.

It’s been public knowledge that Honeycomb (v3.0) was going to be the next major release of Android after Gingerbread (v2.3). It all started when Andy Rubin showed up at the D: Dive Into Mobile event with a mysterious looking tablet that was later revealed to be the Motorola Xoom running Honeycomb. CES gave us a sneak peek at Xoom and a host of other tablets that would run Honeycomb. At the Honeycomb launch event a few weeks back, Google gave us a full-blown preview of the OS. Now, with the Xoom releasing this month, the time has come for Google's official answer to the iPad.

Honeycomb has been designed ground-up for use on tablets. Google also confirmed that Honeycomb is a tablet-only OS for the time being and that some of the new features would eventually transition over to phone versions of the OS. That’s where the next release of Android codenamed Ice Cream comes into picture; more on that later. Honeycomb represents Google’s first effort to be a serious contender in the tablet market. Make no mistake here Honeycomb is an absolutely massive release with a smorgasbord of new user and developer features; some of which are so well implemented that they could give iOS a run for it’s money. Without further ado, let us dive into the juicy bits.

Home Screen

First up, you’re immediately greeted by new home screen. It’s slick, futuristic and predictably neon. Google calls this the holographic UI design based on a content focused interaction model. The new home screen has a very clean layout; there’s the new notifications bar on the bottom right, and three buttons on the left that let you go back, go home and use the new multitasking UI. On the top we have the Google search bar, applications drawer and the add button for adding shortcuts, widgets and other stuff to the home screen.

There are five home screens that you can swipe between; clicking the Add button displays a side-scrollable list of available widgets, applications and wallpapers in the lower half of the screen, and a preview of the five home screens in the upper half. The applications drawer shows a similar preview, but in the bottom half of the screen. Overall, the home screen in Honeycomb is laid out nicely and makes good use of the added real estate offered by tablet-sized screens. Its informative, unobtrusive and yet offers ample space for widgets and other items.

Notification Bar

Honeycomb moves the beloved Android notification bar into relative obscurity; tucked away in the bottom right corner of the screen. It displays only the bare essentials; the time, network connections and battery life when not actively in use. Once you click on the notifications bar, it pops out to show you a detailed system status and lets you access things like brightness, screen orientation, notifications and so on; much like the Power Control widget on Android phones. With Honeycomb, Google has overhauled the notification system by leaps and bounds. Notifications are now much more detailed and are very Growl-like. Notifications from apps like the Music Player show album art and let you control music right from the notification. The Google Talk app for example, shows display pictures and message previews. Notifications can therefore leverage the new UI framework in Honeycomb to include images and other elements to offer users more granular control over apps directly from the home screen.

Rich Widgets

Honeycomb adds support for new interactive widgets that display more than just static information. The new widgets UI is completely redesigned to take advantage of larger tablet screens. Apps like Gmail, YouTube or the Music Player can now use new widget forms like stacks, lists and grids and update them with real-time data. For example, the Gmail widget allows users to scroll through their mailbox and the YouTube widget shows previews of videos arranged in a continuously scrollable stack. The new widgets looked stunning with smooth UI animations and transition effects. Of course, that can be partly accredited to the fact that the Xoom runs some pretty solid hardware; lets just hope Google managed to deliver this performance even on lower-end devices.

Action Bar

Google defines the Action Bar as a widget that replaces the title bar at the top of any activity within an app. It displays contextual options and settings depending on the activity being performed in an app. For example, in the Gmail app, if you’ve selected message, the action bar changes to display options like mark as unread, trash, report spam, change labels or mark as starred. The action bar is tightly integrated into the OS for activities like cut-copy-paste; where pressing and holding initiates the “select” feature and options like cut, copy, paste or share can be accessed via the action bar.

For example, in the image below, the action bar shows the app icon and the activity title on the left and useful items from the options menu as icons on the right. Any other options can be accessed via the Overflow Menu on the extreme right.

Each element that appears in the Action Bar is called an action item and has its own logo. The app icon can be used to navigate home or move up through the activity. The Overflow Menu can also be customized with icons for items not appearing on the Action Bar. The Action Bar also allows moving back and forth through fragments with action tabs. Action tabs, for example, are used extensively in the Mail app and are very useful to navigate directly to specific parts of an app. Action tabs greatly simplify navigation in Honeycomb as compared to iOS, where in most cases, you must sequentially move up the hierarchy of screens to get to the first screen.

Fragments

Fragments is another addition to Honeycomb’s API to let developers create more flexible UI designs for tablet-sized screens. The larger screens make it easier to combine or interchangeably use UI components. Fragments lets developers decompose an activity into multiple fragments. For example, imagine using the Pulse app on a phone and a tablet. On the phone, owing to the limited screen size, viewing a list of articles is one activity, and reading an article is another activity. With fragments, you can combine this into one activity where one fragment shows the list of articles, and the other fragment shows the selected article. Thereafter, each fragment has its own set of callback methods and user input events. A fragment is basically a modular, reusable component with its own layout and behavior that lets it adapt to different screen sizes. In cases where this is not possible, developers can launch separate activities with independent fragments.

Multitasking

Honeycomb builds on Android’s existing multitasking support with a fresh new UI. The multitasking interface slides in from the left of the screen and populates itself as a list that shows recently used and currently running apps with the app icon and a static image of the app’s last saved state. Again, the UI is extremely clean and should work well on tablets.

Application & Under the Hood Updates
POST A COMMENT

65 Comments

View All Comments

  • koss - Monday, February 21, 2011 - link

    Interesting to see where google is going here. I don't know if it is just me or it really looks and borrows a lot from Windows. Fact is after so many releases there are things in windows (since probably 95) that just do not need to be changed or completely redesigned. They are optimized, yes, but nothing new really.
    I think this one will rock Apple's world and be a gamechanger in the tablet world. If only battery can go for > 24h somehow things are getting better in the tablet world.
    BTW after Tegra2 will there be support for the other SOCs and when?

    Cheers
    Reply
  • Tros - Monday, February 21, 2011 - link

    I doubt Google+* could beat Apple for battery life. Apple is fighting this problem on two fronts:

    Programming in iOS has a base design-philosophy of conserving power. There's no garbage collection in iOS, and almost all actions are event-driven. Plus, Apple is still researching in how to extend lithium-ion battery lifetime through different charging methods.

    This is a strong contrast to Google, who is relying on other companies to fix the analog-portion, and the Android-platform, where performance is desired over efficiency (say, moving garbage collection to the second core).

    I have to wonder who will win. The people trying to go for the laptop-holy-grail of interfacing with technology, or the people who disregard that.
    Reply
  • InternetGeek - Monday, February 21, 2011 - link

    So you are saying Apple has figured out an efficient way of using object-oriented design and development without using garbage collection. In other words, developers have to marshal their own resources. Must be a nightmare to program in objective-c. Reply
  • InternetGeek - Monday, February 21, 2011 - link

    Just read objective-c does have a garbage collection based on reference counting. Reply
  • michael2k - Tuesday, February 22, 2011 - link

    Yes, but how is marshalling resources a new thing?

    Even if it is a "nightmare", it's still profitable. No different than programming for any console, handheld, or computer up until the last 5 years.
    Reply
  • InternetGeek - Wednesday, February 23, 2011 - link

    I'm not sure what you mean and I'm not saying its bad by itself. PS3 programming is a nightmare because devs have to perform their own CPU scheduling. It seems Apple wants people to spend resources marshalling their own resources. Having to do that makes teams less productive. Thankfully Apple came to their senses and allowed binary compatibility. Reply
  • kmmatney - Monday, February 21, 2011 - link

    I have an iPhone 3GS and my wife has an Android 2.2 (Froyo) based LG Optimus V. Both phones have the same basic specs with a 600 MHz cpu. I just bought here phone a few weeks ago, and mine is about 1.5 years old. I have to say I was surprised at how "choppy" her phone feels. The all-around UI is not nearly as smooth as my old iPhone, and even games like angry birds stutter a little bit. The battery life is also not nearly as good. Her phone is supposed to get an update to Gingerbread 2.3 in a few months, and I hope that makes things smoother.

    My initial impression is that Android needs better hardware to achieve the same smoothness as iOS. It also uses more battery power, even while not being nearly as smooth in the UI. I appreciate the freedom you get with Android, but I still think it needs more improvement.
    Reply
  • koss - Monday, February 21, 2011 - link

    True, Apple set the bar. But I think you are underestimating google a bit here. Look at their development curve and look at apple's(considering their tablet/phone upgrade strategy exceeds other products). Apple started where no one could come even close, now we are talking of some programming advantages. Mostly coming from the tighter structure of their platform.

    Multicore cpu+ efficient usage can compensate for sheer computing volume... no? Besides we are talking about at least 4 Socs and different optimizations from companies like samsung, nvidia and LG, not powercolor or club3d. I am not so confident apple can best the whole group.
    Reply
  • Dex1701 - Monday, February 21, 2011 - link

    Interesting. Is it possible that there is something wrong with your wife's device? My girlfriend has an iPhone 3GS and an iPhone 4. I will say that Apple does seem to go out of their way to make the general UI transition effects and such look nice. This is something I couldn't care less about, but it is aesthetically pleasing. The iPhone 4 is no exception.

    However, as far as overall performance my Galaxy S device with an EXT4 file system conversion feels much faster and has better battery life than a 3GS by far...even with a faster CPU and the same size battery. Granted, the CPU is faster than that of the Optimus V, but it's roughly the same as that of the iPhone 4, and side-by-side the Galaxy S "feels" just as fast. In fact, in games the Galaxy S is performing better than the iPhone 4 for the most part, although this can vary depending on how well optimized the software is for the particular set of hardware.

    From what I've been seeing, Gingerbread has some rather large improvements in overall UI "smoothness" as well. I think I disagree with your assessment that Android requires better hardware to achieve the same results, though. My device "feels" just as snappy as my GF's iPhone 4, benchmarks just as well, and is running 5 screens worth of widgets in the background while iOS's core UI is just an app drawer and notifications. Is it possible that your wife's Optimus is bogged-down by a lot of bloatware?
    Reply
  • Stas - Monday, February 21, 2011 - link

    iOS has GPU accelerated UI. Android does everything on CPU. That's why the interface and transitions feel smoother on iPhone, yet when it comes to actual performance tests - it doesn't impress. Only some Android phones have dedicated GPUs, so while creating new UI engine, the developers would still have to keep and improve the old one for the less fortunate phones. Which kind of ticks me off. My Motorola Droid is capable of producing much smoother transitions that don't affect battery life so much, if given the proper software (because it has a very good GPU). Yet I see better transitions on cheap new phones with faster CPUs but worthless or non-existing GPUs, only due to how Andoid developers' prioritize feature implementation :( Reply

Log in

Don't have an account? Sign up now