Just a post here for posterity in case myself or someone else needs to fix this in the future. In many cases when I use drawCircle() in the Flash Player, it creates a somewhat distorted shape. One or more sides of the circle appear smashed or clipped. To fix this, you add the following code just before the drawCircle() call.

graphics.lineStyle( 1, 0, 0, true );

The following image is a before and after shot of using this code.

360|Flex DC was last week, and it was a great time. I got to see a lot of old friends and met a ton of new, cool people. I’m not sure how useful they will be on their own, but I wanted to post my slides here for anyone who might be interested in them. I had planned to do a walk through of a Swiz application that includes Flex modules, but was pretty low on time and had to run through it pretty quickly. I will be cleaning up that example soon and pushing it to GitHub as our reference implementation of using Swiz with Flex Modules, but it’s not quite ready yet.

Enterprise ActionScript: Writing Clean Code Fast with Swiz 1.0

Enjoy!

The vaunted, venerable and value-laden 360|Flex conference is coming to Washington D.C. in a few weeks, and you really should be there. This will be my fifth 360 event in total, and my third time speaking, and I can honestly say I’ve never had less than an awesome time at the event. Regardless of your skill set/level, position on your career path or otherwise, if you are part of the Flex community or wish you were, 360|Flex is the place be. For the incredibly reasonable price of $599, you get no less than the following:

• One full day of hands on Flex-related training
• Three full days of outstanding Flex-related sessions
• Ample networking time and opportunities with the brightest minds and biggest names in the Flex industry
• Three (I think) parties with those same Flex industry folk and your fellow attendees
• Catered lunch each day of the conference
• A prime opportunity to enhance your career path through gained knowledge and contacts

Just browse the speaker list, and you’ll see there is no hyperbole in my statements above. Check out the session schedule (PDF) to see the topics being covered, and I bet you’ll be hard pressed to find a slot that doesn’t have at least one session that appeals to you.

360|Flex really is like the family reunion of the Flex industry. Come join the family. REGISTER!

Oh yea, I will be giving a session on Swiz that introduces the framework and shows developers how to get up and running quickly, and how Swiz can help you be more productive writing code. I hope to see you there!

Update: Swiz now supports custom namespaces automatically, so this post is fairly irrelevant. For more info see the Swiz RC1 release notes.

Every now and then someone expresses frustration with the fact that Swiz, and every other Flash Platform dependency injection solution I know of, can only inject into public members. I started thinking about it yesterday and figured it actually wouldn’t be that hard to use a custom namespace rather than public. Granted, it’s not as nice as being able to use private members, but the Flash Player/AVM simply does not allow for that at this time. So tonight I spent about 15 minutes throwing together a proof of concept using Swiz 1.0′s new custom processor feature. What you see here is the result of that 15 minutes.

The first step was to create a custom namespace.

Then I created a view that defined some properties in that namespace.

I then created the custom processor to handle those special [NSInject] tags you see in the view. Subclassing Swiz’s built in InjectProcessor (which handles the standard [Inject] tags) allowed me to override just one simple method to accomplish my goal.

That’s it. It supports both property injection and setter injection, and has a ton of room for improvement. You could easily expand this to support the definition of specific namespaces in the metadata tag, or to read the namespace from the property, or some other enhancement I haven’t thought about. Remember, this was 15 minutes of coding; it has taken me longer to write this post than it did to create the processor and example app.

The ability to extend Swiz with custom processors is revealing itself to be an incredibly powerful feature. I fully believe it will turn out to be far more powerful than we even anticipated when we created it. We’ve not even released the 1.0 final version and people have already created processors related to logging, loading Yahoo Finance data, and mediating AS3 Signals.

What can you build?

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

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.