Posts Tagged ‘google’

Android API designers are reading my mind!

Posted in Android, Software on August 12th, 2013 by loconet – Be the first to comment

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.

Is Android Too Open or Not Open Enough?

Posted in Android, Software on December 22nd, 2009 by loconet – 2 Comments

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.