Here’s a simple example of these collisions in action

View the source

Full details of what is new in this version are on the Flint website.

For this Spring Actionscript example I’ve used exactly the same project as in the previous examples for other frameworks. Like many of the newer frameworks, Spring Actionscript is not prescriptive about your application’s architecture so I’ve used a similar MVC architecture to the one in my Swiz example.

The example is below. Links to the other versions follow. All versions have identical functionality. Right click on the swf to view the source.

The other versions can be viewed here…

• Flexcaster no framework project source
• Flexcaster Cairngorm project source
• Flexcaster PureMVC project source
• Flexcaster Mate project source
• Flexcaster Swiz project source
• Flexcaster Parsley project source
• Flexcaster Robotlegs project source
• Flexcaster SmartyPants-ioc and As3-signals project source

1. It will start as something simple, with a strong foundation and the potential to grow.
2. It will have some very strong developers at its core.
3. It will have at least one project member with an ability to market effectively to the developer community.
4. It will be open source.
5. Its roadmap will develop through open discussion with the community.
6. It will have a very active developer community around it.
7. It’s probably a project that has already begun.

I can think of three excellent projects that meet most or all of these criteria. Whether any of them will one day replace the flex framework depends on many things, including in two cases whether the developers would even want to do such a thing. Here are the projects.

Reflex

The most obvious candidate is Reflex. It actually styles itself as a Flex replacement. It’s also not a first generation project, having evolved from Ben Stucki‘s experiences developing OpenFlux and Jacob & Tyler Wright’s experiences developing the Flight Framework. Reflex is designed as a straight improvement on the way Flex is designed. A key element in this is the use of containment rather than inheritance when creating the component architecture.

The result is aiming to be a simplified, lightweight, extendible component architecture with core features from Flex like MXML and CSS all in a tiny (~50kB) package.

The project is in its early stages but appears to be progressing well. The three core developers are all experienced and talented. Ben knows how to make a noise in the development community so they have that angle covered too.

Robotlegs

Like the original Spring for Java, Robotlegs (which is built on top of SwiftSuspenders) is a lightweight architecture built around a dependency injection container. Currently it complements the Flex framework, but if, like Spring, Robotlegs grew to cover more aspects of development it could perhaps be the foundation for a new approach to simplifying the development process. Put simply, maybe dependency injection could be the foundation for a component architecture.

Robotlegs was founded by Shaun Smith and it has skilled developers, an active and open community and, in Joel Hooks, at least one developer who has an aptitude for promoting the project to the wider world. Moving beyond an elegant micro-architecture into the world of Flex replacement therapy would be a big leap but I suspect the Robotlegs team would be up for it if they want the challenge.

Swiz

Swiz started life as a personal project for Chris Scott, but has evolved into a community project with a number of strong developers. It’s also changed at its core from a dependency injection based lightweight architecture to a metadata processing architecture, with a dependency injection container and event bus architecture built atop it. This puts Swiz in a position to build an architecture around metadata as well as Actionscript/MXML/CSS. Adding additional metadata processors to the Swiz toolset might open up new architectures to replace the traditional Flex model.

Swiz has had issues with documentation (it’s limited and updated intermittently) but the team are getting better at telling the community what’s going on and what their roadmap is, and they are quick to respond to questions which mitigates many of the documentation issues.

Only three?

There are other projects I could have mentioned but from those I know these three most closely match my criteria above. I also like and am excited by all three of these projects.

What would be your candidate for a project with a bright future and the potential to grow into a Flex replacement?

I’ve dipped my toe back in the Java world recently, and I’m reminded of some interesting Java history that may be echoed in Flash’s future.

Back in the distant mist of Java’s past, most large Java web projects were built using something called Enterprise JavaBeans. EJB was a complex framework developed by Sun, the developers of Java itself (with some input from IBM). EJB had a number of good things going for it, in particular

• It had respected advocates in Sun and IBM
• It addressed some real and difficult problems

but some developers also thought that the architecture and APIs were too complex.

Then a smart guy called Rod Johnson wrote a book about an idea, and he created a small framework called Spring to illustrate that idea, and the Java world started to change. Now, EJB is no longer the de-facto standard in the Java world. A smaller, lighter, more agile, more flexible framework called Spring has taken over. There are some who still use EJB (and EJB has become smaller and lighter in response to Spring’s success) but Spring is the framework in demand.

What has all this to do with Flash?

Replace Java with Flash, replace Sun with Adobe, and replace EJB with Flex and you might see a parallel in which Flash is ripe for a smaller, lighter, more agile, more flexible framework than Flex.

That shouldn’t be seen as a suggestion that Flex is rubbish – far from it. I use Flex every day and am often amazed at how good it is. Yet just as often I’m annoyed by its faults. Because Flex isn’t perfect, and its imperfections run very deep. All the new stuff in Flex 4 is great (most of it at least), but it keeps getting bigger, more unwieldy, more complicated.

So I suggest that, as with Java and EJB a few years ago, Flash is ready for a newer, lighter framework to evolve to replace Flex. I don’t know what that framework is but I suspect it will have most of the following attributes

1. It will start as something simple, with a strong foundation and the potential to grow.
2. It will have some very strong developers at its core.
3. It will have at least one project member with an ability to market effectively to the developer community.
4. It will be open source.
5. Its roadmap will develop through open discussion with the community.
6. It will have a very active developer community around it.
7. It’s probably a project that has already begun.

It may be one project, or it may be a merger of many. Maybe it’s that little project you’ve been working on in your spare time. Whatever it is, I suspect a couple of years from now we’ll have a serious alternative to rival the Flex framework.

There is also a follow-up post looking at some projects that might evolve to replace Flex.

Download the example code

The example code is a set of smart components implementing this architecture and designed for building a Twitter client. Also included is an example of their use. This code was used during the presentation.

Links:

• SmartyPants-IOC
• As3-Signals
• AS3 OAuth Twitter Library

Links:

• Cairngorm (code example)
• PureMVC (code example)
• Mate (code example)
• Swiz (code example)
• Parsley (code example)
• Robotlegs (code example)

360|Flex has interested me for some time. It’s the most technical, developer oriented of the many Flash and Flex conferences around, and as a developer myself that obviously interests me. The level of technical knowledge amongst the speakers is immense. (That I’ve been invited to join them makes me feel very special).

But 360|Flex is about more than just technical presentations. John and Tom try very hard to make this a conference where all attendees feel part of a community. My first experience of this was in my invitation to speak, where they made it absolutely clear that they didn’t want me if I wasn’t going to hang around at the conference attending other sessions and chatting to the attendees – all the attendees, even the one’s I don’t know (yet). I like that. I don’t speak at conferences because I like the sound of my own voice, I speak at conferences because I like to exchange ideas with other developers, and that means both talking and listening. It means developing those ideas through discussion (and yes, sometimes those discussions involve beer, but that really isn’t the point).

Conferences aren’t about the sessions, they’re about the people. The sessions form a backbone to an event where developers meet and get to know each other, where we exchange ideas, inspire each other and forge a community. I would urge every developer to attend at least one conference a year. If 360|Flex sounds like your kind of conference, come join us.

I’ve been studying the latest developments in these frameworks to bring the presentation right up to date so even if you’ve seen one of my earlier presentations about frameworks last year, there will be new content and new insights this time around.

If you want to know more about application frameworks, come join us on Tuesday.

The slides from this event are online here.

package somePackage {
  class SomeClass {
    private var _x:int;

    public function getX():int {
      return _x;
    }

    public function setX( value:int ):void {
      _x = value;
    }
  }
}

[N.B. I'm using standard methods rather than AS3 getter/setter methods because it makes the example clearer.]

Now, how do you test it? One temptation is to write a test for each method (many books on TDD suggest treating each method as a unit for testing is a good place to start). To do this, the tests would have to look something like this (in FlexUnit 4).

package testsPackage {
  import somePackage.SomeClass;

  class SomeClassTest {
    [Test]
    public function testGetX():void {
      var obj:SomeClass = new SomeClass();
      obj._x = 10;
      Assert.assertEquals( obj.getX(), 10 );
    }

    [Test]
    public function testSetX():void {
      var obj:SomeClass = new SomeClass();
      obj.setX( 10 );
      Assert.assertEquals( obj._x, 10 );
    }
  }
}

Obviously, this doesn’t work because _x is private. But there are ways around that.

1. We could make _x protected and make our test class extend the class we’re testing.
2. We could make _x internal and place the test in the same package as the class
3. We could define a new namespace and define _x in that namespace

If we did this, we’d have good test coverage. However, we’ve compromised the class to make it testable. We’ve also made a test that is so tightly coupled to the implementation that there is no room for refactoring.

None of these is a good idea. We shouldn’t need to access _x just to test the class. The private _x variable is part of the implementation, and our test shouldn’t depend on the implementation.

If we consider the purpose of the class and the methods and properties used to interact with it (the interface), we realise that all we should care about is if we call setX with a value, then when we call getX we should get that same value back. So the test should look like this.

package testsPackage {
  import somePackage.SomeClass;

  class SomeClassTest {
    [Test]
    public function testX():void {
      var obj:SomeClass = new SomeClass();
      obj.setX( 10 );
      Assert.assertEquals( obj.getX(), 10);
    }
  }
}

If you find yourself wanting to access private methods of a class for your tests, it’s probably because you’re testing the implementation rather than the interface.

N.B. I’d actually test x using a range of values (not just 10) covering edge cases and likely failures. Likely values include negative numbers, maximum/minimum values and zero.