49Building an Android application in Eclipse

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 con- verted 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 impor- tant 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 hav- ing multiple real devices with requisite data plans is a very expensive proposition. A

*.java layout.xml *.class R.java *.dex application.apk file 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.

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 develop- ment 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.

2.4

The Android Emulator

While the best test of an application is running it on the hardware for which it was designed, an emulator often makes the job of the developer much easier. Working in an emulated environment permits a more rapid compile, run, and debug iterative cycle than is typically available when testing on a real hardware device. Taking the time to sync, or copy, an application to a real device typically takes longer than starting an emu- lator session. Also, it is easier to clean the filesystem of an emulator than performing the same maintenance operation on a real device. When you add in the capability of script- ing commands to/from the emulator, it becomes an option worthy of investigation.

Beyond being a faster tool than working with a real device, the emulator tool must consider physical characteristics of a device, primarily the screen dimensions, input devices, and network connectivity.

2.4.1 Skins

Not all mobile devices are equally equipped, so it is important to be able to accommo- date and test varying device characteristics in an emulated environment. The Android SDK comes with an emulator with distinct skins. The skins represent different hardware layouts as well as portrait and landscape orientations. Figure 2.13 shows two emulator views: one in portrait with a hidden QWERTY keypad, the other in landscape mode with a visible keyboard. The skins found with your SDK may vary from those shown here.

Not only is it important to understand and accommodate how the device looks, it is important to understand what connectivity options a device is able to offer. Have you ever tested a mobile application in an area where there is excellent data coverage only to find out that the location where the application is deployed in the field often has only marginal data service? The ability to test this condition in the confines of our

51