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!

Deploying the application

Deploying the application

When you are finished developing an RIA, you need to deploy it so users of the application can access it. Flash applications can run in a variety of contexts, such as desktop applications or touchscreen kiosks. However, the most common deployment mechanism for Flash applications—and the one I focus on here—is running in a web browser.

Embed Flash in HTML

When running in a web browser, the Flash application is embedded in an HTML page. Flash and the HTML page can interact with each other using JavaScript. This interaction is most useful for the following purposes.

Flash detection: Before anyone browses to a Flash application, we need to ensure that the user has at least the minimum required version of Flash Player. There are a number of ways to accomplish this, all of which use HTML and JavaScript. The Flash Player Detection Kit is one excellent approach and is included in Flash Professional 8.

Configuration parameters to Flash: You can send static, fixed parameters from HTML to Flash to configure an application. For example, we can configure RbkCustom using a parameter set in HTML to show a warning dialog box every time it encounters an erroneous recipe:

<param name="flashVars" value="showRecipeErrors=false"> 

In addition, JavaScript can capture query string parameters sent dynamically to an HTML page and forward them to the Flash application as flashVars. RbkCustom supports the sharing of shoe configurations by e-mail using recipe and product query string parameters that the Flash application receives as flashVars.

These query string parameters cause RbkCustom to open a lovely orange, white, brown, and yellow Supercourt shoe (see Figure 2).

Supercourt shoe customized by query string parameters

Figure 2. Supercourt shoe customized by query string parameters

Accessing JavaScript APIs: Some third-party software packages offer JavaScript integration, but not direct Flash integration. Flash can invoke JavaScript functions to utilize these JavaScript APIs. For example, RbkCustom uses the HitBox analytics package from WebSideStory this way. Similar JavaScipt integration is available to a variety of competing analytics packages including Google Analytics and Fireclick. Other JavaScript APIs provide access to mapping, e-commerce, weather, and more.

Eolas patent: The Microsoft Internet Explorer browser was changed in early 2006 to require end users to explicitly click ActiveX controls in order to activate them. This effectively put a speed bump in front of Flash applications. Fortunately, there is an easy workaround: the <object> and <embed> tags used to position the Flash application within the HTML file must be rendered by JavaScript that is contained in a separate external file.

Test, test, and test

To increase the chances of deploying the software smoothly, your development team must test it several ways. The earlier you identify bugs, the more easily you can fix them. For this reason, we emphasize rigorous unit testing by our individual developers to ensure that each individual piece of code behaves as it should.

When functional subsystems of the application are complete, somebody unfamiliar with the application proceeds with testing. Developers know the system too well and often overlook basic problems. We use the open-source Bugzilla bug-tracking system to ensure that the bugs we find are fixed in a timely manner.

To test the performance of some critical systems, we establish minimum guidelines in the technical specification and then conduct performance testing to ensure that we have met those requirements.

Tame the server environments

We usually have two server environments for our projects, one for production deployment and one for development and testing. We make these environments as similar as possible: same number of servers, same hardware, same operating systems, and same software. The similarity of our testing platform gives us increased confidence that our production deployments will be smooth.

RbkCustom has two servers in each environment: a database server and a second, physical server computer that runs both the web server and application server software. Our production environment is hosted by VeriCenter and runs on leased servers. We operate the development environment ourselves. After investing a couple of days in the initial setup, our resident IT wizard spends a couple of hours each month maintaining the development environment.

Maintain version control

We manage all of our code using a version control system that helps us coordinate the work of multiple developers throughout the development process. Version control also helps us deploy our projects into production in a controlled manner.

Prior to deploying the project, we create a tag in the version control system that identifies the specific versions of all the files that are involved in the production deployment. This tag includes all the source code (ActionScript code and FLAs) required to regenerate the deployed SWFs. We only deploy tagged SWFs into production.

For RbkCustom, we have one set of tags for the consumer-facing Configurator application, a second set for the Administrative Tools application, and a third set for the Java application server code that supports them. The Configurator tags have the structure RBKCUSTOM_CONFIGURATOR_1_2_3. The first digit is the major version number, the second is the minor version number, and the third is the subversion number. Similarly the Administrative Tools tags are named in the pattern RBKCUSTOM_ADMINTOOLS_1_2_3, and the server code is tagged with names like RBKCUSTOM_SERVER_1_2_3.

This tagging serves two purposes. If a subsequent deployment causes problems, we can easily revert to the prior version using the prior tag. Sometimes we need to fix a deployed version after subsequent development has occurred that cannot be put into production. In this circumstance, we copy the source code that was used to generate the problematic production build, make changes to that code, and then compile new SWFs for immediate use in production.

A few rules of thumb can help you develop rich Internet applications effectively. Prepare yourself by thoroughly understanding the applications you are building. Creating specification documents and diagrams helps you systematically research your applications and share your knowledge with prospective end users and other team members.

Writing consistently formatted, well-documented, and well-structured code makes it easier for you to work with the code, and improves the support provided by compilers and editors. We minimize the amount of code we write by reusing existing code. This reuse improves both the efficiency of development and the quality of the code.

Flash presents unique development challenges because the binary FLA file format is difficult to share among developers. Two handy rules assist us in working with FLA files: engineers never edit FLAs, and we have at least one FLA per concurrent designer working on the project.

Before deploying your RIAs for public consumption, make sure they are ready for prime time. Write HTML and JavaScript containers so that they cooperate with Flash. Thoroughly test your applications to ensure that individual components behave properly, and that entire applications run as specified. Finally, use a version control system that gives you a security blanket that allows you to reactivate—and even modify—prior versions of the application in cases of emergencies.