object-oriented as2 development

needed to build a monumental video game app in as2.  have always used as2 on an as-needed basis, but decided this time to operate on it.  open it up. see how it works.  or doesn’t work. dragged as2 screaming into the year 2008. into the light.

the utility classes i found, modified, or extended are useful for anyone coming from an object-oriented background:

• DocumentUtil allows you to specify a Document class (aka Main class). :: Ryan Taylor @ boostworthy.com
• BezierTween creates beziers using little phrases that even Flash 7 can compile. :: Felix Turner @ airtightinteractive.com
• MovieClipBubbler bubbles as2 MC events. it is not simpler to use than an Event Broadcaster.  it does have performance benefits over an Event Broadcaster. :: Ralf Bokelberg @ helpqlodhelp.com
• Hitbox is an essential extension of MovieClipBubbler, at least in concept.  you should take my implementation and twist it to your ends.  using Hitbox avoids having to draw zero-alpha’d Hit areas on all your MovieClips.  in simplest execution, the MovieClip in your Library links to Hitbox (rt-click/Linkage/’Export for ActionScript’/Base Class).

the interface is your friend

picnik has the friendliest registration process i have ever experienced with immediate, intuitive, consistent feedback.

moxie & me

“moxie & me,” it sounds like a chick flick. Hell, with the amount of time i spend with Moxie…

Flex Builder 3 (aka “Moxie”) Beta 2 is engaged in a user-friendly direction. Unlike my relationships. Adobe is all over their bug database. Moxie’s current character flaws are worth noting:

• Pre-Moxie workspaces will act irreverant. Import all old projects into a fresh workspace.
• When your project clearly isn’t building, turn off “Project/Properties/Flex Compiler/Generate HTML wrapper file.” Then click “Apply” and turn it on again. Sometimes it works. Other times you need to make a new Project.

Not bugs but some tips to save you time:

• When drawing shapes programmatically: create a UIComponent rather than a Shape, Sprite, or something else that you’d think would work.
• this
  1. var loader:Loader = new Loader();
var url:URLRequest = new URLRequest("http://www.helpexamples.com/flash/images/image1.jpg");
loader.load(url);
this.rawChildren.addChild(loader);

  is not as correct as this

  1. var loader:Image = new Image();
loader.load("http://www.helpexamples.com/flash/images/image1.jpg");
this.addChild(loader);
• Skinning the MenuBar points:
  1. You can apply styles for the submenu to Menu, including borderSkin, fontSize, paddingLeft, and now in build 187191 if openDuration=0, you can skin showEffect.
  2. The submenu doesn’t exist until activated from the MenuBar. myMenuBar.addEventListener(MenuEvent.MENU_SHOW, setSubMenuProperties); You can then alter additional properties and add filters, masks, …
  3. If your user group is expecting MenuBar RollOver to show the menu, you must play Houdini. Listen to anyone having a MOUSE_OVER:
     1. menubar.getChildAt(j).addEventListener(MouseEvent.MOUSE_OVER, menuItemRollover);

     Redirect the event:

     1. e.target.dispatchEvent(new MouseEvent(MouseEvent.MOUSE_DOWN));

Grabbing the swf’s URL when the swf is loaded

I finally got fed up with recompiling our Flex application for the different servers I had to deploy to and decided to have it automatically figure out where it is and configure itself. This should have been relatively simple as the swf’s URL is known by the Flash player and was always available in Flash as _root._url (or _root["_url"]). I knew that Flex had to have this information available so I looked it up.

Sure enough, there is a place in the DisplayObject where you can get this info. DisplayObject.loaderInfo.url. Further looking showed that the Application object should have the loaderInfo. I added some code to test this in a function which was run on the “creationComplete” event and….the loaderInfo object is null.

I then looked further to see if there was another object that maybe had the loaderInfo I needed. The root proprty is supposed to give you the root object of the SWF and this should have the right loaderInfo, right? Nope, still null on “creationComplete”.

I now got suspicious and added some code to look at the URL on the click of a button. Sure enough this code was able to access the loaderInfo and hence get the URL.

So why is the loaderInfo not loaded when the application is created? If I can’t get the URL I can’t do my configuration as there is no other event I know of which I can listen for to set the configuration.

I now dove into the Application code in the Flex framework. I soon found the _url property which is declared as mx_internal. I remembered reading Daniel R’s blog post about mx_internal and quickly set up my code to use mx_internal::_url. Success, this is set on creationComplete.

Now to ask Adobe why we don’t have access to loaderInfo until after the creationComplete event….

flex bug makes 9-slice seem slippery

an especially relevant bug to anyone skinning, 9-slice is non-operative on bitmap assets imported from flash. this lost me a couple hours while skinning tonik.

SearchCoders Dashboard: apollo app integrates as3 dev’s

Find code & commentary.  Provides mail list tracking, RSS feed pulls, Search, plus Chat about Flex/Apollo/Flash.

Bindings to E4X don’t work as expected

Our current application uses a large XML structure to send data back and forth between the frontend and backend. This is a legacy interface which was created 2-3 years ago by the developers of a Flash 6 version of the same application and has stuck with the system since then. If I had my druthers I’d use Flex Data Services to retool this into asynchronous micro-transfers to speed up the whole process but we haven’t been able to convince anyone to buy a license for FDS yet.

To get the data into and out of the XML structure I decided to try Flex’s Bindings. This would mean we’d just have to specify the relationships and whenever the values changed the data/UI would be automatically upated. This worked fine for each individual page I created but once I started running through the entire application each additional page created caused the application to slow down noticeably. By the 20th page or so the UI was nearly unresponsive when touching any element attached to a binding. Typing text into a TextInput was a laborious character-by-character process.

It was obvious that adding the bindings has caused this but at first I couldn’t understand why. Each element was tied to its specific place in the XML and so should have been firing a single binding. Looking closer I noticed that all of the bindings from the XML to the UI were getting fired *every time* a bound UI element changed.

It appears that the reason for this is that an E4X XML object fires a change event on the top-level XML object whenever anything inside it is changed and that bindings which have an E4X source fire when the top level changes. This means that every time I updated a UI element and the binding into the XML changed the value that all of the bindings *out* of the XML to the UI were fired, causing a huge slowdown.

I ended up writing the “bindings” as simple “=” statements and calling them when a page is navigated to or away from. This introduced extra work to make sure these happen at the right time, but it’s far faster and will be simpler to maintain given the structure of the code.

Only one Validator per element??

Further work with Flex Validators has lead me to find yet another limitation. You can have only one Validator per element. If you attempt to apply multiple Validators for one element you end up with the last one fired usually taking precedence as its errorString and valid/invalid events are the last set/fired. I do see the framework limitations making this happen but it is still very frustrating to not be able to combine Validators to their full potential. Things get even worse when you attempt to use a single-field validator and a multi-field validator on one element. This leads to nasty work-arounds which are nearly as bad as rewriting the validation code manually.

RadioButtonGroup is not an IValidatorListener

While building out a new framework for a series of highly form-centric applications in Flex 2 I ran into a strange problem. Seeing as I’m now using Flex I wanted to do things the right way and use a Validator to make sure that a value was selected. Imagine my surprise when the validation didn’t seem to happen. After some debugging and tracing through the Flex framework’s code I finally found that the Validator was firing and getting the correct result but failed to set the errorString property or fire the invalid event on the RadioButtonGroup being validated. Further tracing lead to the problem. The RadioButtonGroup was failing a test for “is IValidatorListener”. In other words, the RadioButtonGroup, which is conceptually a form element, does not respond at all to the events fired by a Validator.

Eventually through documentation and perusal of the RadioButtonGroup code I also realized that the RadioButtonGroup is not a UIComponent. This is understandable as the concept of a RadioButtonGroup is not linked to a specific layout of the radio buttons and the “group” really has no set physical presence. This explains why the IValidatorListener interface isn’t implemented in the same way as the other form elements as the UIComponent base class implements this for most of them. It doesn’t explain why the RadioButtonGroup does not implement it itself, however.

Of course you can always set the listener on the Validator to one of the radio buttons but I’d rather have all of the radio buttons show the error to let the user really know what’s happening.

To this end I created a RadioGroup class which implements IValidatorListener and sets the errorString and fires the valid/invalid events on each of the radios within the group.

editing page content without leaving the page

we should have immediate user feedback working on our flash sites.  ely greenfield’s flex controls provide one means to the end.  his classes allow on-page field editing.