When an app is exited by the user by selecting “Yes” on “Exit?”, the Application becomes a cached background processes because the AndroidHarness Activity no longer exists. If you reexecute the Android app, a fresh AndroidHarness Activity will be started, but the Dalvik VM is the same one so all your static variables in the SimpleApplication object part of the app are still initialiazed to their old values while the other variables are now initialized to their default values. This mix of default values and previous values means an app is unlikly to run. This makes an app behave differently under Android than it does under a desktop.
It is important to me that the app be quick to restart itself. I thought about saving/restoring the SimpleApplication object in the same way that onRetainNonConfigurationInstance/getLastNonConfigurationInstance does in the AndroidHarness during Configuration changes.
I’m unclear how this would be done though. I’m uncertain about what JMonkeyEngine stores for itself in the SimpleApplication object. E.g., do I need to do things like rechange my AppSettings, attach AppStates again, map key inputs, readd processors? Is there any documentation on this that has a list of things to do?
I’m also unsure if I need to do anything special to shut down the app from within my code when its AndroidHarness Activity is destroyed and before the SimpleApplication object is saved.
Is saving the SimpleApplication object the best way to handle this situation?
How do people normally handle a JMonkeyEngine app under Android?
I read the FAQ earlier today and saw the note about using killProcess.
What about the other part of my question of if you want to take advantage of the cached background processes still running to restart from a saved SimpleApplication object that was previously saved?
The little home key is the default to close the game and keep it cached. You can reopen later on the device. In this case the application isn’t destroyed.
The exit key prompts the “Do you want to Exit?” Interface, which should shut down application, but the onDestroy() is pretty much always necessary.
If you want to save after the full close you will actually have to write to the device.
My understanding is that Android standard practice is to have the Home key preserve the current Activity and Application. The Back key should destroy the current Activity but preserve the Application. From what I can tell, an Application without any Activities could theoretically hang around forever as a cached background processes. Obviously, you can kill it off as you suggest, and that would solve the problem of having initialized statics handing around that you might not want. However, am I right in that this is going against the way Android programming is supposed to be done?
In any case, I thought I would take advantage of the fact that Android keeps around a cached background process to make my app come up quicker by saving/restoring the SimpleApplication object. As my original question asked: How does one go about doing this? Do you have to do things like attach AppStates again, etc., or is that type of thing accomplished by simply restoring the SimpleApplication object?
The main difference between desktop and Android in this case is that on desktop the user has full control over the lifecycle of their application because they initialize it in their main() method. On Android, the operating system and consequently the AndroidHarness (Activity) is responsible for managing the application lifecycle. Destroying the SimpleApplication object and then re-creating it (while keeping static variables) is fully within the jurisdiction of AndroidHarness.
Nevertheless, this behavior can cause various issues, especially in games that assume that a new SimpleApplication means all static variables are reset to defaults. In that case, you can either use the onDestroy() killProcess hack mentioned earlier, or somehow keep the SimpleApplication alive through the onDestroy() event, possibly in a static variable. Either way seems ugly to me…