Adobe AIR Development

[quentin]

Don't know if this is a bug, but it looks like so: the nativeApplication.openWindows property returns null where it should return an Array, be it of zero items...

I discovered it because it breaks Grant Skinner's FramerateThrottler utility class. Here's the fix for line 76:

} else if (/* Fix in */ na.openedWindows && /* Fix out */ na.openedWindows.length > 0) {

 That's it!

[MSohm]

It looks like it could be an issue.  I have sent this off to our development team for further investigation.  Thanks for reporting this!

[shawnblais]

Grant's throttler is kinda obselete, newer versions of AIR throttle themselves. AIR for Android throttles itself to 4FPS on DEACTIVATE.

My App actually overrides this, and manually throttles down to 1FPS as I found no negative impact.

Regardless, openWindows is not going to hold any useful info for you, since Mobile AIR Applications are not "Windowed Applications" they are simply "Applications" they only ever have one open window.

[quentin]

Can you tell me more about "newer versions of AIR throttle themselves"? This is true for MXML Applications but I'm not sure it is for AS3 only apps. At least I think it doesn't for PB AIR apps!

I know this openedWindow Array isn't really useful for PB apps but since it looks like a bug and may break existing APIs I thought it was worth mentioning.

[shawnblais]

Since AIR 2 (I believe) they basically took Grant's idea and added it a a standard feature.

So In Desktop Apps, when the window loses focus, you'll see that the App is actually automatically throttled, any animations you have on screen will slow down.

In AIR for Android apps, when you deactivate an app, the runtime throttles down to 4FPS, you can verify this by tracing on ENTER_FRAME with an elapsed millisecond count.

Now, BlackBerry I'm not sure, and it would be great if msohm could clarify.

I would expect that it acts like a standard AIR 2.5 app,  but on the otherhand, I know that they have this nice UI where you can see apps running in the background as you drag to the left or right, so maybe they will not support this throttling behaviour, or implement a less aggressive target framerate?

Would be nice to know

[quentin]

Oh, I didn't know that!

And do you override this FPS setting? I looked for it in the docs but couldn't find.

I think FPS throttling in PB AIR apps is a must-have, you don't want your app to run at full spedd when it's in the background!

[shawnblais]

You just add a DEACTIVATE listener to the stage, and then it looks like this:
protected function onDeactivate(event:Event):void {
            model.savePrefs();
            stage.frameRate = 1;
            System.gc();
        }

Running a GC pass on deactivate is a good idea, your app will likely not GC itself when it's in background as no user interaction is occuring, so by GCing yourself, you release any unneeded memory, reducing the likelihood your app could be killed off by the OS if it runs low on RAM.

[quentin]

Uh OK. I thought there was some kind of "NativeApplication.backgroundFramerate"...
So yes, BB should implement that, or tell us they don't, so we know if we have to handle it.

[shawnblais]

Ya I don't know of any API to control this throttling behaviour directly, I think it's baked right into the AIR 2.5 runtime. I could be wrong though...

[MSohm]

Deactive apps do not render any AIR windows and their frame rate gets set to 4fps. If there is a native window in the AIR app group, like the video in the video app, it will continue to render unless told otherwise.