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. For more information on data
validation, see
"Adding data validation and loading" on page
cross-domain policy files, see
on page 289
and
Projects and version control guidelines
Projects in Flash introduce a way for members on a team to work together on a single Flash
application or project. A project file remembers each of the files it contains, and lets you
incorporate some SourceSafe capabilities into your applications, which helps you keep backups of
modified files.
Note: Flash MX Professional 2004 does not support SourceSafe for version control on the
Macintosh.
"About allowing data access between cross-domain SWF files"
"About allowing cross-domain data loading" on page
124. For more information on
290.
Projects and version control guidelines
127
Need help?
Do you have a question about the FLASH MX 2004-USING ACTIONSCRIPT IN FLASH and is the answer not in the manual?
Questions and answers