One of the problems beginners often struggle with in Android is orientation changes. The problem with an orientation change is that it per se destroys the currently running activity, creates a new instance and starts that instance with the original Intent again.
This behavior can be pretty disturbing in applications with multiple background threads/asynchronous tasks. This article shows how to handle background threads when the current activity instance is destroyed and created back and forth.
Orientation Change Behavior
For the matter of purpose let us assume we have an Activity that shows a large Image using an ImageView loaded from a web server. As the image is very large we decided to show a progress dialog during loading the image.
The example above shows a straight-forward implementation I've already seen in a handful of Android applications (mine included ;)).
Now let us see what happens when an orientation change happens during the image is downloaded. As can be seen from the stack trace below, when orientation is changed, our code somehow leaks an activity instance
and after a while when the dialog needs to be dismissed another exception happens
The behavior seems odd at first glance, but when digging into the Android documentation, one finds the reason: per default Android recreates the currently running activity whenever the orientation is changed. That explains why onPostExecute can't access the current application window and throws an exception (the first exception with the leaking activity instance is explained in a minute).
Handling Orientation changes
There are several ways how to handle an orientation change without leaking windows or accessing "dead" views. In our example above, one way would be to leave the dialog management over to the current Activity. This is done by overriding onCreateDialog and using its companion methods showDialog and dismissDialog.
Overriding the onCreateDialog has the advantage that the Activity base class handles persisting the dialogs state and recreating the dialog on orientation changes.
The problem with the example above is that changing the orientation twice or more times, leads again to the view leaking exception from above as the onCreate method of the activity is called whenever the orientation is changed.
This behavior is caused by DownloadImageTask being an inner class. After the orientation change, the asynchronous task refers to the old activity instance and, even worse, it additionally has a reference to the imageView to set the downloaded image accordingly.
But how could we solve that binding to the outer activity instance in our DownloadImageTask task class?
Using a static Handler/Activity Combo
In order to handle the problem with references to the old activity inside inner class object instances, we could use static variables in combination with Android's Handler class.
The code above always keeps a reference to the current Activity in a static class variable. The asynchronous task implementation now keeps a reference to the Handler instance, avoiding to refer to the old Activity instance. With this little trick we can now safely switch orientations while the background task is running.
But wait, didn't we see that onCreate is called multiple times during orientation changes? That means, whenever the orientation is changed we create a new instance of DownloadImageTask and start the task again!
One way to solve the problem is to introduce another static variable indicating whether the download is currently running in the background or not. But there is another way: we can provide the android:configChanges="orientation" XML attribute in our AndroidManifest.xml.
The configChanges attribute is documented  as
Lists configuration changes that the activity will handle itself. When a configuration change occurs at runtime, the activity is shut down and restarted by default, but declaring a configuration with this attribute will prevent the activity from being restarted. Instead, the activity remains running and its onConfigurationChanged() method is called.
where as orientation is used to react on orientation changes.
Let's add android:configChanges="orientation" to our activity XML declaration and modify the code to
By overriding the onConfigurationChanged method we have avoided activity recreation, which - in our case - does not seem to be necessary. As you can see in the code above, with this approach we do avoid the use of static class variables and the Handler object instance.
There are various ways to handle orientation changes and activity recreations in Android. If you have any other tips or preferred ways to do so, you are free to mention them in this article's comments section.