Spring Actionscript 0.8: My Review

Let's face it. AS3 needed an IoC container. Spring Actionscript delivered it. In an older post, I compared Spring Actionscript and Parsley as IoC containers and the main thing missing from Spring Actionscript (that Parsley had) was documentation. Now, with the release of Spring Actionscript 0.8, that issue is solved.

The documentation available at Spring Actionscript's site (link above) is awesome. It is in keeping with the main Spring IoC container's documentation, as well as other large libraries such as Hibernate's documentation. The documentation is pretty extensive and the feature list is growing by the day. It's becoming easier and easier to throw together a project with Spring Actionscript.

One of the new features that I had originally requested for a while back is autowiring. If you're not familiar with autowiring, it is something that will ultimately save you a lot of lines of configuration code and a lot of time. Autowiring is the process by which an IoC container finds and injects dependencies automatically, either by type or by name. Rather than writing something like this:

<object name="myObject" class="com.something.else.SuperDependency">
   <property name="megaDependency">
      <object class="com.something.else.MegaDependency"/>
   </property>
</object>

You can write something like this:

<object class="com.something.else.SuperDependency" autowire="byType"/>
<object class="com.something.else.MegaDependency"/>

In this case, "MegaDependency" is automagically injected into "SuperDependency" because of a few things: 1) The object tag describing "SuperDependency" has the autowire attribute set to "byType", 2) "SuperDependency" declares a property "megaDependency" of type "MegaDependency". Basically, what is happening behind the scenes is that Spring Actionscript is using introspection and runtime reflection (provided by the AS3 Commons Reflection library) to analyze the fields (getters/setters/instance level variables) of a type, and then is looking for other objects managed by the IoC (Inversion of Control) container which match that type. If it finds an object eligible for injection, it automagically injects that object into the autowired one, saving you 2-3 lines of code per object.

Granted, the process above describes autowiring by type. There is another method of autowiring known as autowiring by name, but that seems pretty self-explanatory, right? Find an object in the IoC container whose name matches the name of the referenced property. Eg: if "SuperDependency" has a property called "megaDependency," the IoC container will look for an object within itself called "megaDependency."

Another game-changing feature of Spring Actionscript 0.8 is Stage autowiring. When used in Flex, Spring Actionscript can now autowire stage objects. By listening for the Event.ADDED event on the Stage, Spring can tell when display objects are added to the stage. When this happens, certain properties can be autowired.

Check out this example:

...
[Autowired(mode = "byType")]
public var myDependency:MyDependency;

[Autowired(mode = "byType")]
public function get myOtherDependency():AnotherDependency { ... }
public function set myOtherDependency(value:AnotherDependency):void { ... }

Assuming this is a class that extends flash.display.DisplayObject, when this instance is added to the display list, Spring Actionscript is notified by the Event.ADDED event, and it attempts to autowire this instance. By looking at the metadata, Spring Actionscript will autowire any necessary properties declared by your class, saving you a lot of work.

Basically, this version of Spring Actionscript is amazing. I love it. By working with it, I have saved tons of time, both in development and in preventing epic madness in the future.

The Spring Actionscript team has also been extremely helpful in fixing a few bugs related to the release. The first major one of these was Module autowiring on the stage. The problem with using Modules in Flex with Spring Actionscript is that Spring is counting on all class definitions being in the main ApplicationDomain. When loading a Module, by default a new ApplicationDomain is created for memory purposes, and the Module's classes are loaded into it rather than the main ApplicationDomain.

Unfortunately this poses a problem as Spring is unable to find class definitions for all Module classes. However, the Spring Actionscript team has been very helpful in addressing the bug and trying to provide a fix. At this point, in the trunk, the issue has been patched but not fixed by preventing Modules from being autowired. Hopefully in the future, a fix will come so that we'll be able to use stage autowiring anywhere, no matter which ApplicationDomain the classes are loaded into.

Another issue that has been fixed since the 0.8 release is complex property resolution. Spring Actionscript uses the Java property format (my.complex.property = something), and that format usually allows for complex property resolution (my.complex.property = ${my.other.property}/tk), but this wasn't working with the 0.8 release. Fortunately, I have been told that this functionality is working great in the trunk, but I have yet to try it out.

Again, mad props to the Spring Actionscript team! Thank you so much for an awesome IoC container for AS3! Looking forward to the next release!

Technorati Tags: as3, ioc, dependency injection, flash, flex, spring

[AS3] Flex Unit 4

I just wired up the latest version of Flex Unit 4 and it is impressive to say the least. For the last week or so, I've been messing around with the version that ships with Flash Builder 4, but I wanted to get up with the latest because of all of the awesome goodies it comes with.

The thing I am really excited about is the new metadata-driven model. It's almost as convenient to use as JUnit (but it still has a few things to improve upon). Finally, we're able to have annotated test cases and test suites and thus are not forced to extend a class or implement an interface. All test-related configuration is done at runtime by the framework and via introspection. A great article that got me started can be found here on InsideRIA.

The framework seems incredibly intelligent. You can even specify if you expect a method to throw an error with a simple metadata parameter. If the test method does not throw that error, it is considered a failed test. I haven't found anything about the actual framework that I don't like. It is a huge improvement over previous versions of Flex Unit and a good step toward standardizing unit testing across platforms.

One cool thing that I found inside of Flash Builder 4 is how easy it makes it to run Flex Unit tests. By right clicking on an Actionscript/MXML file, you can choose to "Execute FlexUnit Tests...", which I really like. The downside to this is that Flash Builder 4 currently prefers an older version of Flex Unit, and encourages you to manually extend a class and follow test naming conventions etc. The upside to running Flex Unit tests inside of Flash Builder 4 is that it will actually show your test results within Eclipse.

This alone is a feature that's been missing for an extremely long time. Being able to run unit tests within your IDE is a huge productivity boost. Having to manually launch a SWF that displays its test results within itself is at least a few extra steps that bog down one's workflow. Unfortunately, since I'm using Flex Unit 4 rather than the Flex Unit that ships with Flash Builder 4, I have to launch my tests and compile them separately, but at least we're now moving in the right direction. Once you understand the flow of working with a LocalConnection, passing data from Flash to, let's say, Java, really isn't that hard. All you need is to master the AMF encoding, and the LocalConnection protocol, both of which have been done. Then, you connect both ends together, pass some nice data objects about test results back and forth, and when the tests are done, call flash.system.System.exit(0) to kill the Flash Player instance.

All of this could be done relatively easy through the use of an Ant task, making the tests completely automated. I prefer building my applications with Ant, since I can use Ant on any platform and at any time and get the same results. Making a project portable is what separates it from the pack. It's easy to throw together a sloppy project that will only compile in a very specific configuration and setup, but with the right planning, you can have a nice project which builds in Ant, anywhere.

Anyway, I digress. Flex Unit 4 is definitely worth checking out. Go out there and start messing with it!Technorati Tags: as3, flex, flash, unit testing, testing, ant

[Linux] Flash Builder 4: Will Adobe Help Us?

The question that has been plaguing me for some time now is this: Will Adobe release Flash Builder 4 for Linux? I don't think I'm alone on this one. Most every linux-using Flash/Flex developer needs a development environment to use. And up to this point, there really isn't anything out there.

Sure, there's Flex Builder 3 for Linux, but it has extremely limited capabilities, and you have to hack it just to get it to work with Eclipse 3.4+. Did I mention that it won't install in a 64bit JVM? Yes, I was able to get it working, but it's a huge pain for something that shouldn't be. It's been a beta for nearly a year now, and with no real hope in sight. Since Adobe just released Windows and Mac beta editions of the new Flash Builder 4, what does it mean for us? Is there a plan out there for Adobe to save the day?

Yes, there is FDT. Enough said. But the full-flavored version of FDT is like $600+! I don't know about you guys, but I don't have that kind of money laying around. However, FDT IS DOING SOMETHING AWESOME and giving their best product away for FREE for open source project teams. I guess I just need to jump on it and get my secret projects (insert evil laugh) into the mainstream. Even so, MXML support is limited, and as far as I know, you can't visually create Flex applications like you can in Flash/Flex Builder.

So my statement is this: Help us help you Adobe. There ARE people out here that are waiting desperately for a Linux Flash/Flex IDE to come out. We DO have money and we're willing to spend it. Just please try and meet us halfway :)

If there were any other way, we'd do it. But there isn't. Wine is a long ways off from being able to virtualize a Windows JVM, so our only real option is to run it natively on Windows or Mac. Hear our cries, Adobe, we'd love to give you money for your product!

AS3 IOC Containers: Spring Actionscript (Prana) vs Parsley

Today, I decided to bring some good ol' IOC and dependency injection into my AS3 workflow. I took two of the most popular IOC containers for test drives and compared the features of both, and in this post, I'm going to log my findings.

1. SpiceFactory's Parsley (current version 1.0.2)
Download | Documentation

Learning to use Parsley was really easy. The documentation was very concise and yet complete, it didn't just shove a bunch of examples and ASDocs in your face, it explained in-depth how the various aspects of Parsley work and how they can be extended. It has really interesting features, kind of a little break from just regular IOC and dependency injection.

Some of the things I really liked about Parsley were:

• The documentation. It rocked. It was so complete and so in-depth that it made it a breeze to get started with Parsley. It showed a lot of examples of how to use Parsley to its fullest, and explained the various API's well.
• Localization of messages. Parsley makes it really easy to provide localization to your applications. Localization is one of the things that has always been a pain for developers to implement, but Parsley covers this facet extremely well. Localization can be manually set or automatically interpreted by Parsley. You create message bundles for the various strings required by your application (such as a tooltip for a button: "Opens a file for editing.") and you create multiple message bundles (which can go in separate XML files) for each locale you're targeting. It's super easy and though I haven't tried it out just yet, one can see how it makes localization a non-issue for application development. The more you take advantage of IOC in Parsley, the more you can incorporate localization. Awesome feature.
• Event listener tags in XML contexts. You can easily register event listeners in the context with the "listener" tag. This makes life a heck of a lot easier for me at least. I despise typing out "addEventListener" four to ten times for a complicated object with lots of dependencies.
• Easy to extend. Fo' sho'.
  

Some of things I wasn't so fond of in Parsley:

• Non Spring-like XML definitions. Parsley breaks away from the Spring XML definitions that I like, and am used to. I'm OCD, so this is basically life-and-death for me ;) Plus the Parsley definition structure is a bit more verbose, so you'll end up typing more code in your definition files.
  
• Inability to simply invoke methods. For the logging framework I've developed and use, I need to call functions like "registerOutput" on my objects, and Parsley simply can't do that yet. Spring Actionscript (Prana) handles this with the "method-invocation" tag, which I like... a lot.
• More verbose setup in parsing contexts. You need to instantiate a parser and have that load a context into another object. This extra step is kind of useless, at least to me it is.
  

All in all, Parsley was ok but I found that I prefer Spring Actionscript (Prana) in the day-to-day stuff. Although Parsley has some really cool API's that I haven't seen yet, I like a more Spring-like IOC container.

2. Spring's "Spring Actionscript", formerly Prana (current version 0.6)
Download | Documentation

Spring Actionscript (Prana) was a bit more difficult to learn because of lack of documentation, but proved to be far more powerful than Parsley, though it lacks some of the cool features that Parsley has. As far as I know, it lacks the cool localization that Parsley offers standard, and it definitely lacks the "listener" tag that Parsley boasts, though you can achieve the same general result with the Spring Actionscript "method-invocation" node. Plus, since Spring has taken charge of the project, it's just like Spring! This, for me, is huge. I love Spring. Spring is amazing and easy to use, and their Actionscript IOC container is such as well.

What I loved about Spring Actionscript:

• It's just like Spring. \m/
• The "method-invocation" node. This really helps make the framework a heck of a lot more flexible.
  
• XML declaration files are less verbose and AS3 instantiation is a less wordy. And it runs just as you'd expect an IOC container to run. If you've used Spring, the migration to Spring Actionscript is a no brainer.
  
• It's a huge framework. I guess this is both good and bad, but I like having a lot versus a little, but maybe that's just me. It has plugins to Cairngorm and PureMVC, which I'm sure a lot of people are grateful for.
  

What I kind of didn't like about Spring Actionscript:

• It doesn't have the "listener" tag that Parsley has. It's more of a convenience thing than a lack of a feature, but it's still really nice to have.
  
• It doesn't have the localization features of Parsley. The message bundle API of Parsley is genius, really powerful and super easy to use.
• Lack of documentation. Insert sad face here. It was a bit of a challenge to get up and going with it, but in the end it was worth it.
• Lack of "init-method" and "destroy-method" and "factory-method" subtags of an "object." It supports the "init-method" and "factory-method" parameters on the "object" tag, but it's nice to just nest those underneath the "object" tag rather than as a parameter to the base "object" tag. The "destroy-method" is completely left out, though I'm not sure how that would apply in AS3, if at all. I'm really missing the "static-factory-method" tag that Parsley supports though. So maybe this aspect of Parsley is more like Spring than, dare I say, Spring Actionscript?
• Not so easy to extend. There's little documentation beyond the ASDocs, so I wouldn't know if I could implement a preprocessor like in Parsley or anything advanced like that.
  

Other than that, my choice is pretty much clear: Spring Actionscript takes the TK Cup! Woot! I'm going to start using it in a real-world application and I'll post again on my findings with working with Spring Actionscript in a real world scenario. Even though I kind of prefer Spring Actionscript, it is definitely missing some of the really awesome Parsley stuff. I, for one, am a huge fan of the localization features of Parsley. So, don't automatically reject using Parsley because of this post. Parsley is an awesome framework for IOC, and SpiceFactory has done a lot of good work on it. It's definitely worth your time to check into both projects and choose which is best for each situation you run into. I can definitely see some areas where I'd prefer using Parsley over Spring Actionscript

Until then, here's my two test projects. They contain basically translations of the same general project, translated to Spring Actionscript and Parsley. The required libraries are included in each projects corresponding lib folder, though I used Arthropod for debugging and I didn't include that. They're Flex projects by the way. These are to help you make your informed choice on what to go on, rather than just depending on my glorious madness to make your decisions upon:
uploads/as3ioctesting.zip

Good luck in the wonderful world of IOC!

EDIT**
Here's a bit of a disclaimer about Parsley. Parsley does have a sort of "method-invocation" tag, though it wasn't clear to me at first. According to Jens Halm, the project lead, you can have multiple init-method tags to invoke methods when the object is instantiated. So basically, you can achieve the same result without the method invocation tag. So now my choice is more unclear. I like Parsley AND Spring Actionscript. I don't know what I'm going to do, but you can still make a choice at least :)

Pros and Cons of a Singlethreaded AVM

I've been doing a lot of thinking lately about the Actionscript Virtual Machine (AVM). I know not too many developers concern themselves with diving deep into what makes Flash Player work, but I think it's important to understand the platform on which we stand and rely.

In a lot of ways, AVM is like JVM (Java Virtual Machine), and in a lot of ways, AVM is nothing like JVM. Perhaps the biggest difference is in threads. JVM is entirely multithreaded. As a Java developer, you could basically create an infinite loop creating an infinite number of threads of execution just as fast as your computer could handle it. You can also build applications that do everything synchronously, from opening server sockets and waiting for connections, opening/reading/writing to and from files, to just about anything imaginable. You can also do things asynchronously in Java, so you have the best of both worlds. AVM is explicitly single-threaded. Though AVM may run multiple threads in the background to give you the result you see, you as a developer have one and only thread to work with in development.

This is good and bad. The pros of a singlethreaded VM are as follows:

• Developers don't have to worry about threads, synchronization, and infinite loops. As soon as you introduce threads into a language, you as a developer have a lot more to worry about. For example, if you have two threads working on the same object at the same time, you could easily throw some variables off with one thread while the other is expecting a different result.
  
  IE: Thread 1 is looking at an Object (which is typed as Object) and is casting it as a Number to perform some addition function on it. Thread 2, which is executing at the same time, grabs the Object and performs a subtraction function on it. Thread 1 applies the addition function it was planning on doing, and a crazy result is received. You as a developer are weeping in your chair wondering what the heck just happened.
  
  
• Since there's only one thread, all operations taking a long (or indefinite) time are forced to be asynchronous. Meet the AVM Event flow system. Honestly, for a single-threaded VM, AVM really is powerful with its event system. Following the Observer design pattern, the event system makes it extremely easy for any developer to trigger asynchronous events at any time.
  

The significant cons of a single-threaded are as follows:

• There is little spreading of damage as far as performance is concerned. If the main thread is running slowly, the whole program is running slowly. In a single-threaded VM you can't just create a thread to handle some intensive process while the main thread does nothing.
  
  
• There is little spreading of damage as far as errors are concerned. The single-threaded AVM handles errors similarly yet different as compared to the JVM. Because of the one and only one thread that is running, developers must be careful to NEVER EVER LET AN ERROR BUBBLE TO THE TOP. If an error makes it all the way to the top to be displayed as a message in the debug player, it is an extremely bad thing for the application. I've had many bad things happen when errors are thrown. You could have an event listener for the ENTER_FRAME event break if an error happens at just the right time in just the right place. Even worse, if the error is in the ENTER_FRAME handler, performance will go down the drain. By multithreading a VM, you're typically going to have to use a lot more try..catch...finally blocks, which is good practice. Oh, and did I mention that if an error happens at runtime, it breaks whatever is next in its execution path? If you have code similar to this:
  

  this.doSomething();
  this.doSomethingElse();

  
  ...and an error is thrown in the doSomething() method, the doSomethingElse() method may never get called, throwing off your entire application.
  
  
• You can't do things synchronously. Honestly, some times it's just easier to call File.open() then File.write() rather than construct a file object, add an event listener, try File.open(), then when it's finally loaded, do what you want with it.
  
  
• A single-threaded VM doesn't have multiple threads :)
  

Although AVM2 is great and performs well for a single-threaded VM, it is quite clear that much better performance can be achieved through a mulit-threaded VM. However, it's definitely apparent there are a few problems for developers in switching over to a multithreaded VM. Hopefully we'll be able to see a multithreaded AVM (AVM3?) for harnessing even more power from the Flash Platform soon... maybe even in the next release of Actionscript.

Making sense of Ternary

I don't know about you, but for the longest time I was confused as heck about the ternary operator. In the AS3 language reference, this is all you get about the ternary operator:

Evaluates expression1, and if the value of expression1 is true, the result is the value of expression2; otherwise the result is the value of expression3.

Not much, right? I would see lines of code like this and my brain would bust: " variable == null ? doSomething() : doSomethingElse();" For sanity's sake (both yours and mine), I'm going to flat out explain the ternary operator/operand/thing.

In TK terms, the ternary operator does this: "If the value before the question mark evaluates as being true, the first expression is called, otherwise the second one is called." FTW? Ok, I'll make it even easier with example code and comments:

//If someVariable is null, execute functionOne, otherwise execute functionTwo
someVariable == null ? functionOne() : functionTwo();

//The preceding line is basically the same as doing this:
if (someVariable == null) {
functionOne();
} else {
functionTwo();
}

So does that make sense? The ternary operator thing saves you 2-3 lines of code and can be used nearly anywhere. Here's some code in action:

this.getState() == States.OPEN ? this.dispatchEvent(new SomeEvent(SomeEvent.CLOSE)) : this.dispatchEvent(new SomeEvent(SomeEvent.OPEN));

Get it? Got it? Good! Now go out there and get some!

What I'm looking for in AS4

Not that you asked, or that you care, but I think somebody needs to post a wish list for AS4 as far as the language construct is concerned. AS3, being a huge step away from scripting and into the world of development, was kind of like man's first steps on the moon. We did it, now what? It's time to colonize, conquer, dominate, install weapons systems... now that the moon is ours :)

Anyways, what I'm saying is that AS3 was a deep jump into uncharted territory for most of us in the Flash community and many of us ran dizzily in circles at the release of something so foreign to the Flash Platform (and many of us still are). Now that enough of us have made the jump from scripting to developing, I believe Adobe needs to "solid up" Flash Player with more Java-like constructs. I mean, AS3 is supposed to be an object-oriented language, yet we don't have abstract methods, abstract classes, and a few general OOP must-haves. Yes, we can create semi-abstract classes by naming conventions and by throwing errors by hand, but come on! Nobody likes to develop abstract classes in AS3, though they're pretty much a necessity in true OOP.

I digress, there's just so much on my mind. I'll now get started on what this post is really about, AS4 and what we need from it.

1. Language Addition - Generics:
   Generics, or parameterized types, are one of the coolest things to ever happen. Even Flash Player 10 is going to support some form of generics through the Vector type. Adobe has noted that when using the Vector over an Array, there is a 40%+ performance increase. Though we now, or soon, have this kewl 'generic-ish' type, we're only seeing the tip of the iceberg. We need a "java.collections.*" equivalent for Flash Player. The Java Collection implementations are some of the coolest thing in all languages, allowing for extremely efficient and simple manipulation of groups of values. It also forces even greater strict-typing, rather than the Array and Object classes. While I totally understand the need to have intrisnic classes like Object and Array, we greatly sacrifice type-saftey with them. A collections API would eliminate the lack of type-safety within Flash Player for the most part. If we don't see this in AS4, we have every reason to be upset. I also feel the need to mention this: though FP10 has Vector&ltObject>, there are no means by which to develop your own parameterized types as in Java. Now, I don't know of too many developers that create their own parameterized types just for kicks, and I myself have never had the need to create my own generic class, but we need this ability. Who knows, somebody in the community could come up with something extremely useful in a generics class, maybe for a 3D engine or a framework.
   
   
2. Language Addition - Abstract Classes/Methods
   WE NEED ABSTRACT CLASSES! As an OOP/Design Pattern enthusiast, I am really feeling the need for abstract types. I can't vouch for performance or any other benefits to abstract classes, but in design patterns, abstract classes are key. As it stands in AS3, the creation of abstract types is pretty limited. There are workarounds to doing it, of course, but still. We greatly need abstract types. Even if it won't affect you on a day to day basis as a developer, this is core to an OOP language.
   
   
3. Language Addition - Memory Management
   Now I'm no C/C++ guy (yet) but AS3 and FP9 definitely have some problems with memory management that make it excruciatingly difficult to manage memory, make sure objects are REALLY deleted, etc. I know that AS3, like Java, run off of a VM and have a garbage collector, and by definition, the VM should take care of itself. However, that doesn't mean memory optimization has to be painful if not a downright nightmare as it is currently! I don't know how it would work or what exactly to suggest that Adobe should do, but we need some tools to track event listeners and object references, as well as add a finalize() method to the Object class and its descendants as per Java. The event system in FP should be optimized to be weaker as well. *Note: Yes, I know about the useWeakReference field in addEventListener. I nearly always set it to true, and yet I have noticed that some objects simply won't let go and be destroyed.
   
   
4. Language Addition - Annotations
   Yeah, FP does have compiler meta-tags, but we as developers should be able to develop our own. I mean, Flex is a framework right? A framework should basically just run off of a platform and have no special requirements, yet Flex requires a special unique compiler and defines its own meta tags such as [Bindable]. If Flex can bind data that easily, why can't we do it in strict AS3 without the Flex compiler?
   
   
5. Player Standard - Ubiquity
   With the advent of FP10, we now have a bunch of GPU effects, Pixel Bender, 3D drawTriangles functionality, etc. However, these features are only supported on certain processors with certain graphics cards. Isn't the purpose of Flash to provide a platform-independent runtime? This sounds an awful lot like Adobe is pushing Flash away from being the same on every OS and configuration to being a specialty runtime for certain CPUs and GPUs. This doesn't make any sense, why enable a feature that's not consistent on every computer? How do we use Pixel Bender? How do we know our target audience will have X processor and Y video card? Does anyone else see the problem in this?
   
   
6. API Rework - Text API
   The flash.text package serves as a great starting point, but definitely leaves one wanting for more. The HTML reading capabilities of Flash Player have always been pretty weak. I think that Flash Player should have default support for reading all standard HTML tags the way that a browser would read them. What I'm hinting at is cross HTML/FP tag reading. If <img> does one thing in a browser, it should do the same thing in Flash. In FP9, <img> inserts a new Loader object with the url ready to load, but it inserts it on a new line. In a browser, this isn't so, it only puts it on a new line if necessary. I've built a few chat applications where I had to use smilies and this makes it a nightmare. Whenever a user inserts a smiley, it automatically puts it on a new line. Text-wrapping around images has also been problematic.

Well, these are just a few things I'd love to see in AS4. Oh, by the way, does anyone know the status on AS4? I know that Tamarin was abandoned by Mozilla, but do we know what Adobe's up to? FP10 is being released soon and we're all stoked about it, but there is definitely a future for Flash beyond 10, and we should start pushing for features now rather than later!