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

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:

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

Why Android?

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.

This piece from Professional Android Application Development explains very well what I see.

What Will Drive Android Adoption?

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.

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:


Gnome-Do Plugin - ManLookUp

Development site:

Read More