I recently noticed a thoughtful bit of User Experience while using my windshield wipers. Like most modern cars, mine has an intermittent wiper mode that includes a dial to control the frequency of wiper activation. What I noticed is that when you adjust the frequency so that the wipers activate more often (in shorter intervals), they also activate immediately regardless of where it was in the timing cycle. When decreasing the activation frequency this does not happen, and the wipers don’t activate again until the next interval is reached.

Now, you may be thinking who the hell cares, but I haven’t been able to get it out of my head since I noticed it. I think it shows quite a bit of thoughtfulness by whoever came up with the idea and managed to get it implemented. It’s not something anyone would complain about if it weren’t there, and it surely goes unnoticed by hundreds of thousands of people, but it shows a clear understanding of users’ intentions and acts on them. If you’re increasing the wiper activation frequency, it’s because the rain has picked up and you not only want the windshield cleared more quickly in the future, but you probably want it cleared now as well. After all, if the rain hadn’t built up on the windshield you’d have no reason to make the wipers go faster. Somebody recognized that and made sure that that desire, no matter how subtle, would be met.

The takeaway from this odd little post is hopefully that next time you are implementing a feature, think about not just what the user is doing, but why they’re doing it. If you do, you may be able to not only meet their expectations, but exceed them.

AS3-Signals is a recent project by Robert Penner as an alternative to Flash Player’s native event system. While I don’t personally have (m)any problems with events, I have been curious about Signals and keeping an eye out for an opportunity to try it, especially in conjunction with Swiz. That opportunity presented itself a few weeks ago, when Joel Hooks finally showed me the world that Robotlegs can be used without extending framework classes all over the place. As he says in the post, I had been asking to see that for a long time, because I cringe at frameworks that mandate lock-in via inheritance.

In looking at Joel’s sample application (which I think is very good), I noticed that it was very similar to a Swiz application. The application is configured using a context class, which is virtually equivalent to a Swiz instance used to configure an area of a Swiz application (or a whole application). So I spent about 15 minutes and took the latest Swiz SWC I had, created a Swiz instance that mapped to his context, put it in the context’s place, and voila; I had the same application running on top of Swiz. Literally the only other thing I had to do was to add a single [PostConstruct] metadata tag. You can see the striking similarities below. Edit: I have now also included the same Swiz configuration as it would look in ActionScript.

Swiz config in MXML

RobotLegs config

Swiz config in ActionScript

You can even take the resulting application and switch the framework it’s running in by simply commenting/uncommenting the ImageGallerySwiz and ImageGalleryContext lines in index.mxml

Application :: Source

Working with Signals couldn’t be simpler, and Swiz supports them right out of the box. In fact, I couldn’t help but be amused by the fact Swiz had better native support for them than RobotLegs did. They are simply defined in a BeanProvider like any other dependency, and then work as expected. The [PostConstruct] I added was on LoadGalleryCommand’s execute() method, and it replaces the last line of ImageGalleryContext’s startup() method.

Summary

I really like the fact that applications can be somewhat interchangeable between the two frameworks now that we’ve settled on [Inject]. I think a reasonable degree of portability is a sign of a good framework, and based on this example you can see that both RobotLegs and Swiz meet that criteria. The obvious question then, is why pick one over the other? Some of it surely comes down to personal preference, but beyond that I think it is a question of power, scalability, adaptability and developer productivity. In future posts, I will show how Swiz is the clear winner in those categories.

Enjoy!

Last night while working on Swiz I ran into FB-12316 – Code hinting doesn’t work with DefaultProperty. It has been fixed in Flash Builder, but those of us still using Flex Builder were apparently out of luck. What the problem boils down to is that if you are using the [DefaultProperty] metadata tag to point to an Array property, code completion breaks unless the property is decorated with [ArrayElementType] metadata.

My Array was not decorated because it can hold items of any type. Therefore, code completion was borked. I wrestled with the problem for a long time, and then as I was waiting to fall asleep last night it occurred to me that in ActionScript everything is actually a descendant of Object. So this morning the first thing I tried was decorating the property with [ArrayElementType( "Object" )] and it worked!

So there you have it, an easy workaround for Flex Builder users! I hope this helps someone get past this a lot quicker than I did.

Enjoy!

Just a quick note that I have changed hosts for this site. It should be seamless but please let me know if you encounter any issues. I can be reached at ben.clinkinbeard on Gmail.

Thanks,
Ben