[SDL] iOS System Callback

[Jared Maddox]

> Date: Wed, 28 Mar 2012 15:17:52 -0400
> From: Brian Barnes <ggadwa at charter.net>
> To: sdl at lists.libsdl.org
> Subject: Re: [SDL] iOS System Callback
> Message-ID: <4F7363E0.70304 at charter.net>
> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
>
> Let's take these one at a time:
>
> Jared wrote:
>
>> At the same time, there may be apps where it makes sense to separate
>> time-critical code&  non-time-critical code. Can't say that I know of
>> any, though (my backburner project likely won't deal with the
>> time-critical bits correctly EVER, so.. ). Can anyone think of any
>> cases where it would be useful to have both callbacks&  events?
>
> Jeremy wrote:
>
>> Your use of the words 'time-critical' hit the nail on the head.
>> Theoretically...
>>
>> Perhaps some system might implement such events as signal handlers, which
>> would add a new synchronization element to handling them. In such cases
>> clients might not want to enter the murky waters of correct signal
>> handling
>> and opt to wait for the nice message to be handled in a normal context on
>> the main thread.
>>
>> You asked for an example, so I made one up :)
>>
>> I feel as though we should avoid over-tailoring this patch to iOS, but I
>> still strongly suggest the callback mechanism, as it's the only way to
>> keep
>> the library out of the way of clients that want to get down to the metal.
>> I
>> understand the confusion that might arise from having two delivery
>> mechanisms, but remember that the library already provides alternate ways
>> of doing the same thing (such as LoadWAV vs using rwops).
>
> The bottom line is there's no other way to do this.  Apple *requires*
> that this stuff be handled IN the callback.  And more important than
> that, after the callback exits, your code *no longer receives any time!*
>

As far as my comment goes, it was about duplicating the callback into
the event queue. I have no problem with callbacks.

> You can't handle it by polling later.  You code is halted.  So it *has*
> to be in the callback.
>

Remember how I mentioned time-critical vs non-time-critical? My
'backburner' project is adding SDL support to a pre-existing virtual
machine. This virtual machine allows the programmer to act as if the
virtual machine never shuts down (time just magically passes faster
than normal, all connections fail, etc.). If I spend the effort to
adapt this to iOS (which is unlikely, since I don't have one of the
devices) then I'll obviously need to put code into one of the
callbacks to implement this...

However, the code running on the virtual machine should ALSO be
informed of this (example: so that it can figure out if it needs to
reload textures), and that realistically can (AND SHOULD) be relegated
to events.

Thus, two types of reaction to callbacks:
1) time-critical code that needs to run INSIDE the callback, and
2) non-time-critical code that can run anywhere as long as it eventually runs.

As for me asking whether anyone can come up with a use-case? I don't
think I'll be using this, so I don't feel that I can JUSTIFY the
developer effort with my example. It may be informative, but I could
just as easily implement the events myself, and I probably won't be
using the callbacks for this project regardless.

> These type of callbacks are, by their very nature, very system
> independent.  Ones of android, or any future system (windows phone, etc)
> aren't going to be necessarily the same.  Instead of creating a
> confusing call that says "on X it does Y on Z it does W" kind of thing,
> make the calls specific to the OS that is catching them.
>

I think you mean system-dependant. At any rate, I don't know where
you're going with this?

> Vittorio wrote:
>
>> Finally, there other ways, like the one I mentioned, to respond to any
>> event you like, just by subclassing the SDL_UikitAppDelegate and
>> override the methods you are interested in.
>
> But the point of SDL is to hide the implementation details and make
> things as cross platform as possible.  Actually overriding internal
> structures and objects in a library is not the best way to go about
> this.  The callback is simple, clean, and best of all, future proof.
>

I heartily agree, callbacks are the correct way to do this.

> Date: Wed, 28 Mar 2012 17:07:25 -0700
> From: "RodrigoCard" <cuecax at gmail.com>
> To: sdl at lists.libsdl.org
> Subject: Re: [SDL] iOS System Callback
> Message-ID: <1332979645.m2f.32436 at forums.libsdl.org>
> Content-Type: text/plain; charset="iso-8859-1"
>
>
> Jared Maddox wrote:
>>
>> > Date: Tue, 27 Mar 2012 09:59:42 +0100
>> > From: Tim Angus <tim at ngus.net>
>> > To: SDL Development List <sdl at lists.libsdl.org>
>> > Subject: Re: [SDL] iOS System Callback (attn: Piotr Drapich) (fwd)
>> > Message-ID: <4F71817E.9030807 at ngus.net>
>> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>> >
>> > On 27/03/2012 08:19, sdl at union.pl wrote:
>> >
>> > >
>> > > > It also implements all important iOS events as SDL
>> > > > events:


>> > I sort of wonder if it's a good idea expose the functionality by events
>> > as well as it implies it is expected to work OK where in many situations
>> > it won't. It also means the same functionality is exposed in two
>> > different ways; this may be confusing.


>> At the same time, there may be apps where it makes sense to separate
>> time-critical code & non-time-critical code. Can't say that I know of
>> any, though (my backburner project likely won't deal with the
>> time-critical bits correctly EVER, so.. ). Can anyone think of any
>> cases where it would be useful to have both callbacks & events?


> Handling it ALSO as an event could be useful.
> For example, I could pause the game or prevent drawing the next frame (until
> the assest are reloaded, in case you dump all the textures in the
> willenterbackgorund ) when iOS returns control to the mainloop.
>
> The main loop must be aware that the callback was called, posting these
> events as sdl events looks correct.
>

So this makes sense to someone else, too? That's good.