Passive View is another presentation pattern that can be used to increase the testability of graphical applications. It does this primarily by extracting all logic and state from your views, making it pointless to test the view itself. In fact, in the article linked above, Martin Fowler says the following:

With the view reduced to a dumb slave of the controller, you run little risk by not testing the view.

You instead test the component to which the logic and state have been extracted. This component can be referred to by names such as mediator, presenter or controller but the name itself is irrelevant. What is important is that it is not a view component (meaning it does not exist on the display list, in Flash/Flex specific terms), which are inherently hard to unit test. In the example application I have created I refer to these components as mediators.

Example Application

For this post I have simply converted the Swiz example application I created using the Presentation Model pattern. The conversion took maybe 30 minutes, which includes looking up some of the specifics of the pattern, because I had not actually implemented it before.

Application :: Source

Motivations

One of Swiz’s biggest strengths is the flexibility it affords you when using it. Rather than enforcing (or even suggesting) a particular architecture, it provides tools and utilities that help you to create well architected applications. I think showing the same application built with different (albeit similar) presentation patterns demonstrates this point quite well. I will also admit that I was influenced by the RobotLegs Best Practices document in selecting Passive View as the pattern to demonstrate since they demonstrate/promote the pattern there. Hell, I will even admit there was a bit of “anything you can do, we can do better” sentiment on my part. That is not meant to take anything away from the RobotLegs team as they are certainly a smart bunch of guys, but I wouldn’t have joined the Swiz team if I didn’t think it was the best thing out there.

Thoughts on Passive View

I sort of like that your views become plain MXML with no logic, state or external references whatsoever when using the Passive View pattern. What I don’t like is what your mediator/presenter/controller becomes in order to purge your view of those things. I feel like you end up with a frankenstein class that is part (presentation) model, part controller and part code behind.

It is not truly code behind since it uses composition rather than inheritance, but it feels the same. You are reaching into the view to add listeners to its child components, setting properties directly on its child components, etc. Handling events from those child components is like a controller, but you also end up storing some state for the view as well. You could obviously break that out into a separate model class but for most views that is going to be massive overkill. I suppose that presentation models are or can be somewhat of a controller and model combination as well too though. I think adding all the knowledge of the view and its internals is what creeps me out most.

I also feel like Passive View fights against the platform a bit. Since the view has no references to anything, binding is not an option. The view can only be updated by user interaction or manually from the mediator, and even for the extremely simple example I created this felt very tedious. I also wonder if testing the mediator could not potentially be complicated by needing an instance of the view it mediates for operation. Flex Unit 4 likely overcomes much of what would have been painful in the past in this area, but I feel like removing view components from the testing process completely is ideal.

In summary, I think Passive View is a decent pattern, but I won’t be abandoning Presentation Model to use it. In my opinion the drawbacks outweigh the benefits, but the same may not hold true for your particular needs and/or preferences.

Further reading

Be sure to read the Martin Fowler piece linked at the beginning of this post (and anything else by Fowler you have time for), and for another example of the Passive View pattern in Flex check out Paul Williams’ post on the topic.

Enjoy!

A couple of weeks ago, I posted about a workflow I had devised that allowed me to utilize Flash library symbols but still write my code in Flex Builder. While Adobe apparently thinks this awkward hybrid approach qualifies as “integration”, I thankfully discovered a better process just a day or so after my posting. I discovered the main concept of this better workflow from Arpit Mathur’s blog.

What it basically boils down to is using Flash authoring to create a SWC that you then use as a library in your ActionScript project in Flex Builder. Getting Flash authoring to generate a SWC is as simple as checking a box in the Publish Settings dialog.

Then make your ActionScript project use the resulting SWC.

What you can then do is create ActionScript classes that extend the symbols in your Flash file. As long as you give your symbol a linkage name it will be available for extension (and will itself extend MovieClip by default), allowing you to add behaviors and logic using class-based ActionScript like developers expect and prefer to do. The convention I have settled on is to add “_Symbol” to the end of the class names specified in Flash authoring to make it completely clear where everything originates.

The other major advantage this approach has is that it renders the “Automatically declare stage instances” debate irrelevant. You can let the designers leave this setting off and write bits of timeline code if they need to and your classes that extend their symbols will still work. Regardless if they are specified manually in class files for the symbols themselves or Flash generates the classes automatically, the children of your symbols (text fields, child movie clips, etc.) will all be available to your code.

With this simple structure of a symbol in Flash:

You can write a class like this to control it.

The result is a functioning button that allows the designer to use the expressive, proven tools in Flash authoring to create the graphical assets while allowing the developer to use the mature code editing environment of Flex Builder. This process has proven valuable and efficient over the last two weeks and it addresses the major shortcoming of my previous post. That was an inability to use a proper debugger, and it also lets the designer and developer work in parallel, both in the environment most familiar to them. It lets each tool and each team member do what they do best.

While I developed this workflow (not that its an original one by any means, just new to me) due to my assignment on a project that could not use Flex, I actually think it could be valuable in Flex projects as well. For views that are highly detailed and/or non-standard it may very well be easier to let your designer create them in Flash than it would be to create some crazy MXML file that carefully layers exported images and animations that you then try to wire up and orchestrate with code. Simply write a class that extends your designer’s symbol and manipulates it as needed.

To me this seems like the best kind of workflow available today by far, and so its really disappointing and frustrating to think Adobe may not be taking things a step further in their next releases. We don’t need or want Flash Builder to compile and run our projects in Flash authoring. What we need are workflows that allow us to use tools that do their job well and that we’re comfortable with, and that simplify the inevitable round tripping between design and development. Having Flash Builder trigger compiles in Flash authoring may sell more licenses to the uninformed, but its a sad excuse for integration from a company that creates tools ranging from authoring to runtime.

All code and sample files for this post can be found in my Google Code repository.

Nostalgia and complaining

Years ago, before AS3 and Flex 2 were on the scene, I was a Flash developer. I dabbled in other things like PHP, JavaScript and the horrific “classic” ASP, but Flash development with AS2 was always more interesting to me. I worked with great designers who of course used Macs, while me and the rest of the developers were on PCs. (Don’t worry, I use a Mac now.) In order to preserve the designers’ fonts and hand crafted animations, we taught them how to assign linkage names to their symbols and would have them deliver a .swf to us that had nothing on the stage, allowing us to pull symbols out of the library as we needed. Using the fantastic MTASC compiler and an editor like PrimalScript, our class-based AS2 code would be injected into the designers’ .swf, bringing the site/game/whatever to life. Ahh, those were the days.

Fast forward to last week when I was assigned to my first ever non-Flex AS3 project and discovered that developing like we used to in Flash (tying AS classes to library symbols) is pretty painful these days. Or at least it was for me, until I constructed a very convenient workflow that you can probably guess at based on the title of this post. Now, I should probably explain what I mean by painful. You can write your AS3 classes in Flash authoring, and the process is very straightforward; just create classes whose names match the symbol linkage names and you’re done. Just like AS2. However, Flash authoring’s code editor is absolutely abysmal. I mean, I knew it was bad, but I was actually shocked at how bad it is. It won’t even create import statements for you when you create properties! If you have used Flex Builder or any other decent editor for more than 10 minutes, this is completely unacceptable. You could also write your code in Flex Builder, save, switch to Flash authoring and then test movie or publish from there. Honestly though, do you really want to do that 500 times a day? Me neither.

So, what is this better way you ask? Well, we use one improvement that did come with Flash authoring’s support of AS3, which is the document class construct. This means that you simply create a custom class to represent your application, make sure it extends MovieClip, and tell the .fla to use it. We don’t need any code at all in our .fla, unlike back in the day. This essentially means that your custom class is your root timeline, and adding display objects to it is like adding them to the stage.

Coding in Flex Builder

Since I use a Mac, Flex Builder and FDT are the only realistic options for AS3 editors, as far as I know. If you are on a PC, FlashDevelop is also a great program. Now, Flex Builder allows you to create ActionScript projects. In contrast to a Flex project, I assumed an ActionScript would be devoid of any reference to Flex SDKs, but this is not the case. Your ActionScript project will still reference an SDK in the compiler settings and in the build path dialog, but that is OK. Since you don’t reference any Flex classes, you will not be pulling the framework into your .swf. I think it is only referenced so Flex Builder knows where to find mxmlc, but I am not completely sure. In order to use library symbols as class instances, you will need to create corresponding classes (that extend MovieClip) for them that match the name specified in the their linkage field. Whether you need to add custom code or not, the classes must exist in order for you to reference them in Flex Builder. To reference their properties, like child text fields or buttons I declare those properties in the class and turn off “Automatically declare stage instances” in the .fla’s publish settings.

Compiling in Flash authoring

OK, none of that was revolutionary but now comes the hard part. How do you compile/test your project without having to switch back to Flash every time? The first piece of the puzzle is to use the flashcommand Python script that Mike Chambers posted a long time ago. (It is only for OS X in its current state but I would assume creating a PC-friendly version wouldn’t be too hard.) All this really does is open Flash if necessary, and compile the .fla(s) you tell it to, by writing JSFL to a temporary file and then running a line of AppleScript to execute the JSFL code. That is really great, but switching to Terminal every time I want to compile is no better than switching to Flash. I needed something I could trigger from within Flex Builder, so I naturally turned to Ant. All you need is a super simple build file, like this:

As you can see, it just sets up a couple of properties and asks Python to run the flashcommand script. The -e argument tells flashcommand to include doc.exportSWF() in the generated JSFL, which will publish the .swf to the location specified in the -o argument. If this is all you need to do, but want to then launch the newly created file in Flash Player, you can add the following to your build.xml file.

That was my initial approach but it makes viewing your traces kind of a pain. The easiest way I found was to tail your flashlog.txt file but that still kind of sucks. Its especially bad because a LOT of .swfs on the web still include trace statements, meaning your Terminal is flooded with statements generated by every banner ad running in your open browsers.

What I ended up doing was to edit flashcommand so that the -e argument also adds fl.getDocumentDOM().testMovie() to the generated JSFL, causing Flash authoring to execute a test movie action. I also added activate to the end of the generated AppleScript so that Flash’s test movie window would be brought into focus and ready for interaction. This allows you to use Flash’s built in Output panel to view your trace statements, and your trace statements only. (I tried making the test movie option a separate command line argument but couldn’t get it working correctly. If any Python hackers out there want to show me the way I’d be much obliged.)

Set up a keyboard shortcut in Flex Builder for running Ant and your workflow is almost identical to a Flex or code-only ActionScript project. Your .swf will be generated and published to whatever location you’ve specified, and will also be opened in Flash authoring for visual inspection and testing. I am probably not the first to come up with something like this, but I didn’t find any good links on the subject and other people expressed an interest in hearing about my workflow. If you have suggestions on further improvements (like how to use Flex Builder’s debugger for these projects) I would love to hear them. Regardless, I hope this is useful to other coders who find themselves needing to develop AS3 projects that associate custom classes with library symbols.

If you’d like to replicate this setup, you can download my modified version of flashcommand.

Enjoy!

As I mentioned in my last post, I have begun a project using the Flare data visualization toolkit, and I intend to document things I learn along the way. One of the first things I investigated, after familiarizing myself with the basics was how customizable the grids and axes for visualizations could be. It took me longer than I expected to figure things out, but now that I have I would say the grids and axes in Flare are highly customizable, and should be capable of accommodating just about any needs you may have.

This post is mostly code and images, but in case you want to jump around here is a table of contents.

• Background info
• Base code and a basic grid
• Controlling grid bounds
• Customizing grids and axes
• Useful methods

Background info

Before we dive in to the examples, I need to cover a tiny bit of background information and establish some constants we'll be using. First, all of the examples will be using this simple data source:

As you can see, its just an array containing 3 elements who each have an x and y property. Next, we'll look at a bare bones plot chart built with Flare. The following is essentially the bare minimum of code required to create a visualization in Flare. The default visualization is a plot chart using circular shape renderers, which is fine for our purposes here. We'll be using this code as a basis for the code added/demonstrated through the rest of the post, but I won't be repeating it all every time. Lastly, remember that Flare visualizations are really just Sprites, which means they cannot be added directly to Flex containers, only to DisplayObjectContainers, which is also Sprite's super class. UIComponent, and therefore most every Flex component, are in fact descendants of Sprite, meaning you can add Sprites to UIComponents. For more information on Flash Player's core display classes, see this page.

Base code and a basic grid

This code produces the following visualization:

As you can see, the grid bounds are dynamically created based on the data being shown. This would be very convenient if that is what we wanted, but in my case it was not.

Controlling grid bounds

If we'd like the chart's minimum values to always be zero, we can use the zeroBased property of the xScale and/or yScale properties of our axisLayout. The following code will cause both the x and y axis to begin at zero.

To control the maximum values of our chart we can use the preferredMax property.

Note that there is a preferredMin property as well, but it (oddly) is ignored when set to zero. You can use it to set the lower bounds of your axes to any value other than zero. Adding the two snippets above has specified that our chart axes should begin at zero and end at 10, regardless of the data being shown. The resulting chart looks like this:

Customizing grids and axes

To really start customizing your chart, you'll want to use the xyAxes property of Flare's Visualization class. xyAxes is of type CartesianAxes and contains several convenient properties, as well as providing access to xAxis and yAxis properties that represent exactly what their names say, and are both of type Axis.

Maybe you want to eliminate the default grid pattern in favor of a simple bottom and left border.

The xAxis and yAxis elements also provide some useful properties that we can use to further customize our chart.

This code produces the following chart:

Useful methods

There is also an axisScale property on the Axis class (our xAxis and yAxis elements). axisScale is typed as Scale, but will usually be a ScaleBinding instance as Scale is essentially an abstract class. Scale (or rather its subclasses) provide two very useful methods, interpolate( value:Object ):Number and lookup( f:Number ):Object. The interpolate method will return a number representing where on the scale the passed in value falls. In our example where our range is 0 to 10, 5 would return .5, 8 would return .8, etc. The lookup method essentially does the opposite, accepting a number and returning the corresponding value on the scale, meaning .5 would return 5 in our example, 2 would return 20, and so on. These methods can be extremely helpful if you need to do custom drawing on your chart, and are the kind of value translation methods that seem to be missing from the Flex charts.

Conclusion

This is obviously not an exhaustive list of customizations possible with Flare, but it hopefully gives you an idea of the kinds of things you can do out of the box. I haven't decided which topic to cover next, so if there are specific questions or features people would like to see let me know in the comments.

If you haven't heard of Flare, go check out the demo right now. I'll wait.

Pretty cool, eh? Flare is an ActionScript port of Prefuse, a "set of software tools for creating rich interactive data visualizations" written in Java. The development of both Prefuse and Flare were led by Jeff Heer, I believe as part of his Master's thesis. I have recently begun to investigate Flare as a potential replacement for Flex charts in my current project at work and have been lucky enough to spend the past two weeks simply diving in and learning how to use the library. I needed to determine whether or not, and how easily, we can do everything we hope to on this project. My conclusion is that Flare is extremely powerful and will almost certainly support any kind of visualization we can think up.

That being said, our project is a Flex application, and Flare is simply an ActionScript library. It has a very basic wrapper component (FlareVis) that extends Flex's Canvas component, which allows basic instantiation and configuration in MXML but the library is not especially Flex-friendly. My plan is to create some wrapper APIs and higher level classes that will make using Flare in Flex much easier. What is even cooler is that our awesome client has expressed their desire for these enhancements to be contributed back to the community so that others may benefit. There is a lot of work to be done but I am really excited to start making progress. For example, Flare doesn't have specific components like a Bubble Chart, you simply have a base Visualization class that you customize and extend to create what you need. Developing with Flare has reminded me of my old AS2 days because of its dynamic qualities and freedom from the constraints the Flex framework places on you. (Note I am certainly not knocking Flex; its how I make my living and the only kind of serious AS3 work I have ever done.)

Flare works with lower level classes than you normally would in Flex, with Sprite being the core display class. This is undoubtedly one of the reasons you can attain such amazing performance with Flare. During one of my tests I animated 2000 bubbles on a chart with no noticeable slowdown or degradation, which I don't think would be the case on a Flex chart. In case you are not aware, Sprites are like single frame MovieClips in Flash. They do not have an internal timeline, but they are a direct extension of DisplayObjectContainer, meaning they can contain child objects. They of course also have a graphics property that allows you to use the drawing API to customize their appearance. They are not UIComponents, so you cannot add them directly to containers in Flex, but that is not a big deal. You can add them as a child of a UIComponent instance, and then add the UIComponent to a container like usual.

That is probably enough introduction and rambling for now, but you can expect a steady stream of posts from me about various aspects of Flare, further experiments and progress on the wrapper APIs. For more frequent and less formal updates, you should follow me on Twitter here.

I don't really want to get fully involved in the discussion being had by Ryan Stewart, Asa Dotzler and Simeon Bateman. However, in reading through each argument a few things Asa said struck me as particularly indicative of the fact that he, and I suppose maybe Mozilla as a whole, simply don't get it. I am admittedly cherry picking here, but I couldn't resist pulling out a few quotes.

Open is developing the protocols and specifications in a co-operative and participatory environment and then competing on implementations.

Replace "Open is" with "The colossal headache that is developing consistent experiences that are cross browser/platform and engaging to users is thanks to" and you've got a true statement. I use Firefox as my primary browser and think overall its a great application but unfortunately, telling a client their new site looks great in Firefox and like garbage in IE won't exactly result in a lucrative career. Developing for "competing implementations" sucks, and its a large part of why Flash Player is so widely embraced and successful.

If I was in Adobe's shoes, I'd give everything away, all of it. Hell, I'd pay people to develop on the Adobe platform and I'd encourage dozens of competing implementations of my platform across every type of device imaginable because, in the end, it'd be my platform and I'd decide how and when it evolved and to what ends.

See above for my thoughts on competing implementations.

So, all I can do in this battle for the future of the Web is to advocate for advances in real open Web standards from groups like ECMA, W3C, and WHATWG. It may be a bit slower to market, (hopefully not too much slower,)...

A bit slower? Seriously? Just a bit? Far as I can tell HTML 4.01 was finalized in December of 1999. Nineteen ninety freakin' nine. Best I can tell the latest Flash Player back then was version 4. So in the 9 YEARS we've been stuck with HTML 4 there have been 5 full version releases of Flash Player. If thats a bit then I am just a bit shy of being a billionaire. Yes, Firefox has had a few releases in that time but it wasn't adding any new capabilities, just improving its implementation of the same old spec.

So be patient everyone, for by 2011 you will almost certainly have a finalized HTML 5 spec and, not only that, your choice of no less than 4 major implementations of it to choose from!

Did you know that AS2 includes rudimentary implementations of collections and iterators? I didn't until a few months back, but they do come in handy from time to time. An added bonus is that they make me less sad about developing in AS2 and missing out on all that AS3 goodness when the project requires FP8 compatibility.

Anyhow, the default implementation still leaves a bit to be desired, especially for those of us who spend the majority of our time coding AS3. The built-in class not only bears the unfortunate name CollectionImpl (which implements the Collection interface, both of which reside in the mx.utils package), but it also lacks some methods I've grown to appreciate in AS3's ArrayCollection class. Those methods are as follows:

• length (getter)
• addItemAt()
• contains()
• getItemIndex()
• removeAll()
• removeItemAt()

The following class provides those methods. I know, nothing fancy or impressive, but useful (in my opinion) nonetheless. CollectionImpl isn't all bad though, it does provide us with most of the basic collection-related functionality you would expect, including the removeItem() method that was left off of AS3's ArrayCollection class. As such, this class inherits from CollectionImpl and attempts to fill in the blanks.

Feel free to alter the package path here and insert this class into your library wherever you want.

I just discovered Graeme Harker's Flex.NET blog (via Jesse Warden) and I must say I am impressed. His article concerning marketing Flex to developers is dead on, and I really hope Adobe listens to some of his suggestions.

As someone who has successfully convinced their .NET development shop employer to adopt Flex, I can attest to the fact that Adobe's insistence on literally ignoring the .NET community was one of the hurdles I had to overcome. As a developer that learned Flex in the context of a .NET environment, I can tell you that the lack of tutorials using anything but FDS was a real disappointment and a significant hindrance. If I were a .NET developer investigating Flex, rather than a Flash developer doing so, I probably would have given up thinking that Flex is intended as a front-end for Java stacks. At the very least put some Web Service tutorials out there!

Anyhow, this post was intended to point you to Graeme Harker. He seems to know his stuff and I look forward to working my way through his past articles.

This may be obvious to others but I found it a bit counter intuitive and thought I would post a note as much for my own reference as for others. Consider the following code:

This will return the correct value (22222), but I thought it was a bit odd that the dot that precedes the condition does not actually take you down into the node, allowing you to still directly access the property you're after. I think this is a very smart implementation because otherwise it would be very difficult and convoluted to select a value based on a sibling value. It would likely require something similar to, albeit more complicated than, the methodology recently discussed by Mike Chambers.

E4X definitely rocks the house.

Over the past week or so I have been fortunate enough to get to help out the guys from FlashDevelop, as they added support for AS3. This has been really fun so far. Even though I have not used FlashDevelop very much, my limited exposure to it along with ringing endorsements from some well known and respected Flash developers makes it obvious that it is a great editor with a very bright future. This is reinforced by the talented, enthusiastic and very responsive people behind the program, and my hat certainly goes off to them for implementing a feature requested by the community so quickly.

This work gave me a chance to finally try my hand at C# and to dig deeper into regex than I've dared before. Thanks to Expresso and some knowledgeable, helpful co-workers it was quite a positive experience. I am really looking forward to continuing to work on this.

Anyhow, rather than crud up my main page every time there is an update to announce, I have created a page devoted to my tiny piece of the pie. I would expect that any new developments (like Javadoc info) will be announced on the FD site, but the instrinsic class files will always reside in the same place. Unless they move. But they probably won't.

Now go try FlashDevelop! I know I'm gonna