I’m running Jason through an introduction to the glory of Actionscript 2.0 Programming. About 10 minutes into it, I started to feel very bad for him when I realized that the event handling was going to seem really really weird when we get to that. Then, as I was working up the basic application architecture, I had flashbacks to the frustration of getting “Hello World” running in today’s environments…so much typing for so little gain! Or so it would seem at first…

These are today’s notes on the teaching experience, so I don’t forget.

What We’ve Done So Far

To now, Jason’s been working on understanding some MovieClip basics: properties, creating clips within a hierarchy, and how to catch events from them. He created a skeleton app with a couple of sliders controlling the scale of another movieclip. From here

Today’s Lesson: Naming, Architecture, and Classes aka How Dave Gets Organized

There’s a kind of naming grammar that I’m trying to define for my AS2.0 programming. I gave a first-pass explanation of what that meant: Good Names reflect a Good Categorization, which leads to Self-Documenting Code; once you define the System (categorization, labeling, assigning of responsibility, cooperation between entities), the names of methods, properties, classes, objects, and so forth should simply follow from that. That’s the ideal, at least…time to haul out Code Complete and take another pass through it, methinks.

For Architecture, I laid out a FLA file that simply imports a file called init.as, which is what actually does all the initialization. I use the FLA file only for named library elements for use with attachMovie(); basically, I treat the FLA is a big resource file.

We’ve talked about 4 main classes for now:

• Application, a global instance using the singleton pattern.

• Screen is essentially a manager class that abstracts the Stage by creating a single empty MovieClip to _root. We attach all our MovieClips to that clip, and provide methods for creating layers at runtime. It also uses singleton; there’s a single global instance.

• Debugger is my abstraction of the trace() command. The version we’re implementing here just wraps trace() for now, but eventually we’ll be adding a custom debug panel so we can get our messages from the Browser without using the Flash IDE’s debugger. Which. Is. Painfully. Slow. And. Awkward. To. Use.

• Clip is a wrapper for MovieClips. Its constructor accepts a parent MovieClip, which is retrieved from the Screen class, which is used to create a child MovieClip. We’re not extending the MovieClip class directly, choosing composition because I can then do things like var foo = new Clip(Screen.GetRoot()) and actually CREATE a movieclip. The downside is that you end up writing interface functions to the various movieclip properties unless you want to yoink mc directly. Clip is the base class for our components, and it will eventually encapsulate quite a bit of functionality. Other classes like Slider will extend this class directly, which is a good time to mention that this approach probably has some performance downside due to the way that class inheritance works in Flash Player. I’m not sure, though…will have to really study the FlashPlayer bytecode to see what it really does. Just one more thing to throw on the ToDoSomeday pile.

<

p>Notice that Event Management is missing? That’s because I’m not sure yet how I want to approach it in this architecture. In the past, I’ve wrapped the non-object oriented callback functions with code that re-establishes the object calling context. There’s at least three or four ways to do it, which is worthy of an article in itself.

Anyway, the result of today’s teaching is that I should firm up my notion of what a “grammar” should be. In addition to Code Complete, I have From Coder to Developer on my shelf too, unread, so that certainly should go into the reading queue. Jason is converting his creation code into the AS 2.0 syntax, which should keep him busy for a while :-)