Asynchronous Android: As an Android developer you know you're in a competitive marketplace. This book can give you the edge by guiding you through the concurrency constructs and proper use of AsyncTask to create smooth user interfaces.

AsyncTask was introduced in Android at API level 3, Cupcake, with the express purpose of helping developers to avoid blocking the main thread. The Async part of the name of this class comes from the word asynchronous, which literally means not occurring at the same time.

AsyncTask is an abstract class, and as such, must be subclassed for use. At the minimum, our subclass must provide an implementation for the abstract doInBackground method, which defines the work that we want to get done off the main thread.

protected Result doInBackground(Params… params)

There are four other methods of AsyncTask which we may choose to override:

protected void onPreExecute()
protected void onProgressUpdate(Progress… values)
protected void onPostExecute(Result result)
protected void onCancelled(Result result)

Although we will override one or more of these five methods, we will not invoke them directly from our own code. These are callback methods, meaning that they will be invoked for us...

AsyncTask is a generically typed class, and exposes three type parameters:

abstract class AsyncTask<Params, Progress, Result>

When we declare an AsyncTask subclass, we'll specify types for Params, Progress, and Result; for example, if we want to pass a String parameter to doInBackground, report progress as a Float, and return a Boolean result, we would declare our AsyncTask subclass as follows:

public class MyTask extends AsyncTask<String, Float, Boolean>

If we don't need to pass any parameters, or don't want to report progress, a good type to use for those parameters is java.lang.Void, which signals our intent clearly, because Void is an uninstantiable class representing the void keyword.

Let's take a look at a first example, performing an expensive calculation in the background and reporting the result to the main thread:

public class PrimesTask
extends AsyncTask<Integer, Void, BigInteger> {
  private TextView resultView;

  public PrimesTask(TextView...

Having implemented doInBackground and onPostExecute, we want to get our task running. There are two methods we can use for this, each offering different levels of control over the degree of concurrency with which our tasks are executed. Let's look at the simpler of the two methods first:

public final AsyncTask<Params, Progress, Result> execute(Params… params)

The return type is the type of our AsyncTask subclass, which is simply for convenience so that we can use method chaining to instantiate and start a task in a single line and still record a reference to the instance:

class MyTask implements AsyncTask<String,Void,String>{ … }
MyTask task = new MyTask().execute("hello");

The Params… params argument is the same Params type we used in our class declaration, because the values we supply to the execute method are later passed to our doInBackground method as its Params… params arguments. Notice that it is a varargs parameter, meaning that we can pass any number...

Having started what we know to be a potentially long-running task, we probably want to let the user know that something is happening. There are a lot of ways of doing this, but a common approach is to present a dialog displaying a relevant message.

A good place to present our dialog is from the onPreExecute method of AsyncTask, which executes on the main thread. Hence, it is allowed to interact with the user interface.

The modified PrimesTask will need a reference to a Context, so that it can prepare a ProgressDialog, which it will show and dismiss in onPreExecute and onPostExecute respectively. As doInBackground has not changed, it is not shown in the following code, for brevity:

public class PrimesTask extends AsyncTask<Integer, Void, BigInteger>{
  private Context ctx;
  private ProgressDialog progress;
  private TextView resultView;

  public PrimesTask(Context ctx, TextView resultView) {
    this.ctx = ctx;
      this.resultView = resultView;
  }

...

Another nice usability touch we can provide for our users is the ability to cancel a task before it completes—for example, if the task depends on some user input and, after starting the execution, the user realizes that they have provided the wrong value. AsyncTask provides support for cancellation with the cancel method.

public final boolean cancel(boolean mayInterruptIfRunning)

The mayInterruptIfRunning parameter allows us to specify whether an AsyncTask thread that is in an interruptible state may actually be interrupted—for example, if our doInBackground code is performing interruptible I/O.

Simply invoking cancel is not sufficient to cause our task to finish early. We need to actively support cancellation by periodically checking the value returned from isCancelled and reacting appropriately in doInBackground.

First, let's set up our ProgressDialog to trigger the AsyncTask's cancel method by adding a few lines to onPreExecute:

progress.setCancelable(true);
progress.setOnCancelListener...

The callback methods defined by AsyncTask dictate that we cannot throw checked exceptions, so we must wrap any code that throws checked exceptions with try/catch blocks. Unchecked exceptions that propagate out of AsyncTask's methods will crash our application, so we must test carefully and handle these if necessary.

For the callback methods that run on the main thread—onPreExecute, onProgressUpdate, onPostExecute, and onCancelled—we can catch exceptions in the method and directly update the user interface to alert the user.

Of course, exceptions are likely to arise in our doInBackground method too, as this is where the bulk of the work of AsyncTask is done, but unfortunately, we can't update the user interface from doInBackground. A simple solution is to have doInBackground return an object that may contain either the result or an exception, as follows:

static class Result<T> {
  private T actual;
  private Exception exc;
}
@Override
protected final Result<T&gt...

So far, we've carefully avoided being too specific about what exactly happens when we invoke AsyncTask's execute method. We know that doInBackground will execute off the main thread, but what exactly does that mean?

The original goal of AsyncTask was to help developers avoid blocking the main thread. In its initial form at API level 3, AsyncTasks were queued and executed serially (that is, one after the other) on a single background thread, guaranteeing that they would complete in the order they were started.

This changed in API level 4 to use a pool of up to 128 threads to execute multiple AsyncTasks concurrently with each other—a level of concurrency of up to 128. At first glance, this seems like a good thing, since a common use case for AsyncTask is to perform blocking I/O, where the thread spends much of its time idly waiting for data.

However, as we saw in Chapter 1, Building Responsive Android Applications, there are many issues that commonly arise...

As with any powerful programming abstraction, AsyncTask is not entirely free from issues and compromises.

Now that we have seen how to use AsyncTask, we might ask ourselves when we should use it.

Good candidate applications for AsyncTask tend to be relatively short-lived operations (at most, for a second or two), which pertain directly to a specific Fragment or Activity and need to update its user interface.

AsyncTask is ideal for running short, CPU-intensive tasks, such as number crunching or searching for words in large text strings, moving them off the main thread so that it can remain responsive to input and maintain high frame rates.

Blocking I/O operations such as reading and writing text files, or loading images from local files with BitmapFactory, are also good use cases for AsyncTask.

Of course, there are use cases for which AsyncTask is not ideally suited. For anything that requires more than a second or two, we should weigh the cost of performing this operation repeatedly if the user rotates the device, or switches between apps or activities, or whatever else...

In this chapter, we've taken a detailed look at AsyncTask and how to use it to write responsive applications that perform operations without blocking the main thread.

We saw how to keep the user informed of the progress, and even allow them to cancel operations early. We also learned how to deal with issues that can arise when the Activity lifecycle conspires against our background tasks.

Finally, we considered when to use AsyncTask, and when it might not be appropriate.

In the next chapter, we'll take a look at some lower-level constructs—fundamental building blocks on which the other concurrency mechanisms of the platform, including AsyncTask, are built.