Sunday, May 30, 2010

The limitations of AsyncTask

AsyncTask is a fine API, it's been said that it "holds your hand", and makes performing background operations painless. It pulls this off so well in fact, that I see people overusing it in situations where it's not really appropriate.

It's particularly unsuited for situations when you have a multiple tasks to perform concurrently. Imagine an Activity that needs to download about 30 small images from a remote server, and update the UI as these become available. AsyncTask uses a static internal work queue with a hard-coded limit of 10 elements. That means if you were to create an AsyncTask instance for each image, the work queue would quickly overflow and many of your tasks would get rejected. The best solution in this case is to create your own ThreadPoolExecutor instance that uses a queue that's large enough to hold all your tasks, if you need an unbounded queue, a LinkedBlockingQueue will work just fine.

Another severe limitation is that an AsyncTask can't survive your Activity being torn down and recreated on the other side.  Even if you pass it to the new instance via onRetainNonConfigurationState, the internal Handler inside the AsyncTask is still going to be stale and it's not going to behave correctly.  This is important to consider, and the Android documentation makes no mention of it all.  I've already blogged this scenario in detail, so I won't flog a dead horse here.

There are a few other minor issues, such as the fact that you can't change the background threads execution priority. It's hard-coded to a low priority, which granted, is the sensible default.  Also, exception handling is not very well supported.

So just to reiterate, AsyncTask is a nice API, but you should understand it's limitations and apply it appropriately.  If you're serious about writing mobile apps, then you're going to need a few more tools in the toolbox to get the job done.