Developing with Google Android

By Jeff Cogswell |
Posted 2008-10-08

Developing with Google Android

Google's Android is a complete mobile operating system. While the technology is meant to challenge other mobile OSes-including Microsoft's Windows Mobile and Apple's iPhone-it also promises to be a key development platform.

For developers, that means using
Java and Eclipse, and understanding the fundamental mobile architecture of Android.
Here is an overview of the architecture.

Eclipse: The Preferred IDE

The preferred development environment
for developing for Android is the open-source Eclipse IDE.
While developers could use their favorite editor and command-line tools
directly, development is certainly easier in Eclipse, since Google has given us
a pretty nice plug-in to simplify development in Eclipse. This plug-in
automatically creates a project for developers, including some starter files
such as a class for the main application, which even includes some starting
code.

Development, therefore, requires
that Eclipse and the Android software development kit be installed, as well as
the plug-in for Eclipse.

The Language Is Java

To develop for Android, programmers
use the latest version of Java. Included with the Android SDK is a whole set of
Java libraries found in such namespaces as android.app and android.os. These
classes are all contained in a single jar file; looking at the jar file, I saw
such namespaces as android.content, android.database, android.graphics,
android.hardware, android.net, android.net.wifi (cool!), android.sax (as in

Additionally there's a large set of Apache
classes and World Wide Web Consortium classes. The Apache classes are primarily
for HTTP communication, while the W3C classes are the DOM
(Document Object Model) processing classes.

Remember, Android is a complete
operating system, and as is obvious, through these Java classes, developers
have access to a great deal of features that they can use in their programs.

I was curious about one aspect of
the HTTP classes in particular. I looked through all the class names, and sure
enough, this one was present: org.apache.http.HttpServerConnection. That's for
server-side processing. Does Android let developers run an actual HTTP server?
HttpServerConnection is just an interface; on further inspection, I found this
class: org.apache.http.impl.DefaultHttpServerConnection. Indeed, this class is
an implementation of a server connection class. I didn't have time for this
particular article to explore this further, but I'm definitely going to do that
soon. The idea of running server software on a mobile device is certainly intriguing.

The Android Architecture

The Android Architecture

Remember, Android is an entire operating
system. As such, it has several features you would expect.

One is the notion of a service. Services
are basically programs that run in the background. The official Google docs use
a media player as an example of a service, and it comes down to a fundamental
issue: If a user is listening to music on your device, and they switch to a
calendar application, they don't want the music to suddenly stop. The GUI has
gone away, but the service playing the music continues to run.

A single application also has a specific
architecture that Google has defined. The most obvious to the user is the Activity.
An Activity is essentially a single screen. A single application might have
multiple screens; the official docs mention a messaging program that includes a
screen listing the user's contacts, as well as a screen where they type in their
message, among others. Each screen is an Activity.

What's interesting is that that
these Activity screens are handled by the operating system in a manner similar
to a windowing system on a desktop computer (such as Windows itself), but more
suited for a handheld device. The Android operating system's window manager
includes a stack for your application's Activity screens. If a developer has an
Activity screen showing, then switches to another, the operating system takes
the previous one and puts it onto a stack and pauses it. This, in turn, allows
for a history button, where the user can navigate back through the screens,
just like they might find in a Web browser. (And indeed, when playing with the
Android emulator, one can see the back button.)

Earlier I mentioned that there's a
set of database classes. The database Google engineers have chosen is the one they've
preferred in the past (such as with their Gears architecture)-the SQLite
database. In my own opinion, I was pleased to hear that Android includes
SQLite, since that allows for SQL, a familiar database architecture that's easy
to use. However, for those developers looking for something a little simpler
with access to standard data such as contacts, there's another content provider
built in that doesn't use SQL and supports common data types such as audio,
video, contacts and so on. What's interesting is that this content provider
organizes its data through URIs (uniform resource identifiers) such as "content://contacts/people/23."

Further, programmers can even develop
their own content provider.

Finally, I should point out that
it's through these content providers that data can be shared among applications.

Intents

Intents

In articles and videos about Android
that Google released on YouTube, users have likely heard the word "intent," such
as in phrases like "broadcast an intent." However, like me, not everyone totally
got the gist of this, as the descriptions were geared toward end users rather
than developers.

Essentially, intents are a common
way to categorize what applications typically do. A contact application will allow
a developer to view a list of contacts and select one, edit a contact, add a
new contact and so on. Google has predefined these types of processes with
words like VIEW for the viewing of a contact, PICK for the selection of a contact
and EDIT for the editing of a contact.

The whole intention of intents
(sorry) is to facilitate late binding. Look at it this way: One person could
create an application (call it Application A) that can make use of features in
other applications. Later, somebody could create an application that provides
such a feature. Call this second application Application B. When Application A
was developed, the programmers couldn't have known about Application B. While
the developers of A could create their own careful specification by which
future developers providing a feature must adhere to-meaning future developers
must link their code into the first application-Google engineers have found a
simpler method.

Instead of statically linking code together,
they allow for a message system that accomplishes late binding. This message
system is the Intent class and its associated classes.

Applications can then publish their
intents to the entire system. This is where the cool part happens. As I said in
a previous article about Android, you can replace standard applications (such
as a phone or contact application) with a custom app. That way, if a programmer
doesn't like the built-in phone software, they can use a better one someone
else wrote. That replacement app would advertise its intentions. Then, if they
have yet another program that launches the phone dialer, instead of launching
the built-in dialer, it would launch the replacement app. The app doing the
launching could send data to the replacement dialer; the developer can see then
how late-binding factors in here.

When an application provides intentions,
it can respond to various events that aren't necessarily triggered by a human.
For example, a user might write a special program that needs to respond when
the phone rings. (Speaking off the top of my head, I can't think of a good
example of such a program, but I'm sure others can come up with some interesting
ideas here.) One nice thing here is that your program doesn't have to already
be running; because it has broadcast an intent, the operating system will
launch the program in response to the event.

GUI Layout

GUI Layout

Google documentation walks you
through a basic "Hello World" application; this sample makes use of the plug-in
and its default application.

Developers can try that out if they-ve
downloaded the SDK and Eclipse. One thing I want to mention in particular is
something that makes development for Android easy. Most of today's development
tools allow for easy development of a GUI by describing the GUI rather than
coding it. Instead of calling an API
function to add three buttons to a window, a user describes the three buttons
and the run-time does the hard work of reading the descriptions and adding the
buttons to the window. This concept isn't by any means new-early Mac and
Windows developers have used resource files for ages, and today we have

As you would therefore expect, especially
considering this is Java we're using, the GUI development includes a full set
of layouts, such as a table layout, various list layouts, absolute layouts and
others.

Conclusion: Where to Go Next

I found the best place to understand
how everything fits together is to read three articles in particular from the
official documentation in this order: