The geeks over at Automata Studios are this week’s guest on Adobe XD’s INSPIRE. Today's post is all about the challenges surrounding creating occasionally connected applications.

Check it out!

The geeks over at Automata Studios are this week's guest on Adobe XD's INSPIRE.  Today's post is from Branden, who writes all about the challenges of creating the Skit-Based pranks for the recently released jackassworld pranks application.

Check out the article at INSPIRE!

I was playing around with Flash Builder 4 & Flex 4 after the public beta was announced, and decided to whip up a quick, very simple AIR client for Basecamp.  It's pretty straight forward and there's not much code, but if you're having trouble getting started with AIR, Flex 4, or Gumbo, perhaps it will help.  

Basecamp provides a very simple REST-based API, which is documented at http://developer.37signals.com/basecamp/. I just used URLLoader and URLRequest to pull the data, with authentication turned on. When authentication is turned on, your OS will handle username and password requests.

I ended up using anchor-based layouts because I couldn't figure out, with the spark components, how to center my screens.  Maybe this is the way you're supposed to do it...I'm not sure.  If anyone has any input as to best practices for the new layout mechanisms in Flex 4, I'd love to hear about them.

Beyond that, there's not much to the application...just a sample.  Maybe I'll flush this thing out as I continue to play with Flash Builder 4.  All in all, in regards to my feelings about Flash Builder 4 and Flex 4, I am going to reserver judgement until I have a larger data set to work with.  Building this sample was very easy, but I don't think I accessed enough of the new features to cast judgement yet.

Download source as a Flash Builder 4 Project Here!

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!)