Reputation: 14600
I've recently been trying to refine my knowledge and skills in regard to managing Android application state during various points in an app's process lifecycle. Specifically, I've been testing the various ways to maintain and share global data between activities. In my test apps, in order to test the recreation of global application data and/or singleton data, I need to wait for a few hours or more in order for my phone to decide that other processes are more important and to put my test app in empty process state as defined in the process lifecycle documentation. At this point, the app's data is released and needs to be recreated once the app is brought to the foreground again. If done incorrectly, the reinitialization of the app's last known state can cause a force close for various reasons.
So, my question is, aside from waiting for this to happen organically, is there a real world way of testing this occurrence. For example, what would a QA use case look like that tests the application going into the background for a (very) extended period of time and then being brought to the foreground again once the app has reached the empty process state?
Upvotes: 4
Views: 723
Reputation: 14600
I've been doing a bit of trial & error with this and have come up with a good solution:
Ultimately, this comes down to each Activity being able to restore it's state independently. This holds true for the Application as well. The "Empty Process" state is the final state that the OS puts the app into after it is deemed as no longer important.
Here's what's been working for me to test my app's Empty Process scenario:
Running the above test for each activity & fragment allows for the testing of the complete recreation of not just the activity and/or fragment, but also the entire application.
This is a bit of a P.I.T.A., but it is effective.
Upvotes: 3