FABridge & memory …

One of the biggest changes in the latest FABridge release is the addition of memory management mechanisms. If until now everything that was passed from ActionScript to JavaScript via the bridge stayed in memory until the page was reloaded, this is true no more. now various objects behave differently with their allocated memory, depending on their origin and purpose.

The mechanism behind the memory management functions is basic reference counting, without cycle handling. This is enough because both ActionScript and JavaScript already have their garbage collection schemes in place, so all that was needed was a way to remove object references from the bridge structures. And this has been put in place. If you don’t care about the memory you are using, then you can develop applications almost just like now (there’s a single thing to chase here). If you do care, the bridge offers the tools to help:

  • Increasing the reference count for an object: object.addRef() or the more arcane FABridge.addRef(object). Useful when an object is destroyed automatically but you still need it. (Special hint here for those who do not care about memory – you still need to do this, or you’ll end up with stale references).
  • Decreasing the reference count for an object object.release() or FABridge.release(object). Do this when you care about memory and want to clear out old objects. If the reference count has been artificially increased above 1, this call will not destroy the object. If it is already 1, the object will be destroyed immediately.
  • FABridge.releaseNamedASObject(object) -immediately destroy the object passed as argument, regardless of its reference count.

As you can see a lot has been going on when it comes to memory, with emphasis on helping the user and keeping it simple. These changes mean that now some objects clean themselves up when they are no longer needed, but not all. And as such, if you want to avoid errors triggered by null object references you should understand what is kept and what not.

The following rules apply:

  1. Objects created explicitly by the user from JavaScript are not removed from the bridge automatically.
  2. Objects creates as the result of an ActionScript function call and returned to the user in JavaScript are kept. Their intended purpose is not obvious, so we cannot remove them automatically.
  3. New objects created in ActionScript after being passed as arguments to function / method calls from JavaScript are not automatically destroyed.
  4. Events and other objects created automatically in ActionScript and passed to a handler function in Javascript only live for the life of their dispatch function. Outside its scope, the object reference no longer exists.

One of the most basic examples which will appeal to both developers which care and which don’t care about memory is the case when you add an event handler from JavaScript and need to delay an execution via a setTimeOut call, like here:

….
var flexapp = FABridge.flash.root;
flexapp.myButton.addEventListener(“click”,jsDispatchFunction);
…..
function jsDispatchFunction(event) {
setTimeout(function() {doSomethingLater(event);},10);
}
…..
function doSomethingLater(event) {
alert(event.getKind());
}

This snippet of code, as it is right now will fail, because once the direct dispatch function ends, the event object is destroyed. Thus, the doSomethingLater function will throw an error. If you add a line inside the jsDispatchFunction, like this

event.addRef()

will fix everything.

And this is it for this post, for it is already too long!


Posted

in

,

by

Tags: