February 20, 2009
by Branden
Let’s just say, for the sake of argument, that you were building an AIR application that needed to load external SWFs. Let’s also say you needed to communicate back and forth between that SWF and the AIR application. As it says on old maps – “here by dragons”.
AIR introduces two properties to the LoaderInfo object – parentSandboxBridge and childSandboxBridge. You can use these to communicate from the child to parent and vice versa. However, there are a few gotchas.
First, it appears that the the ability for the child SWF to set the “childSandboxBridge” property on it’s instance of LoaderInfo depends on AIR to do some magic. If your child SWF is small, it will probably happen prior to your constructor being called, but you can’t depend on that. It turns out you need to listen for the Event.INIT event coming from the SWFs LoaderInfo to know when you can actually start to populate childSandboxBridge.
Secondly, anything that goes through the sandbox bridge gets totally stripped down to essentially generic objects with properties – there are no methods and I have yet to find a way to cast these generic blobs of data back into a proper instance of a class (this even applies for built in classes, like ByteArray and BitmapData!). The only real good news here it is possible to take any class that supports the [] operator (such as ByteArray) go across the bridge, you just have to do a bit of work. On the receiving end of the data you just create an instance of the class you want, then loop through the data that came over the bridge (it’s length property will work) and use that data to populate your object. (I just used this to send Bitmaps through the bridge via a Bitmap -> BitmapData ->ByteArray ->BitmapData -> Bitmap progression. It worked, but YUCK!)






no comments