The Strange Case of Dr. Action and Mr. Bar

Lately, I've been trying to finally update the behavior of the ObjectForms Demo application on the Honeycomb tablet and one of the missing pieces was support for the ActionBar, the new feature of Honeycomb. Well, not that so new feature. ActionBar was promoted by Google engineers (such as this one) even before Honeycomb was published.



As many other app developers, ObjectForms tried to be a good Android citizen and followed the Google provided advice, so there is a custom implementation of the ActionBar related functionality for a quite some time and I thought since I crafted my interface to look similar to actual Honeycomb API so I thought this will be piece of cake.

With some awkward reflection and dynamic invocation code (I wanted the same codebase to work on pre-Honeycomb as well) I was set to go. To my surprise, I the ActionBar was not showing up on the Motorola Xoom device no matter how hard I tried. The ActionBar was not there and this call :

public ActionBar getActionBar() of the class Activity (see the API)

was returning no value.

Neither ActionBar documentation nor the ActionBar developer Guide gave any relevant answers. I learned some interesting aspects about the ActionBar design.

First, documentation says that if the ActionBar is visible or not, is controlled by the changes of (!!!!) visual theme ! WOW, that's example of very bad engineering. Sure I did try to apply the correct theme, but it made no difference.

Second thing that I found very unusual was the fact that ActionBar, although very visual component itself, able to contain other visual components (tabs, custom components etc.) is not part of the visual hierarchy and is not descendant of View class, but rather just plain Object. It made no sense to me.

I was ready to find some workaround. Let's keep my original, custom ActionBar, and just put the button that would show the menu - once you declare in the Android manifest that you target Honeycomb device the "compatibility" menu (located in the bar on the bottom of the screen, next to the "Back" and "Home" buttons) is gone and you can only access it from the ActionBar (in the top right corner). But to my great surprise, the method :

public void openOptionsMenu() of class Activity (see the API)

was doing nothing, although it worked perfectly well on the Gingerbread and earlier Android devices. Hm.

Typically, I would explore the Android source code to see what might be the reason for that unusual behavior, but Honeycomb is not quite open source ;-( so I was out of luck there. Seems I hit the wall.

The next effort was to understand what the hell this visual theme actually does to hide the ActionBar. Problem was, that content of the theme is not public either. But trying to search for any clues, I got to this page that helped me to solve the entire mystery. Yeah, title might be that important attribute. As I had my own implementation of ActionBar on the top, I wanted to maximize the available space and asked the window manager to hide a title for me. With single line of code commented out :

if(android.os.Build.VERSION.SDK_INT < 11) {
    requestWindowFeature(Window.FEATURE_NO_TITLE);
}

And the magic is gone and Honeycomb ActionBar is there. It is really just a glorified title bar, so it must be visible in Honeycomb to behave correctly. This little fact is mentioned in the Android Honeycomb documentation, so this is my first take-away for people trying to cope with the same problem :

Make sure that title of window is visible if you want to show the Honeycomb ActionBar !

Since I believe most developers face the similar scenario I had, they have their own implementation of the ActionBar for Gingerbread and as the result they had a window without the title, the solution Google has for the Honeycomb is extremely unintuitive. Glad I found a solution.

Not only this, but to my surprise I found that openOptionsMenu() started to work as well. That's amazing !



But I was still not done. As you can see from the picture above, the first version had both native Honeycomb ActionBar and the custom Gingerbread one.
I wanted to reorganize my code to be more reusable and in middle of this I realized the ActionBar is gone again, the getActionBar() is returning nothing again. But I was able to track my changes, so it didn't take long to figure out what is problem this time. I tried to create my visual hierarchy first and expected that getActionBar() will tell me if I have native HoneyComb ActionBar or not. But this method is useless, as it assumes setContentView(view) has already been called. Since I was just constructing that view, this was not the case. Of course, this is another quite important aspect never mentioned in the documentation.

Hey Google, if your code requires the contract, and you are not able to enforce it by API design, please do us a favor and let us know about the contract !

So this is my second take-away as the case gets some clarification :

Make sure the setContentView(view) has been already called for your Activity, otherwise getActionBar() will return null.

Just to make the story complete, I wanted to have the look of the native ActionBar to be similar to previous version, and wanted to replace the logo with one that doesn't look as been a part of the button. I was not shocked to learn that customization is possible only in form of replacing the XML attribute "logo" with a custom value, and there is no corresponding Java API for that. It is still not clear to me why ActionBar is not descendant of View and why it is so difficult to deal with it, but apart of that, all the mystery has been solved.



As you can see, I decided to solve this customization problem by hiding the native ActionBar and rely on the fact that menu button in the top right corner works as expected. In this context, perhaps you'd think that I could save a lot of hassle and skip the ActionBar completely. There is one important aspect, which is the third and final take-away from this post :

If you target Honeycomb in the manifest, you need native ActionBar to be at least hidden, otherwise there is no way to show the option menus.

Hope you find the information mentioned in this post useful and hopefully they can save you some head-scratching time I had recently.

Android vs. iOS Battery-related Myths

Apple just recently introduced the new version of its mobile operating system, iOS 5. Among many enhancements that were announced, the ones that caused the most attention are definitely the new notification system and introduction of more powerful (and more complex) lock screen. Especially the notification centre resembles the system used by Android for several years (some call it a blatant rip-off) and lock screen is now also closer to what can be found on many other "smartphones".

These new features fueled somewhat dying discussions about possible introduction of still-missing "widgets" to enhance spartan Springboard home screen of iOS and the evergreen debate concerning the differences of implementation of the multitasking and the its availability for the third party developers.
The old demon of presumed better energy efficiency of the iOS implementation got a sprinkle of the fresh water and it become a popular argument of the iOS supporters once again, so perhaps it is good time to have a closer look at many myths that surround the multitasking implementation in the respective operating systems.

Widgets on iOS are definitely possible, if you don't mind jailbreak

Let's kick-off with the facts. Both iOS and Android are (relatively) modern OS, based on strong, battle tested cores (BSD Unix in the iOS case, mobile optimized Linux version for Android) running on modern, powerful hardware, that makes any form of multitasking perfectly possible. Both OS are built around multitasking and it is used by the System software.

Both systems are heavily optimized for the mobile usage. Not only the power consumption is of a big importance, there is strong focus on availability of the system resources in case of urgent need : if there is a immediate demand for the uninterrupted processor power, such as in the case of the incoming call (which is top priority to be handled without interference from whatever tasks that may be keeping the CPU busy). Both systems are very able in that regard and the entire OS metaphor is build around idea that app might exit expeditiously - in both cases there are very few states, there are no dialogs that expect the user to explicitly confirm to complete the current action, there is no "Quit" command in the menu etc.

Android engineers spent quite a lot of time optimizing the platform for the power consumption

iOS metaphor was initially designed to be very simple. There was no sense of multitasking at all, this was only introduced later, and in quite a limited form for the third party software running on iOS. Apple hype machine tried to sell this as paramount feature as being super power efficient. Developers are irresponsible idiots, the system needs to make sure no resources are wasted so only a very special, limited form of background activity is permitted for third party, was iOS mantra and at the same time Apple tried to depict their rival as total battery hog driven by many apps that all arrogantly eat precious juice of the pesky green bot machines even if there is no real need to do so. We are so much better designed system, was the conclusion of iOS supporters.

Wait...it is not that apps on Android live happily in the background and all they do is ruin the battery life. As mentioned earlier, both platforms apps are designed to be ready to die at any given moment. That moment usually comes right when the user navigates away from the given application to another one. It is usually suspended, or straight killed. The happy live in the backyard bush is only granted to special code on Android too, known as services. There are rules for them too and service is not automatically granted unlimited resource access. However Android gives developers more freedom to suck the battery, based on idea that perhaps there are situations where user really wants to use apps that do some intensive tasks in the background for a limited period of time and are OK with the reduced battery life. If they fathom that their device run on single charge is too short, Android gives them ways to track the offending piece of code quickly and take action (uninstalling, one-starring, even mailing the developer until order is restored).

Android service lifecycle

But that "we are more efficient" illusion of iOS is not something its fans want to cede easy. The stronghold argument of the power consumption superiority remains the home screen and widgets. New lock screen of iOS 5 might be seen as precursor of third party widgets coming soon. "Never, widgets are just catastrophe, ever updating on the background". This is just another myth. Lets have a look at the following :

How Android can be more power efficient, despite widgets and more relaxed rules for services ?

"Impossible, we are the best" is the short answer from the iOS camp. Well perhaps not really. Let's go for more arguments. "iOS is build around notifications, your application get will start once there are new data for it, no need to poll the server. iOS rocks !"

This is true. It is also true that very same system is available on the Android too, no need to poll the server either. But wait, there is actually more. Android is build about idea of small pieces of code, Activites, that constantly share information through the mechanism called Intents. OS provide a wide array of such data on its own, through system called Event Broadcast.

"Ha ! Another battery life trap ! Android developers constantly run some code, while the iOS is quietly conserving power". Well not quite like that. Sure, if you execute some code in Broadcast filter, this means extra consumption, but this code is super light. On the other hand, it gives the developer information, that is not available to third party software on iOS and must be obtained by - guess what - polling. If your application wants to do something special if some event just happened, it can, just running that little snippet of code. Say there is some other application trying to get the latest GPS location - listen for this type of event and your application can get the the most accurate location info for free. Another example : your application needs to send some stuff to the server. Again, if time of delivery is not that critical, wait for some other application to establish the network connection (which is expensive operation in terms of battery life) and take opportunity to bundle some data while radio is on. This is how a lot of battery life can be saved.

Android battery profiler reveals most juice is lost thanks to display. If you want to save power, don't use the damn device !

The best proof this is a viable concept is the fact that Apple is introducing similar concept in the latest iterations of iOS and developers can register at the NSNotificationCenter, however it is still quite limited in comparison to Android system-wide mechanism.

We, developers at Perpetum Design are super serious about the quality of our apps, and the impact the application has on the battery life of the device is an integral part of our design decisions. There were multiple cases when we were able to convince our customers to tackle the problem differently just because of the battery life concerns.

We believe most of developers think that way, thus more flexibility you have as the developer, the better for the entire ecosystem. Fortunately, the OS vendors seems to understand this too, and iOS and Android are looking more and more similar in that regard.

Hope this article helped to get light on some of those myths that surround differences between mobile platforms and their battery life related architecture and performance.

Android spotted in the Apple AppStore

Not just ordinary Android, but SuperAndroid. Thought this word is complete tabu there. Wrong

Honeycomb Live Wallpaper Icon mystery

Trying to create a correct icon for a live wallpaper now. To my great surprise, this is not really documented anywhere, thus I assumed the default 96 x 96 pixels icon will do just fine (after all, this is the size of the icon for the example live wallpaper project shipped with Android SDK. Everything seems to be just fine on the phone (including Gingerbread), although I noticed that other icons tends to be just rectangular "screenshots" instead of icons - again this is nowhere documented.Just did a quick test on the Xoom tablet, and to my another surprise, the icon looks completely ugly. Honeycomb seems to use 208 x 192 as the size of the icon (or rather thumbnail) which explains why the 96x96 icon looks so ugly (see the picture) :

Hope we'll get the updated documentation soon and this guess work will be a thing of the past.

Any comments on this topic are very welcome.

What is HTC brewing ?

Interested to see what will come out of today's HTC event in London. Can't wait, in fact. They do some pretty interesting mobile hardware lately.

Even more interesting (at least for me) was to see the invitation for this event. See the original HTC artwork :

And compare it with a slide from my recent talk at the Droidcon conference in Berlin in March :

Can you spot 7 differences ? My talk was just days before HTC sent out the invitation, any chance they were in my audience ;-) ?

Giving the similarities in our approach to design, it is very likely ObjectForms will run just fine on the latest HTC toys, assuming they release something new with Android onboard.

GWT Code Generators

Planning to do a future version(s) of ObjectForms, based on Google Widget Toolkit, that will have the same API as the Android version that is to be published soon.

For that to happen, GWT needs to have ability to use more complete reflection available on the client (since the UI is created on the client at the runtime). Right now, the prototype is using great library from Robert "Kerberos" Cooper, the Gwittir, which has some support for runtime reflection, but it is far from complete. Most notably, the reflection of Annotations is missing completely.

I thought that Google GWT team is going to add those features to the core GWT one day, but it seems this is not on their to-do list at all, so we'd need to write the Annotation reflection support by ourselves.

Looking for someone who might be interested to do the same thing, we can join the forces perhaps ?

There might be a future Czech Hackathon Group session devoted to this, if we can get enough interested participants.

Here is the (ever expanding) list of pointers to documentation, tutorials and related articles :

Gwittir introspection : http://code.google.com/p/gwittir/wiki/Introspection

Generator abstraction in Rocket GWT library : http://code.google.com/p/rocket-gwt/wiki/Generator

(former) Lombardi Generator experiments blog : http://jectbd.com/?p=48

Random notes from Droidcon in Berlin

Glad to be able to visit Droidcon in Berlin last week and had a chance to talk about Effective programming for Android and the ObjectForms framework for Android that I am busy at getting ready for the public release. Thanks everybody for coming, it was great to see the auditorium packed and even better to get so many positive feedback and questions. Can't wait for ObjectForms to get released and that date is near.

I had a chance to attend a couple of other presentations, and more importantly, meet and talk to bunch of interesting people during the conference. Here are my observations and notes, in no particular order :

• the quality of talks was very fluctuating. Some of them were absolute gems, at some I just said "I want my half-hour back". More on this later
• Motorola Xoom looks pretty impressive, but it is no "iPad killer". Honeycomb doesn't look too intuitive, even to the Android user. New "holo" theme is a mess.
• Speaking of Xoom, Motorola scheduled two developer events in April (Berlin & London). Hope Xoom is available by then. It is a real shame that manufacturers can't do a global launch.
• There was a bunch of companies offering alternative app markets or payment options. Most of them had hard time to explain why ordinary developer should bother. 
• Lots of companies were hunting for developers. It is great time to be a mobile developer in 2011.
• Plenty of various Android devices popping up. My apps work pretty good on all that I had chance to test. No fragmentation issues whatsoever, but thanks for asking, Mr. Jobs.
• The most impressive device for me was LG Optimus 3D. While I am a big fan of emerging 3D technologies so this is not that much of surprise, the main reason I like the the new LG phone and think it can be truly a breakthrough device is not the ability to see (very narrow) 3D picture on the screen or taking stereoscopic pictures. But it is still the dual lens camera, what makes the phone so interesting. It gives Optimus a new kind of sensor, which is able to analyze the depth information. The device is powerful enough to handle the computations needed to do to analyze the video stream and get the depth info out. The example of poking the AR monster by a finger and its fighting back was super impressive and this was a top moment of entire show for me. 
• From that perspective, hope that recent rumors that LG is making the "Nexus Tablet" i.e. reference HW implementation holds true. That would be awesome, I am definitely getting one of those babies.
• SE Xperia with integrated PSP and HW controls looks nice too. How many see it as a benchwarmer until the NGP is out, i.e. same way I do ?
• Another presentation I liked a lot was Michael Straeubig's intro to Droid.AR library (filling for author Simon Heinen). I see a lot of synergy with what I was doing in my previous projects and hope to pick this up soon.
• Erik Hellman's talk was interesting indeed, many fascinating aspects covered. It is not completely clear what is SE's motivation behind many ideas he presented, though.
• Sparky Rhode's Honeycomb presentation was the absolute low of the entire event. Basically just a (not very well organized) walkthrough of the Xoom connected to the projector. Developers expect to get more information, not a bunch of plastic robot toys thrown into audience. Still rubbing my eyes in disbelief this came out of Google employee. 
• Speaking of disappointment, I noticed I am not the only one who is not happy with the state of the Android API and the documentation quality. There was a bar-camp session devoted to problems of the documentation and an ad-hoc initiative to create a site with more quality examples, as you can see the beginners sites flooded with errors copied from the official docs. 
• I moderated another bar-camp session, devoted to people experiences with data storage. Seems everybody is resigned to live with plain SQL Lite, although nobody really liked this prospect. But there was no interest in simpler options, such as direct persistence of objects, or reusing JSON to store data etc. Interesting discovery to me.