All Things Flex, Flash, and ActionScript

As Flex Architects / Team Leads can attest (at least those of us who do the proper preparation for a project), choosing an architecture to base your code upon isn’t an easy task since many good ones are out there, however each is like a relationship that leaves just a little off the table to be truly a desirable solution. However as with any framework worth it’s work, most of them are highly extensible without the need to modify the original to achieve the characteristics you need / want.

RobotLegs: Mediating sub-content to a Spark NavigatorContent pane.
Turns out there is a ‘bug’ and/or limitation when using the spark-based layout framework, and thankfully it’s a relatively easy one to over come. It has to do with the <s:NavigatorContent /> and how those children are built according to it’s creationPolicy as set by an appropriate container (TabNavigator, Accordion, and so on). Because the mediator is triggered on the FlexEvent.CREATION_COMPLETE event, it doesn’t take into consideration that while additional containers will be put on the stage, their containing children will not be instantiated since it’s part of the deferred process. This leaves the mediator in ‘limbo’ land since we obviously want to setup the user gestures for all the guts of the container (combos, buttons, data grids, etc). (more…)

Off topic here, but in the sense of the Adobe development world it’s not since the new rollout uses the Flash Platform. Seriously though, generating a wrapper isn’t that hard especially since the FB or FX tool generates one for you to start with, but really this sort of egregious issue gets all the way into production – past the developers, past QA, past UAT? Really? How sad.

Even more ridiculous is the IE version has a whole host of issues:

• The sandbox issue stems from http to https communication is not explicitly stated in the crossdomain policy.
• The same remote translation object is not properly encoded on the GET parameters.
• The caught exception where it’s painfully obvious the developer doesn’t understand even the most basic String API with either substr(start, length) or substring(start, end) – the .xml is missing which is why it can’t find the file.

There is probably only a handful of things that are probably less understood at the SDK level as to how just exactly the Drag-Drop event sequence is generated, captured, and handled. First off, the UIComponent is the one where events can be registered but does absolutely nothing about dispatching or even ‘psuedo-dispatching’ through an intermediary.

Not In Here:

Case is point – we all know about the DragManager, and how you have to enable certain targets to allow the capture sequence to generate events for the final drop event, however it’s really the SystemManager that handles a bunch of marshalling for you – since it sits at the near root level it knows about MouseEvents for just about every object.

It’s this ferrying back and forth between the InterManagerRequest.DRAG_MANAGER_REQUEST event between the DragManager and ultimately passed through the Implementor (ie DragManagerImpl), and the SystemManager, is what creates the DragEvent to eventually be fired via the DragProxy. This is why the documentation says it is important to trigger the allowDragDrop method from within the DragEvent.ENTER event – because the target is then assigned directly to the proxy instance.

(more…)

Highly flexible applications and highly secure applications are usually at the opposite ends of the spectrum and require some sort of constant balance. So how do you mitigate your security risks when you need to build an application that is dependent on running modules at runtime via some sort of configuration?

ApplicationDomain.currentDomain is the just about the worst thing you can do when trying to build a secure application.

The problem:
Your modules are loaded at runtime which need to interface internal code you’ve written in your main application. This means the ModuleLoader needs to then set the currentDomain to ApplicationDomain.currentDomain. However ideally the module loader needs to be able to distinguish levels of trust if it’s a module you (or trusted developer) have written, or a rogue module.

The ugly issue:
When using a blanket statement to allow all modules to load with the currentDomain, you are giving every loaded swf trusted access to your entire platform. Some cases, this isn’t a big deal. It becomes a nasty headache if you’re building an e-comm solution. It will allow man-in-the-middle attacks to allow someone to load their module, and using any number of methods for decompiling and introspection to figure out what class and methods are used to capture and/or listen to events for sensitive information like user info and payment tokens. Their swf only needs to add itself as an IEventDispatcher or through the document tree to add itself to the sensitive classes and wait for these methods to be triggered.

The solutions:
There are several different ways to help combat this problem, however some are better than others. Any solution pretty much involves using 2 ModuleLoader’s. One for secure / trusted, another for insecure untrusted. Always start the loading process from the insecure, then based on which method you choose -transfer the loaded swf to the untrusted ModuleLoader via addChild(), swapChild(), etc.

1. Use a trusted Interface in your platform that is always loaded at the application layer. However this is the weakest of them all since this only provides a minimal level of security as it can still be broken. The most flexible Modules use -load-externs as a compiler command to allow most of the dependent classes to be front loaded to the application. This makes things a bit speedier especially when loading several modules that share an entire platform. By using an internal interface you can check at the ModuleLoader level if the loading module has sufficient trust to be given access. This works in theory since the Flash AVM will not replace a duplicate namespace collision, but can still be defeated since I can write a rogue module and duplicate the secure interface using the exact same package.
2. Use server side methods to generate hash key’s in the configuration which matches the particular node of the module in question. NEVER use this method in conjunction with deciphering the hash key internally, it’s way too easy to figure out what’s going on in your code. Instead pass this hash key back to the server, ask it to validate it against the file name and it’s own interally identifiable metrics (eg file size, mod date, etc) to then pass back a Boolean pass/fail for trust. Based on this service, then assign which domain it can be loaded into.
3. Use a domain trust method in a static and final class to determine if the source of the module’s URL is coming from a place that is trusted. This basically means using RegEx along with hardcoded strings to determine if the URL is from ‘mydomain.com’. While this can be a bit laborious since it might require constant care to edit the domains that are trusted, however this particular solution isn’t as easily defeated since the list of trusted domains are embedded in your application.

The design detail:
You want to be able to create item renderers in a list that apply different styles depending on different visual cues or the data itself. For example lets take the TSA’s security approach with colors – the text changes for each level of severity.

The problem:
The problem is in handling the default case where every item renderer style should be the same, in the protected method of makeRowsAndColumns():Point After the itemrenderer instance has been created it’s styleName is set to the listContent container. This is important because no amount of setting through the ClassFactory properties, or setting styles anywhere in the pre-construction phase will save these unique values since it’s reset after it’s created.

The solution:
The one I came up with overrides the actual styleName property itself, where with a bit of checking we can safely ignore only the request coming from this creation area. This looks to make sure the object requesting the new stylename reference isn’t a ListContentBaseHolder or List so long as there is a stylename already set. Remember – properties are populated immediately after construction and before the initialization phase, that means this styleName will have already had something set on it from our ClassFactory in the List/Tree instance when setting our renderer.

Now in the List/Tree instance we can set our styleName:
Where:

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.

The problem domain: An issue exists where in a modular application you want to be able to share events from different modules without creating a dependency between the two. Deeply nested objects make this even more apparent when you realize you can’t use bubbling since they don’t reside within the same branch line down to the root trunk.

(more…)

I’m putting this out there as a give back to other Flash-Flex developers that want to use Joomla! as a data repository for any projects, in part because Rune Skjoldborg Madsen has taken the time to build specific component views in php to change the transport layer to XML.

(more…)

For anyone who might have noticed, especially if you’re coming from the flex showcase, the FlexPress application has been put in a suspended state of “permanent maintenance”. There are several reasons for this:

• The xml-rpc.php gateway (at least as of version 2.4) had to be ‘hacked‘ in order to inject additional methods to retrieve standard queries based on predominantly consumer-based methods. If you check the downloads section, it included things like getting data for blogrolls, comments, and a list of posts -where you only want the id’s and intro (useful for high volume). However because it was ‘hacked’ it made it impossible to keep up with the latest install. Since my php skills are elementary at best, it worked for the time being but it definitely had a short shelf life -if I put some time into it (read: not likely with home life), I could probably figure out how to extend the IXR gateway class to inject my own dependencies. With a recent update to 2.8 to eliminate annoying comment spam, this obviously broke the gateway, but broke it even further since I relied on SQL queries to get some of this data directly from the tables -however the tables have completely changed.
• I’m at a point where I need to start giving serious consideration to updating the ‘portfolio’ side of things, however I’ve put it off as long as possible because while design-wise it still fits with the presentation I want, the management of data is gnarly at best. It was designed/developed with Dreamweaver, but as completely static html using templates -good at the time but considering the maturity of app services using any sort of DB, it finally makes it possible to do things that couldn’t be achieved with static content: popular views, most current views, segregation of recent projects vs. archived material, etc. Using Joomla -I decided on this primarily for the extensive plugin library that makes it possible to build not only a front-end layer (by getting to just the raw data -see my other post about this -for anyone who wants to do the same thing but with traditional fixed property classes) but also in a TeamSite-ish way, this is where I’ll be concentrating my efforts (when I have them) for the time being.

Since the portfolio would be a 2nd ‘mini’ app I would be building (in Flex of course), it gave me an idea to build an overall Portal application that can load and interact with Portlet modules -this of course being an excellent example of some of more indepth things you can do with Flex (especially if one builds cross gateway functionality -ie Mash-Up to either add/modify or implement interactive services from one portlet to another). One of the neat things that makes it possible in building modular applications, is if one was adventurous enough, could event build a second UI layer to manage the administration of the back-end functionality. Initial Portlets that will eventually be built:

• The Portfolio (and Archive) with it’s Joomla back-end.
• The FlexPress with a WordPress bank-end will be resurrected -most if not all of the UI will be re-incorporated but obviously the entire data services layer will probably have to be updated in a meaningful way.
• A Gallery: this won’t be open to the public since it’s the media management center for our family -but I’ll screenshot it as a app in the portfolio.

I don’t make any promises of it’s current status since it’s very much still an development release (read: expect an occasional crash, plain ‘halo’ styles, and some parts just aren’t implemented yet) -but if you’re curious to see how this is turning out, you can check it here.