The Android Architecture
Email
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.
