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.