The paperCrane’s view from the reverseFold

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….

UPDATE: After more searching I found the FlexEvent.APPLICATION_COMPLETE event. If you try to access Application.loaderInfo.url when this event is called it is set.

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.

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. I’ve filed two bugs with Adobe, SDK-11973 and SDK-11974.

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.