Friday 15 April 2011

Project Structure of Android Programming



The Android build system is organized around a specific directory tree structure for your Android project, much like any other Java project. The specifics, though, are fairly unique to Android and what it all does to prepare the actual application that will run on the device or emulator. Here's a quick primer on the project structure, to help you make sense of it all.

Root Contents

When you create a new Android project (e.g., via activityCreator.py), you
Get five key items in the project's root directory:

• AndroidManifest.xml, which is an XML file describing the application
Being built and what components – activities, services, etc. – are
Being supplied by that application

• build.xml, which is an Ant script for compiling the application and
Installing it on the device

• Bin/, which holds the application once it is compiled

• Sac/, which holds the Java source code for the application

• Res/, which holds "resources", such as icons, GUI layouts, and the
Like, that gets packaged with the compiled Java in the application

• Assets/, which hold other static files you wish packaged with the
Application for deployment onto the device

The Sweat Off Your Brow

When you created the project (e.g., via activityCreator.py), you supplied the fully-qualified class name of the "main" activity for the application (e.g., com.android.demo). You will then find that your project's src/ tree already has the namespace directory tree in place, plus a stub Activity subclass representing your main activity (e.g., src/com/ android/Demo.java). You are welcome to modify this file and add others to the src/ tree as needed to implement your application.


The first time you compile the project (e.g., via ant), out in the "main" activity's namespace directory, the Android build chain will create R.java. This contains a number of constants tied to the various resources you placed out in the res/ directory tree. You should not modify R.java yourself, letting the Android tools handle it for you. You will see throughout many of the samples where we reference things in R.java (e.g., referring to a layout's identifier via R.layout.main).

And Now, the Rest of the Part of Structure

You will also find that your project has a res/ directory tree. This holds "resources" – static files that are packaged along with your application, either in their original form or, occasionally, in a preprocessed form. Some of the subdirectories you will find or create under res/ include:

• Res/drawable/ for images (PNG, JPEG, etc.)
• Res/layout/ for XML-based UI layout specifications
• Res/raw/ for general-purpose files (e.g., a CSV file of account
Information)
• Res/values/ for strings, dimensions, and the like
• Res/xml/ for other general-purpose XML files you wish to ship

What You Get Out Of It

When you compile your project (via ant or the IDE), the results go into the
Bin/ directory under your project root. Specifically:

• bin/classes/ holds the compiled Java classes
• Bin/classes.dex holds the executable created from those compiled
Java classes
• bin/yourapp.apk is the actual Android application (where yourapp is
the name of your application)

The .apk file is a ZIP archive containing the .dex file, the compiled edition of
your resources (resources.arsc), any un-compiled resources (such as what
You put in res/raw/) and the AndroidManifest.xml file.




Inside the Manifest

The foundation for any Android application is the manifest file: Android Manifest.xml in the root of your project. Here is where you declare
What all is inside your application – the activities, the services, and so on.
You also indicate how these pieces attach themselves to the overall Android
System; for example, you indicate which activity (or activities) should appear
On the device's main menu (a.k.a., launcher).

When you create your application, you will get a starter manifest generated
For you. For a simple application, offering a single activity and nothing else,
the auto-generated manifest will probably work out fine, or perhaps require
a few minor modifications. On the other end of the spectrum, the manifest
file for the Android API demo suite is over 1,000 lines long. Your production
Android applications will probably fall somewhere in the middle.

Most of the interesting bits of the manifest will be described in greater detail in the chapters on their associated Android features. For example, the service element will be described in greater detail in the chapter on creating services. For now, we just need to understand what the role of the manifest is and its general overall construction.

In The Beginning, There Was the Root, And It
Was Good

The root of all manifest files is, not surprisingly, a manifest element:


...


Note the namespace declaration. Curiously, the generated manifests only apply it on the attributes, not the elements (e.g., it's manifest, not android: manifest). However, that pattern works, so unless Android changes, stick with their pattern.

The biggest piece of information you need to supply on the manifest element is the package attribute (also curiously not-name spaced). Here, you can provide the name of the Java package that will be considered the "base" of your application. Then, everywhere else in the manifest file that needs a class name, you can just substitute a leading dot as shorthand for the package. For example, if you needed to refer to com.joomlavogue.android.Snicklefritz in this manifest shown above, you could just use .Snicklefritz, since com.joomlavogue.android is defined as the
Application’s package.


Permissions, Instrumentations, and Applications

Underneath the manifest element, you will find:

•uses-permission elements, to indicate what permissions your application will need in order to function properly – see the chapter on permissions for more details

• permission elements, to declare permissions that activities or services might require other applications hold in order to use your application's data or logic –again, more details are forthcoming in the chapter on permissions

• instrumentation elements, to indicate code that should be invoked on key system events, such as starting up activities, for the purposes of logging or monitoring

• an application element, defining the guts of the application that the manifest describes







...

In the preceding example, the manifest has uses-permission elements to indicate some device capabilities the application will need – in this case, permissions to allow the application to determine its current location. And, there is the application element, whose contents will describe the activities, services, and whatnot that make up the bulk of the application itself.




No comments:

Post a Comment