Also filed internally at RIM via issue PR104184
Despite setting systemIdleMode to KEEP_AWAKE, the backlight still dims on Tablet.
NativeApplication.nativeApplication.systemIdleMode = SystemIdleMode.KEEP_AWAKE;
After further investigation, the root of this issue lies within the WebWorks framework. The window object used by the WebWorks framework is different than that of the window object used by WebKit.
"... confirmed that setting KEEP_AWAKE on a window that's not truly visible does nothing. If in your case the WebKit window is totally covering the application window (e.g. 1024x600 on Winchester1) then setting keep awake on the application window won't work.
You could possibly set the keepawake on the application window's child window, which is the webkit window. But keep in mind that Flashplayer plugins could mess with this, unlike HTML5 video which does not."
Need help from an AIR expert. How can a WW developer target the WebKit window, rather than the application window? Is this just a matter of referencing a different namespace, or is it more complicated than that?
The following was received from a 3rd party developer:
"After some playing I think I found a (dirty) work around. I noticed from the sample app on github that if the video had been started and sleep mode turned off, the state would be maintained even after the video had been paused. If the video wasn't started, the sleep mode state was ignored.
So, I added the video to my code, ran it once on auto, muted it and placed it behind the other container windows. Combined with the extension, my app has been running 15min with no timeout and no evidence of the video being present."
Clever! I may give this a try in my app.
It's been several months and PlayBook 2.1 was released recently. Is there any update on this issue? Thank you.
Given that BB10 will not be coming to the playbook, being able to use playbooks as persistent displays would be really handy. For this to be feasible we would really need this extension to work. Is there any way we can get any traction with this? The BB10 preventSleep extension uses a native method screen_set_window_property_iv; is there any chance this exists in TabletOS?
Just as a followup: the BB10 PreventSleep compiles with the Tablet OS 2.1 NDK. All that is missing is the Air Native Extension to call PreventSleepNDK::setPreventSleep.
Looking at the PreventSleep code the real question is whether int handle = (int) strtol(root["handle"].asCString(), NULL, 10); actually returns a handle to the window handle on TabletOS.
int handle = (int) strtol(root["handle"].asCString(), NULL, 10);