http://arstechnica.com/news.ars/post/20071219-google-android-plagued-by-dysfunctional-development-process.html
By Ryan Paul | Published: December 19, 2007 - 10:39AM CT
The software development kit for Google's Linux-based Android mobile phone
operating system has been out in the wild for a over a month now, plenty of
time for developers to form opinions of the platform and assess the
capabilities of the API. The verdict from seasoned mobile software
programmers is somewhat mixed; some are even expressing serious frustration.
Related Stories
I put Android to the test myself in an attempt to see how bad the situation
really is. What I discovered is a highly promising foundation that is plagued
by transitional challenges and a development process that needs more work.
Android has many bugs, some of which are impeding development. Unfortunately,
Google's QA infrastructure for the platform is completely inadequate for a
project of Android's scope and magnitude.
There is no public issue-tracking system for Android. Instead, users post
information about the bugs they encounter in the Android Developer Google
group and hope that one of Google's programmers sees it so that it can be
added to Google's private, internal issue-tracking system. Users have no way
to track the status of bugs that they have reported, and they never know
whether the issue is being addressed at all until after it is resolved, at
which point it is mentioned in the release notes for a new SDK release.
"Unfortunately there is currently no externally-accessible issue-tracking
system," wrote Google developer Dan Morrill in response to complaints about
the bug reporting situation. "We are considering how we might implement such
a system, but we don't have an answer yet. The biggest snag is simply keeping
our internal issue tracker in sync with an external one. So, it's a process
problem, rather than a technical problem."
Companies like Skype, Nokia, and Trolltech all have public issue tracking
systems for their software, so one has to wonder why Google, with all of its
resources, can't do the same for Android. This is a pretty clear symptom of a
dysfunctional development process. In an effort to minimize the frustration
of not having centralized issue tracking, users have started to independently
catalog known bugs at an unofficial Android wiki.
Another major problem with Android is lack of documentation. The API
reference material doesn't provide enough information and one sometimes has
to experiment (that is, guess) to figure out what the parameters for various
methods actually do. In many cases, I found the developer discussion group to
be far more informative than the API documentation. I also grew frustrated
with some of the inconsistencies in the API naming conventions, an issue that
other developers have complained about as well.
Working with the layout model for the Android user interface can also be
frustrating. The code samples mostly emphasize the XML-based user interface
description language, so there aren't enough examples that demonstrate
programmatic layout techniques.
A recent article in the Wall Street Journal illuminates problems encountered
by other developers who are attempting to build applications for Android.
"Functionality is not there, is poorly documented or just doesn't work,"
MergeLab mobile startup founder Adam MacBeth told the WSJ. "It's clearly not
ready for prime time."
The strength of an android
Although Android has its share of problems, there are some places where it
really shines. The Eclipse plug-in is quite effective and provides excellent
integration with the Android emulator. Every time you initiate the debugging
process in Eclipse, it will start up your program inside the emulator and
connect it to the Eclipse debugger automatically. You don't even have to
close the emulator between tests; you can just modify the code and run the
debug process again and it will restart your program in the currently running
emulator instance. The seamless support for breakpoint debugging is so
effective that it feels like developing a regular desktop application.
The setup is also surprisingly easy if you already have Eclipse installed.
You just unzip the SDK, install the Eclipse plug-in, tell it where you put
the SDK, and you are good to go. Downloading the SDK to compiling my first
Hello World program took me less than ten minutes. In that respect, Android
provides a much better experience than Maemo, for instance, which is a real
pain to set up.
There are a few other places where Android surprised me with goodness. The
ScrollView widget appears to support kinetic scrolling right out of the box,
which means that developers won't have to implement that at the application
level like they do with Maemo. I was also impressed by Android's seamless
support for screen rotation and multiple resolutions. The emulator comes with
several skins that you can use to test your application at various screen
sizes and in different orientations. My applications worked fine in both
horizontal and vertical orientations without requiring any custom
programming. The user interface changed to accommodate horizontal orientation
in much the same way a regular desktop application changes when it is resized.
To test out the API, I wrote a few experimental Android programs, including a
Twitter client. The API is moderately conducive to rapid application
development, but there are still some gaps. Although the API offers a lot of
really nice functionality for animated transitions, alpha transparency, and
other similar visual effects, it doesn't make it easy to create applications
that have a really polished look and feel. For my Twitter application, for
instance, I wanted to put a nice picture in the background and have a
transparent, rounded rectangle with a border behind each tweet, but those
kinds of embellishments end up being way more trouble than they are worth in
Android. By comparison, getting the same effect with XUL only requires a few
trivial lines of CSS.
I had a hard enough time getting the basic layout to look right even without
thinking about embellishments. Android would benefit greatly from a
drag-and-drop design utility that provides an interactive approach to layout
and exposes all of the widget attributes in a clear and expressive way.
Despite some of the bugs and limitations in the API, it is definitely a
viable and effective platform for application development. My Twitter client
was only about 130 lines of code, which is impressive. That said, I could
still crank out applications faster with Java FX Script. In general, I think
that Java FX Mobile is probably the competing platform that is most analogous
to Android.
The inevitable comparisons between Android and the iPhone platform seem a bit
misguided now that I've really worked with Android. The iPhone platform seems
to be tailored to a very specific kind of user experience that is particular
to the hardware. Apple has always been good at leveraging the tight coupling
between its hardware and software, and the iPhone is no exception. With the
iPhone, Apple has sacrificed the potential for hardware diversity but gained
in the process the ability to make innovative technologies like multitouch a
ubiquitous part of the user experience. Android, on the other hand, has to be
designed from the ground up to support an extremely diverse range of hardware
devices with vastly different capabilities.
Android's design seems to be heavily focused on making as few assumptions as
possible about the kinds of devices on which the software will run. And
seriously, some of those devices are going to be monstrously ugly clunkers
compared to the iPhone.
It's important to remember that Android is still in early stages of
development and that its present weaknesses aren't indicative of failure.
Devices with Android won't even start to hit the market until later next
year, so this is like a pre-release aimed at spurring early development so
that a healthy ecosystem of third-party software applications is available at
launch.
Despite pre-release status, some of Android's weaknesses are indefensible.
Google's Android team needs to get its act together and figure out how to
interact with a rapidly growing community of professional and enthusiast
developers. The "release early and often" strategy is generally a good thing,
but it utterly fails when infrastructure isn't in place to facilitate proper
handling of user feedback. Google has a habit of embracing the early release
philosophy with a little too much enthusiasm, and the current situation with
Android is emblematic of that approach.
--
修改:FreeWizard FROM 123.119.79.53
FROM 123.119.79.53