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