We use cookies on our websites. Information about cookies and how you can object to the use of cookies at any time or end their use can be found in our privacy policy.

3 min read 4 comments

Fragmentation for all! - more details on Honeycomb APIs

I'm always amazed the the level of humor with which Google presents itself to the public. Few, if any, companies that size would dare to openly jab at competitors and critics the way Google does and I quite like it. After operation 'honeypot' where Google busted Microsoft's chops for filling missing search results in from the Google's database, the new Fragments API that'll launch alongside Honeycomb 3.0 includes the above jab at Jobs & Co. that criticized Android for its fragmentation. Read past the break for more on what the API means for you and for the rumored phone version of Honeycomb.



The post on the Android Developer blog talks about the many ways in which Android has supported different display sizes and resolutions and how it will continue to do so. I'm not a developer, so most of the post does not make too much sense to me, but from what I gather, this is what we're looking at: as you've seen in some earlier videos about Honeycomb, it now displays apps according to context (based on resolution and screen orientation) to allow developers to build apps that make sense regardless of what and how you're holding.

Like some apps on the iPad, notably the email client, Honeycomb tablets will show multiple panes in landscape to allow for a comprehensive view of all navigation options and only selected items when rotated to portrait. Android goes one step further than Apple however: as you might know, the iPad can display iPhone apps, but when they're set to utilize the entire screen they're pixelated and don't scale. From what I can gather from the post it seems that this Fragments API is targeted both at optimizing the way tablets can display items, but also ensuring that phones will be able to use many of the tablet only apps by just displaying panes in succession instead of side by side. Google also makes the following statement that brings the rumor mill surrounding 3.0 for phones a little closer to the truth:

With Fragment only being available in Android 3.0, their shorter-term utility is greatly diminished.To address this, we plan to have the same fragment APIs (and the new LoaderManager as well) described here available as a static library for use with older versions of Android; we’re trying to go right back to 1.6.

I'm not sure how this will work on phones exactly, if it's a code workaround or an OTA update will be needed (in which case devices with 1.6 are probably never going to see any changes), but it's good to know that backwards compatibility for Android is not targeted at 2.2 and up or even 2.x only. I've said it before, when I reviewed the Viewsonic GTablet that any app I had on my phone scaled perfectly to the 2.5 times bigger diagonal and the 1024x600 resolution. So far, I can't quite say the same for Honeycomb on the Nook Color, but since I'm running a hacked pre-release version I will continue to assume full compatibility.

All this talk about all the new, cool features inside Honeycomb makes me want the full SDK to drop ASAP so I can play around with it (developer interest and skills permitting). Any developers care to shine some light on how they see the code portion implemented in earlier Android versions or apps they have developped ?

Pictures: Android Developer Blog


Write new comment:
All changes will be saved. No drafts are saved when editing

  • Fabien Roehlinger
    • Admin
    • Staff
    Feb 7, 2011 Link to comment

    Thanks for the clarification!

  • Don't mix it up! "Fragmentation" here means a new API feature, which enables better reuse of components, like in the example the list and the preview "fragments". For Smartphones, you first see the list and can open the preview by tapping. For tablets, both are visible side by side.
    It's a small but good extention to the "Widget" concept Android already had before. Where "Widget" doesn't only mean the ones on the Home screen (called "app widget" by Google) but any reusable UI control, from simple labels to date/time pickers to really complex ones.
    Now what Google promises, is a library developers can link to their app, so they can use this new API for any app compatible to devices using at least Android 1.6, making it easier to develop apps supporting both Smartphones and tablets.

    Android always had good ways to support different screen sizes and old versions, so Android version fragmentation only really matters if an app really requires new features (e.g. the improved media features in 2.3 or live wallpapers in 2.1) or the developer's too lazy too support old versions (or doesn't think it's worth the efford, esp. 1.5 compatibility can be a PITA)...
    However, I think Google should do something about it's updates. Not so much for "fragementation" but for bugfixes and securitiy issues.

  • Fabien Roehlinger
    • Admin
    • Staff
    Feb 7, 2011 Link to comment

    That sounds pretty interesting... Fragmentation is one the big obstacles for Android.

  • Since it will be a library, developers can add the fragment api to their app, without needing to update the whole os. Basically the update will come with the apps that choose to use it.

Recommended articles