Hi!
Is there any special event for the iPhone to manage calls/low memory message/low battery message… dialogs? I would like to pause my game when this happens.
Thanks a lot for help.
There isn’t currently, but I’d happily accept a patch.On Sun, Oct 4, 2009 at 3:59 AM, ricardo_ruiz wrote:
Hi!
Is there any special event for the iPhone to manage calls/low memory
message/low battery message… dialogs? I would like to pause my game when
this happens.Thanks a lot for help.
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
–
-Sam Lantinga, Founder and President, Galaxy Gameworks LLC
Oh dear! 
Welcome to mobile! 
-bill!On Sun, Oct 04, 2009 at 09:34:22AM -0700, Sam Lantinga wrote:
There isn’t currently, but I’d happily accept a patch.
Any suggestion before I try it? or am I alone facing danger?
By the way, in my current project I implemented landscape mode. After finish my game I will try to send you it.
Sam Lantinga wrote:> There isn’t currently, but I’d happily accept a patch.
On Sun, Oct 4, 2009 at 3:59 AM, ricardo_ruiz <@Ricardo> wrote:
Hi!
Is there any special event for the iPhone to manage calls/low memory
message/low battery message… dialogs? I would like to pause my game when
this happens.Thanks a lot for help.
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org–
-Sam Lantinga, Founder and President, Galaxy Gameworks LLC
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Thanks!On Sun, Oct 4, 2009 at 11:15 AM, ricardo_ruiz wrote:
Any suggestion before I try it? or am I alone facing danger?
By the way, in my current project I implemented landscape mode. After
finish my game I will try to send you it.Sam Lantinga wrote:
There isn’t currently, but I’d happily accept a patch.
On Sun, Oct 4, 2009 at 3:59 AM, ricardo_ruiz wrote:
Quote:
Hi!
Is there any special event for the iPhone to manage calls/low memory
message/low battery message… dialogs? I would like to pause my game when
this happens.Thanks a lot for help.
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org–
-Sam Lantinga, Founder and President, Galaxy Gameworks LLC
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
–
-Sam Lantinga, Founder and President, Galaxy Gameworks LLC
Any suggestion before I try it? or am I alone facing danger?
Should this be a new event (SDL_INTERRUPTED or something?), or do we
just want SDL to hijack the application until the phone call/alarm/etc
finishes? I suspect the former is better, but the latter doesn’t need
the app to explicitly handle it. Then again, lots of apps will probably
break in this case.
Eric Wing: please chime in on this one, since you just wrote a book
about it.
–ryan.
Le Sun, 04 Oct 2009 15:37:57 -0400
"Ryan C. Gordon" a ?crit:
Any suggestion before I try it? or am I alone facing danger?
Should this be a new event (SDL_INTERRUPTED or something?), or do we
just want SDL to hijack the application until the phone call/alarm/etc
finishes? I suspect the former is better, but the latter doesn’t need
the app to explicitly handle it. Then again, lots of apps will probably
break in this case.
Why not simply use this:
/* Send an internal deactivate event */
SDL_PrivateAppActive(0, SDL_APPACTIVE);–
Patrice Mandin
WWW: http://pmandin.atari.org/
Programmeur Linux, Atari
Sp?cialit?: D?veloppement, jeux
So I can only speak to iPhone OS as I don’t know other phone APIs.
But there are actually two different places you are generally expected
to deal with phone call interruptions on iPhone OS.
One place is the application delegate where you are given 3 delegate
method callbacks you can handle.
-
(void)applicationWillResignActive:(UIApplication *)application;
-
(void)applicationDidBecomeActive:(UIApplication *)application;
-
(void)applicationWillTerminate:(UIApplication *)application;
So for example, when a phone call starts coming in, the
applicationWillResignActive method will be invoked.
If the user declines to accept the phone call,
applicationDidBecomeActive will be invoked.
But if the user accepts the phone call, applicationWillTerminate will
be invoked. It is also important to underline that your application
will quit whether you like it or not if the user accepts the phone
call. So this method is generally where you are expected to save your
application state so when the user relaunches, you can restore the
application state.
Also important to point out, if your application does not finishing
doing what it is doing in some short amount of time (like 5 seconds),
your application will be killed by the OS.
I also need to point out that these 3 methods are not just for phone
calls and may be called in other events too (screen locking, alarm
clocks, SMS, launching, quitting). So these are general purpose
methods and I don’t think there is a way to distinguish the specific
underlying event that triggered it.
The other place is the audio interruption callback system. (This is
what I talk about in my chapters of the book.) These are more
deliberate for audio interruptions and a little less general than the
above (e.g. quitting and screen locking will not trigger this
interruption), but they still cover more than just phone calls (e.g.
alarm clocks, etc). But these were really intended for just audio so
you could save your music state or deal with some audio system
technical requirements (e.g. disable the OpenAL context or tear down
OpenAL completely), though I suspect they could be abused to handle
more than just audio, but I haven’t tried this and I would be nervous
about doing so. (I recall other callbacks in Core Audio are done in
high priority threads and if you don’t finish within the realtime
constraints, the behavior is not well defined.)
Also note that if a user accepts a phone call, the audio interruption
callback will not fire again and the
So here is an example callback sequence
(starting application)
applicationDidBecomeActive:
(incoming phone call)
AudioInterruptionCallback (kAudioSessionBeginInterruption)
applicationWillResignActive:
(user declines phone call)
AudioInterruptionCallback (kAudioSessionEndInterruption)
applicationDidBecomeActive:
(quit application)
applicationWillTerminate:
Or in the example of the user accepting a phone call:
(starting application)
applicationDidBecomeActive:
(incoming phone call)
AudioInterruptionCallback (kAudioSessionBeginInterruption)
applicationWillResignActive:
(accept phone call)
applicationWillTerminate:
For SDL, I think it will be hard for SDL to hide this because we won’t
know how to archive the specific application state in case of
termination. And we won’t know how to deal with OpenAL if the user is
combining SDL and OpenAL in their app.
-EricOn 10/4/09, Ryan C. Gordon wrote:
Any suggestion before I try it? or am I alone facing danger?
Should this be a new event (SDL_INTERRUPTED or something?), or do we
just want SDL to hijack the application until the phone call/alarm/etc
finishes? I suspect the former is better, but the latter doesn’t need
the app to explicitly handle it. Then again, lots of apps will probably
break in this case.Eric Wing: please chime in on this one, since you just wrote a book
about it.
If we don’t already, we should post SDL_APPACTIVE changes for
applicationWillResignActive() and applicationDidBecomeActive(), that’s
pretty much the definition of SDL_APPACTIVE right there.
I can’t test right now, Eric, you want to take a stab at that?
See ya!On Mon, Oct 5, 2009 at 2:47 AM, E. Wing wrote:
On 10/4/09, Ryan C. Gordon wrote:
Any suggestion before I try it? or am I alone facing danger?
Should this be a new event (SDL_INTERRUPTED or something?), or do we
just want SDL to hijack the application until the phone call/alarm/etc
finishes? I suspect the former is better, but the latter doesn’t need
the app to explicitly handle it. Then again, lots of apps will probably
break in this case.Eric Wing: please chime in on this one, since you just wrote a book
about it. ?So I can only speak to iPhone OS as I don’t know other phone APIs.
But there are actually two different places you are generally expected
to deal with phone call interruptions on iPhone OS.One place is the application delegate where you are given 3 delegate
method callbacks you can handle.
(void)applicationWillResignActive:(UIApplication *)application;
(void)applicationDidBecomeActive:(UIApplication *)application;
(void)applicationWillTerminate:(UIApplication *)application;
So for example, when a phone call starts coming in, the
applicationWillResignActive method will be invoked.If the user declines to accept the phone call,
applicationDidBecomeActive will be invoked.But if the user accepts the phone call, applicationWillTerminate will
be invoked. It is also important to underline that your application
will quit whether you like it or not if the user accepts the phone
call. So this method is generally where you are expected to save your
application state so when the user relaunches, you can restore the
application state.Also important to point out, if your application does not finishing
doing what it is doing in some short amount of time (like 5 seconds),
your application will be killed by the OS.I also need to point out that these 3 methods are not just for phone
calls and may be called in other events too (screen locking, alarm
clocks, SMS, launching, quitting). So these are general purpose
methods and I don’t think there is a way to distinguish the specific
underlying event that triggered it.The other place is the audio interruption callback system. (This is
what I talk about in my chapters of the book.) These are more
deliberate for audio interruptions and a little less general than the
above (e.g. quitting and screen locking will not trigger this
interruption), but they still cover more than just phone calls (e.g.
alarm clocks, etc). But these were really intended for just audio so
you could save your music state or deal with some audio system
technical requirements (e.g. disable the OpenAL context or tear down
OpenAL completely), though I suspect they could be abused to handle
more than just audio, but I haven’t tried this and I would be nervous
about doing so. (I recall other callbacks in Core Audio are done in
high priority threads and if you don’t finish within the realtime
constraints, the behavior is not well defined.)Also note that if a user accepts a phone call, the audio interruption
callback will not fire again and theSo here is an example callback sequence
(starting application)
applicationDidBecomeActive:(incoming phone call)
AudioInterruptionCallback (kAudioSessionBeginInterruption)
applicationWillResignActive:(user declines phone call)
AudioInterruptionCallback (kAudioSessionEndInterruption)
applicationDidBecomeActive:(quit application)
applicationWillTerminate:Or in the example of the user accepting a phone call:
(starting application)
applicationDidBecomeActive:(incoming phone call)
AudioInterruptionCallback (kAudioSessionBeginInterruption)
applicationWillResignActive:(accept phone call)
applicationWillTerminate:For SDL, I think it will be hard for SDL to hide this because we won’t
know how to archive the specific application state in case of
termination. And we won’t know how to deal with OpenAL if the user is
combining SDL and OpenAL in their app.-Eric
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
–
-Sam Lantinga, Founder and President, Galaxy Gameworks LLC