The Android Architecture

By Jeff Cogswell  |  Posted 2008-10-08 Print this article Print


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.

Jeff Cogswell is the author of Designing Highly Useable Software ( among other books and is the owner/operator of CogsMedia Training and Consulting.Currently Jeff is a senior editor with Ziff Davis Enterprise. Prior to joining Ziff, he spent about 15 years as a software engineer, working on Windows and Unix systems, mastering C++, PHP, and ASP.NET development. He has written over a dozen books.

Submit a Comment

Loading Comments...
Manage your Newsletters: Login   Register My Newsletters

Rocket Fuel