If after the AsyncTask starts there is a screen rotation the owning activity is destroyed and recreated.
When the AsyncTask finishes it wants to update the UI that may not valid anymore.
Using Loaders, one can easily overcome the activity destruction/recreation.
It is important to use either the v4 compatibility library or not, but do not use part of one and part of the other, as it will lead to compilation errors. To check you can look at the imports for android.support.v4.content and android.content (you shouldn't have both).
Lock Screen's rotation programmatically
It is very common that during development, one may find very useful to lock/unlock the device screen during specific parts of the code.
For instance, while showing a Dialog with information, the developer might want to lock the screen's rotation to prevent the dialog from being dismissed and the current activity from being rebuilt to unlock it again when the dialog is dismissed.
Even though we can achieve rotation locking from the manifest by doing :
One can do it programmatically as well by doing the following :
And then calling the following, to respectively lock and unlock the device rotation
Locking Screen Orientation
If you want to lock the screen orientation change of any screen (activity) of your android application you just need to set the android:screenOrientation property of an <activity> within the AndroidManifest.xml:
Now that activity is forced to always be displayed in "portrait" mode.
Manually Managing Configuration Changes
If your application doesn't need to update resources during a specific configuration change and you have a performance limitation that requires you to avoid the activity restart, then you can declare that your activity handles the configuration change itself, which prevents the system from restarting your activity.
However, this technique should be considered a last resort when you must avoid restarts due to a configuration change and is not recommended for most applications. To take this approach, we must add the android:configChanges node to the activity within the AndroidManifest.xml:
Now, when one of these configurations change, the activity does not restart but instead receives a call to onConfigurationChanged():
In many cases, we can avoid problems when an Activity is re-created by simply using fragments. If your views and state are within a fragment, we can easily have the fragment be retained when the activity is re-created:
This approach keeps the fragment from being destroyed during the activity lifecycle. They are instead retained inside the Fragment Manager. See the Android official docs for more information.
Now you can check to see if the fragment already exists by tag before creating one and the fragment will retain it's state across configuration changes. See the Handling Runtime Changes guide for more details.
Saving and Restoring Activity State
As your activity begins to stop, the system calls onSaveInstanceState() so your activity can save state information with a collection of key-value pairs. The default implementation of this method automatically saves information about the state of the activity's view hierarchy, such as the text in an EditText widget or the scroll position of a ListView.
To save additional state information for your activity, you must implement onSaveInstanceState() and add key-value pairs to the Bundle object. For example:
The system will call that method before an Activity is destroyed. Then later the system will call onRestoreInstanceState where we can restore state from the bundle:
Instance state can also be restored in the standard Activity#onCreate method but it is convenient to do it in onRestoreInstanceState which ensures all of the initialization has been done and allows subclasses to decide whether to use the default implementation. Read this stackoverflow post for details.
Note that onSaveInstanceState and onRestoreInstanceState are not guaranteed to be called together. Android invokes onSaveInstanceState() when there's a chance the activity might be destroyed. However, there are cases where onSaveInstanceState is called but the activity is not destroyed and as a result onRestoreInstanceState is not invoked.
Saving and Restoring Fragment State
Fragments also have a onSaveInstanceState() method which is called when their state needs to be saved:
Then we can pull data out of this saved state in onCreateView:
For the fragment state to be saved properly, we need to be sure that we aren't unnecessarily recreating the fragment on configuration changes. This means being careful not to reinitialize existing fragments when they already exist. Any fragments being initialized in an Activity need to be looked up by tag after a configuration change:
This requires us to be careful to include a tag for lookup whenever putting a fragment into the activity within a transaction:
With this simple pattern, we can properly re-use fragments and restore their state across configuration changes.
This modified text is an extract of the original Stack Overflow Documentation created by following contributors and released under CC BY-SA 3.0