In this section, we’ll introduce you to the high-level Android Java APIs that you’ll use todevelop end-user applications for an Android handheld. We will briefly talk about the Android phone emulator and foundational components, UI programming, services, media,telephony,animation, and OpenGL. We will also show you some code snippets when they
are helpful.

The Android Emulator

The Android SDK ships with an Eclipse plug-in called Android Development Tools (ADT). You will use this Integrated Development Environment (IDE) tool for developing, debugging, and testing your Java applications. (We’ll cover ADT in depth in Chapter 2.)

You can also use the Android SDK without using ADT; you’d use command-line tools instead. Both approaches support an emulator that you can use to run, debug, and test your applications. You will not even need the real device for 90 percent of your application development.

The full-featured Android emulator mimics most of the device features, but you’ll encounter some limitations regarding USB connections, camera and video capture, head- phones, battery simulation, and Bluetooth.

The Android emulator accomplishes its work through an open source “processor emula-tor” technology called QEMU (http://bellard.org/qemu/) developed by Fabrice Bellard. This is the same technology that allows emulation of one operating system on top of another, irre-spective of the processor. QEMU allows emulation at the CPU level.


In the case of the Android emulator, the processor is based on ARM (Advanced RISC Machine). ARM is a 32-bit microprocessor architecture based on RISC (Reduced Instruction Set Computer), in which design simplicity and speed is achieved through a reduced number of instructions in an instruction set. The emulator actually runs the Android version of Linux  on this simulated processor. PowerPCs supporting Apple Macs and SPARC chips supporting Sun
workstations are examples of RISC architectures.

ARM is widely used in handhelds and other embedded electronics where lower power consumption is important. Much of the mobile market uses processors based on this archi-tecture. For example, Apple Newton is based on the ARM6 processor. Devices such as the iPod, Nintendo DS, and Game Boy Advance run on ARM architecture version 4 with approxi-mately 30,000 transistors. Compared to that, the Pentium classic contains 3,200,000 (3.2 million) transistors.

You can find more details about the emulator in the Android SDK documentation at http://code.google.com/android/reference/emulator.html.

The Android UI

Android uses a UI framework that resembles other desktop-based, full-featured UI frame-works, but it’s more modern and more asynchronous in nature. Android is almost a fourth-generation UI framework if you were to call the traditional C-based Microsoft Windows API the first generation and the C++-based MFC (Microsoft Foundation Classes) the second generation. The Java-based Swing UI framework would be the third generation, introduc-ing design flexibility far beyond that offered by MFC. The Android UI, JavaFX, Microsoft Silverlight, and Mozilla XML User Interface Language (XUL) fall under this new type of  fourth-generation UI framework in which the UI is declarative and independently themed.

Programming in the Android UI involves declaring the interface in XML files. You will then load these XML view definitions as windows in your UI application. Even menus in your application are loaded from XML files. Screens or windows in Android are often referred to as activities, which comprise multiple views that a user needs in order to accomplish a  logi-cal unit of action.Views are Android’s basic UI building blocks, and you can further combine them to form composite views called view groups.Views internally use the familiar concepts of canvases, painting, and user interaction. An activity hosting these composite  views, which include views and view groups, is the logical replaceable UI component in Android.

One of the Android framework’s key concepts is the lifecycle management of activity win-dows. Protocols are put in place so that Android can manage state as users hide, restore, stop,and close activity windows. You will get a feel for these basic ideas in Chapter 2, along with an introduction to setting up the Android development environment.15



The Android Foundational Components


The Android UI framework, along with other parts of Android, relies on a new concept called an intent. An intent is an amalgamation of ideas such as windowing messages, actions,publish-and-subscribe models, interprocess communications, and application registries.Here is an example of using the Intent class to invoke or start a web browser:
public static void invokeWebBrowser(Activity activity)
{
Intent intent = new Intent(Intent.ACTION_VIEW);
intent.setData(Uri.parse("http://www.google.com"));
activity.startActivity(intent);
}

Through an intent, we are asking Android to start a suitable window to display the content of a web site. Depending on the list of browsers that are installed on the device, Android will choose a suitable one to display the site. You will learn more about intents in Chapter 3.

Android also has extensive support for resources, which include familiar elements and files such as strings and bitmaps, as well as some not-so-familiar items such as XML-based view definitions. The framework makes use of resources in a novel way to make their usage easy, intuitive, and convenient. Here is an example where IDs are automatically generated for resources defined in XML files:

public final class R {
public static final class attr { }
public static final class drawable {
public static final int myanimation=0x7f020001;
public static final int numbers19=0x7f02000e;
}
public static final class id {
public static final int textViewId1=0x7f080003;
}
public static final class layout {
public static final int frame_animations_layout=0x7f030001;
public static final int main=0x7f030002;
}
public static final class string {
public static final int hello=0x7f070000;
}
}

Each auto-generated ID in this class corresponds to either an element in an XML file or a whole file itself. Wherever you would like to use those XML definitions, you can use these gen-erated IDs instead. This indirection helps a great deal when it comes to localization. (Chapter 3 covers the R.java file and resources in more detail.)


Another new concept in Android is the content provider. A content provider is an abstrac-tion on a data source that makes it look like an emitter and consumer of RESTful services. The underlying SQLite database makes this facility of content providers a powerful tool for appli-cation developers. (In Chapter 3, we’ll discuss how intents, resources, and content providers promote openness in the Android Platform.)


Advanced UI Concepts

We have pointed out that XML plays a role in describing the Android UI. Look at an example of how XML does this for a simple layout containing a text view:




android:layout_width="fill_parent"     android:layout_height="wrap_content"
android:text="@string/hello"
/>



You will then use an ID generated for this XML file to load this layout into an activity win-dow. (We’ll cover these ideas further in Chapter 4.)

Android also provides extensive support for menus, from standard menus to context menus. You’ll find it convenient to work with menus in Android because they are also loaded as XML files and because resource IDs for those menus are auto-generated. Here’s how you would declare menus in an XML file:




android:orderInCategory="10"
android:title="clear" />

android:orderInCategory="5"
android:title="show browser" />


Although Android supports dialogs, all dialogs in Android are asynchronous. These asynchronous dialogs present a special challenge to developers accustomed to the synchro-nous modal dialogs in some windowing frameworks. We’ll address menus and dialogs more extensively in Chapter 5, where we’ll also provide a number of mechanisms to deal with asyn-chronous-dialog protocols.



Android also offers support for animation as part of its UI stack based on views and drawable objects. Android supports two kinds of animation: tweening animation and frame-by-frame animation.

“Tweening” is a term in animation that refers to the drawings that are “in between” the key drawings. You accomplish this with computers by changing the intermediate values at regular intervals and redrawing the surface. Frame-by-frame animation occurs when a series of frames is drawn one after the other at regular intervals. Android enables both animation approaches through animation callbacks, interpolators, and transformation matrices. More-over, Android allows you to define these animations in an XML resource file. Check out this example, in which a series of numbered images is played in frame-by-frame animation:

“Tweening” is a term in animation that refers to the drawings that are “in between” the
key drawings. You accomplish this with computers by changing the intermediate values at
regular intervals and redrawing the surface. Frame-by-frame animation occurs when a series
of frames is drawn one after the other at regular intervals. Android enables both animation
approaches through animation callbacks, interpolators, and transformation matrices. More-
over, Android allows you to define these animations in an XML resource file. Check out this
example, in which a series of numbered images is played in frame-by-frame animation:


android:oneshot="false">

……




The underlying graphics libraries support the standard transformation matrices, allowing scaling, movement, and rotation. A Camera object in the graphics library provides support  for depth and projection, which allows 3D-like simulation on a 2D surface. (We’ll explore anima-tion further in Chapter 6.)

Android also supports 3D graphics through its implementation of the OpenGL ES 1.0 standard. OpenGL ES, like OpenGL, is a C-based flat API. The Android SDK, because it’s a Java-based programming API, needs to use Java binding to access the OpenGL ES. Java ME has already defined this binding through Java Specification Request (JSR) 239 for OpenGL ES, and Android uses the same Java binding for OpenGL ES in its implementation. If you are not
famil-iar with OpenGL programming, the learning curve is steep. But we’ve reviewed the  basics here,so you’ll be ready to start programming in OpenGL for Android in Chapter 10.

Starting with release 1.5 Android has simplified OpenGL so that it is approachable to begin-ning OpenGL programmers. We will cover these improvements in Chapter 13. Additionally, that SDK introduced a new concept called live folders, which we will also cover in Chapter 13.