In this Activity, you can :
Read below to learn more.
The advantage of a static inner class (exactly the same as a proper public class in a different file) is that the AsyncTask doesn't hold any invisible reference to the activity. Instead, the AsyncTask will be given an explicit reference to the current Activity. Thus, we have more control over this reference.
In this activity, we used a workaround to tie the Activity life cycle to the same instance of the AsyncTask. If you start an AsyncTask, rotate the device and don't start any new AsyncTask, the Activity will be destroyed and a new instance will be created. As before, the AsyncTask will continue its life until it completes. But we re-link the new instance of the Activity to the AsyncTask.
After a new instance of the Activity is created, its UI will be updated by the formerly created AsyncTask.
The advantage of this technique is that an AsyncTask instance holds a reference to the most recent Activity instance. It doesn't prevent garbage collection of the Activity instances that are not displayed anymore.
The technique proposed here uses the method : getLastCustomNonConfigurationInstance. This method is only available in support classes. In the "normal" Android SDK, you would use the method getLastNonConfigurationInstance but this method is deprecated as it used internally by the Loader Framework of Android and is not available in the support library class FragmentActivity. This method is not a general solution, as it depends on the Activity class you use (with support or not).
As we said, to limit the risk of memory leak, we propose an implementation so that the same AsyncTask instance can hold a reference only to one single instance of the outer Activity. This is better than the basic AsyncTask example.
Nevertheless, this produces a memory leak if you start several AsyncTasks, not as important as the previous demo Activity but still a memory leak.
When AsyncTasks are executed, they are passed to an ExecutorService (that used to be single-threaded prior to DONUT release, multi-threaded between DONUT and HONEYCOMB, and back to single-threaded after HONEYCOMB included). This means that the ExecutorService is holding a reference on all your AsyncTask instances. As in every AsyncTask we hold a reference to an Activity, the Activity can't be garbage collected as long as the AsyncTask is still queued by the ExecutorService. This causes a memory leak.
To simulate the problem, start an AsyncTask, rotate the device, and repeat this process. After 30-40 times, you will get an OutOfMemoryException. It takes more time as some AsyncTask terminate their live and allow garbage collection of some activities, but they can't cope if you start AsyncTasks at a rapid pace.