Android has similar concepts, but packaged differently, and structured to make phones more crash-resistant.
Activities
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
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
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).
Services
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.
Stuff at Your Disposal
Android comes with a number of features to help you develop applications.
Storage
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.
Network
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.
Multimedia
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.
GPS
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.
Phone Services
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.
CHAPTER 2
Project Structure
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.
Root Contents
When you create a new Android project (e.g., via the activitycreator script, 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] 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
The Sweat of Your Brow
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.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).
The Rest of the Story
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