Adobe AIR Development

[TheDarkIn1978]

during the PlayBook webinars there was talk about the importance of pausing your application's active processes durring a deactivate event (application becoming minimized), only restarting those paused processes during the subsequent activate event, logically, to save on system resources.

however, from the previews of the device coming out of CES 2011 this week it appears that the user will have full control of what they want to have happen when an application becomes minimized/deactivated (see attached image).

therefore, since it's ultimately up to the user, it's not clear whether programatically managing activate/deactivate events is something that should still be considered.

the way i see it is that if the user chooses to deactivate their applications when they leave full screen mode then the system will force the application to pause.  however, it might also mean that deactivate/activate events will only be executed if the user selects to deactivate applications.  i assume the former is the case, since it wouldn't make sense to permit developers to leave their wares running while the user has explicitly chosen otherwise.

thoughts?

[zezke]

Since RIM told us explicitly that we should listen for de/activitation events, I think those events will only be dispatched in case the user really wants his apps to be deactivated when not in the front. However the alternative you present also has some clear advantages for the Playbook.

[peter9477]

I believe DEACTIVATE will still be received, and is a clear signal to an app that it is no longer running full-screen and with the user's devoted attention.  An app that receives this signal should persist unchanged state ("save data" in non-geek speak) and take other action as appropriate.  For many Flash apps it might be a good idea to drop the frame rate down to 1-3 Hz in any case.  I think if the system is configured to pause background apps that this will always be done for us, but it may be a good idea to save CPU by doing this for yourself in apps where it's pointless to continue rendering.

Apps which have the ability to do something "useful" by continuing to run can be structured so they do that even after receiving DEACTIVATE... not that I think this ability is nearly as useful as they've been hyping.  After all, how many videos can one play without watching them?

I haven't seen application-specific controls for the throttling/pausing behaviour.  The user was limited to "pause when not in foreground", "pause only when some other app comes to foreground", and "never pause" (roughly...).  So the user may want to configure their system to allow a few interesting apps to be simultaneously active, yet not really want your app to suck CPU by continuing to render updates even after receiving DEACTIVATE.  Also, this may still be something that's in flux, as previously we've heard that they are still exploring what users want in this area.

I plan to respond to DEACTIVATE always by persisting data (if appropriate) and preparing to be killed.

[peter9477]

New information is available that is highly relevant to this thread.  I've posted a new thread about it here.

One key fact is that, depending on the QNXSystemPowerMode settings, an app may not get a DEACTIVATE event when it is minimized, so using that alone to tell you when to persist your app state is unreliable.