Thank you for visiting the BlackBerry Support Community Forums.
BlackBerry will be closing the BlackBerry Support Community Forums Device Forums on April 1st (Developers, see below)
BlackBerry remains committed to providing excellent customer support to our customers. We are delighted to direct you to the CrackBerry Forums, a well-established and thorough support channel, for continued BlackBerry support. Please visit http://forums.crackberry.com or http://crackberry.com/ask. You can also continue to visit BlackBerry Support or the BlackBerry Knowledge Base for official support options available for your BlackBerry Smartphone.
"When we launched CrackBerry.com 10 years ago, we set out to make it a fun and useful destination where BlackBerry Smartphone owners could share their excitement and learn to unleash the full potential of their BlackBerry. A decade later, the CrackBerry community is as active and passionate as ever and I know our knowledgeable members and volunteers will be excited to welcome and assist more BlackBerry owners with their questions."
- Kevin Michaluk, Founder, CrackBerry.com
Developers, for more information about the BlackBerry Developer Community please review Join the Conversation on the BlackBerry Developer Community Forums found on Inside BlackBerry.
01-07-2011 12:59 AM - edited 01-07-2011 01:07 AM
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.
01-07-2011 03:37 AM
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.
01-07-2011 07:11 AM
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.
04-13-2011 09:59 AM
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.