Screens Conventions

Screens let you organize and develop applications using a unique way of arranging assets, which can dramatically reduce the time to write an application. You can use screens with or without using the Timeline. The process that’s used to organize documents might seem logical to some developers, or make more sense for certain screen-based projects; for example, if you have to create an application that follows a linear process or has multiple states, such as one that requires server validation or multipart forms that a user must fill out and send to a database. You can also use classes that are built into screens to quickly and easily add additional functionality to your application.

Like the Behaviors guidelines, there are issues with how to organize and structure projects built with the screen-based authoring environment. Screens provide an intelligent and easy to use framework to control loading, persistence of data, and state using classes.

Some developers build applications with all their ActionScript code in a centralized location. Other designers and developers, usually newer to Flash, might use a more visual approach to writing a screens document.

Organizing Code for Screens

There are three places you can place code in a screen-based application:

• On the Timeline
• On screens and symbol instances
• In an external file

Because code can be placed in many different locations, you must consider the type of application you’re writing and what it requires in the way of ActionScript code. As with behaviors, you should use ActionScript consistently in screen-based applications.

Screens Conventions

The difference between screens and behaviors is that the ActionScript code that behaviors add is much more complex than most of the behaviors available for a regular FLA file. Screens are based on complex ActionScript code, so some of the code used for transitions and changing slides might be difficult to write yourself, in which case behaviors are useful and might outweigh any drawbacks.

You might use either behaviors or ActionScript that attaches directly to screens, combined with either a timeline or an external ActionScript file. Even if you attach code directly to a screen, it is more acceptable and easier to use than in regular FLA files for the following reasons:

• The code that attaches to screens when you use behaviors often doesn’t interact with other ActionScript code you might write—you can place behaviors there and you might not have to worry about editing the code further, which is ideal.
• The code placed directly on screens is easy to locate and view the hierarchy of, because of the Screen Outline pane. It is easy to quickly locate and select all of the screens that you might have attached ActionScript to, which is much easier than hunting down movie clip or button instances that have code attached to them.

If you use behaviors placed on screens (or other instances), remember to document the location on Frame 1 of the main Timeline. This is particularly important if you also place ActionScript on the Timeline. The following code is an example of the comment you might want to add to your FLA file on Frame 1:

/* ActionScript is placed on individual screens and directly 
on instances in addition to the code on the Timeline 
frame 1 of root screen).    ... */ 

New Flash users frequently like the visual approach of placing ActionScript code for a particular screen directly on an object. When you click the screen in the Screen Outline pane, you see the code that corresponds to the instance or the name of the function that’s called for that instance. This makes navigating an application and associated ActionScript code visual. It’s also easier to understand the hierarchy of the application while in the authoring environment, and much easier to find code attached to screens than it is to search for object instances that have code attached to them.

Using External ActionScript Files

You can organize your screen-based FLA file by writing external code and not having any code in the document. When you use external ActionScript code, try to keep most of it in external AS files to avoid complexity. Placing ActionScript code directly on screens is acceptable, but avoid placing ActionScript code on instances on the Stage.

You can create a class that extends the Form class. For example, you could write a class called MyForm. In the Property inspector, you would change the class name from mx.screens.Form to MyForm. The MyForm class would look similar to the following code:

class MyForm extends mx.screens.Form 
{ 
  function MyForm() 
  { 
    trace("constructor: "+this); 
  } 
}
   

Working with Other Structural Elements

A screen-based document, when published, is essentially a single movie clip on the first frame of a timeline. This movie clip contains a few classes that compile into the SWF file. These classes add additional file size to the published SWF file compared with a nonscreen-based SWF file. The contents load into this first frame by default, which might cause problems in some applications.

You can load content into a screen-based document as separate SWF files onto each screen to reduce the initial loading time. Load content when it is needed, and use runtime shared libraries when possible. This approach reduces what the user needs to download from the server, which reduces the time that the user must wait for content if they do not have to view each different part of the application.