Keeping Your App Responsive

The most effecive way to create a worker thread for longer operations is with the

AsyncTask

class. Simply extend

AsyncTask

and implement the

doInBackground()

method to perform the work. To post progress changes to the user, you can call

publishProgress()

, which invokes the

onProgressUpdate()

callback method. From your implementation of

onProgressUpdate()

(which runs on the UI thread), you can notify the user.

private class DownloadFilesTask extends AsyncTask<URL, Integer, Long> {
// Do the long-running work in here
protected Long doInBackground(URL... urls) {
int count = urls.length;
long totalSize = 0;
for (int i = 0; i < count; i++) {
totalSize += Downloader.downloadFile(urls[i]);
publishProgress((int) ((i / (float) count) * 100));
// Escape early if cancel() is called
if (isCancelled()) break;
}
return totalSize;
}

// This is called each time you call publishProgress()
protected void onProgressUpdate(Integer... progress) {
setProgressPercent(progress[0]);
}

// This is called when doInBackground() is finished
protected void onPostExecute(Long result) {
showNotification("Downloaded " + result + " bytes");
}
}

Although it's more complicated than

AsyncTask

, you might want to instead create your own

Thread

or

HandlerThread

class. If you do, you should set the thread priority to "background" priority by calling

Process.setThreadPriority()

and passing

THREAD_PRIORITY_BACKGROUND

. If you don't set the thread to a lower priority this way, then the thread could still slow down your app because it operates at the same priority as the UI thread by default.

If you implement

Thread

or

HandlerThread

, be sure that your UI thread does not block while waiting for the worker thread to complete—do not call

Thread.wait()

or

Thread.sleep()

. Instead of blocking while waiting for a worker thread to complete, your main thread should provide a

Handler

for the other threads to post back to upon completion. Designing your application in this way will allow your app's UI thread to remain responsive to input and thus avoid ANR dialogs caused by the 5 second input event timeout.

The specific constraint on

BroadcastReceiver

execution time emphasizes what broadcast receivers are meant to do: small, discrete amounts of work in the background such as saving a setting or registering a

Notification

. So as with other methods called in the UI thread, applications should avoid potentially long-running operations or calculations in a broadcast receiver. But instead of doing intensive tasks via worker threads, your application should start an

IntentService

if a potentially long running action needs to be taken in response to an intent broadcast.