The Android SDK is completely open. There's no cost to download or use the API, and Google doesn't charge (or require review) to distribute your finished programs on the Android Market or otherwise. You can download the latest version of the SDK for your development platform from the Android development homepage at http://developer.android.com/sdk/index.html

The SDK is presented as a ZIP file containing only the latest version of the Android developer tools. Install it by unzipping the SDK into a new folder. (Take note of this location, as you'll need it later.)

Before you can begin development you need to add at least one SDK Platform; do this on Windows by running the "SDK Setup.exe" executable, or on MacOS or Linux by running the "android" executable in the tools subfolder. In the screen that appears, select the "Available Packages" option on the left panel, and then select the SDK Platform versions you wish to install in the "Sources, Packages, and Archives" panel on the right. The selected platform will then be downloaded to your SDK installation folder and will contain the API libraries, documentation, and several sample applications.

The examples and step-by-step instructions provided are targeted at developers using Eclipse with the Android Developer Tool (ADT) plug-in. Neither is required, though — you can use any text editor or Java IDE you're comfortable with and use the developer tools in the SDK to compile, test, and debug the code snippets and sample applications.

If you're planning to use them, the next sections explain how to set up Eclipse and the ADT plug-in as your Android development environment. Later in the chapter we'll also take a closer look at the developer tools that come with the SDK, so if you'd prefer to develop without using Eclipse or the ADT plug-in you'll particularly want to check that out.

Using Eclipse with the ADT plug-in for your Android development offers some significant advantages.

Eclipse is an open-source IDE (integrated development environment) particularly popular for Java development. It's available for download for each of the development platforms supported by Android (Windows, MacOS, and Linux) from the Eclipse foundation homepage: www.eclipse.org/downloads/

There are many variations available; the following is the recommended configuration for Android:

WST and the JDT plug-in are included in most Eclipse IDE packages.

Installing Eclipse consists of uncompressing the download into a new folder. When that's done, run the eclipse executable. When it starts for the first time, create a new workspace for your Android development projects.

The ADT plug-in for Eclipse simplifies your Android development by integrating the developer tools, including the emulator and .class-to-.dex converter, directly into the IDE. While you don't have to use the ADT plug-in, it does make creating, testing, and debugging your applications faster and easier.

The ADT plug-in integrates the following into Eclipse:

Figure 2-1 shows the DDMS perspective within Eclipse with the ADT plug-in installed.

Installing the ADT Plug-In

Install the developer tools plug-in by following these steps:

1. Select Help

   

2. In the resulting dialog box enter the following address into the Work With text entry box and press Enter: http://dl-ssl.google.com/android/eclipse/

3. Eclipse will now search for the ADT plug-in. When finished it will display the available plug-in, as shown in Figure 2-2. Select it by clicking the checkbox next to the Developer Tools root node, and click Next.

4. Eclipse will now download the plug-in. When it's finished, ensure both the Android DDMS and Android Developer Tools plug-ins are selected and click Next.

   

   Figure 2-1. FIGURE 2-1

5. Read and then Accept the terms of the license agreement, and click Next and then Finish. As the ADT plug-in is not signed, you'll be prompted before the installation continues.

6. When installation is complete you'll have to restart Eclipse and update the ADT preferences. Restart and select Window

   

7. Then select Android from the left panel.

8. Click Browse... and navigate to the folder into which you unzipped the Android SDK; then click Apply. The list will then update to display each of the available SDK targets, as in Figure 2-3. Click OK to complete the SDK installation.

Note

If you download a new version of the SDK and place it in a different location, you will need to update this preference to reflect the SDK with which the ADT should be building.

Figure 2-2. FIGURE 2-2

Figure 2-3. FIGURE 2-3

To create a new Android project using the Android New Project Wizard, do the following:

Figure 2-4. FIGURE 2-4

If you selected Create Activity the ADT plug-in will create a new project that includes a class that extends Activity. Rather than being completely empty, the default template implements Hello World. Before modifying the project, take this opportunity to configure launch configurations for running and debugging.

Launch configurations let you specify runtime options for running and debugging applications. Using a launch configuration you can specify the following:

You can specify different launch configurations for running and debugging applications. The following steps show how to create a launch configuration for an Android application:

You've created your first project and created the run and debug configurations for it. Before making any changes, test your installation and configurations by running and debugging the Hello World project.

From the Run menu select Run or Debug to launch the most recently selected configuration, or select Run Configurations... or Debug Configurations... to select a specific configuration to use.

If you're using the ADT plug-in, running or debugging your application does the following:

If you're debugging, the Eclipse debugger will then be attached, allowing you to set breakpoints and debug your code.

If everything is working correctly you'll see a new Activity running in the emulator, as shown in Figure 2-7.

Let's take a step back and have a real look at your first Android application.

Activity is the base class for the visual, interactive components of your application; it is roughly equivalent to a Form in traditional desktop development. Listing 2-1 shows the skeleton code for an Activity-based class; note that it extends Activity, overriding the onCreate method.

package com.paad.helloworld;

import android.app.Activity;
import android.os.Bundle;

public class HelloWorld extends Activity {

  /** Called when the activity is first created. */
  @Override
  public void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
  }
}

Figure 2-7. FIGURE 2-7

What's missing from this template is the layout of the visual interface. In Android, visual components are called Views, which are similar to controls in traditional desktop development.

The Hello World template created by the wizard overrides the onCreate method to call setContentView, which lays out the user interface by inflating a layout resource, as highlighted below:

@Override
public void onCreate(Bundle savedInstanceState) {
  super.onCreate(savedInstanceState);
  setContentView(R.layout.main);
}

The resources for an Android project are stored in the res folder of your project hierarchy, which includes drawable, layout, and values subfolders. The ADT plug-in interprets these resources to provide design-time access to them through the R variable, as described in Chapter 3.

Listing 2-2 shows the UI layout defined in the main.xml file created by the Android project template.

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
  android:orientation="vertical"
  android:layout_width="fill_parent"
  android:layout_height="fill_parent">
  <TextView
    android:layout_width="fill_parent"
    android:layout_height="wrap_content"
    android:text="Hello World, HelloWorld"
  />
</LinearLayout>

Defining your UI in XML and inflating it is the preferred way of implementing your user interfaces, as it neatly decouples your application logic from your UI design.

To get access to your UI elements in code, you add identifier attributes to them in the XML definition. You can then use the findViewById method to return a reference to each named item. The following XML snippet shows an ID attribute added to the Text View widget in the Hello World template:

<TextView
android:id="@+id/myTextView"
  android:layout_width="fill_parent"
  android:layout_height="wrap_content"
  android:text="Hello World, HelloWorld"
/>

And the following snippet shows how to get access to it in code:

TextView myTextView = (TextView)findViewById(R.id.myTextView);

Alternatively (although it's not generally considered good practice), you can create your layout directly in code, as shown in Listing 2-3.

public void onCreate(Bundle savedInstanceState) {
  super.onCreate(savedInstanceState);

  LinearLayout.LayoutParams lp;
  lp = new LinearLayout.LayoutParams(LayoutParams.FILL_PARENT,
                                     LayoutParams.FILL_PARENT);

  LinearLayout.LayoutParams textViewLP;
  textViewLP = new LinearLayout.LayoutParams(LayoutParams.FILL_PARENT,
                                             LayoutParams.WRAP_CONTENT);

  LinearLayout ll = new LinearLayout(this);
  ll.setOrientation(LinearLayout.VERTICAL);

  TextView myTextView = new TextView(this);
  myTextView.setText("Hello World, HelloWorld");

ll.addView(myTextView, textViewLP);
  this.addContentView(ll, lp);
}

All the properties available in code can be set with attributes in the XML layout. As well as allowing easier substitution of layout designs and individual UI elements, keeping the visual design decoupled from the application code helps keep the code more concise.

You'll learn how to create complex layouts and about the Views used to populate them in Chapter 4.

When creating foreground applications you need to carefully consider the Activity life cycle (described in Chapter 3) so that the Activity switches seamlessly between the foreground and the background.

Applications have little control over their life cycles, and a background application with no running Services is a prime candidate for cleanup by Android's resource management. This means that you need to save the state of the application when it is no longer in the foreground, to let you present the exact same state when it is brought to the front.

It's also particularly important for foreground applications to present a slick and intuitive user experience. You'll learn more about creating well-behaved and attractive foreground Activities in Chapters 3 and 4.

These applications run silently in the background with very little user input. They often listen for messages or actions caused by the hardware, system, or other applications, rather than rely on user interaction.

It's possible to create completely invisible services, but in practice it's better form to provide at least some sort of user control. At a minimum you should let users confirm that the service is running and let them configure, pause, or terminate it as needed.

Services and Intent Receivers, the driving forces of background applications, are covered in depth in Chapters 5 and 9.

Often you'll want to create an application that reacts to user input but is still useful when it's not active in the foreground. Chat and e-mail apps are typical examples. These applications are generally a union of visible Activities and invisible background Services.

Such an application needs to be aware of its state when interacting with the user. This might mean updating the Activity UI when it's visible and sending notifications to keep the user updated when it's in the background, as seen in the section on Notifications and Services in Chapter 9.

In some circumstances your application may consist entirely of a widget component. Using widgets, described in detail in Chapter 10, you can create interactive visual components that users can add to their home screens.

Widget-only applications are commonly used to display dynamic information such as battery levels, weather forecasts, or the date and time.

Manufacturers of embedded devices, particularly mobile devices, generally value small size and long battery life over potential improvements in processor speed. For developers, that means losing the head start traditionally afforded thanks to Moore's law (the doubling of the number of transistors placed on an integrated circuit every two years). In desktop and server hardware this usually results directly in processor performance improvements; for mobile devices it instead means smaller, more power-efficient mobiles without significant improvement in processor power.

In practice, this means that you always need to optimize your code so that it runs quickly and responsively, assuming that hardware improvements over the lifetime of your software are unlikely to do you any favors.

Since code efficiency is a big topic in software engineering, I'm not going to try to capture it here. Later in this chapter you'll learn some Android-specific efficiency tips, but for now just note that efficiency is particularly important for resource-constrained environments like mobile devices.

Advances in flash memory and solid-state disks have led to a dramatic increase in mobile-device storage capacities (though MP3 collections still tend to expand to fill the available storage). While an 8 GB flash drive or SD card is no longer uncommon in mobile devices, optical disks offer over 32 GB, and terabyte drives are now commonly available for PCs. Given that most of the available storage on a mobile device is likely to be used to store music and movies, most devices offer relatively limited storage space for your applications.

Android devices offer an additional restriction in that applications must be installed on the internal memory (as opposed to external SD cards). As a result, the compiled size of your application is a consideration, though more important is ensuring that your application is polite in its use of system resources.

You should carefully consider how you store your application data. To make life easier you can use the Android databases and Content Providers to persist, reuse, and share large quantities of data, as described in Chapter 7. For smaller data storage, such as preferences or state settings, Android provides an optimized framework, as described in Chapter 6.

Of course, these mechanisms won't stop you from writing directly to the file system when you want or need to, but in those circumstances always consider how you're structuring these files, and ensure that yours is an efficient solution.

Part of being polite is cleaning up after yourself. Techniques like caching are useful for limiting repetitive network lookups, but don't leave files on the file system or records in a database when they're no longer needed.

The small size and portability of mobiles are a challenge for creating good interfaces, particularly when users are demanding an increasingly striking and information-rich graphical user experience.

Write your applications knowing that users will often only glance at the (small) screen. Make your applications intuitive and easy to use by reducing the number of controls and putting the most important information front and center.

Graphical controls, like the ones you'll create in Chapter 4, are an excellent means of displaying a lot of information in a way that's easy to understand. Rather than a screen full of text with lots of buttons and text-entry boxes, use colors, shapes, and graphics to convey information.

If you're planning to include touch-screen support (and if you're not, you should be), you'll need to consider how touch input is going to affect your interface design. The time of the stylus has passed; now it's all about finger input, so make sure your Views are big enough to support interaction using a finger on the screen. There's more information on touch-screen interaction in Chapter 15.

Android phones are now available with a variety of screen sizes including QVGA, HVGA, and WVGA. As display technology advances, and Android expands beyond mobile devices, screen sizes and resolutions will continue to increase. To ensure that your app looks good and behaves well on all the possible host devices it's important to design for small screens, but also make sure your UIs scale well on larger displays. You'll learn some techniques for optimizing your UI for different screen sizes in Chapter 3.

In Chapter 5 you'll learn how to use Internet resources in your applications. The ability to incorporate some of the wealth of online information in your applications is incredibly powerful.

The mobile Web unfortunately isn't as fast, reliable, or readily available as we'd often like, so when you're developing your Internet-based applications it's best to assume that the network connection will be slow, intermittent, and expensive. With unlimited 3G data plans and citywide Wi-Fi, this is changing, but designing for the worst case ensures that you always deliver a high-standard user experience.

This also means making sure that your applications can handle losing (or not finding) a data connection.

The Android Emulator lets you control the speed and latency of your network connection. Figure 2-8 shows the emulator's network connection speed and latency, simulating a distinctly suboptimal EDGE connection.

Experiment to ensure seamlessness and responsiveness no matter what the speed, latency, and availability of network access. In some circumstances you might find that it's better to limit the functionality of your application or reduce network lookups to cached bursts, based on the network connection(s) available. Details on how to detect the kind of network connections available at run time, and their speeds, are included in Chapter 13.

If you're a mobile owner, you know all too well that some of the more powerful features on your mobile can literally come at a price. Services like SMS, some location-based services, and data transfer can sometimes incur an additional tariff from your service provider.

Figure 2-8. FIGURE 2-8

It's obvious why it's important that any costs associated with functionality in your applications be minimized, and that users be aware when an action they perform might result in their being charged.

It's a good approach to assume that there's a cost associated with any action involving an interaction with the outside world. In some cases (such as with GPS and data transfer) the user can toggle Android settings to disable a potentially costly action. As a developer it's important that you use and respect those settings within your application.

In any case, it's important to minimize interaction costs by doing the following:

Often the best solution is to use a lower-quality option that comes at a lower cost.

When using the location-based services described in Chapter 8, you can select a location provider based on whether there is an associated cost. Within your location-based applications, consider giving users the choice of lower cost or greater accuracy.

In some circumstances costs are hard to define, or they're different for different users. Charges for services vary between service providers and contract plans. While some people will have free unlimited data transfers, others will have free SMS.

Rather than enforcing a particular technique based on which seems cheaper, consider letting your users choose. For example, when downloading data from the Internet, you could ask users if they want to use any network available or limit their transfers to times when they're connected via Wi-Fi.

In a resource-constrained environment, being fast means being efficient. A lot of what you already know about writing efficient code will be just as applicable to Android, but the limitations of embedded systems and the use of the Dalvik VM mean you can't take things for granted.

The smart bet for advice is to go to the source. The Android team has published some specific guidance on writing efficient code for Android, so rather than rehash their advice, I suggest you visit http://developer.android.com/guide/practices/design/performance.html and take note of their suggestions.

One of the keys to writing efficient Android code is not to carry over assumptions from desktop and server environments to embedded devices.

At a time when 2 to 4 GB of memory is standard for most desktop and server rigs, typical smartphones feature around 200 MB of SDRAM. With memory such a scarce commodity, you need to take special care to use it efficiently. This means thinking about how you use the stack and heap, limiting object creation, and being aware of how variable scope affects memory use.

Android takes responsiveness very seriously.

Android enforces responsiveness with the Activity Manager and Window Manager. If either service detects an unresponsive application, it will display the dreaded "Sorry! Activity is not responding" message — often reported by users as a Force Close error. This is shown in Figure 2-9.

This alert is modal, steals focus, and won't go away until you hit a button or your application starts responding. It's pretty much the last thing you ever want to confront a user with.

Android monitors two conditions to determine responsiveness:

Figure 2-9. FIGURE 2-9

The most likely culprits in cases of unresponsiveness are network lookups, complex processing (such as the calculating of game moves), and file I/O. There are a number of ways to ensure that these actions don't exceed the responsiveness conditions, in particular by using Services and worker threads, as shown in Chapter 9.

Android applications have access to networks and hardware, can be distributed independently, and are built on an open-source platform featuring open communication, so it shouldn't be surprising that security is a significant concern.

For the most part, users need to take responsibility for the applications they install and the permissions requests they accept. The Android security model restricts access to certain services and functionality by forcing applications to declare the permissions they require. During installation users are shown the application's required permissions before they commit to installing it. (You can learn more about Android's security model in Chapter 15 and at http://developer.android.com/guide/appendix/faq/security.html)

This doesn't get you off the hook. You not only need to make sure your application is secure for its own sake, you also need to ensure that it can't be hijacked to compromise the device. You can use several techniques to help maintain device security, and they'll be covered in more detail as you learn the technologies involved. In particular, you should do the following:

The idea of a seamless user experience is an important, if somewhat nebulous, concept. What do we mean by seamless? The goal is a consistent user experience in which applications start, stop, and transition instantly and without noticeable delays or jarring transitions.

The speed and responsiveness of a mobile device shouldn't degrade the longer it's on. Android's process management helps by acting as a silent assassin, killing background applications to free resources as required. Knowing this, your applications should always present a consistent interface, regardless of whether they're being restarted or resumed.

With an Android device typically running several third-party applications written by different developers, it's particularly important that these applications interact seamlessly. Using Intents, applications can provide functionality for each other. Knowing your application may provide, or consume, third-party Activities provides additional incentive to maintain a consistent look and feel.

Use a consistent and intuitive approach to usability. You can create applications that are revolutionary and unfamiliar, but even these should integrate cleanly with the wider Android environment.

Persist data between sessions, and when the application isn't visible, suspend tasks that use processor cycles, network bandwidth, or battery life. If your application has processes that need to continue running while your Activities are out of sight, use a Service, but hide these implementation decisions from your users.

When your application is brought back to the front, or restarted, it should seamlessly return to its last visible state. As far as your users are concerned, each application should be sitting silently, ready to be used but just out of sight.

You should also follow the best-practice guidelines for using Notifications and use generic UI elements and themes to maintain consistency among applications.

There are many other techniques you can use to ensure a seamless user experience, and you'll be introduced to some of them as you discover more of the possibilities available in Android in the coming chapters.

Android Virtual Devices are used to simulate the software builds and hardware specifications available on different devices. This lets you test your application on a variety of hardware platforms without needing to buy a variety of phones.

Each virtual device is configured with a name, a target build of Android (based on the SDK version it supports), an SD Card capacity, and screen resolution, as shown in the "Create new AVD" dialog in Figure 2-17.

Each virtual device also supports a number of specific hardware settings and restrictions that can be added in the form of NVPs in the hardware table. These additional settings include:

Different hardware settings and screen resolutions will present alternative user-interface skins to represent the different hardware configurations. This simulates a variety of mobile device types. To complete the illusion, you can create a custom skin for each virtual device to make it look like the device it is emulating.

Use the installed and available package tabs to manage your SDK installations.

Installed Packages, shown in Figure 2-18, displays the SDK platforms, documentation, and tools you have available to use in your development environment. When updating to a new version you can simply click the Update All... button to have the manager update your SDK installation with the latest version of each component.

Figure 2-18. FIGURE 2-18

Alternatively, Available Packages checks the Android SDK repository for any source, packages, and archives available but not yet installed on your system. Use the checkboxes, as shown in Figure 2-19, to select additional SDK packages to install.

Figure 2-19. FIGURE 2-19