Adobe Flash Professional CC 2014 v.13.0 - Manual (Page 866)

To the top
To the top
To the top
One of the best ways to perform error handling in ActionScript 2.0 is 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. For more
information on throwing custom errors, see the Error class in ActionScript 2.0 Language Reference. For more information on try-catch-finally
blocks, see try..catch..finally in ActionScript 2.0 Language Reference.
In ActionScript 3.0, use the flash.errors class to catch errors.
For more information, see “Handling synchronous errors in an application” in Programming ActionScript 3.0.
Organizing files and storing code
Consider the following guidelines before you start organizing files and storing code:
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, store your server-side code and files in a logical directory structure, similar to those in an ActionScript
package. 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 UI elements or other assets that perform similar functions.
Using the MVC design pattern
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 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. The returned data can be used for different interfaces (or views).
The view 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 the user 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 Professional interacting with other applications on the page), 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 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), the other parts of the process do not usually need modification, which reduces problems. 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.
An important reason to use the MVC 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 Professional interfaces, such as an interface for the web, one for Pocket PC, a version for cell phones, and perhaps an HTML
version that doesn’t use Flash Professional 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 Professional 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 Professional applications. If you build an application in which you need the additional complexity, consider using MVC to organize your work.
Creating secure applications
859