8 ways to do asynchronous processing in Android and counting
Android provides several API’s to do asynchronous processing, compound these with what Java provides and you have (probably) dozens of ways to perform asynchronous tasks.
There is a tendency to just use Java threads or Android AsyncTasks for everything since they are well known and can do what you want. However, not all API is equal, choosing the right method for your requirements can make your code stable, cleaner, easier to read and more intuitive.
With that said, let’s jump into 7 ways of performing asynchronous jobs in Android. The options are sorted first by being part of the Android API or Java, then by how frequently I have encountered or used them.
AsyncTask
Perhaps the best known of the asynchronous API, AsyncTask is easy to implement and returns results on the main thread. There are some issues with AsyncTask, for example, they are not aware of the activity or fragment lifecycle and so it is the programmer's responsibility to handle the AsyncTasks behaviour when the activity is destroyed. This means that they are not the best option for long running operations and also, if the app is in the background and the app is terminated by Android, your background processing is also terminated.
new AsyncTask<URL, Integer, Long>() {
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;
}
protected void onProgressUpdate(Integer... progress) {
setProgressPercent(progress[0]);
}
protected void onPostExecute(Long result) {
showDialog("Downloaded " + result + " bytes");
}
}.execute(url1, url2, url3);
// Modified Code from google Android APIIntentService
This is the defacto choice for long running processing on Android, a good example would be to upload or download large files. The upload and download may continue even if the user exits the app and you certainly do not want to block the user from being able to use the app while these tasks are going on.
public class RSSPullService extends IntentService {
@Override
protected void onHandleIntent(Intent workIntent) {
// Gets data from the incoming Intent
String dataString = workIntent.getDataString();
...
// Do work here, based on the contents of dataString
...
} }// AndroidManifest.xml
<application
android:icon="@drawable/icon"
android:label="@string/app_name">
...
<!--
Because android:exported is set to "false",
the service is only available to this app.
-->
<service
android:name=".RSSPullService"
android:exported="false"/>
...
<application/>
Loader
Loaders are a complex topic, any single implementation of Loaders probably deserved a post all for itself. For now it would be worth pointing out that Loaders were introduced in Android Honeycomb and are part of the compatibility library. They are aware of Fragment and Activity lifecycle and can even cache loaded data.
I would like to bring attention to AsyncTaskLoaders as they solve a lot of problems that are inherent to AsyncTask. Android Design Patterns has an amazing write-up on Loaders and I recommend reading it to get a deeper understand of Loaders.
JobScheduler and GcmNetworkManager
The reason I’m bundling these 2 together is because they effectively are similar. JobScheduler was released in API 21 and as yet there is not official compatibility version from Google (Evan Tatarka has filled the void with JobSchedulerCompat). However, GcmNetworkManager that is bundled as part of Google Play 7.5 is something similar but specifically for network operations.
Using JobScheduler is a little complex, luckily there is a sample of how to use JobScheduler from Google. Effectively, you have to create a Service and create a job using JobInfo.Builder that specifies your criteria for when to run the service; such as being on a unmetered network, or when the app is charging. It is important to remember that there is no guarantee that your code will be executed as soon as these conditions are met or the order of the execution. Below is an extract from Google’s code on how to schedule a job.
JobInfo.Builder builder = new JobInfo.Builder(kJobId++,
mServiceComponent);String delay = mDelayEditText.getText().toString();
if (delay != null && !TextUtils.isEmpty(delay)) {
builder.setMinimumLatency(Long.valueOf(delay) * 1000);
}String deadline = mDeadlineEditText.getText().toString();
if (deadline != null && !TextUtils.isEmpty(deadline)) {
builder.setOverrideDeadline(Long.valueOf(deadline) * 1000);
}boolean requiresUnmetered =
mWiFiConnectivityRadioButton.isChecked();
boolean requiresAnyConnectivity =
.mAnyConnectivityRadioButton.isChecked();if (requiresUnmetered) {
builder.setRequiredNetworkType(JobInfo.NETWORK_TYPE_UNMETERED);
} else if (requiresAnyConnectivity) {
builder.setRequiredNetworkType(JobInfo.NETWORK_TYPE_ANY);
}builder.setRequiresDeviceIdle(mRequiresIdleCheckbox.isChecked());
builder.setRequiresCharging(mRequiresChargingCheckBox.isChecked());mTestService.scheduleJob(builder.build());// CANCEL JOBS
JobScheduler tm = (JobScheduler) getSystemService(Context.JOB_SCHEDULER_SERVICE);
tm.cancelAll();
I’ll let you see the GcmNetworkManager page for example code on how to use it. The general concept is similar where you have to schedule a Service to run when certain criteria are met. The Scheduled Tasks can be One-off or Periodic.
CountDownTimer
No prizes for guessing what this is used for. This is very easy to use however it is context sensitive, so if you exit your Activity or Fragment, you need to clean this up by cancelling it. To be clear, there really is nothing Asynchronous about CountDownTimer. If you look at it’s source, it simply posts delayed messages on a Handler which means that it will run on whatever thread you launch it from and onTick() and onFinish() will be executed on whatever thread you run the CountDownTimer from so you can do UI updates in it. For this reason, it’s also important to not do any heavy operations onTick() or onFinish(). The reason CountDownTimer is included in the list is because using this class does not block the user from using the app even when the CountDownTimer is initialised from the main thread, effectively giving a asynchronous effect. Also keep in mind, if your update intervals are small and your processing is time consuming, you can have a back-pressure problem which will result in blocking of your execution thread.
new CountDownTimer() {
@Override
public void onFinish() {
}@Override
public void onTick(long millisUntilFinished) {
}
}.start();
Java Threads or Android HandlerThread
Java Threads are rather straight forward to implement. However, they are best to avoid in Android. I have seen them used in all sorts of instances however they are limiting as Android doesn’t really allow UI updates on the background thread. A better option may be to use AsyncTask.
new Thread(new Runnable(){
public void run() {
// do something here
}
}).start();Android HandlerThread, can be used to handle messages of a background thread. While the use for this is rather limited as Message handling tends to do more of a redirection rather than processing, it nonetheless provides us a way to perform some tasks on the background thread. A possible use may be to run a Service in a background thread.
public class TickTockService extends Service {
public void onCreate() {
// Start up the thread running the service. Note that we create a
// separate thread because the service normally runs in the process's
// main thread, which we don't want to block. We also make it
// background priority so CPU-intensive work will not disrupt our UI.
mThread = new HandlerThread("ServiceArguments",
Process.THREAD_PRIORITY_BACKGROUND);
mThread.start(); // Get the HandlerThread's Looper and use it for our Handler
mServiceLooper = mThread.getLooper();
mServiceHandler = new Handler(mServiceLooper);
}
}
FutureTask
FutureTask performs asynchronous processing, however, if the result is not ready yet or processing has not complete, calling get() will be block the thread.
Surprisingly I've used this a few time. Sometimes you want to execute a request in Google Volley in a blocking manner. Below is an example of how to do this. Note, if you do this, make sure you're not blocking the UI thread.
RequestFuture<JSONObject> future = RequestFuture.newFuture();
JsonObjectRequest request = new JsonObjectRequest(URL, null, future, future);
requestQueue.add(request);It will always block you can use future.get(30, TimeUnit.SECONDS); after that time it will throw timeout exception rather than waiting indefinitely
try {
JSONObject response = future.get(); // this will block (forever)
} catch (InterruptedException e) {
// exception handling
} catch (ExecutionException e) {
// exception handling
}Java Timer / ScheduledThreadPoolExecutor
An example of using Java Timer to do something after 5 seconds. These can be used to schedule some processing on a background thread. There are other ways to handle the same in Android, you could use a Handler with postDelayed or Handler with sendMessageDelayed() and the handler can run on a background thread as shown above. Also, keep in mind that since this API is not aware of the Android lifecycle, any hard reference to an Activity, Fragment or View in here is a possible memory leak.
Timer timer = new Timer();
timer.schedule(new TimerTask(){
public void run() {
// time ran out.
timer.cancel();
}
}, 5000);From Java API: A ThreadPoolExecutor that can additionally schedule commands to run after a given delay, or to execute periodically. This class is preferable to Timer when multiple worker threads are needed, or when the additional flexibility or capabilities of ThreadPoolExecutor (which this class extends) are required. Delayed tasks execute no sooner than they are enabled, but without any real-time guarantees about when, after they are enabled, they will commence. Tasks scheduled for exactly the same execution time are enabled in first-in-first-out (FIFO) order of submission.
public class CustomScheduledExecutor extends ScheduledThreadPoolExecutor { static class CustomTask<V> implements RunnableScheduledFuture<V> { ... } protected <V> RunnableScheduledFuture<V> decorateTask(
Runnable r, RunnableScheduledFuture<V> task) {
return new CustomTask<V>(r, task);
} protected <V> RunnableScheduledFuture<V> decorateTask(
Callable<V> c, RunnableScheduledFuture<V> task) {
return new CustomTask<V>(c, task);
}
// ... add constructors, etc.
}// Code from Java API
The ScheduledThreadPoolExecutor suffers from a lot of the same problems on Android as Timer and Java Threads. If you need to update the UI you’ll need to use a Handler to post messages to the UI thread or pass in a Listener. A ScheduledThreadPoolExecutor is part of Java, it’s not aware of the Activity or Fragment lifecycle and as such any Listeners will have to be cleaned up or replaced manually in order to prevent memory leaks.
Do you know more?
If you know of more useful ways to do asynchronous processing in Android, let me know in the comments. Also, feel free to follow me on LinkedIn, Google+ or Twitter.
