Developing with Google Android
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.
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.
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:
code.google.com/android/intro/appmodel.html for information on the application model, and then
code.google.com/android/intro/lifecycle.html for information on the application lifecycle.
Understanding these three documents is vital to understanding how Android works.
Senior Editor Jeff Cogswell can be reached at firstname.lastname@example.org.