Skip Links

Network World

Mark Murphy

Fragmentation Fears

Managing Development for Multiple Android Devices

By Mark Murphy on Mon, 09/21/09 - 3:28pm.

There has been a recent upswing in blog posts and the like regarding fragmentation of the Android platform. People see a widening range of devices, from HTC going with a resistive touchscreen for the Tattoo, to Motorola's CLIQ with a D-pad instead of a trackball, to the 5” WVGA screen of the Archos 5 Internet Tablet. This raises concerns, particularly in people who witnessed the problems that JavaME experienced with platform fragmentation. The fear is that in spite of the larger market for devices that such fragmentation brings, it may wreak havoc upon third-party developers.

Those fears are reasonable. However, here are a few reasons why I do not expect quite the problem with Android that we saw with JavaME:

  1. Android is a richer platform to begin with, making it easier for Android to offer frameworks to help manage varying hardware. Those frameworks could be supplied by Android (e.g., the resources framework for selecting UI layouts on the fly based on device capabilities) or written by third parties.
  2. Android will tend to run on faster devices than did JavaME in its heyday, meaning the aforementioned frameworks will not necessarily slow things to an unbearable level.
  3. Android has a formalized system for vendor-specific add-ons — witness Motorola leveraging that add-on system for their CLIQ and its four-way screen rotation. This will help steer device manufacturers to make their departures from the norm better supported for developers.
  4. The Android emulator already has a rich mechanism to emulate devices with a wide range of hardware capabilities.
  5. The core Android team seems to be actively learning from and attempting to avoid the pitfalls that befell JavaME (and, to a lesser extent, Windows Mobile). One example is the filtering system they have developed, to help Android devices and the Android Market screen out applications that definitively will not run on the user's device.

This does not mean that the future is all peaches and cream. There will be a fair bit of developer angst over each fresh departure from what has gone on before, such as the current concerns over QVGA (Tattoo) and WVGA (Archos) screens. However, I feel that Android has as good a chance as any mobile platform of solving, or at least managing, the fragmentation issue.

Fragmentation

0

I'm not sure I really agree with these points about Android not being as fragmented as Java ME. It may actually be worse.

Take point (5). There are ways to do matching of device- capabilities to content-requirements using UAProf and RDF capability files. This is all very well developed in the Java ME space for showing the correct content on the device. Android has nothing like it. Since Google considers the Android Market a closed application, I don't really see them leading the community on this problem. Sun did a much better job on openness here.

For (3), standardized extensions is not the issue. The issue is getting the right application to the right device. Java ME developers have a standard way of defining these API's through the JCP; but it is still a fragmented market. We already see signs of Motorola talking about extensions to the API. Google does this already. Other vendors will do it as well so that it leverages the maximum capabilities of their device (they have to do this to compete). All these standard extensions, fragment the market.

(1) has some merit. The UI in Android is largely adequate. The UI in MIDP 1.0 was terrible. I remember telling one of the manager's from Sun back at an embedded systems conference in 2002 that the UI was terrible and that it would cause vendors to create extensions. She seemed offended and said that would create fragmentation and was against the spirit of Java. A lousy standard UI did create fragmentation, as we all saw. So Google did this part right.

As for (2), I don't really see faster devices factoring in here unless you mean the CLDC/CDC fragmentation in Java ME. That was a bit of painful point 4-5 years ago but largely these days people develop for CDC in the smart phone market.

(4) Maybe more convenient for the developer, but again not sure it has anything to do with fragmentation.

Fragmentation

0

All open systems are sooner or later accused of being ripe for fragmentation. The only time you don't get accusations is if you're completely closed like iphone or windows.
The real question isn't so much will fragmentation happen, but will android in whatever shape and forms it takes in future, provide a consistent developer platform. So in effect will the openness of the platform still allow developers to target multiple variations without too much pain.

I'm not really too interested in what's gone before, but I am interested in how Android evolves, and I'm pretty sure no-one can predict exactly how that will be.

Sure highlight past problems, but the key points should be focusing on making Android a vibrant developer platform.

Android not that open, fragmentation not that likely

0

Fragmentation is a part of Open Source. What you pay for creating fertile ground for innovation. The alternative is control. But Android may turn out to be less open that it seems.

The Google complaint against CYANOGEN (an independent Android Rom developer) teaches us that Google is trying to control the Android market and the Android user experience. Exactly like Apple controls the iPhone market.

This opens the door for for Apple/AT&T to go back to the FCC and say that they are exactly like Google and there is no merit to the complaint about GoogleVoice.

Google made a big legal mistake. Penny wise (win vs Cyanogen), pound foolish (lose vs. Apple/AT&T).

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Post new comment

The content of this field is kept private and will not be shown publicly.
  • You can use BBCode tags in the text.
  • Lines and paragraphs break automatically.
  • Allowed HTML tags: <p> <strong> <i> <br /> <br> <ul> <ol> <li> <dl> <dt> <dd> <blockquote>

More information about formatting options

CAPTCHA
This question is for testing whether you are a human visitor and to prevent automated spam submissions.
Welcome, visitor. Register Log in
About Android Angle
Mark Murphy is the founder of CommonsWare and the author of The Busy Coder's Guide to Android Development. A three-time entrepreneur, his experience ranges from consulting on open source and collaborative development for the Fortune 500 to application development on just about anything smaller than a mainframe. A polished speaker, Murphy has delivered conference presentations and training sessions on a wide array of topics internationally. Outside of CommonsWare, Murphy has an avid interest in how the Internet will play a role in citizen involvement with politics and government.