Joeflash’s Enigmacopaedia

Whilst doing some research on the mysterious MainTimeline class, I bumped into this really neat site which has all kinds of cool tutorials on using advanced math to craft Flash animations and effects. It’s also got some pretty decent beginner’s tutorials on the AS3 and Flash CS3 in general.

On their site, they indicate,

The website evolved from our ongoing project sponsored by the National Science Foundation and the Mathematical Association of America whose purpose is to empower educators in math and sciences to create web-based teaching materials using Adobe Flash. As a part of this project, we have been developing a collection of ActionScript 3 tutorials.

Wish I had this resource in High School…

In the process, we have dicovered that these tutorials are of interest to the general Flash developers’ community.

You betcha!

Check it out, it’s a gold mine.

Sean McSharry, co-author of Foundation Actionscript 3.0 with Flash CS3 and Flex, has issued a challenge to the community in giving out free copies of his book.

The challenge is: “Which is better and why: Flex or Flash?”

Since my answer was unexpectedly long-winded, I am reposting it here.

Let us assume by Flash we mean both the Flash CS3 IDE and its compiler, and by Flex we mean Flex Builder and its MXMLc compiler.

a) Different tools for different jobs. Neither is better.

From a design standpoint, Flash CS3 as an authoring environment is better suited toward designers creating interactive or “branding-oriented” gaming experiences which do not rely heavily on data enablement, due to the ability to create timeline animations using the design tools.

The Flash workflow can also be used to create component-enabled solutions using the CS3 components (fl.*), which results in a much lighter weight application, though this advantage will be less important when Flex 3 comes out with Persistent Framework Caching RSLs.

The Flex workflow, on the other hand, is a coding-centric environment for creating component-centric data-enabled applications using the Flex component framework (mx.*). Flash CS3-based projects can be data-enabled, but the Flex framework has more tools for large-scale data integration, and the CS3 component set lacks data-enabled components such as Tree or DataGrid.

So, tools for the job: do you want expressiveness and possibly light-weight components for your project, or do you want a component-centric large-scale data-enabled application?

b) Since both the Flash CS3 compiler and Flex Builder/MXMLC compiler both produce SWFs aimed at the Flash Runtime which are based upon the core ActionScript 3.0 language/Flash API, both are better.

Both workflows can be leveraged intelligently to create both visually engaging experiences and data-enabled large scale applications. Flex component-centric data-enabled applications can leverage Flash assets developed using a Flash workflow. In other words, Flash assists a Flex project.

Another workflow use-case scenario, is that the Flex workflow can be used to create “Flash”, i.e. pure ActionScript 3.0-based applications (flash.*) which are not component nor necessarily MVC-based, and does not require the use of the CS3 or the Flex component frameworks. An example of such an application would be a very complex interactive game or 3D simulation using PaperVision 3D, Sandy or a physics engine. Since as of Flex 3 the Flash-Flex workflow is be more closely integrated, both can be used in the workflow. In other words, Flex assisting the development of what might have previously been considered a “Flash” project.

In other words, an ActionScript 3.0-based project which is not dependant on either the CS3 component architecture, or the Flex component architecture, can use either Flash, or Flex, or both authoring environments in its creation.

In summary, the answer is: neither, and both, are better.

The latest addition to the Flex 101 series is now available on Community MX. In this tutorial we go into the Event subclasses — what they are, when and when not to use them, complete with examples. We describe when certain event classes are dispatched from component interactions, what classes to type to depending on use, and the event class package and inheritance structure in Flex 2.

There’s a great article on the O’Reilly DigitalMedia Blog about whether it is harder to learn AS2 or AS3, by Colin Moock.

As I commented on the Flash In TO forums, great article. Should go a long way to dispelling a lot of myths and apprehensions that beginners have about delving into AS3. Every college multimedia teacher and Flash instructor should give this to their students.

Although I do have to disagree with Moock on one fundamental point: you do need to teach basic OOP principles to beginners for them to get AS3. In AS2, you could get away with not learning about classes and objects until you used some of the Flash 7 API stuff like MovieClipLoader, and it was essential to do anything with Flash 8 API classes such as BitmapData or Tween.

But teaching OOP to beginners is not the daunting task most instructors or writers think it is. In fact, if you teach the basics of OOP — what is an object, what is a class, class inheritance — without getting into building custom classes, you’re doing beginners a huge favour, and will vastly increase their comprehension of the material. I usually find a Taxonomy/DNA metaphor works best when explaining OOP concepts.

I’ve taught an AS3 course the old way, without OOP until the end, and with a discussion of OOP right at the start, and I’ve found that students absorb the material much easier when exposed to the concept of objects and classes and inheritance right from the start. If you don’t teach them OOP at the very start, you’ll find there’s a barrier of comprehension when they try and increase their knowledege to an intermediate level (i.e. coding with advanced API functionality, but still on the timeline). And you can talk about OOP and still teach timeline-based coding.

The one argument I’ve heard arguing for AS2 being easier than AS3 are events, or more particularly the new event model. As an advanced ActionScripter, it’s heaven. But I have to agree, for the novice ActionScripter, events in AS3 do seem more complicated. Although, like I mentioned, I found that once students had a firm understanding of objects, classes and functions, the leap was not that large. What is crucial in the understanding of the Flash designer is whether they get function scope. Once they understand function scope, the benefits of the AS3 event listeners over AS2 event handlers is evident. The disadvantage of AS event handlers does not become obvious until the student moves into intermediate projects, and they wonder why their project isn’t working, because AS2 doesn’t use closed methods. It’s far harder to explain mx.utils.Delegate than to show them the AS3 event model IMO. So to the novice who is used to learning AS exclusively by doing, yes learning AS 3 may seem harder on the basis of the AS3 event model. But once they actually understand the fundamentals, the benefits of AS3 become obvious and this perceived barrier to learning is not so daunting.

Slightly OT, there are a few things that piss me off about AS3 I wish they’d continued from AS2, such as private constructors (though I understand the reasoning behind this move), and the lack of equivalent for the AS2 onReleaseOutside event. But the advances in so many other areas in AS3 far far outweigh these annoyances.

As Colin mentions, another great resource to convince would-be AS3-ers is Grant’s 50 Reasons ActionScript 3.0 Kicks Ass. :)

On the whole an excellent article.

Since early 2006 I’ve been authoring articles as a staff writer for Community MX, an online magazine and tutorial resource. It is a wonderful journey of discovery, which I came to define whist I was teaching at Humber College: that you only truly know what you know until you teach it, or in this case, write about it.

In each article, in each tutorial I write, I discover something new about what I do, programming with Adobe Flash Platform technologies. This is primarily because I need to be writing it from the perspective of someone who does not know what I know, so I cannot assume anything except a certain baseline of knowledge vaguely defined by the scope and difficulty rating of the article. That’s the challenge of technical writing: it makes me a better communicator and a better programmer.

In August of this year, I began writing a new series to test my knowledge of Flex fundamentals, and to share certain tricks I have picked up along the way. The series is called the Flex 101 series, currently up to Part 13, with many more to come.

Flex 101: Part 1 - Introducing Adobe Flex 2
Flex 101: Part 2 - What’s New In Flash Player 9
Flex 101: Part 3 - Using Flex Builder 2
Flex 101: Part 4 - Building in Design Mode
Flex 101: Part 5 - Using MXML

Flex 101: Part 6 - Components and Databinding
Flex 101: Part 7 - Events
Flex 101: Part 8 - AS3 in MXML
Flex 101: Part 9 - Custom MXML Components
Flex 101: Part 10 - Databinding Custom Components
Flex 101: Part 11 - The Event Class
Flex 101: Part 12 - Using the Flex 2 Debugger
Flex 101: Part 13 - Declaring Events in AS3

The first few articles in the series are free, with the rest available at $4 US. I hope you enjoy them as much as I did writing them!

This past September, a good friend and trusted colleague of mine David Stiller came to me with a puzzling debug message: the dreaded Error #2044. At the time I didn’t have much to tell him, until I encountered it myself a few weeks later. Now I just had to find an answer.

Unfortunately the Adobe LiveDocs runtime error listings are not particularly helpful in this regard. Judah’s blog post on the matter does give some additional info, but neither David or I had encountered this error because of a problem uploading a file, nor did the try-catch solution seem to fit in our case.

The solution at first glance seems simple: make sure that either the file the application is loading, uploading or the server-side script it is referencing, is actually there, and it is not corrupted. All of the above can result in a #2044 error.

But what if you want the error handled without the runtime debugger being in your face about it? In both David’s and my case, we wanted to ensure that if files referenced by application were not there or corrupted, that the user (i.e. QA person/developer) would get a nice alert popup instead of a runtime error — or worse, having the app fail silently.

You would expect that the following would handle the error:

But that doesn’t work. As the error implies, you need to use the IOErrorEvent class, not the ErrorEvent class.

That works. But hang on, we’re not quite done. If you use a custom event bubbling scheme, as I had done in a custom MVC framework I built for a client…

… and you dispatch an IOErrorEvent.IO_ERROR event, you also need to handle it all the way up the chain… or you’ll get the same runtime debugger error.

Once all possible dispatches of that event were handled as it bubbled all the way up through my Services and my Controller classes, my View showed a nice Alert with the error text, no debugger crashes.

So the lesson here is: anywhere you load a file, access a script, or load or upload any data of any kind whatsoever, in order to build a robust application, you can’t just think about handling the ErrorEvent.ERROR event: you also need to account for the IOErrorEvent.IO_ERROR event as well, or your application will have holes in it which may let slip by the dreaded Error #2044.