Android, AsyncTask, long running processes, and orientation changes

Question

In the past, orientation changes and AsyncTask (and other long running background tasks) have not played well with each other. There's always been the issue of knowing what tasks (or threads) are still running in the newly created activity (from an orientation change), and what to do when a task ends while an Activity isn't attached.

Even with Fragments and the LoaderManager, this still seems to be a problem to me.

What is the preferred way these days, to manage arbitrary long running tasks and orientation changes? To know what tasks are running in the newly created activity. To make sure a task doesn't try to deliver it's information when an Activity isn't attached.

Thank you

Answer 1

In my program I just put

 android:configChanges="orientation|keyboardHidden|keyboard"

in my activities in the manifest and be done with it. After 1 year I have had 0 problems.

Answer 2

As other post suggests, you can use android:configChanges=xxx.

BUT, this is not always desired. Android is designed to kill activity on configuration change, and create new one, and you may benefit from this in some situation, by providing alternative screen layout. This makes sense for example in multi-pane app, where landscape orientation shows different views than portrait orientation.

So to return to your question: I didn't read about preferred way to handle long running operations, but from own experiences I'd suggest to store such task in persistent activity state (saved/restored in onRetainNonConfigurationInstance/onCreate), or using persistent Fragments.

If your Activity detects that some task is already running, it can give it chance to recreate dialog to show its progress.

And note: orienation change is not the only that can make your activity to be recreated. Be prepared for language change, docking, and other possibilities :) But still, orientation change is the most common one.

Answer 3

Its the same as it always has been: use a service. Broadcast events from your service and catch them in your activity (or some intermediate layer). Your activity can then choose what to do with those events based on its state.

This is a rather broad question.