Due to problems with multitasking (game not stopping until after the screen had gone blank, differences between data saved state and game position causing multiple bugs), I resorted to UIApplicationExitsOnSuspend to turn off multitasking, even though I would rather of not have if possible.
With my game just a couple of days from completion (I was hoping to submit before the middle of the week), I discovered that using UIApplicationExitsOnSuspend makes the app size much bigger, pushing over the 20MB 3G download limit.
I didn’t want to send my almost complete project for a bug report, but I have now. Bug 379694.
Does anyone have any suggestions as to how to work around the problem? OnApplicationPause only acts when the game finally enters the background which is too late. Xcode has the applicationWillResignActive which my research suggests happens much earlier, such as at the point of the Home button press, but I cannot find any way to access that through Unity.
Using this flag has no impact on the application size at all actually, its an indicator for the OS it has no code dependencies at all.
If it jumped over the 20mb then because you added assets or by error switched the architecture in unity to armv6 + armv7
willResignActive / didBecomeActive map to OnApplicationPause( bool pause ) within unity (they are also called when the app goes to background in addition to notification and phone calls)
Despite not doing anything differently today, the app size has returned to normal when using UIApplicationExitsOnSuspend. Several times over the weekend I used Replace instead of Append when building my project and it didn’t solve the problem. Yet today the size is fine after doing a Replace.
I mentioned the Home button press as that is the fastest way to test, but know it applies to all cases. I am now wondering if I am formatting OnApplicationPause correctly and only triggering it on didBecomeActive. How should it be formatted to trigger on willResignActive? I am doing it this way:
function OnApplicationPause (pauseState : boolean) {
if (gameActive == "play" pauseState == true)
Instantiate (pauseMenu);
}
gameActive is a check that I am not triggering pause if I am already in a pause state or on a menu screen. I have also tried pauseState == false and other combinations, with no luck.
this is correct given gameActive is right (though using == string checks is a rather bad idea, use enums or booleans instead those don’t trashbomb the garbage collector)
just keep in mind that instantiate won’t pick up until the next frame and the next frame will not happen until the unpause has happened again!
Thanks Dreamora, even the code below doesn’t solve the problem, so I don’t believe gameActive is the problem.
function OnApplicationPause () {
Instantiate (pauseMenu);
}
The pause menu is only exited by a player action. My intention is that the game will return in a paused state so that the player can assess the situation before playing. I just want to trigger the pause as soon as possible. “instantiate won’t pick up until the next frame” shouldn’t be too much of an issue in that case should it?
As mentioned, whatever you do in here, if its not just setting a bool, won’t take part until after the device came back from pausing.
there is no future processing to execute anything that requires until next frame etc to execute so these things (like execute, yield, …) are useless as they will pick up once the user came back.
Instantiate especially, as being a “longer operation” will definitely not be there beyond pause. have the pause menu in the scene and disable it to reenable it when you need it (optimally have it there all time and just not rendering), that reduces the latency until it shows up and use timeScale 0 to prevent the game going on after this point here until you allow it to.
Thanks again Dreamora, I had seen / heard the game running after the Home button is pressed, but you say there is no new frame, so I am getting the pauseMenu on the next frame, but that is not until the app has relaunched.
This triggered a thought. I’m guessing the game appearing to run is a continuation of the current frame, and I’m seeing the rendering of it before the app disappears. Because the system is busy with the app switching, the frame is running longer, potentially up to the Maximum Allowed Timestep. I tried reducing this to the same value as the Fixed Timestep and I see a large improvement. I will need to test this quite a bit to see if it solves the problem, and I will have to raise the maximum a bit to prevent other problems.
I’m also guessing there will still be a potential problem of the game logic changing as before, it just has a much smaller window in which to change. The problem being some data appears to be saved from the start of the frame, some from the end.