Although the size and complexity of Android applications can vary greatly, their structures will be similar. Figure 2-7 shows the structure of the "Hello World!" app you just built.
- 0 pro.android + [J] HelloActivity.java + [J] R.java
+ Ba Android Library
Figure 2-7. The structure of the "Hello World!" app
Android applications have some artifacts that are required and some that are optional. Table 2-1 summarizes the elements of an Android application. (Note that Android 1.5 adds a few elements; see Chapter 12 for details.)
Table 2-1. The Artifacts of an Android Application
AndroidManifest.xml src assets res drawable layout values xml raw
The Android application descriptor file. This file defines the Yes activities, content providers, services, and intent receivers of the application. You can also use this file to declaratively define permissions required by the application, as well as grant specific permissions to other applications using the services of the application. Moreover, the file can contain instrumentation detail that you can use to test the application or another application.
A folder containing all of the source code of the application. Yes
An arbitrary collection of folders and files. No
A folder containing the resources of the application. It's the Yes parent folder of drawable, anim, layout, values, xml, and raw.
A folder containing the images or image-descriptor files used No by the application.
A folder containing the XML-descriptor files that describe the No animations used by the application.
A folder containing views of the application. You should cre- No ate your application's views by using XML descriptors rather than coding them.
A folder containing other resources used by the application. No All the resources in the folder are also defined with XML descriptors. Examples of resources included in this folder include strings, styles, and colors.
A folder containing additional XML files used by the application. No
A folder containing additional data—possibly non-XML No data—that is required by the application.
As you can see from Table 2-1, an Android application is primarily made up of three pieces: the application descriptor, a collection of various resources, and the application's source code. If you put aside the AndroidManifest.xml file for a moment, you can view an Android app in this simple way: you have some business logic implemented in code, and everything else is a resource. This basic structure resembles the basic structure of a J2EE app, where the resources correlate to JSPs, the business logic correlates to servlets, and the AndroidManifest.xml file correlates to the web.xml file.
You can also compare J2EE's development model to Android's development model. In J2EE, the philosophy of building views is to build them using markup language. Android has also adopted this approach, although the markup in Android is XML. You benefit from this approach because you don't have to hard-code your application's views; you can modify the look and feel of the application by editing the markup.
It is also worth noting a few constraints regarding resources. First, Android supports only a linear list of files within the predefined folders under res. For example, it does not support nested folders under the layout folder (or the other folders under res). Second, there are some similarities between the assets folder and the raw folder under res. Both folders can contain raw files, but the files within raw are considered resources and the files within assets are not. So the files within raw will be localized, accessible through resource IDs, and so on. But the contents of the assets folder are considered general-purpose contents, to be used without resource constraints and support. Note that because the contents of the assets folder are not considered resources, you can put an arbitrary hierarchy of folders and files within it. (We'll talk a lot more about resources in Chapter 3.)
Note You might have noticed that XML is used quite heavily with Android. We all know that XML is a bloated data format, so this begs the question, "Does it make sense to rely on XML when you know your target is going to be a device with limited resources?" It turns out that the XML we create during development is actually compiled down to binary using the Android Asset Packaging Tool (AAPT). Therefore, when your application is installed on a device, the files on the device are stored as binary. When the file is needed at runtime, the file is read in its binary form and is not transformed back into XML. This gives us the benefits of both worlds—we get to work with XML and not have to worry about taking up valuable resources on the device.
Was this article helpful?