First, a short description of the problem’s background:
I’ve run into troubles with handling background workers lifecycles in line with Activity lifecycle. First problem is that a new instance of activity is created whenever the configuration changes (this includes screen orientation) so I had to pull my workers from the old instance to the new one. Second, this is complicated by the fact that sometimes workers display a progress dialog and also, occasionally, they display an error dialog which the user has to interact with. Handling all that stuff – workers, dialogs, etc. – across the activity instances has grown so complex that now I clearly see it was the wrong way to go.
The right way to go, I believe, was to eliminate that re-instantiation in the first place. If that was provided then I had activities with a very straight-forward and simple lifecycle and no need for tracking workers and dialogs. This can be achieved by putting android:configChanges="..." in the manifest.
Now, the question is:
Given that activity has android:configChanges="..." which includes every possible thing (orientation, keyboard, and all the rest) – is there a guarantee that an activity is instantiated exactly once while it’s alive and not killed/re-created even in the background? The documentation is not clear about this point.
If someone knows cases when such guarantee doesn’t hold up – please let me know. And most important – how to simulate those cases in order to test against them?
I appreciate your answers very much.
PS: What documentation does say is that “system can remove your activity at any point if it wants to” – but we don’t consider it here, because that will be a new story for a new instance when the user is back to the screen which activity got removed this way. In this case we’ll simply start from the scratch like if the user just opened this screen.
If you are asking this, your app is probably broken.
So — why do you care? If you can’t handle your activity being restarted, then you will break in the situation where your app’s process needs to be killed for memory while in the background and the user later returns to it.
If you can handle being restarted, why do you care that there may be some case where the activity needs to be restarted?
Anyway the answer is that there is no way to guarantee that the activity is never restarted, so don’t abuse android:configChanges to try to avoid that. You can’t prevent it, you just make it less obvious to yourself that your app is broken, but users will still encounter the bugs you have.
If you are having trouble dealing with this, consider using some recent facilities like fragments and loaders in the new support library. These have a number of features that make it easier for apps to handle their activity being restarted — fragments can be retained across restarts, loaders keep their data loads active, etc.
Also the set of possible reasons that an app may need to be restarted is not fixed. New changes can and will be added in the future, and you can’t account for them.