The SDL forums have moved to discourse.libsdl.org.
This is just a read-only archive of the previous forums, to keep old links working.

I have an event filter set up using SDL_SetEventFilter that checks for SDL_APP_TERMINATING. When the app is in the foreground and I quit it, I hit this event. When it is in the background and I terminate it, I never hit this event, and the app crashes on seemingly random things (ios is doing some trickery to forcibly shutdown the app?). Why don't I get a chance to shut down gracefully when shutting down from the background?

The system doesn’t let the app know that it’s being terminated when it’s in the background, because it expects the app to do all relevant work when it first goes into the background.

(This is part of the iOS app lifecycle design, rather than a quirk of SDL.)

So how do you shut down gracefully from being terminated in the background then? Short of returning 0 from main when the app goes into the background, I cannot possibly do all relevant work to shutdown upon backgrounding (and I wouldn't want to either... I want the app to come back where it was...).

iOS expects your app to do all necessary work to be able to restore itself, when the app enters the background. If for some reason that takes your app more than a short duration (which it really shouldn’t), then there are a couple mechanisms to perform work in the background without being active:

https://developer.apple.com/library/ios/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/BackgroundExecution/BackgroundExecution.html#//apple_ref/doc/uid/TP40007072-CH4-SW1

Even when using those methods, you will still need to do it when the app goes into the background, since the system doesn’t wake up apps that are suspended when it kills them to reclaim memory.

It’s also a good incentive to use as little memory as possible (especially while suspended), since the system will kill your app first if it’s suspended and using the most memory.

It's not a problem at all to do all the work I need to when backgrounding. In my app I completely shut it down except for the main sdl message loop, and re-create everything on foregrounding. My problem is that with only the SDL main message loop running (well, not running because I get no cpu time when backgrounded, but nothing in code stops it from running), I crash when terminated from the background. This isn't visible to the user. I can only see the crash when I do this attached to a debugger. It doesn't really hurt anything either, since presumably ios reclaims any memory/other things I didn't release correctly in the app. Is this expected?

Also worth mentioning: it doesn't actually expect you to shut down gracefully. it only really expects you to do what is necessary to ensure that it saves persistent state that is important to the user. The default expected behavior is that your application will be terminated at some point while running in the background, and you really shouldn't expect your application to be resumed instead of terminated.


How aggressively it does that really depends on the specific device, but older devices tend to be especially aggressive about evicting applications. Either way, resuming a background process is opportunistic and totally dependent on what else the user is doing with the device.


The preferred behavior is that you take the opportunity to free up any buffers/caches that can be regenerated when relaunching. When the process is restored you can then regenerate all that data and resume execution with no real hiccup, whereas when it's terminated and relaunched you can then take the stored data and use it to return the application to the state it was in when you left off. On a more traditional application this is pretty easy to do and does decrease the likelihood that the system terminates the process - however given how much time it can take to reload textures and geometry in asset intensive games it's a pretty common decision to not particularly bother.


That is part of the reason quite a few apps will re-launch into a screen that lets you start a new game or resume the existing one instead of re-launching directly into the game. This effectively treats the backgrounding of the app as saving and pausing the game, and if they happen to resume the game before it gets evicted that's a nice perk.


The tradeoff here is that not doing a thorough teardown when it gets backgrounded means it's more likely to get terminated, but if the user resumes the process before it's terminated it might be ready to the user much sooner.



On Wed, Aug 26, 2015, at 10:23 AM, Alex Szpakowski wrote: