As Flash MX becomes an integral part of enterprise applications and rich-media interfaces, developers must learn to incorporate Flash into their established software development processes. A few years ago, Flash’s idiosyncrasies would have required staffing a whole new position to fill gaps in both design and development, but since then, Flash has evolved into a platform that allows designers and developers to work more autonomously, in a fashion more consistent with traditional web or desktop applications. But maintaining efficiency and scalability in rich-client development entails introducing your developers to a new authoring model.
This article compares Flash MX development to familiar traditional environments like .NET, Visual Basic and Java. You’ll see how the structure of Flash movies and the nature of the Flash IDE require that developers adopt a new mindset and a few new techniques.
Nonlinear Time-based Authoring Flash borrows its overall structure from film. Flash movies consist of items placed on a timeline separated into frames. When played by themselves, without controlling code, Flash movies play exactly like films?one frame after another, from beginning to end.
To create a Flash movie, authors place elements onto the timeline in layers. Layers correspond to a z-order, so authors can control whether elements appear above or below other elements. The layers can also function as segments within the timeline corresponding to different “screens” of an application. Figure 1 depicts a layered timeline split into several logical segments, with keyframes defining changes on individual timeline layers.
Modern desktop applications rely on an event-based model, where the program reacts to user input. In event-based programs, GUI components such as buttons and list boxes generate events, and the program responds accordingly. Since most web applications rely on middleware like COM+ or EJB, they are object-based rather than event-based. Events in a browser are converted into request-response communications, with application directives passed through an interface language like COM to an object request broker.
One challenge facing developers is how to manage code inside Flash movies. Developers programming Flash combine these two methodologies in the context of the Flash timeline. Buttons and other interface elements can generate events to which ActionScript methods may respond. In addition, the timeline itself generates events, such as when the playback head enters a frame. Developers can attach their code to objects such as Movie Clips and to timeline frames. As a result, interface elements, timeline organization, and code commingle in the Flash IDE, which can wreak havoc on code manageability. Figure 2 and Figure 3 show actions attached to both a timelime keyframe and to a Movie Clip tracked as a button.
Always work from the perspective that the Flash code you develop will need to integrate with design and animation elements later. Jumbling code and design is the greatest threat to a handoff-style workflow between artists and developers. You should divorce core code from the interface and the timeline as much as possible. When user actions or the system invoke application logic, make those calls as simple as possible.
One of the best ways to avoid confusing code and code scope in nested layers of Flash movies is simply to move all core application code to one location in the movie?typically to a single frame, in the movie root or to a layer just off of the root. Doing this allows developers to author code-only Flash movies independently from animations, navigation, or other interface elements. Moving core logic away from timeline elements also averts most of the problems associated with code scope and timeline organization.
Consider a Flash application that includes a member login function. Even when application developers don’t know how or where login GUI widgets will appear in the interface, they can still code an ActionScript method that facilitates the login process by abstracting the process to accept a user name and password. The following partial method takes login parameters and configures an XML HTTP request to process the login.
_global.login = function (strScreenname, strPassword) { var request = new XML(""); request.firstChild.attributes.screenname = strScreenname; request.firstChild.attributes.password = strPassword; request.sendAndLoad("http://localhost/login"); ... }
Flash offers several ways to invoke methods such as the one shown above. The simplest is to call the method directly within a frame action. When the playback head enters the frame, the player interprets and executes the script; more commonly, user or system changes invoke application logic.
Flash MX offers an improved event model for user actions closely resembling that of Visual Basic or Java. To delegate actions to events, the developer could first load the handler code inside the movie root or in an identifiable layer off the main timeline such as _root.Membership. Flash MX even lets you declare an object, function, or variable as global using the _global declaration as shown above. An event action, perhaps from a button click that initiates the login process, could then invoke this method from any timeline and scope, as long as an inner scope identifier doesn’t take precedence.
Flash MX’s new event model also lets developers define event handlers using relative or absolute references to the object. For example, the following code handles a button click and invokes the login method.
To handle user and system actions, Flash MX offers new listener objects. Like Java 1.1 delegation, Flash notifies listeners when requested events fire. Flash listeners support multicasting, where one event invokes several actions. The following code would cause a login validation every time the movie stage resizes.
myListener = new Object(); myListener.onResize = login(myLayer.strScreenname, myLayer.strPassword) Stage.addListener(myListener);
One practice that carries over to Flash from traditional development is the ability to move code out of the application for easier change and version management.
Flash supports a server-side #include syntax for importing the contents of an external flat file, which means you can easily way keep code under source control and outside of Flash. For example, if the login() function shown above were defined in an external text file called Membership.as, the Flash movie could include it with the following line of code:
#include "Membership.as"
In addition to application logic, you can use external files to define application settings. Rather than republishing your Flash movies every time a server configuration or address changes, place such settings in an external file that a Flash movie reads and parses each time it runs. Often a Flash movie needs to communicate with server applications whose URIs might change, for example when moved from server to server. To avoid the risks of republishing for deployment, place the URIs in XML or plain text files that you can edit easily. Then load and read these settings in the first frame of your movie. Flash MX provides a special preprocessor-style command, #initclip, to identify ActionScript code blocks that the runtime should interpret first.
#initclip 0 var settings = new XML("settings.xml"); var1 = settings.firstChild.nodeValue; … #endinitclip
Strategy 3: Abstract Software Subsystems Component-based software like EJBs and COM provide abstracted, standardized, reusable interfaces to applications. Components change the focus of application development from writing code line-by-line to one primarily concerned with assembling larger building blocks. Component software models have proven to save considerable time in traditional application development.
Flash offers effective ways to use software more objectively. For the first time, Flash MX offers true object support, including class inheritance. Flash MX also supports components. Unlike conventional software components, Flash components can contain either pure code or a combination of code and interface elements. Component authoring is complex enough to warrant a lengthy description of its own, but essentially, a Flash component is a Movie Clip object that developers can “register” into a namespace. New objects or clips created with a registered component namespace automatically bind to the corresponding object. In addition, the Flash MX IDE gives developers design-time control over component properties, much as ActiveX objects do for VB or VC++. The following code shows how you could create a binding for a set of membership routines such as the login method shown earlier above.
#initclip 1 function MemberManager() { ... } // object constructor // inherit MovieClip MemberManager.prototype = new MovieClip(); MemberManager.prototype.login = function (strScreenname, strPassword) { ... }Object.RegisterClass("Membership", MemberManager); #endinitclip
The Object.RegisterClass() statement lets you invoke MemberManager objects using the binding name Membership?just as you would use a COM ProgId or an EJB moniker.
var myMemberMan = new MemberManager();
Flash components are convenient, but they still don’t offer the security and ease of transport that DLLs and EJBs do. While the published .swf format isn’t as secure as compiled byte code, it is a good substitute. Consider publishing ActionScript-only movies that register ActionScript or MovieClip classes, then load these published movies into a layer of any Flash movie to simulate a compiled software component.
Final Thoughts As Flash has evolved, it has adopted features from conventional development methodologies. With ECMAScript compliance and true object support, traditional application and web developers Flash are finding ActionScript increasingly accessible. Traditional developers excel at Flash development when they learn to treat it as just another tool for creating the same kinds of applications they create in other languages and environments. While Windows DNA or Java developers need to gain a considerable amount of Flash-specific coding knowledge to master Flash, following the techniques and best practices for time-based media development shown in this article will help make Flash more accessible.
About Our Editorial Process
At DevX, we’re dedicated to tech entrepreneurship. Our team closely follows industry shifts, new products, AI breakthroughs, technology trends, and funding announcements. Articles undergo thorough editing to ensure accuracy and clarity, reflecting DevX’s style and supporting entrepreneurs in the tech sphere.
Charlie has over a decade of experience in website administration and technology management. As the site admin, he oversees all technical aspects of running a high-traffic online platform, ensuring optimal performance, security, and user experience.
