All Things Flex, Flash, and ActionScript

This one has been bugging me, and a few other people who were trying to figure out ultimately what version of SQLite is embedded in AIR. Running a SQLStatement of: ‘SELECT sqlite_source_id()’ gives us this result: onSQLresult result key sqlite_source_id() value 2010-12-07 20:14:09 a586a4deeb25330037a49df295b36aaf624d0f45.

As per SQLite.org this method returns the code characteristic for which your embedded version has been built against. Using the canonical timeline viewer, going back a few pages now of (200 entries) we find this one:

http://www.sqlite.org/cgi/src/timeline?n=200&a=2010-12-07+07%3A57%3A50
And low-and-behold down near the bottom: 2010-12-07 20:14 [a586a4deeb] Version 3.7.4 (user: drh, tags: trunk, release, version-3.7.4)

So it turns out, that the modified version of AIR 3.1 SQLite is based on 3.7.4 – and the real question of foreign key support is at least there – I was able to test against it using a simple CREATE TABLE, but according to the documentation- this is parsed but not enforced. Lets hope that is now wrong too – since even Adobe Employee’s couldn’t come up with this one.

Not sure how well some of us actually read this, but there is 1 section in particular that I find to be fairly interesting, and another is well, lets just say hopefully they learned since AS3 quite frankly is used in mission critical software.

Type inference: Type declarations will only be necessary in certain strategic places. Everywhere else the compiler will automatically infer suitable type declarations and treat the whole program as statically typed, even though the programmer does not have to state any types. Thus the convenience of untyped programming can be approximated quite well, while providing the performance advantages of typed programming.

So two comments on this one, one trivial the other not so much:

1. Trivial – A lot of code-hinting programs will probably need some rework on giving the correct intelli-sense, since usually with RegEx it would be fairly straight forward (look for the next whole word after the colon where it’s declared). If I understand this correctly, basically what Adobe is hinting at is that the type declaration is only needed at the original source of the declaration? For code editors, this now means going back up the symbolic link chain to find where the parameter / class variable was originally created – this is really no small feat, and I would imagine would cause some parsing concerns.
2. Opinion – Since when amongst any serious fundamental programmer is untyped “convenient”? Every major development platform that I know of, ALL uses strongly typed. Java, the entire C family, heck even databases do this with affinity. Seriously, it’s not convenient except anywhere more than one class is used. Typed languages have equal weight in performance (no prototypical look up), but also on the human – after all we are the ones who write this stuff, and well documented, well written code is hinged upon knowing exactly what type / interface you are dealing with at the moment.

 

Compatibility: The next version of ActionScript will be an evolution of ActionScript 3, but in some instances may not be completely compatible with ActionScript 3. We expect that any migration from ActionScript 3 will be significantly less burdensome than the move from ActionScript 2 to ActionScript 3. Regardless, we are exploring options for tooling that would either ease or automate this transition.

Adobe, please for the love of code, please don’t make us go through that again.

And lastly, a note on the Flex roadmap which obviously is of keen interest to me.

RSLs for Apache-released versions of Flex:
Now that Flex is a community-driven project, it is no longer appropriate nor practical for Adobe to sign the resulting Apache Flex RSLs. This means that when using an Apache Flex release, framework RSLs will not be cached globally by Flash Player, but rather per domain in the web browser.

Per domain in the browser?! Are you freaking serious? What’s the point of relying on a framework that is essentially stable and publicly available, only to have every single domain and sub-domain have to deal with loading their own copy? Wow I hope Apache is able to sign this sort of thing, and has the capacity on its servers to handle the request load.

Lastly, Flash nor Flex is dead as many in our industry fret – HTML5 is just another shiny ball that so many chase after looking for the proverbial development “fountain of youth.” Like outsourcing, it won’t be all that it’s cracked up to be and live up to it’s over-hyped promises, but instead will have it’s place in the world under certain circumstances.

In some instances when JSON is the only available communication protocol, we all know full well about it’s limitations especially when it comes to preserving type or saving state. But what if you were in a closed-loop system where you could simply save what the front-end end would send? In a Flex environment this is still somewhat trivial since you can still use the [RemoteClass] metatag even without an RPC-based mediary like LCDS.

In Flex 4.5 using the Adobe extension to JSON the following will work. In 4.6+ it gets a little harder since the JSON class is now a top-level object – which makes overriding private / modifying protected and/or static methods nearly impossible.

Modifying the encoder entails when encountering complex types that are not just anonymous Objects, if that’s the case then we can prefix the fully qualified class name before the bracket, and do the reverse in the decoder.

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.