Mark Murphy - Beginning Android

Android has similar concepts, but packaged differently, and structured to make phones more crash-resistant.

The building block of the user interface is the activity. You can think of an activity as being the Android analogue for the window or dialog in a desktop application.

While it is possible for activities to not have a user interface, most likely your “headless” code will be packaged in the form of content providers or services, like the following described.

Content providers provide a level of abstraction for any data stored on the device that is accessible by multiple applications. The Android development model encourages you to make your own data available to other applications, as well as your own — building a content provider lets you do that, while maintaining complete control over how your data gets accessed.

Intents are system messages, running around the inside of the device, notifying applications of various events, from hardware state changes (e.g., an SD card was inserted), to incoming data (e.g., an SMS message arrived), to application events (e.g., your activity was launched from the device’s main menu). Not only can you respond to intents, but you can create your own, to launch other activities, or to let you know when specific situations arise (e.g., raise such-and-so intent when the user gets within 100 meters of this-and-such location).

Activities, content providers, and intent receivers are all short-lived and can be shut down at any time. Services, on the other hand, are designed to keep running, if needed, independent of any activity. You might use a service for checking for updates to an RSS feed, or to play back music even if the controlling activity is no longer operating.

Android comes with a number of features to help you develop applications.

You can package data files with your application, for things that do not change, such as icons or help files. You also can carve out a small bit of space on the device itself, for databases or files containing user-entered or retrieved data needed by your application. If the user supplies bulk storage, like an SD card, you can read and write files on there as needed.

Android devices will generally be Internet-ready, through one communications medium or another. You can take advantage of the Internet access at any level you wish, from raw Java sockets all the way up to a built-in WebKit-based Web browser widget you can embed in your application.

Android devices have the ability to play back and record audio and video. While the specifics may vary from device to device, you can query the device to learn its capabilities and then take advantage of the multimedia capabilities as you see fit, whether that is to play back music, take pictures with the camera, or use the microphone for audio note-taking.

Android devices will frequently have access to location providers, such as GPS, that can tell your applications where the device is on the face of the Earth. In turn, you can display maps or otherwise take advantage of the location data, such as tracking a device’s movements if the device has been stolen.

Of course, Android devices are typically phones, allowing your software to initiate calls, send and receive SMS messages, and everything else you expect from a modern bit of telephony technology.

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 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, particularly for the sample code referenced in this book, which can be found in the Source Code area of the Apress Web Site at http://apress.com.

When you create a new Android project (e.g., via the activitycreatorscript, which you will see in Chapter 4, or an Android-enabled IDE), you get several items in the project’s root directory:

• AndroidManifest.xml, an XML file describing the application being built and what components — activities, services, etc. — are being supplied by that application

• build.xml, an Ant [5] http://ant.apache.org/ script for compiling the application and installing it on the device

• default.properties, a property file used by the Ant build script

• bin/holds the application once it is compiled

• libs/holds any third-party Java JARs your application requires

• src/holds the Java source code for the application

• res/holds resources, such as icons, GUI layouts, and the like, that get packaged with the compiled Java in the application

• assets/holds other static files you wish packaged with the application for deployment onto the device

When you create an Android project (e.g., via activitycreator), you supply the fully-qualified class name of the “main” activity for the application (e.g., com.commonsware.android.SomeDemo). 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/commonsware/android/SomeDemo.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.javayourself, 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).

As already mentioned, the res/directory tree 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/menu/for XML-based menu 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

We will cover all of these and more in later chapters of this book, particularly Chapter 19.

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.dexholds the executable created from those compiled Java classes