Android API designers are reading my mind!

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.

Read More

Rant on the complete disaster that is Ubuntu’s Unity

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.

Read More

ca.loconet.android Tip

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().

So, the trick is to OR the flag with FLAG_ACTIVITY_SINGLE_TOP:


intent.addFlags(Intent.FLAG_ACTIVITY_CLEAR_TOP | Intent.FLAG_ACTIVITY_SINGLE_TOP);

From the docs on FLAG_ACTIVITY_SINGLE_TOP:

If set, the activity will not be launched if it is already running at the top of the history stack

Read More

What motivates us

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. 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.

Watch the video:

Read More

Is Android Too Open or Not Open Enough?

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 users are now considering their 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: RogersMary has 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.

Read More

lget 1.0 for Firefox 3.5

You should be able to upgrade to lget for Firefox 3.5 from the Mozilla’s official addon’s website: https://addons.mozilla.org/en-US/firefox/addon/435

Changes in this release:

  • Use of new SQLite storage API for history
  • Compatible with Firefox 3.5
  • New download window now closes itself after a new download is initiated
  • Some code cleanup
  • Several minor bug fixes

UPDATE: For those looking for the Firefox 3.6 update, please see this comment.

Read More

Gnome-Do Plugin – ManLookUp

Instead of working on my Artificial Intelligence assignment I spent some time last night playing with Gnome-Do (Crazy Delicious!).

For those of you not familiar with Gnome-Do, it’s a very nifty way of accessing commonly used files, actions, tasks, etc in your system. It’s a bit hard to explain with words so check out the screencast. Many of you will recognize its functionality to be very similar to GNOME Launch BoxQuicksilver for the Mac, or launchy for Windows. Gnome-Do of course runs on Linux and it is written in C# using Mono.

The plugin architecture is decently documented, and because it is open source, it is very easy to dive into the code and learn how things are setup to get you quickly going with plugin development.

So, after some researching and hacking around, I came up with “ManLookUp”. It is a is a very simple Gnome-Do plugin that allows to quickly search for man pages installed in your system. One can either type the command: “Man lookup” “View Manual Page” “Read Manual”-> hit Tab  to get a list of pages + description of the entry or search for a man page entry directly. Selecting one of the entries brings up the man page entry on a terminal window. Selected text as well as Application Items indexed by Do itself are also supported. I hope this plugin is helpful for others as well.

Monodevelop project, release/debug binary, and of course, sources can be downloaded from:

http://www.loconet.ca/files/ManLookUp-1.0.tar.gz

Screenshot:

Gnome-Do Plugin - ManLookUp

Development site: https://code.launchpad.net/~loconet/do-plugins/ManLookUp

Read More