Building the application

At this point, our application has compiled and is actually ready to be run on the device. Let's look deeper at what happens after the compilation step. We don't need to perform these steps because the ADTs handle these steps for us, but it is helpful to understand what is happening behind the scenes.

Recall that despite the compile-time reliance upon Java, Android applications do not run in a Java virtual machine. Instead, the Android SDK employs the Dalvik virtual machine. This means that Java bytecodes created by the Eclipse compiler must be converted to the .dex file format for use in the Android runtime. The Android SDK has tools to perform these steps, but the ADT takes care of all of this for us transparently.

The Android SDK contains tools that convert the project files into a file ready to run on the Android Emulator. Figure 2.11 depicts the generalized flow of source files in the Android build process. If you recall from our earlier discussion of Android SDK tools, the tool used at design time is aapt. Application resource xml files are processed by aapt, with the R.java file created as a result—remember that we need to refer to the R class for user-interface identifiers when connecting our code to the UI. Java source files are first compiled to class files by our Java environment, typically Eclipse and the JDT. Once compiled, they are then converted to dex files to be ready for use with Android's Dalvik virtual machine. Surprisingly, the project's xml files are converted to a binary representation, not text as you might expect. However, the files retain their .xml extension on the device.

The converted xml files, a compiled form of the non-layout resources including the Drawables and Values, and the dex file (classes.dex) are packaged by the aapt tool into a file with a naming structure of projectname.apk. The resulting file can be read with a pkzip-compatible reader, such as WinRAR or WinZip, or the Java archiver, jar. Figure 2.12 show this chapter's sample application in WinRAR.

We are finally ready to run our application on the Android Emulator! It is important to become comfortable with working in an emulated environment when doing any serious mobile software development. There are many good reasons to have a quality emulator available for development and testing. One simple reason is that having multiple real devices with requisite data plans is a very expensive proposition. A

layout.xml

R.java

*.dex

*.class

1 >

K

<r

Android-Manifest.xml

Figure 2.11 The ADT employs tools from the Android SDK to convert source files to a package ready to run on an Android device or emulator.

Figure 2.12 The Android application file format is pzip compatible.

single device may be hundreds of dollars alone. If the Open Handset Alliance has its way, Android will find its way onto multiple carriers with numerous devices, often with varying capabilities. Having one of every device is impractical for all but the development shops with the largest of budgets. For the rest of us, a device or two and the Android Emulator will have to suffice. Let's focus on the strengths of emulator-based mobile development.

0 0

Post a comment