All Things Flex, Flash, and ActionScript

Not sure if anyone else has come across this, although I heard through someone else that it may have been mentioned by Grant Skinner on one of his circuits but I don’t see anything on his site about it.

As far as I know, this predominantly applies to applications built in the Halo space, although I suppose it could have some sort of implied effect to Spark.

The Symptoms: When setting the compatibility flag to “3″ certain runtime elements will render to the screen approximately twice as fast when using the Flex 4 SDK (and yes I mocked out an uber-simple PerformanceMonitor which checks the time delta between construction and the FlexEvent.CREATION_COMPLETE). This will become even more evident if you use a distributed rendering model to draw A LOT of elements to the screen (eg iterating a list of elements in a Queue paradigm -this is typically used to manage user expectations during heavy cpu cycles).

The Probable Cause: If you delve into the guts of SDK you’ll notice they use the FlexVersion.VERSION_3_0 just about everywhere in order to determine what behaviors or styles to run. It’s 1 way to keep your software platform up to date using a single source, however it complicates things with backward compatibility. The one area where it probably has the biggest affect is in the StyleManager. Considering the StyleManager is essentially a giant hash map used to manage both inherited, non-inherited, single overridden class selectors, and default type selectors: this is probably the biggest culprit for the Flash Player to be putting on the breaks.

The Risk Assessment: Thankfully not a whole lot appears to change and / or render incorrectly when using both a mix of type and class selectors in stylesheets. The one thing I did notice is some elements which would be typically interpreted as straight string must be encapsulated in quotes (eg textAlign : right now needs to be textAlign : ‘right’ ).

The Key: The key to using the flag is setting it to only 3 or 3.0, because this code checks against a Number, setting the flag to 3.1, 3.2, or 3.3 will cause the additional code to execute thereby giving you the same performance degradation as with just running the actual Flex 4 SDK.

I found only a few references to this, but not much of a well documented solution, so for those who stumble upon this needing one, you’re in luck.

The problem: The ComboBox does not dispatch a change event under all circumstances, most notably when you use the keyboard to select find the particular item in the list. Think of a states combo, where by ‘n’ will first cycle to Nebraska. This then closes the combo, but does not appropriately fire the change event as it would if you manually scrolled and selected ‘Nebraska’ from the list.

Why the problem exists: The combo is a composition of a TextInput, a Button, and a List. While the appropriate change event listener is added to the input, it’s not added to the List to it’s fullest extent. It only checks to see if non-printing characters are used to see if the user is attempting to scroll the list with the arrow or page-up / page-down keys. Thus, when using a normal alpha-numeric filter,  this doesn’t reflect itself in the parent combo control.

The fix: This fix is unusually difficult in light of the fact of one of my earlier rants that at best all properties and / or methods of a highly public and distributed platform, ie the SDK should only ever be protected. Literally all accessors to both the instance list and it’s combo listeners are private? What the hell?

Further proof of their own exacerbation, is a comment that literally says starting around Line 1512:

private function displayDropdown(show:Boolean, trigger:Event = null):void

// Subclasses may extend to do pre-processing
// before the dropdown is displayed
// or override to implement special display behavior

So remind me, how is that possible with a private selector? Oh yeah.

So the only way around this is to override the downArrowButton_buttonDownHandler() handler, and use the mx_internal::isShowingDropdown property to find if the list is about to be shown, and get a reference to the list by grabbing the dropdown property where you will attach your own ListEvent.CHANGE listener. In this handler you proxy dispatch a clone from the ComboBox point of view, and you finally have a change event that now works.

Finally, create another Event.REMOVED_FROM_STAGE event in the createChildren() method, since destroyDropdown() is also private (note to self: !#$#@!) to clean up your additional change event to prevent  a memory leak.

http://help.adobe.com/en_US/AS3LCR/Flash_10.0/flash/sampler/package-detail.html

It’s interesting to see, not necessarily from a backward compatibility model, but interesting none the less for those of us who are leading enterprise applications which are still stuck at “lowest common denomenator” just due to their tremendous size and expected reach.

I can certainly see how many applications can expect to reach a better performance vs cost (engineering man hours, legacy patch costs, etc) ratio for their intensive parts which either have the best chance for memory or cpu utilization management. Lets face it, none of our applications can be so brazen to run on a Cray with unlimited resources (although it sure as hell would be a lot easier on reducing Engineering constraints or getting “Pixel Nazi’s” off our backs).

This one seems weird to be but I guess I didn’t notice it earlier. As we all know Styles set as an external source need to be compiled first, which even for a modest application pushes this up to about 100k or so. I thought this was a bit heavy but didn’t think of it any further.

What the documentation tells you about Modules fails to mention that you can most certainly do the same thing when running the compiler on your compiled.swf stylesheet.

Run the stylesheet builder with the

against the

and instantly save at least 10x the file size (at least this is what I experienced), as it went down to about 10-12k or so.

mxmlc -link-report=myapplication.xml -output=myapplication.swf MyApplication.mxml

mxmlc -output=mystylesheet.swf -load-externs=myapplication.xml MyStyleSheet.css

Instant savings.

Getting a tree to represent data in XML is fairly straight forward, and most examples use this as the default. However, what happens when you have an object tree and want to be able to represent that as the descriptor you built but also easily allow drag-drop operations (especially in cases where you need the parent object reference)?

It turns out writing a new DataDescriptor class is not necessary (as I learned the hard way), but it was necessary to figure out what they are trying to do with ancestors and child objects. While there is no defined interface for it, the data descriptor tries to figure out if the current object is parented by looking for a property called children.

So if you implement your object class with this property as an ICollectionView (it will convert to a ListCollectionView -so you might as well go the extra step to do it yourself), you’re all set.

To the naysayers of MXML / “I don’t see that it’s any better if I can write it all out myself in AS” / progress antagonists, if you’re the type to write ItemRenderers and/or ItemEditors this is where you single-handedly loose in time & money, readability, code quality. Every time. (Those who I previously worked for should seriously pay attention -free lesson here -but they never paid attention to me the 1st time around =) . (more…)

Arrays: every, filter, map, some

Nearly all callback methods to a filter-based method only specify that the type of object to be inspected be of type Object. While this certainly allows for the greatest flexibility in what is stored in the ordinal list, this doesn’t give you much control over chasing down RTE’s or allow for IDE ease of use in auto-completion. (more…)

The delete operator:
The documentation says the delete operator in reference to XML object can take an XMLList reference. In the initial outset this sounds fantastic because I can apply just about any searching algorithm (think regular expressions, descendants, etc), to a deeply nested object without having to traverse the entire object. However this simply is not the case.
(more…)

One of the things that I’ve noticed that might catch a Java developer off guard, is the use of methods that expect a return type and the incorporation of try catch finally – throw statements. The Flex compiler at this time isn’t smart enough (or quite possibly by design), that it doesn’t detect when a throw statement is executed that it kills the execution thread.
(more…)

One of the things that I’ve noticed with the SDK that is hit or miss, and can probably be attributed to a slew of different developers working on various aspects, is most event handlers are written in the private space especially if it’s a top level component.

This is not good design especially in light of the news that Adobe has announced it will make the SDK apart of its open source initiative with staring with Flex 3. The simple reason why is extensibility. Most projects are made up of at least 1 and probably up to several dozen custom components that extend off the SDK architecture. FlexLib is a prime example of this. With privatized event handlers, this makes it impossible to write an extended object that needs to intercept and enhance a given event. Duplicating the event by assigning the same event to a different handler achieves a work around however this essentially only adds overhead and to the overall confusion of trying to keep track of duplicated events.

Writing the handler to the protected space is a far better solution. It offers the same security protections of not allowing other objects to mistakenly execute the method, but allows the integration of an event hierarchy to become seamless. It also gives one added underrated benefit: event polymorphism. The encapsulating owner now has conditional execute privileges over the super method, which gives rise to writing controllers a lot easier to manage.