You know you are working with a generous and well thought out system when there are moments you think the API designers are reading your mind. One of the greatest complements to an API designer’s foresight!

While working on a relatively dynamic layout for an Android app I’m developing, I came across a simple problem with RelatieveLayout. A certain View within the layout must always be aligned with another View … almost always. There will be times when this anchor view might be gone. Without manipulating the layout in code, that is only using the layout XML, how do we tell the layout manager where to align things if this anchor View might be missing? Wouldn’t it be nice if it just knew to fall back on using the parent ViewGroup as the alignment guideline? Well, Android API engineers thought that it would be nice as well: android:alignWithParentIfMissing. Sometimes I’m glad my problems are not as unique. More info here.

A friend of mine recently sent me an insightful animate of a talk about an MIT social experiment where somewhat surprising results were seen. The study showed that higher monetary rewards can usually lead to a decrease in performance if money is the ONLY reward employees get for their work. It explains that money is a great incentive in repetitive mechanical tasks but when tasks require greater cognitive abilities and creativity, autonomy, mastery and purpose were far more important.

I say this is “somewhat” surprising to me not because I didn’t expect these results but rather that these results were finally found in a controlled scientific study. I had seen the behavioral patterns illustrated in the talk in myself as well as some colleagues. Being financially compensated fairly for our work is necessary but not sufficient. Looking back at my career so far, I’ve spent a lot of time doing extra “work” after work hours totally unrelated to my real job simply for the enjoyment of it. I have read and taught myself different aspects of technology not because it will eventually help me get a raise or obtain a better position but because I simply enjoy it like one might enjoy playing a musical instrument. This gives me some purpose and reaffirms the love I have for this profession even after sometimes stressful days. I am definitely not the only one who feels the same way. It is then not surprising to me that this same behavior can be seen in a more general context.

The countless complaints on this entry over at slashdot speak about the complete disaster that is Ubuntu’s Unity and to a lesser extend, the new Gnome 3. I recently had to upgrade my system’s video card and in order to use my new piece of hardware fully, I was forced to upgrade Ubuntu. After the upgrade I was “greeted” to what I consider one of the most frustrating usability experiences I have gone through. From the hidden running tasks list, to the hidden static launcher bar, to the idiotic way it places the application’s menu bar at the top of your screen, the new Ubuntu UI is a disaster. I shouldn’t have to guess or work extra hard just to switch to a different window. This is my desktop not a smartphone, stop trying to save screen space with tricks that are counter-productive in this context. I usually welcome change as long as there is a purpose. However, change for the sake of change while degrading the user experience is not welcomed!

Luckily there are still options and I was able to switch to Gnome 3. It is a big change from Gnome 2 and very far from perfect but so far it’s “acceptable”.

If Ubuntu continues down this road I will sadly need to start looking at alternatives. My desktop should not be getting on the way of me getting work done.

Android development can be a lot of fun but it can also be frustrating at times, specially with the many small gotchas that the framework and documentation have. As I work on a personal project for the Android platform, I will post some thoughts and tips about my adventures in the platform. Hopefully it will help someone or people out there can point out better solutions!

Using the app icon as an action item

For those of us targeting Honeycomb (or working with compatibility libraries) , one of the cool features we have at our disposal is the ActionBar. One of the standard elements of the ActionBar is the app icon presented on the top let corner of the application. This icon is supposed to act as a button that allows the user to go to the home Activity from anywhere in the application. According to the documentation, the following piece of code should be the standard way of having a the activity handle the selection of the app icon:@Override
public boolean onOptionsItemSelected(MenuItem item) {
switch (item.getItemId()) {
case android.R.id.home:
// app icon in Action Bar clicked; go home
Intent intent = new Intent(this, HomeActivity.class);
intent.addFlags(Intent.FLAG_ACTIVITY_CLEAR_TOP);
startActivity(intent);
return true;
default:
return super.onOptionsItemSelected(item);
}
}

Of interest is the intent Intent.FLAG_ACTIVITY_CLEAR_TOP flag. According to the documentation:

If you respond to the application icon by returning to the home activity, you should include the FLAG_ACTIVITY_CLEAR_TOP flag in the Intent. With this flag, if the activity you’re starting already exists in the current task, then all activities on top of it are destroyed and it is brought to the front. You should favor this approach, because going “home” is an action that’s equivalent to “going back” and you should usually not create a new instance of the home activity. Otherwise, you might end up with a long stack of activities in the current task.

What the documentation fails to mention, is that under default conditions, this approach alone will have the framework re-create your home Activity. Let’s say HomeActivity starts ActivityB, the activity stack should look like: HomeActivity, ActivityB. If ActivityB now handles the app icon with the code above, it will tell the system to destroy the activities on top of it. Unfortunately, in this case, the target HomeActivity itself will also be destroyed and its onCreate() will be called again. This is something not entirely clear if you are only reading the ActionBar fundamentals.

FLAG_ACTIVITY_CLEAR_TOP’s documentation is a bit more clear on this point:

For example, consider a task consisting of the activities: A, B, C, D. If D calls startActivity() with an Intent that resolves to the component of activity B, then C and D will be finished and B receive the given Intent, resulting in the stack now being: A, B.

The currently running instance of activity B in the above example will either receive the new intent you are starting here in its onNewIntent() method, or be itself finished and restarted with the new intent. If it has declared its launch mode to be “multiple” (the default) and you have not set FLAG_ACTIVITY_SINGLE_TOP in the same intent, then it will be finished and re-created; for all other launch modes or if FLAG_ACTIVITY_SINGLE_TOP is set then this Intent will be delivered to the current instance’s onNewIntent().

Tomorrow, the end of a beautiful month comes to an end in the most romantic of ways possible. Two of the best qualified teams in the world play against each other. It was only fair. Numbers are not the only guests invited to this party though. Both of their styles are rooted in the same philosophy of Total football. Anyone can play any position, possession is fundamental and the sudden masterfully choreographed attack is the reward. Spain’s eight Barcelona players, and some of them core of La Roja, were brought up in the Cruyff football school. Netherlands’ current team still shows signs of that beautiful commanding style. It should be a final for the ages, we will once again have a new champion. No matter what happens, Johan, one of football greatest might finally get to smile and be content with the outcome. Let the best students win

Before this rant^H^H^H^Hblog entry, I would like to say that I have been an Open Source supporter for a very long time and I am committed to using/developing for the Android platform. I truly believe that consumers, and the mobile industry in general, can benefit greatly from this model. Having said that, it is not always so rosy.

One thing you have to give credit to Apple is consistency. Consistency in the way they design their products, and in the way they control the customer experience. At times this control is the source of much criticism from people (including myself) who prefer to use and develop technology under an open environment. However, this centralized mandate of how the technology is to be used does have its benefits. One of these benefits is the way software updates arrives to the customers’ devices.

In the age of the iPhone, the PS3, the Wii, etc.; we, as consumers, have become accustomed to manufacturers or software authors providing us with software upgrades without major hassle through our network-capable hardware. We have taken the complexity and costs associated with those upgrades for granted. Naturally, this arrangement becomes more complex the more members are involved in the product’s “eco-system” and, even more complex, when that product runs under different hardware configurations or in the case of mobiles, it is carried by different services. This is the case of Android, where unlike Apple’s iPhone, it runs under a plethora of hardware configurations and is serviced by many carriers. In this setup, each manufacturer and carrier has the choice of distributing their own version of Android to meet their needs and those of their customers. It all seems like a beautiful eco-system where; developers, manufacturers, and carriers are customizing while sharing technology for The Greater Good ™. As I have recently learned, this is true until someone needs to upgrade the software and support that new upgraded version. Who exactly should be providing the upgrades to users and do all the work associated with an upgrade? Should Google? Should the manufacturer? Should the carrier? Should the user do it himself? It seems to me some of these questions were not answered fully before Android was haled as the healer for all mobile industry pains. Or if they were answered, someone is not pulling their weight.

In order to illustrate this point, let’s look at a recent development in Canada, where HTC and Rogers Wireless have officially decided not to upgrade their customers’ HTC Android devices (I’d be curious to know what will happen to the LG Eve). One of HTC’s argument is that 1.5 is stable enough and “delivers a terrific user experience”. The HTC Magic and Dream were released in June of 2009 in Canada running version 1.5 of the Android OS. Since then, 1.6 and 2.0 have been released, with 2.1 being rumored to be out on devices soon. When we consider that the number of applications that support 1.6+ will only increase and that popular application such as Google’s own Google Goggles, and Google Navigation will only work on recent releases of the OS, it is easy see how many Canadian usersare now consideringtheir devices obsolete. Some such as my self might be inclined enough to root the device and install the update ourselves, but not only does it require time, it also has the potential of voiding the device’s warranty. How about going to a different carrier? Not likely given the 3-year contracts we are chained to. It is naive to think that the majority of users will go that route, never mind the fact that Android’s model was supposed to make the need for hacks like that unnecessary. Not many are happy.

Why is HTC releasing phones that can’t be upgraded? Why is Rogers selling them? The exact reasons as to why HTC/Rogers decided to go against the norm in this context and not provide software upgrades, are cloudy at the moment and is very important to note that information on the subject is very fragmented (PR on both ends are working extra time). On one hand, Rogers blames HTC for not wanting to provide upgrades for non-“Google Experience”-Android phones (ie. Rogers’ HTC Magic, HTC Dream, etc). On the other hand, HTC blames Rogers for not asking for the update. Customers looking into the issue are still not sure who is telling the truth or what is accurate. It has become quite the hot potato game between HTC and Rogers. Regardless of the reasons, the harmonious open eco-system proposed by the Open Handset Alliance, where “Each member of the Open Handset Alliance [where HTC is one of them] is strongly committed to greater openness in the mobile ecosystem” is not only harmed by the lack of software upgrades itself but also by the lack of accurate open information.

There isn’t conclusive information as to the reason of the Rogers/HTC debacle yet so we can only stipulate and wait. My guess is that due to carriers being allowed to customize ROM installed on the devices they sell, it makes it much harder (ie. costly) to test, deploy and support any major upgrades. Is that respect then, is the Android model too open for its own good? Or is the problem that it isn’t open enough? Would it help users know about the intricacies of the support and development agreements between carriers and manufacturers in order to make better purchasing decisions? Do we need openness beyond the source code in the way of disclosure of agreements between carriers and manufactures in hopes of shining a light on these will keep them honest? Listen, if you decided to customize the ROM to include your “<Insert-Carrier-Name-Here> Homepage” icon, I think you should be footing the bill for upgrades to support your customers. I would like to know who to blame, that information should be open no? I’m probably dreaming. I can’t help to think that it could very well be that the mobile industry is just not mature enough for this form of cooperation when it comes to technology development. I can’t help to think that they still can’t see beyond their quarterly profits….but that’s just my opinion.

As I looked at this entangled mess these past few days, I became suspiciously intrigued by the familiarity of it all. I realized that in a way, Android’s model is not entirely new. That same similar model somewhat works in other areas of technology development. If we look at how Linux distributions work in the desktop/servers world, we see a similar approach. Similar to the Android project, where code updates are centralized, kernel updates are done and approved by one central cluster of people and organizations. Also similarly, organizations such as Canonical, RedHat, and Novell then take those updates and push them onto their customized Linux versions in the form of Linux distributions. Users then choose one of the many Linux distributions according to their specific needs. The key part here is that, at all points, all players of the Linux desktop eco-system take responsibility in doing their part in order to accomplish the success of the product. It is worth noting that I say it “somewhat” works because it never comes out perfect – I still have to deal with proprietary driver issues, fun with back-ports, bugs bouncing back and forth between projects, etc., but the model does work for the most part. In the Android world however, some parties are still immature enough to pass the buck in who should get the work done. At this time, the problem in the model being followed by Android appears to be the two uncooperative nodes that exist on the line going from the Android project to the costumer. These two nodes being the manufacturer and the carrier. One could argue the two models have different economic needs, and therefore different incentives for getting the work done (and footing the bill) exist, but regardless of those aspects, wouldn’t the long-term health of the eco-system benefit all parties in the long run? Wouldn’t all parties want to make sure that the eco-system remains strong and growing to benefit from it economically in the long-term? I’m not sure some organizations see it that way.

It is still very early to tell if Android’s model will succeed or not. It definitely sounds great on paper to me, and it has made some great progress in general but the drama going on in Canada with Rogers and HTC has definitely splashed a little sense of reality on my enthusiastic view. I *really* *really* *really* hope for the sake of the project that one of the players; be it Google, or the Open Headset Alliance, are taking note of this, hopefully small, obstacle and have started to correct the errors.

By the way, whatever happened to paid apps in Android’s Market place for Canadians? .. I guess that’s a whole other mess.

Update 1: RogersMaryhas posted an update on the android forums letting people know that Rogers and HTC are working towards resolving this issue. I’m still confused as to how an upgrade road-map was not planned when the “Revolution” started.

You know computers run your life when you are sending a message to a friend and catch yourself adding a space between the last word of the sentence and the period. No, it wasn’t a mistake or simple ignorance on how to use a period properly. Somewhere in my head, I feared that sooner or later, having a period immediately following the last word might confuse a parser somewhere .

Several people have asked me why I’m so excited about Android. They don’t believe it can ever rival iPhone’s success. “It is too little too late”. In part they are correct, Apple has done a tremendous job in putting the iPhone in the hands of consumers. Its sleek design, excellent usability, and “hype” have won the mind of just about anyone that uses a mobile device now days. However, they are not looking at what Android promises deep enough. It is not just about the cut and dry technical merits. It is the potential for greater availability of applications and choice of hardware where I believe Android will come out on top. I have been playing with the Android SDK (on Linux, with Eclipse, no NDAs, no payments, no applications) for a few days and from what I have seen, I believe that developers will shift momentum Android’s way. Apple has made that mistake before. “Developers! Developers! Developers!…”; Crazy delivery but very true words.

When we look at how things are turning out in the mobile world, one can’t help to be reminded of the PC vs Macs battle of the 80s and the Internet vs AOL/Prodigy/Compuserve of the 90s. We all know how those conflicting approaches turned out.

Android is targeted primarily at developers, with Google and the OHA betting that the way to deliver better mobile software to consumers is by making it easier for developers to write it themselves. As a development platform, Android is powerful and intuitive, letting developers who have never programmed for mobile devices create useful applications quickly and easily. It’s easy to see how innovative Android applications could create demand for the devices necessary to run them, particularly if developers write applications for Android because they can’t write them for other platforms.

Open access to the nuts and bolts of the underlying system is what’s always driven software development and platform adoption. The Internet’s inherent openness and neutrality have seen it become the platform for a multi-billion-dollar industry within 10 years of its inception. Before that, it was open systems like Linux and the powerful APIs provided as part of the Windows operating system that enabled the explosion in personal computers and the movement of computer programming from the arcane to the mainstream.

This openness and power ensure that anyone with the inclination can bring a vision to life at minimal cost. So far, that’s not been the case for mobile phones, and that’s why there are so few good mobile phone applications and fewer still available for free.

Corporations will also be attracted to Android for the level of control it offers. By using a popular enter prise programming language in Java, no licensing fees, and offering the level of access and control users demand, Android offers an excellent enterprise platform.