Compile me if you can

Lately alot of talk of SWF compilers has been going on. MTASC has arisen as a great alternative to compiling in the Flash IDE, and has allowed developers to integrate into other development enviornments such as Eclpise.

Last week I was meeting with a client of ours that is bringing us into a large software development project. As usual we are developing the Client UI, but this time it is a reqirement for us to integrate with a large software firm's source system. They have a fully automated build system, and requested information from me in regards to automating Flash compiling in their build system. I must say I was embarrased when i presented an open source, third party tool to them as the solution for doing it. Not that MTASC is bad or anything(it is great!), but it just seemed silly that Macromedia has not addressed this type of workflow. The emergence of MTASC alone, is testimony to the demand for such a solution.

Since that, I have been using MTASC on a project and I must say that there is an astounding difference in compile time using the tool. We have a large project (SNL Merger Model) that utilizes 100+ Actionscript classes,(outside of the mx framework) that we are currently in the process of reworking to compile under MTASC. I must say that this is not an easy feat. In a project that large, there are many little typing and variable definition rules that we did not adhere to that MTASC enforces.

Already though, compiling is faster and much less stressful on the system. Compiling the application currently from the Flash IDE takes about 3-4 minutes on my computer(1.7 gig, 512 RAM). When it completes, the computer feels as if it got hit by a car, and takes a minute or two to recover from the process.

Now imagine debugging a Flash application that takes that long to compile. Every little change causes you to waste time as you test. It has been a major problem on the project, and when I say major I mean that potentially up to 1/4 of our development time has been spent on compiling.

So as a result, we are investing the time to alter all the code to compile under MTASC. More than that I have built a little UI and command set for running MTASC from the Flash IDE. This was a bizarre concept for some developers I talked to about it. They had always percieved MTASC as a tool to utilize in other enviornments rather than the Flash IDE. I think however that using MTASC in Flash is a simple and great idea, and it is looking like the Compiler will not only solve our problem with SNL, but fit easily into the workflow we have already established.




So this exercise has led me to some conclusions:

1/ My #1 wishlist entry for the Flash IDE is an improved compiler, comparable to or better than MTASC. I want to see speed and I want to see the ability to add assets or classes without recompiling the whole swf.

2/ MTASC is a great example of what Flex should be. I still do not understand why Flex must be a server (other than price, and some of the "nice to have" server features).

Delegates,be careful....

I have been noticing alot of code samples around the web that features actionscript code that looks like the following:


myComponent.addEventListener( "someEvent" , Delegate.create( this , someFunction ) );

Delegates are extremely powerful tools, and I use them frequently, but through experience I must say that in my eyes, the above is not good form when building a Flash application. My qualms are up for debate here, so I am inviting anyone to toss in their 2 cents.

First off, I have always had an issue with the way Delegate.create has been created. I had a little pow wow with Stacey about it a month or so ago. The problem is the fact that it asks you to pass an actual reference to the function in question:

Delegate.create( this , someFunction );

To me this is an issue because if for some reason someFunction is overwritten at runtime (which is common in AS) then your delegate no longer refers to the correct function. I cannot think of one case where storing the function reference would be advantageous.

I rewrote Delegate to look like this:

Delegate.create( this , "someFunction" );

This simple change allows you to overwrite the target function and still have Delegate call it correctly.


Now on to addEventListener. Everytime I see the following it gives me shivers:

myComponent.addEventListener( "someEvent" , Delegate.create( this , someFunction ) );

On large scale Flash applications this would be your doom. You would be asking for some serious memory leak action if you had an application that changed states frequently.

The issue with it in my mind is that it provides no mechanism for removing these listeners! On a small scale 1 form application this is surely tolerable, but many Flash applications of any level of complexity place and remove items frequently, making this a disaster waiting to happen. Consider the Stage object. It is global, and often you would be making items listen to it's events for resizing and the like. Would you add listeners to it in this fashion? If the answer is yes then you are going to have a real problem one day.

I guess people are thinking that if they use these with UIcomponents, then if the UI component is removed the Delegate will be garbage collected. That is true, but the scary thing is that if you start coding that way in a big project, you start getting into issues like this:

managerClass.addEventListener( "someEvent" , Delegate.create( this , someFunction ) );

By managerClass, I am refering to something that does not get removed from stage, or some kind of global object or perhaps a singleton. This is where there is major potential for problems. You are introducing the oppourtunity for the application to add duplicate listeners, and on top of that providing no facility to remove them other than going directly to the listeners array of the dispatching object.


So my suggestions are the following:

1/ Use listener objects in which a reference remains in the scope of where it was applied as a listener. It is likely that if it is to be removed then it will be removed in that scope. It may seem like more work but it will help you avoid memory leak issues.

2/ Extend EventDispatcher to accomodate callbacks. The default implementation does not allow you to do this, but there are others that do. One I can think of is gDisptacher by Grant Skinner


So in final I am just highlighting a few concerns regarding Delegates, because it can be easy to get carried away with Classes as helpful as it is.

Don't Learn Actionscript...?

I am just writing this in response to this post from Flash Insider:

http://www.flashinsider.com/2005/07/18/dont-learn-actionscript/

I certainly agree that it is great to look at other languages to cross-reference the similarities, but to what end?

Most non-programming Flash users are designers. Explaining methods, classes, events, etc in other programming models will not do much other than confuse someone that is trying to add a little code to their Flash work for the first time.

Designers tend to understand how assets in Flash behave, like MovieClips, Textfields, Video, etc, therefore starting to learn programming in Flash with Actionscript is easier to explain to them because it is based on a system of events that a designer can actually see for themselves. Once they get a good grasp on it there, it surely opens the gateway to learn other programming models.

On another yet similar note,

These days alot of developers are coming into the world of Flash. They are being beconed in by tools such as Flex. These types of tools abstract the bottom layer of what Flash actually is, and makes Flash development seem much more like other familiar models.

This is great but the truth is, that the deep understanding of Flash not Actionscript has led to most of the brilliant work that really stands out over the last 6+ years. So many people in the development community these days curse at the timeline in Flash and state how they are looking at tools for development that hide it away. The only reason that occurs is because many of those people have not taken the time to explore Flash at it's simplest level to see how powerful it actually is.

I had to work with a team of Java developers at SNL Financial last year. They were new to Flash and immediately jumped right into Actionscript to start building things. While they were able to do great things, it wasn't until they were shown the simplest tricks of Flash timelines that their eyes lit up with real intrest. The Flash timeline may not be like other programming models, but that is the reason why Flash has become so popular over the years, not Actionscript.

So to conclude, while all these designers are out there trying to pick up all of these different programming languages to help them with their Flash work, maybe more developers should take some time to learn how to use a traditional Flash timeline for tweening. And if they did, maybe they could also take a look at

- After Effects
- SVG authoring tools
- Director
- 3DS Max
- etc

That could really help developers understand visual interface and motion design at a higher level...........

It would also confuse and annoy the crap out of most of thedeveloper community to even take the time to do such a thing. All those tools are similar in the fact that they have timelines, and key frames and tweening. But they are all so different in implementation that it would take a while to wrap your head around all of it, and to be able to use and understand them all.

So in final, I would recomend that Flash designers looking to add some interactivity to their work, stick to Flash and Actionscript. It is a great learning tool and will open thet gateway to bigger things when you are ready.

Try the SWFStudioV3 Add-in!

I have uploaded an .mxp of the current build of the SWFStudio Add-in we have been building. People can feel free to try it out if you have SWFStudio 3. The extension still has features that need to be added, but I would like to get feedback from people and how it feels so far.
Here are some details on the Extension as it stands:

SWFStudio Add-in for Flash MX 2004

SWFStudioV3


SWFstudio Commands:



The SWFStudio Add-in installs 2 new commands into your Commands menu in the Flash IDE. These commands can be easily tied to keyboard shortcuts for ultimate integration.


[SWFStudio]-Export Settings



This command launches a SWFPanel that allows you to set all of the SWFStudio options. The options are tied to the .fla file that you are working on, so it automatically includes the .swf file generated from the current .fla as the SWFStudio main movie. Doing this, eliminates many of the options that you are required to set when using the SWFStudio interface, including the output, and movie panels.The SPF data that this command generates is stored in the .fla file itself. This means that you use SWFStudio without ever having to worry about SPF files at all, more than that, passing the project to another developer does not involve resetting paths as they are mostly all relative, and paths that are not are resolved at compile-time.


[SWFStudio]-Build

And of course the simple yet beautiful Build Command. It basically causes SWFStudio3 to build the project. SWFStudio will open, build, launch the resulting file, and enter debug mode! Attach a keyboard shortcut to that, and bling, blang!, Full integration!I tried forcing Flash to export the .swf file first then proceed to doing the SWFStudio compile, but a Studio build fails if the .swf file is busy. Unfortunately, there is no way to determine when a .swf is finished exporting in the JSAPI, so failures are common when I implemented it in that fashion. So instead I settled on not including the .swf compile in the command.


Other Notes:

1/ Support for Layout (Files) exists but is not complete in this build, so I switched it off for now.

2/ No Support for SWFStudio Masks yet.

3/ place an .ico file in the same directory as your application and it will automatically become the app icon when the project is built.


Feedback:

I am really looking for feedback on this extension, please contact me at tony@teknision.com if you have any issues or suggestions.

Enjoy!

SWFStudio3 - MultiUser without the Server

another feature I have played alot with in SWFStudio 3 is the UDP Plug-in. Below is a small exceprt from the documentation:

The UDP plugin enables the use of simple socket connections with SWF Studio applications. Using the UDP plugin, you can send and receive text messages using UDP datagrams, as well as broadcast messages to computers on a local subnet.

The UDP plugin uses connectionless sockets, making them very efficient for quick communication between computers. You can use this plugin in situations where it is not necessary to know if the transmitted message was received by the destination computer(s). It must also be noted that there is no guarantee as to the order in which messages will arrive. Though it is very unlikely, it is possible for two messages sent at almost the same time to arrive in the reverse order from which they were sent.

So basically you can create an instance of a UDP object, select a port, and start sending and recieving packets accross a network. This is great for internal chat systems, notification systems, the sky's the limit really.

SWFStudio has introduced a great Actionscript API in V3. That API provides better access to the functionality of SWFStudio, but I always find myself wrapping API's in Classes still in V3. This is not a complaint, it is just merely a matter of preference. The SWFStudio AS API is robust enough that you can code effectively directly at it, but I am just not a fan of allowing callbacks to run rampant in my production work.

As result I have built up a little code sample on the use of UDP, and within it I am including my UDP AS2 class, along with it's super, the Plugin Class. Using it looks like this:

////////////////////////////////////////////////////

myUDP=new UDP(6868);//port number

textArea_ta.onUDPData=function(event){
var ctext=this.text;
this.text=ctext+event.data.ip+">>"+event.data.msg+newline;
}

myUDP.addEventListener("onUDPData",textArea_ta);
myUDP.open();

////////////////////////////////////////////////////

Then send away like so:

myUDP.broadcastMsg("Hey guys! Check this UDP action!");

////////////////////////////////////////////////////

The source for my UDP class can be found here.

SWFStudio3 File Formats

I am just going to do a quick round up of some things I have been playing with in SWFStudio3 that may not be apparent in a quick feature overview. There are so many new features, so I am just going to focus on the discoveries I have made that really got me excited. My next few entries will take a closer look at some of these features 1 at a time.

1/ SPF, SPG, and SPX files

SPF files are the main SWFStudio file format. In SWFStudio3 SPF files are just .ini files. This means that they can easily be opened and edited in a text editor. Inside you will find a list of name and value pairs that represent all of the SWFStudio export options. These files can easily be generated by other programs other than SWFStudio now!

SPG files are batch command files for SWFStudio. Executing one of these files will cause SWFStudio to build any SPF file referenced in that file. The format of the file is as follows:


./myproject.spf
C:\Documents and Settings\tony\My Documents\UDPTest\UPD.spf



This file just contains paths that are relative or absolute paths to the files to cause Studio to build. SWFStudio will open, build the files, then close, making the process very discreet. There are a few other parameters that can be utilized as well:

# autotest stayopen
./build.spf

By including the comment line shown above you can force SWFStudio to stay open after a build as well as launch the project you are building when it is complete. This only works if you are building only one SPF file.


SWFStudio Add-In

The above additions allowed us to build an extension to the Flash IDE that allows the process of using SWFStudio to be totally controlled from Flash Commands.

We have built 2 commands:


[SWFStudio]-Export Settings

This command launches a SWFPanel that allows you to set all of the SWFStudio options. The options are tied to the .fla file that you are working on, so it automatically includes the .swf file generated from the current .fla as the SWFStudio main movie. Doing this, eliminates many of the options that you are required to set when using the SWFStudio interface, including the output, and movie panels.

The SPF data that this command generates is stored in the .fla file itself. This means that you use SWFStudio without ever having to worry about SPF files at all, more than that, passing the project to another developer does not involve resetting paths as they are mostly all relative, and paths that are not are resolved at compile-time.

[SWFStudio]-Build

And of course the simple yet beautiful Build Command. It basically causes SWFStudio3 to build the project. SWFStudio will open, build, launch the resulting file, and enter debug mode! Attach a keyboard shortcut to that, and bling, blang!, Full integration!

I tried forcing Flash to export the .swf file first then proceed to doing the SWFStudio compile, but a Studio build fails if the .swf file is busy. Unfortunately, there is no way to determine when a .swf is finished exporting in the JSAPI, so failures are common when I implemented it in that fashion. So instead I settled on not including the .swf compile in the command.


SPX Files

SWFStudio3 now allows you to export your project from Studio as a .spx file. It takes all of your assets and bundles them together into one package, that you can then send to others to work on. It acts as a project file of sorts. These files will be very useful to many, and most of the SWFStudio3 samples are bundled this way.


SWFStudio3 Add-in Extension Testing

If anyone is interested in trying out the extension, drop a comment and i will contact you. It is pretty much complete, but it needs a few people to give it a test run before I release it in full.


In the next entry I will cover one of the plugins that I have had a blast playing with. The mighty UDP Plugin! Multi-User, No Server!

SWFStudio V3! - (Add In coming)

I just wanted to point people to the Northcode site to check out V3 of SWFStudio. The new version is brilliant, introducing features such as a JScript interpreter, new plugins such as UDP and TCP, as well as a robust Actionscript API in place of the old fscommands.

On the Teknision front, we are just about ready to release an extension to the Flash Authoring Enviornment allowing you to create applications and screensavers right from Flash leveraging SWFStudio. You can set and edit all SWFStudio V3 options right in Flash as well as do builds. The SWFStudio SPF data is all stored inside the fla file, making it very portable.

I am currently in meetings all day in Boston, but I will do a full write up on my impressions of V3 when I return to Ottawa tonight, and hopefully have the SWFStudio Extension ready for release by tommorrow.

My Biggest JSAPI wish....

I have developed many extensions since the JSAPI was added to Flash MX 2004. The Frame Labels Panel, Extensions Builder Panel, a tonne of Commands, and a whole bunch of internal project flow extensions here at Teknision.

There is one thing that has constantly frustrated me though, and many of my coolest extension possibilitities have gone to the wayside because of it.

That wish is for access to Actionscript classpaths at both the document and Flash preferences level. There is so much possibility for lookup, creation, archiving and retrieval.

I really hope that at some point they would add this simple little feature, because it would make a huge difference.

I am just in the process of trying to gather all of the work our team and I have done over the last 2 years in terms of extensibility, and it I just noticed how many times we bumped into that issue.

Flex, Avalon, the oncoming storm

I was just reading this post by Mike Rankin:

http://mrmx.blogspot.com/2005/07/avalon-good-for-macromedia-customers.html

He discusses the oncoming battle between Avalon, and Macromedia's Flex product. In summary, he states that Flex is aimed at the enterprise (2% of business), as it's price point is so high per processor. He worries that Macromedia must change their pricing policy as Longhorn and Avalon start to appear on the scene.

I have spent alot of time considering Flex for RIA development. We did consider it for the SNL Merger Model application for SNL financial, but chose not to go with it. The SNL Merger Model would have certainly been a candidate for Flex deployment but the issues that made the client and their in-house development team turn it down were:

1/ Pricing, they could not justify the high cost per processor. They thought it was much too high. This became a big issue because of the next point:

2/ Flex shouldn't be a server. Some may really disagree here, but their thought was: "Why pay 10k per processor for a component assembler?"

Even if we had used Flex, 90% of the development was in creating custom components and skinning. This means that 90% of the job would be done in Flash anyways.

The Flex model certainly would have sped the process in terms of data binding, component assembly, as well as integration with source control and team development, but still not worth the cost as a server. The java developers I was working with thought that the tool should work exactly as is, but compile on the client instead of at the server.

So in the end we developed it all in the Flash IDE, and Eclipse. They were already running JRUN on the back-end meaning we had Flash Remoting at our disposal as well.


So to conclude, I am certain that Macromedia's Zorn project will like address this. Macromedia's original strategy was to create a new entry point into the Flash Platform for application developers coming from other backgrounds. There is really no reason why Flex should be a server in my mind. If it must stay a server, then I would tend to agree with the original poster. The price point is too high.

FLVs popping up everywhere

This is not going to be as exciting as it sounds.

I was watching the news (in Ottawa,Canada) last night with my girlfriend, and a friend of hers, and there was a report on a new shriners hospital that London, Ontario and Montreal are competing to get built.

Anyways in the report it showed a video that was made in support of the city of London, and bashing the Montreal site. The video was central to this weird story, but it was a web video, and they kept showing clips of it. It was an FLV video, playing in the Video player component.

So there we are sitting there watching this and I blurt out "That's an FLV! Woohoo!". Needless to say it was really geeky, but it is totally cool to see FLV videos becoming more and more common.

I also noticed that IGN is starting to do video previews in FLV format.

FLV Halo Vids

if you select, "Watch it Now" you will see they are FLVs.