Android code , Android Phone, Android Developers

If you have a decent amount of experience as an application developer, you are familiar with the concept of an application life cycle. An application life cycle consists of the steps that the application’s processes must follow from execution to termination. Every application, regardless of the language it was written in, has a specific life cycle, and Android applications are no exception. This section examines the life  cycle of an ASP application and compares that to an Android application’s life cycle.

Standard ASP Application Life Cycle The life cycle of a standard ASP application is similar enough to that of an Android application to make this a good comparison. ASP applications step through five distinct processes from launch to disposal. These steps are required to be implemented by all ASP applications, and really define what an ASP application is. The steps, in order, are

1. Application_Start
2. Event
3. HTTPApplication.Init
4. Disposal
5. Application_End

TIP
Some ASP reference materials consider Disposal and Application_End to be one step in the life cycle. However, the Disposal call can be intercepted before it is passed to Application_End. This can allow the application to perform specific functions before it is actually destroyed.
Application_Start is called when the application is requested from the server. This process in turn leads into the Event process(es). When all associated application modules have loaded, HTTPApplication.Init is called. The application executes its events, and when the user attempts to close it, Dispose is called. Dispose then passes processing on to the Application_End process, which closes the application.

This is a fairly standard application life cycle. Most applications follow similar life cycles: an application is created, loaded, has events, and is destroyed. The following section demonstrates how this compares to the Android application life cycle.

Android Application Life Cycle
The Android application life cycle is unique in that the system controls much of the life cycle of the application. All Android applications, or Activities, are run within their own process. All of the running processes are watched by Android and, depending on how the activity is running (this is, a foreground activity, background activity, and so forth), Android may choose to end the activity to reclaim needed resources.

NOTE
When deciding whether an activity should be shut down, Android takes into account several factors, such as user input, memory usage, and processing time.

Some of the specific methods called during the life cycle of an android activity are

1 onCreate
2 onStart
3 Process-specific events (for example: launching activities or accessing a database)
4 onStop
5 onDestroy
Following the same logic as other application life cycles, an Android application
is created, the processes are started, events are fired, processes are stopped, and the application is destroyed. Though there are a few differences, many application developers should be comfortable with the steps in the life cycle.

ActivityCreator
activityCreator (.bat or .pn) is a simple command-line tool that is used to set up a basic development environment. When run from the command line, activityCreator will set up the shell files needed to create a basic Android application. Having these shell files is especially useful if you are not using Eclipse. The Android plugin for Eclipse sets up these shell files for you by calling the activityCreator when you create a new project.
Depending on what type of environment you are running, you will see the activityCreator represented by a different type of script file. If you are in a Windows environment, this will be a .bat file; otherwise it will be a python (.pn) script. You simply execute the script, which in turn calls the actual activityCreator process with the correct parameters.

APIs
The API, or application programming interface, is the core of the Android SDK. An API is a collection of functions, methods, properties, classes, and libraries that is used by application developers to create programs that work on specific platforms. The Android API contains all the specific information that you need to create applications that can work on and interact with an Android-based application. The Android SDK also contains two supplementary sets of APIs—the Google APIs and the Optional APIs. Subsequent chapters will focus much more on these APIs as you begin writing applications that utilize them. For now, take a quick look at what they include so that you are familiar with their uses.

Google APIs
The Google APIs are included in the Android SDK and contain the programming references that allow you to tie your applications into existing Google services. If you are writing an Android application and want to allow your user to access Google services through your application, you need to include the Google API. Located in the android.jar file, the Google API is contained within the com.google.* package. There are quite a few packages that are included with the Google API. Some of the packages that are shipped in the Google API include those for graphics, portability, contacts, and calendar utilities. However, the packages devoted to Google Maps will be the primary focus of us.
Using the com.google.android.maps package, which contains information for Google Maps, you can create applications that interact seamlessly with the already familiar interface of Google Maps. This one set of packages opens a whole world of useful applications just waiting to be created.
The Google API also contains a useful set of packages that allows you to take advantage of the newer Extensible Messaging and Presence Protocol (XMPP) developed by the Jabber open source community. Using XMPP, applications can quickly become aware of other clients’ presence and availability for the purpose of messaging and communications. The API packages dealing with XMPP are very useful if you want to create a “chat”-style program that utilizes the phone messaging capabilities.

Optional APIs
The Android SDK includes a number of Optional APIs that cover functionality not covered by the standard Android APIs. These Optional APIs are considered optional because they deal with functionality that may or may not be present on a given handset device. That is, some devices created for the Android platform may include upgrades and features that others do not; the Optional APIs cover your programming options when trying to utilize these features in your Android applications.
One of these optional features  is a cell-phone-based GPS. The Android LBS (Location-Based Services) API deals with the functionality needed to receive and utilize information from a device’s GPS unit. (Combine the information in the Android LBS API with that in the Google Maps API, and you might have a very useful application that can automatically display a map of where you are located at any given point in time.) Other Optional APIs include those for utilizing Bluetooth, Wi-Fi, playing MP3s, and accessing 3-D—OpenGL-enable hardware.

The Android SDK supplies developers with a number of powerful and useful tools. Throughout this book, you will use only a handful of them directly. This section takes a quick look at just a few of these tools, which will be covered in much more depth in the following chapters, as you dive into command-line development.

NOTE

For more detailed information about the other tools included in the Android SDK, consult the Android doc files.

Emulator.exe

Arguably one of the most important tools included in the Android SDK is emulator.exe. emulator.exe launches the Android Emulator. The Android Emulator is used to run your applications in a pseudo-Android environment. Given that, as of the writing of this book, there were no hardware devices yet released for the Android platform, emulator.exe is going to be your only means to test applications on a “native” platform.

You can run emulator.exe from the command line or execute it from within Eclipse.  However, in the interest of giving you all the information you need to program with the Android SDK outside of Eclipse, Chapter 6 covers command-line usage of emulator.exe when you create your Hello World! applications.

When using the Android Emulator to test your applications, you have two choices for navigating the user interface. First, the emulator comes with usable buttons, as shown in Figure 4-1. You can use these buttons to navigate Android and any applications that you develop for the platform.

TIP

The Power On/Off, Volume Up, and Volume Down buttons are slightly hidden to the sides of the virtual device. They identify themselves when you hover the mouse pointer over them.Given that many higher-end phones now include a touch screen, the second input choice you have when using the emulator is a simulated touch screen. You use your mouse as a stylus. The objects on the emulator’s screen can be interacted with using the mouse.

adb.exe

Another tool that will become very useful to you when you are using command-line programming is Android Debug Bridge or adb (adb.exe). This tool allows you to issue commands to the Emulator.exe tool.

When you are working in a command-line environment, the adb tool allows you to do the following:

● Start and stop the server

● Install and uninstall applications

● Move files to and from the emulator

MKSDCARD.exe

MKSDCARD.exe is a very useful tool if you are testing an application that will need to read or write files to or from an SD Memory Card inserted into the mobile device. MKSDCARD.exe creates a small partition drive on your drive that will hold and retain the test files. The emulator will treat this partition like an SD Memory Card.

DX.exe

DX.exe is the compiler of the Android SDK. When run against your Java files, DX.exe will create files with .dex extensions—Dalvik executable format. These files are in the correct format to be understood by, and run on, an Android device.

NOTE

Android executable files are called Dalvik executable files as a reference to the Dalvik virtual machine that Android used to run all applications. The Dalvik virtual machine runs each application in its own thread with the same priority as core Android applications.