This is just to good to miss on a bloc called “I don’t like computers.”:
I’m currently sneaking around the dependency injection (DI) frameworks Dawn, Swiz and Parsley. None of which I have ever used in production, so take my judgment with care. At first look, the use of Dawn is simplest and most concise and somewhat similar to Google’s Guice which I like. In Swiz, I don’t like the global state used in event handling. Parsley is well documented but a framework that is configurable by XML makes me very suspicious.
DI depends on reflection on classes which is mainly done with describeType() in Flash. I had in mind that it was a very slow function, but I didn’t know for sure. So I wrote some code to estimate the runtime performance of DI frameworks:
Find metatdata tag [Inject] in different classes: 5050 μs for UIComponent 5150 μs for PersonDetails 700 μs for PersonDetails with DescribeTypeCache 30 μs for SimplestClass 360 μs for describeType XML of UIComponent 2 us to dispatch and handle an event 0.2 μs to call getQualifiedClassName(UIComponent) 1.6 μs to call getDefinitionByName(UIComponent) 0.3 μs to call uiComponent['drawFocus'] 0.2 μs to call uiComponent.hasOwnProperty('maxHeight') 0.7 μs to call uiComponent['maxHeight'] 9 μs to call Log.getLogger('mx.core.UIComponent') 12 μs to call CreateLogger.withClassNameOf(VBox) μs = microseconds
describeType() is really slow. It takes more than 5ms on UIComponent. What surprised me positively is the speed of getQualifiedClassName(). I flipped all logger creation to using getQualifiedClassName() with the helper class CreateLogger.as since.
Dependency injection frameworks make only sense in big projects. Let’s assume a project with 200 different classes that have injected objects, the start up time will increase by 1 second. Knowing that Flex applications don’t fire up quickly, 1 second is surely too long. For BlocStac, I will use DI only in side projects and hope that Flash Player offers faster reflection functions soon.
This is just an other story why I don’t like computers… When the Flash Player loads files from Amazon S3, it most likely crosses the domain border. This means that you have to put up yourself with Flash Player security. If you planned a new security concept for Flash Player and you want to make it as complex and convoluted as you could ever imagine and then, you power this by the factor of 10, you most likely come up with the current Flash Player security concept. Ok, if it hadn’t changed much over the years. But did you know that for example the allowed HTTP header changed in every release! I bet that there are no more than 10 people on the world that understand everything including the implications of the changes over the years.
Whatever, loading the crossdomain.xml from Amazon S3 does not fail because of Flash Player. That’s why loading the file works fine in Firefox but fails in Internet Explorer and Safari. The URL was something like “https://images.example.org.s3.amazonaws.com/crossdomain.xml“. It turns out that Internet Explorer does not accept address with “.” for wildcard SSL certifactes like “*.s3.amazonaws.com”. So this story ends with the fact that you should only use bucket names without “.” like “https://myimages.s3.amazonaws.com/crossdomain.xml“.