Recently, I have been working on a number of interesting projects that have allowed me to really test FlashMX 2004 as an application development platform. While I am very happy with the workflow improvements in the new version, I have also encountered a number of fairly large flaws that can make developing applications in F04 a migraine-inducing experience. Because of this, I have decided to start a new series of posts called “FLAws” (oh how witty), which will outline these issues as I encounter them.

My intent is not to just bitch about these problems. It is to raise these problems in Macromedia’s collective consciousness, and to help others avoid the same headaches by providing suggestions and work-arounds. I also welcome input from the community – if I get something wrong, you have a work-around to share, or you have discovered a problem I haven’t mentioned (please research it thoroughly first), please drop a note in the comments.

I suppose the first of the FLAws was really the EULA issues, which are still outstanding, but I think I’ve covered those well enough (at least for now). I will be making my first official FLAws post later today with a description of a Flash Player 7 bug that has caused us a lot of grief, and some workarounds.

I don’t know if everyone has seen a huge decrease in blog spam, or if my simple blog spam counter-measures have just paid off, but it’s way down for me. In fact, I haven’t received a single piece of blog spam in over a week now.

Besides the technical changes I made, I’ve also been deleting spam within minutes of it being posted, which hopefully helps to deter manual spammers over the long run, as they realize what a waste of their time it is.

Gregg Wygonik raised another really good point regarding Macromedia’s wonderful EULA for F04. It basically prohibits distributing third party SWCs (compiled components) built on Macromedia’s framework.

In order to build proper SWCs, you have to use Macromedia sample code (this includes all of the component base classes such as UIObject), which is then compiled into the SWC. However, Macromedia’s EULA specifically disallows you to distribute any “product or application designed for website development” that uses their sample code. Seems to me, any third party Flash component fits that description dead on.

Oh, and you can’t call it a “Flash component” if it uses Macromedia’s component code, either. That would be using “Macromedia trademarks to market your application”, which is also prohibited.

Looks like the only real answer here (unless MM revises the EULA, or gives each of us specific written permission to distribute) is writing a new framework, that isn’t bound by this restrictive licensing agreement. Or, we could just go back to distributing movie clips – then we wouldn’t have to include MM’s sample code. Macromedia wonders why the adoption rate for F04 is so low? Could it be, in small part, because of the derth of code for F04 being shared by the community, and some hesitation as to what this new EULA means to building client projects.

Does anyone at Macromedia know if there’s been any progress on this topic?

I recently completed a tutorial for Ultrashock on creating an MVC based application using forms and screens. Writing it was more of a struggle than I expected, in part due to the lack of documentation on the subject at the time (it has improved since), but also because the current Form implementation lacks a couple of elements that I would consider requisite for developing a clean application:

1. The Form class does not include a collection of child forms. This means that you can only reference child forms by a largely arbitrary index number, not by name, unless you declare each child form manually in your class.
2. Because the class initializes before the UI components it contains and its child forms, it is very difficult to write logic that sets up and populates interface elements initially, or sets listeners on child forms.

Continue reading →

A few posts back, I mentioned that I was planning to extend the EventDispatcher class to add some features that I wanted. I quickly realized that to satisfy my needs, I would need to do a full re-write, and GDispatcher was born. Being the generous fellow that I am ;), I thought I’d share it with the community – read through this post to download it.

GDispatcher is a new event dispatching class for ActionScript 2.0. It fully implements the EventDispatcher interface, allowing it to be interchanged easily (yay polymorphism!). Beyond the basic functionality found in EventDispatcher (described here), it also supports these new features:

• Listeners can subscribe to all events from a dispatcher
• Listeners can specify a function to handle specific events, or all events (within the scope of the listener)
• Can check if a listener is already subscribed to an event
• Can remove all listeners for a specific event or for all events

Continue reading →