Showcase and discover digital art at yex

Follow Design Stacks

Subscribe to our free newsletter to get all our latest tutorials and articles delivered directly to your inbox!

Guidelines for Creating Flash Applications

Guidelines for Creating Flash Applications

The best way to create different Flash applications depends on the application you create and the technology that you are using to build the application. You can refer to guidelines that can help make the application process easier. You also need to make several decisions.

An online application lets a user influence a website by interacting with it. For example, the application might collect information from the user (such as a username and password for a registration), information might be added to the site (such as in a forum), or the user might interact in real time with other site visitors (such as a chat room or interactive white board). Results from the server often appear in the SWF file, depending on the interaction. These examples are applications that involve the user and different kinds of server interaction. However, a website that does not use visitor information or data is not an application (for example, a portfolio, cartoon animation, or static informational site). Flash applications involve an interactive process between the user, a web application, and a server. The basic process is as follows:

  1. A user enters information into a SWF file.
  2. The information is converted into data.
  3. The data is formatted and sent to a web server.
  4. The information is collected by the web server and sent to an application server (for example, ColdFusion, PHP, or ASP).
  5. The data is processed and sent back to the web server.
  6. The web server sends the results to the SWF file.
  7. The SWF file receives the formatted data.

Your ActionScript processes the data so the application can use it. When you build an application, you must select a protocol for transferring data. The protocol alerts the application when data has been sent or received, in what format the data is transferred, and how it handles a server’s response. After data is received in the SWF file, it must be manipulated and formatted. If you use a protocol, you do not have to worry about data being in an unexpected format. When you are transferring data using name/value pairs, you can check how the data is formatted. You need to check that the data is formatted correctly, so you do not end up receiving XML formatted data and vice versa, so the SWF file knows what data to expect and work with.

Collecting and Formatting Data

Applications depend on user interaction with the SWF file. Frequently, it depends on the user entering data into forms, such as using combo boxes, buttons, text fields, sliders, and so on. You might create custom input devices, use the UI Components included with Flash, or download third-party components. You might collect data in a series of pages (sometimes each one is a screen) that are contained within the single SWF file, which the user submits to the server. Flash provides many ways you can enter and format data in Flash applications. This flexibility exists because of the capabilities you have with animation and creative control over the interface, and error checking and validation you can perform using ActionScript.

Using Flash to build forms to collect data has several benefits:

  • You have increased design control.
  • You have decreased or no need for page refreshing.
  • You can reuse common assets.

Tip: If you want to save information that you collect from the user, you can save it in a shared object on the user’s computer. Shared objects let you store data on a user’s computer, which is similar to using a cookie.

Sending and Processing Data

You must typically process information before you send it to the server, so it’s formatted in a way that the server understands. When the server receives the data, it can be manipulated in any number of ways and sent back to the SWF file in a format that it can accept, which can range from name-value pairs to complex objects.

Note: Your application server must have the MIME type of its output set to application/x-www-urlform-encoded. If that MIME type is missing, the result is usually unusable when it reaches Flash.

There are many ways to send data to a server and receive data using Flash. Table 1 shows you several options.

Table 1. Flash Data Sending and Receiving Options

Send Data Description
Sends name/value pairs to a server-side script for processing. LoadVars.send sends variables to a remote script and ignores any response. LoadVar.sendAndLoad sends name/value pairs to a server and loads or parses the response into a target LoadVars object.
Sends XML packets instead of name/value pairs, otherwise similar to LoadVars.
MovieClip.getURL Enables you to send variables from Flash to a frame or pop-up window.
Flash Remoting Enables you to exchange easily complex information between Flash and ColdFusion, ASP.NET, Java, and more. You can also use Flash Remoting to consume web services.
Web services Flash Professional 8 includes the WebServiceConnector component that enables you connect to remote web services, send and receive data, and bind results to components. This lets Flash developers quickly create Rich Internet Applications without having to write a single line of ActionScript code. It is also possible to consume remote web services using WebServiceClasses, which can require writing complex ActionScript.

Adding Data Validation and Loading

Try to validate any information you retrieve before you send that data to a server. This reduces strain on the remote server, because it does not handle as many requests when users do not fill in required fields. You should never solely rely on client-side validation in any application, so there must also be server-side validation.

Even if you build a simple registration or login form, check that the user has entered his or her name and password. Perform this validation before sending the request to the remote server-side script and waiting for a result. Do not rely only on server-side validation. If a user enters only a user name, the server-side script has to receive the request, validate the data being sent, and return an error message to the Flash application, stating that it requires both the user name and password. Likewise, if validation is performed only on the client side (within the SWF file), it might be possible for a user to hack the SWF file and manage to bypass the validation, and send data to your server in an attempt to post the bad data.

Client-side validation can be as simple as making sure that a form field has a length of at least one character, or that the user entered a numeric value and not a string. If you try to validate an e-mail address, for example, check that the text field in Flash isn’t empty and contains at least the at sign (@) and dot (.) characters. For the server-side validation, add more complex validation and check that the e-mail address belongs to a valid domain.

You must write ActionScript code to handle the data that loads into the SWF file from the server. After you finish loading data into a SWF file, the data can be accessed from that location. It’s important to use ActionScript to check whether the data has been fully loaded. You can use callback functionsor listeners to send a signal that the data has been loaded into the document.

When you load data, it can be formatted in several ways. You might load XML, and in this case, you must use the XML class methods and properties to parse the data and use it. If you use name-value pairs, the pairs turn into variables and you can manipulate them as variables.

You might receive data from a web service or from Flash Remoting. In both cases, you could receive complex data structures, such as arrays, objects, or record sets, which you must parse and bind appropriately.

Using Error Handling and Debugging

An important part of application development is expecting and handling errors. No matter how simple your application might seem, there are always users who manage to enter data or interact with the SWF file in an unexpected way. Your application needs to be robust enough that it can anticipate certain errors and handle them accordingly.

For example, if you expect users to enter a numeric value into a text field, check that the value is numeric before you try and store or manipulate the value using code. If the value is not numeric, it is likely that the code will fail or return an unexpected result because the application cannot handle this result. Even if the user enters the data in the proper data type, you might have to validate that the data is usable before processing it. For example, if you did not check the validity of an integer before trying to perform a mathematical function, you might discover that your code fails when you try to divide a number by zero, which returns the numerical constant Infinity.

One of the best ways to perform error handling in Flash 8 to use the try-catch-finally blocks that let you throw and catch custom errors. By creating custom error classes, you can reuse code throughout your application without having to rewrite error handling code.

Organizing Files and Storing Code

After you decide on a protocol for transferring data, you must consider how to organize your SWF files, their assets, and ActionScript. How you organize and execute your application depends greatly on its design, size, and requirements. There are guidelines to help your overall success. The following are some of the primary things you must consider before you start:

  • Do you divide the SWF file into multiple SWF files, and, if so, how should they interact?
  • What assets can you share across SWF files?
  • What files do you dynamically load?
  • How and where do you store ActionScript?

When you develop an application, try to store your server-side code and files in a logical directory structure, similar to those in an ActionScript 2.0 package. Try to arrange your code this way to keep it well organized and reduce the risk of the code being overwritten. For larger applications, encapsulate client-server communication and services in classes.

When you use classes, you benefit in the following ways:

  • You can reuse the code in more than one SWF file.
  • You can edit code in a central place, and update all SWF files by republishing them.
  • You can create a single API that can manipulate different user interface elements or other assets that perform similar functions.

Using the MVC Design Pattern

Many Flash developers implement the MVC (model, view, controller) design pattern when they build applications to separate the logic and data of the application from the user interface. This section defines how the design pattern works, and provides an overview of how and why you might use it for your Flash applications.

The MVC design pattern is used to separate the information, output, and data processing in the application. The application is divided into three elements: model, view, and controller; each element handles a different part of the process.

  • The model: This part of the MVC design pattern incorporates the data and rules of the application. Much of the application’s processing occurs in this part of the design pattern. The model also contains any components (such as CFCs, EJBs, and web services), and the database. Data returned is not formatted for the interface (or front end) of the application in this part of the process. This means that the returned data can be used for different interfaces (or views).
  • The view: This particular component of the pattern handles the front end of the application (the interface with which the user interacts), and renders the model’s contents. The interface specifies how the model’s data is presented and outputs the view for the user to use, and lets them access or manipulate the application’s data. If the model changes, the view updates to reflect those changes by either pushing or pulling data (sending or requesting data). If you create a hybrid web application (for example, one that includes Flash interacting with other applications on the page), you can consider the multiple interfaces as part of the view in the design pattern. The MVC design pattern supports handling a variety of views.
  • The controller: The controller handles the requirements of the model and view to process and display data, and typically contains a lot of code. It calls any part of the model, depending on user requests from the interface (or view), and contains code that’s specific to the application. Because this code is specific to the application, it is usually not reusable. However, the other components in the design pattern are reusable. The controller does not process or output any data, but it takes the request from the user and decides what part of the model or view components it needs to call, and determines where to send the data and what formatting is applied to the returned data. The controller ensures that views have access to parts of the model data that they must display. The controller typically transmits and responds to changes that involve the model and view.

Each part of the model is built as a self-contained component in the overall process. If you change one part of the model (for example, you might rework the interface), it reduces problems because the other parts of the process do not usually need modification. If your design pattern is created correctly, you can change the view without reworking the model or controller. If your application does not use MVC, making changes anywhere can cause a rippling effect across all your code, which requires many more changes than if you were using a specific design pattern.

There are other reasons why MVC is valuable for some applications. An important reason to use the pattern is to separate data and logic from the user interface. By separating these parts of the process, you can have several different graphical interfaces that use the same model and unformatted data. This means that you can use your application with different Flash interfaces. Perhaps the application has a Flash interface for the web, one for Pocket PC, a version for cell phones, and perhaps an HTML version that doesn’t use Flash at all. Separating data from the rest of the application can greatly reduce the time it takes to develop, test, and even update more than one client interface. Similarly, adding new front ends for the same application is easier if you have an existing model to use.

Only use MVC if you build a large or complex application, such as an e-commerce website or an e-learning application. Using the architecture requires planning and understanding how Flash and this design pattern work. Carefully consider how the different pieces interact with each other; this typically involves testing and debugging. When you use MVC, testing and debugging are more involved and difficult than in typical Flash applications. If you build an application in which you need the additional complexity, consider using MVC to organize your work.

Creating Secure Applications

Security is an important concern that you need to address when you build applications for the Internet. There are dishonest users who might try to hack your application, whether you build a small portal site where users can log in and read articles or a large e-commerce store. For this reason, there are several steps you can consider to secure your application.

You can post data to HTTPS for data that needs to be secured. You can encrypt values in Flash before sending them to a remote server to be processed. For example, you could find a Flash library that lets you encrypt your sensitive values using an MD5 hash to help distract casual prying eyes. However, this solution means that your server-side application code must decrypt the data after it is received or compare the encrypted version of the data against an encrypted password that is stored in a database to see if they match.

Caution: Never store any information or code in a SWF file that you don’t want users to see. It is easy to disassemble SWF files and view their contents using third-party software.

Perhaps the most obvious security measure for your application to add is a cross-domain policy, which prevents unauthorized domains from accessing your assets.