In the world of code development, stuff changes all of the time. And when a programming language makes a big change everyone using that language suddenly gets reduced from being fluent to, say, a seven-year-old who is recovering from having just fallen from a tree. You brain hurts all of the time and you can't remember where you left your shoes or how to tie them.
In the Adobe Flash world I have lived through a few of these large changes. For example, Flash used to have a coding language under it that was, well, fairly silly at best. But it was the most interactive language for client-side web development and so I learned it. From that language (I believe this would be back in Flash 3 or maybe 4) ActionScript was born. ActionScript (later referred to as ActionScript 1) added some standardization but also let you write code the older, sillier way. But it was a syntax move in the right direction (they added something called "dot notation" which pretended to be object oriented.) Then along came ActionScript 2.0 which was a move from "dot notation" to a slightly more "object oriented" reality.
Since ActionScript 2.0 a Flash Developer had the luxury of writing code that adhered (mostly) to object oriented development techniques but
could also write completely valid AS 2.0 code that had far less to do with Object Oriented Programming (OOP.)
Now we are in ActionScript version 3.0 and that is also quite similar to AS 2.0 but the OOP-side of AS 3.0 is far closer to OOP than flash has ever been. As a result, people attempting to learn AS 3.0 are searching the web for examples of how to build Flash content using AS 3.0 and are
running into a mix of OOP techniques and non-OOP approaches. I say OOP approached because Object Oriented Programming to many people comes down to meaning "I built a bunch of classes" but that is a very rudimentary understanding of what OOP is. Saying OOP is "building a bunch of classes" is like saying web accessibility is "
adding ALT properties to IMG tags in HTML." To a degree that is true, but that doesn't begin to come close to explaining what 508 web accessibility really is, how it works and all that it encompasses.
If you have made the jump from "timeline" code in flash to "class-based" code then you have surmounted the first hurdle. Again, because you could write non-OOP code in AS 2.0 making the jump into AS 3.0 was like pulling off a motorcycle trick across the wide side of the Grand Canyon. Having at least created classes in AS 2.0 is like having a bigger more powerful bike and simply jumping across, say, the Mississippi River: still scary but you can at least see the other side without squinting.
So, if you have made the first jump (building classes) then here is a hint to understanding some of the rest of the jump.
Now, I don't have the time to help outline all of the new classes or any new syntax here. That is an unavoidable effort at scratching around and memorizing a new framework / code-base. There are no shortcuts to that, but I can say that tools like FlashDevelop can help you find your way much faster since FlashDevelop will add your import statements to your custom classes. The bigger (or at least equally as large) hurdle in making the AS 3.0 jump is understanding the most appropriate approach to coding your classes and how the timeline (or visuals) relates to that code. Most folks don't know how to avoid writing code in the timeline and are searching desperately for what the right best approach might be.
The amazing part about OOP is that there are a number of excellent approaches to organizing your coding effort, but I am going to briefly explain one of the older techniques that remain valid to this day.
Let's look at the Model-View-Controller (MVC) approach to development.
Model-View-Controller is about cleanly separating the three parts of a software development experience: The interface (View), the common utility logic (Model), and the instance of the application and it's controlling of the interface and the utility logic (Controller.) Let's go through each of the three parts.
The View:In the Flash world, the View is the "front-end" interface where the user is listening, watching, talking, typing and clicking. In the MVC approach the interface would be planned appropriately to break apart the interface into various logical parts: video player, audio player, text presentation, lists, editing forms, common game controls, etc.
In the various Views you might create animations that are completely controlled in code by class utilities like "Tweener" which can be told to animate something from one frame to another specific frame and notify you when that animation is complete. That sort of "control" code is written into the Controller to manipulate various states of a View.
The Model:The Model is where we put the logic of the application. I previously referred to it as common utility logic because I want to separate in your mind the code that animates the state of an application and the code that provides common services in a very interface-agnostic utilitarian manner. Said another way, you might create a rich internet application (RIA) in flash that retrieves information from an RSS feed for displaying in the browser. In this architecture and approach you would write an interface-agnostic utilitarian class that simply gets that data and hands it over as a result. If you write a class to retrieve RSS feed data (XML) and hand back the results and you keep that separate from any interaction with the presentation / interface / View then you can reuse that code (Model utility class) in future projects that implement different interfaces.
Your custom common utility classes, any other classes you are using in Flash, or classes from some third party are typically referred to as part of the Model part of the MVC approach.
The Controller:The Controller as you can imagine is also comprised of code. In the AS 2.0 world the controller was typically just a number of functions in the lowest level "_root" timeline in flash. In the AS 3.0 world inside the Flash paradigm of development, the Controller is the Document Class associated with the lowest level timeline FLA. Inside the Flash project properties you can now assign a class to basically be the code that the SWF calls first before anything else. It is inside the Document Class where all of the action starts.
The document class could create an instance from the View (some interface, possibly a login), animate it into visibility and link up code that "Controls" (or watches) for clicks from that Interface, which might create instances of common utility classes from the Model to perform some function. Let's look at one example of what that interaction might look like.
Going back to the previous example, let's imagine someone arrives at your RSS Viewer RIA. Once the SWF loads it would call the code in your Controller (Document class.) The Controller would animate in a presentation of the RSS List View (an Interface element from the library) and then wire-up the list to code, in real time (animate and setup the View for interaction): The Controller might use a class from the Model to get the list of RSS Feeds and then populate the View with that information. The Controller might dynamically associate a mouse-click event with the list.
Let's imagine that the user mouse-clicks on an RSS Feed item presented in the RSS list View. The Controller would be notified of that click (because it wired it up a moment ago) and would then need to present the RSS Feed Reader View (yet another View inside the View part of the MVC approach.) Before it does this you might have written the Controller to clean up the List View by unloading arrays or removing event watchers that are no longer needed.
Once the RSS Reader View was ready, the Controller would wire up that view for scrolling and various kinds of mouse-click interactions.
This is the basic MVC approach to OOP in AS 3.0 under Flash CS3 and CS4. As you can see, it is all about events managed by the Controller resulting in the presentation of new Views and the Controller management of their interactions via Controller code as well as the Controller using other utility classes from the Model but it is all about events.
Naturally you are going to want to get really familiar with the ActionScript 3.0 event model: how do you code for events, how do you handle asynchronous events, how do you author asynchronous events in your custom classes, what are the more common View related events that the Controller needs to manager (for example: setting up a View, managing interactions a user experiences with a View, cleaning up after a View no longer needed in that moment, etc.)
Well, that is MVC and I hope it wraps some context around knowing how to explore AS 3.0 and what sort of architecture and approach decisions you might want to make inyour new coding projects. Have fun and build cool stuff!
