[SDL] iOS System Callback

[Brian Barnes]

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!*

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

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.

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.

[>] Brian