Basics: Android Applications

Applications in Android are a bit different from what you may be used to in the desktop and server environments. The differences are driven by a few key concepts unique to the mobile phone environment and unique to Google’s intentions for Android.

Limited resources

Mobile phones today are very powerful handheld computers, but they are still limited. The fundamental limitation of a mobile device is battery capacity. Every clock tick of the processor, every refresh of memory, every backlit pixel on the user’s screen takes energy from the battery. Battery size is limited, and users don’t like frequent battery charging. As a result, the computing resources are limited— clock rates are in the hundreds of MHz, memory is at best a few gigabytes, data storage is at best a few tens of gigabytes.

Mobile mashups

In the desktop Internet world, mashups make it very easy to create new applications by reusing the data and user interface elements provided by existing applications. Google Maps is a great example: you can easily create a web-based application that incorporates maps, satellite imagery, and traffic updates using just a few lines of JavaScript on your own web page. Android extends that concept to the mobile phone. In other mobile environments, applications are separate, and with the exception of browser-based applications, you are expected to code your applications separately from the other applications that are running on the handset. In Android you can easily create new applications that incorporate existing applications.

Interchangeable applications

In other mobile software environments, applications are coded to access data from specific data providers. If you need to send an email from a Windows Mobile application, for example, you code explicit references to Pocket Outlook’s email interface, and send the email that way. But what if the user wants to use another email client?

Android incorporates a fundamental mechanism (Intents) that is independent of specific application implementations. In an Android application, you don’t say you want to send email through a specific application; instead, you say you want to send an email through whatever application is available. The operating system takes care of figuring out what application can send emails, starts that application if needed, and connects your request so the email can be sent. The user can substitute different browsers, different MP3 players, or different email clients at will, and Android adapts automatically.

That is why android sounds exciting and has endless features to play with.

Understanding the Android Software Stack

So far I have discussed Android’s history and its optimization features. In this section, I would like to cover the development aspect of Android. 

At the core of the Android Platform is Linux kernel version 2.6, responsible for device drivers, resource access, power management, and other OS duties. The supplied device drivers include Display, Camera, Keypad, WiFi, Flash Memory, Audio, and IPC (interprocess communication).

Sitting at the next level, on top of the kernel, are a number of C/C++ libraries such as OpenGL, WebKit, FreeType, Secure Sockets Layer (SSL), the C runtime library (libc), SQLite, and Media.

The WebKit library is responsible for browser support.

Android GUI Architecture

The Android environment adds yet another Graphical User Interface (GUI) toolkit to the Java ecosphere, joining AWT, Swing, SWT, and J2ME (leaving aside the web UI toolkits). If you’ve worked with any of these, the Android framework will look familiar. Like them, it is single-threaded, event-driven, and built on a library of nestable components.
The Android UI framework is, like the other UI frameworks, organized around the common Model-View-Controller pattern illustrated in Figure. It provides structure and tools for building a Controller that handles user input (like key presses and screen taps) and a View that renders graphical information to the screen.


The Model
The Model is the guts of your application: what it actually does. It might be, for instance, the database of tunes on your device and the code for playing them. It might be your list of contacts and the code that places phone calls or sends IMs to them.

While a particular application’s View and Controller will necessarily reflect the Model they manipulate, a single Model might be used by several different applications. Think, for instance, of an MP3 player and an application that converts MP3 files into WAV files. For both applications, the Model includes the MP3 file format and codecs for it. The former application, however, has the familiar Stop, Start, and Pause controls, and plays the track. The latter may not produce any sound at all; instead, it will have controls for setting bitrate, etc. The Model is all about the data.

The View

The View is the application’s feedback to the user. It is the portion of the application responsible for rendering the display, sending audio to speakers, generating tactile feedback, and so on. The graphical portion of the Android UI framework’s View, is implemented as a tree of subclasses of the View class. Graphically, each of these objects represents a rectangular area on the screen that is completely within the rectangular area represented by its parent in the tree. The root of this tree is the application window.

The Controller

The Controller is the portion of an application that responds to external actions: a keystroke, a screen tap, an incoming call, etc. It is implemented as an event queue. Each external action is represented as a unique event in the queue. The framework removes each event from the queue in order and dispatches it.