[SDL] Bug: UIKit (iOS) version should NOT be calling Pump

[Jeremy Jurksztowicz]

My own setup is simply a *hack*, were I receive the callbacks and respond
immediately, I'm ignorant of the architecture, but recall readying about
how the callbacks are synchronous and run on the main thread. I assume that
SDL hijacks said thread and so stays single threaded, therefore I don't
deal with any concurrency issues.

So I receive said callbacks (and you MUST be able to respond to low memory
ones, unless your app has a completely static memory map, for instance I
unload music and delete pather and AI caches), and react right then and
there. I don't see any way in which to shoehorn SDL's event system to the
iOS system in a way which guarantees the systems intentions are
communicated clearly, so I vote for a really simple extension to SDL,
whereby you register a listener, and when such an event is triggered, the
listener immediately receives the event and handles it as best it can. It's
not (IMHO) in SDL's scope to to massage any such system callbacks into
something that they aren't, especially since we're talking about a system
specific behaviour. Let the dev respond as best they can!

For example, Cocoa allows you to spawn background threads that run even
while your app is suspended, these are designed for the very problems this
thread is discussing. However, it's not SDL's responsibility to present
this in it's API. If you're writing for iOS, you can integrate this (or
not) into your app in a way that is best suited to your needs! Yes, there
are some best practices such as stopping rendering (a must), and unloading
textures, saving state, but SDL is not responsible for enabling those, devs
can do that on their own using the best API at hand.

In conclusion, simple listener callbacks please.

On Thu, Mar 22, 2012 at 10:03 AM, Tim Angus <tim at ngus.net> wrote:

> On 22/03/2012 13:54, Brian Barnes wrote:
>
>> iOS, by design, expects you to do this stuff in a callback. Can you get
>> away with an event? Probably, but it'll be in the realm of a hack and
>> you are asking for future problems in new iOS versions and possible
>> rejections.
>>
>
> I looked at this briefly a while back and came to the same conclusion.
> More specifically, if you're handling things with events it means that
> there is a period of execution between when the event is created and when
> you handle it.
>
> Anything can happen in the intervening time, including things that you're
> not allowed to do that can easily crash the whole app. The SDL event model
> isn't really compatible with how iOS expects things to be handled.
>
> ______________________________**_________________
> SDL mailing list
> SDL at lists.libsdl.org
> http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.org<http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20120322/3fb60c9b/attachment.htm>