Android: possible issues & solutions with configuration changes, part 1

In this article I want to review the situation that occurs in the development of almost every Android application, the problems that may arise, as well as solutions to handle them.

Situation:
your application needs to receive some data via network from the back-end.

For example, user goes to some screen, appropriate Activity object initiates a network call to request XML or JSON data to parse it and show in the UI. So, typical implementation scheme could be:
in a separate thread (to prevent UI blocking) make HTTP request, receive response and parse it. When thread has finished the task, you need to notify someone (usually the caller, or Activity) that data was received and ready to be shown.

Usually, you can meet implementation with AsyncTask (as a worker thread) that has a reference to a caller Activity or some callback object. And this will work without issues until the device configuration changes.

Problem:
when the configuration of the device changes, then you may find unexpected behavior and even crashes (for example, if you will try to dismiss progress dialog at onPostExecute method of the AsyncTask object). Why? Unless you specify otherwise, a configuration change (screen orientation, input devices, language, etc) will cause your current Activity to be destroyed, going through the normal activity lifecycle process. This is done because any application resource, including layout files, can change based on any configuration value.

So, if your current Activity was destroyed and re-created, while the worker thread was active, then at worker thread completion moment you will have non actual references to a caller Activity, callback, etc.
The key questions is: how to guarantee, that worker thread will have valid return point reference at the moment of completion?


Solutions:
While, described problem is very common, Android doesn't suggest one proven and proper way to handle it. So, I will show several possible solutions with their pros and cons.

1) android:configChanges="orientation"
This is the simplest and... definitely not the best solution.
All you need to do is to add to the activity declaration in the manifest attribute "android:configChanges" and specify configuration changes types you want to handle by yourself. For example:
     <activity
            android:name=".activity.HomeActivity"
            android:label="@string/home_name"
            android:configChanges="orientation"/>
But, handling the configuration change by yourself can make it much more difficult to use alternative resources, because the system does not apply them for you automatically. So, according to Android team recommendation, this technique should be considered a last resort when you must avoid restarts due to a configuration change and it is not recommended for most applications.

2) retaining an object during a configuration change
Activity has well defined lifecycle and we can retain some state object between runtime configuration change. So, you may override onRetainNonConfigurationInstance method to return the object, that keeps references to running worker instances (e.g. AsynTask objects). Then when your activity is created again, call getLastNonConfigurationInstance to recover your state object and update AsyncTask's references to caller, callback, etc.
You can read more about it here:
http://developer.android.com/guide/topics/resources/runtime-changes.html
Also, onRetainNonConfigurationInstance/getLastNonConfigurationInstance pair is useful to retain and restore partially downloaded data (instead of re-fetch the data from the scratch).
While this approach works pretty well, I don't like that I had to define a class for state object that keeps references to running AsyncTask instances and all other stuff.

3) Ordered Broadcast and IntentService
This approach is well described by Murk Murphy (author of the great "The Busy Coder’s Guide to ..." books series). So give a word to him:
http://commonsware.com/blog/2010/08/11/activity-notification-ordered-broadcast.html

4) Event Bus
This approach was designed by me, while I was thinking about easy to use solution, to be notified when some background task becomes completed. The powerful and easy to use event dispatching model of Adobe Flex was an inspiration. I will describe this approach in details in the second part of this article. It will come soon, so be in touch! ;-)