Using an Open Source Workflow (Open Source Flash Development) Part 3

Building the application

In the “Creating a Flash application with FlashDevelop” section, you reviewed how to set up your project options to enable building from within FlashDevelop.

From the FlashDevelop toolbar, change the pull-down menu on the right from Debug to Release. Now, press F5, or select the Project > Test Movie menu option. This will build the application and launch it in your web browser. You should now be looking at a fully working Recipe Viewer application, as shown in Figure 4-10.

The Flex-based Recipe Viewer application running in a web browser

Figure 4-10. The Flex-based Recipe Viewer application running in a web browser

Building with Ant

The build script for the Flex-based application is nearly identical to the ActionScript 3 Flash-based version. The only change necessary is to point the compiler to the main .mxml file instead of the main ActionScript file:

tmpeeee-97_thumb[2][2]


 

 

tmpeeee-98_thumb[2][2]

Upon issuing the same build command of ant buildAndCopy, you should see output similar to the following:

tmpeeee-99_thumb[2][2]

You’ve now seen how to create two different types of ActionScript 3 applications using FlashDevelop and the Flex SDK. The rest of this topic will focus on using open source tools to create an ActionScript 2-based project.

ActionScript 2 development

ActionScript 2 has been around a lot longer than ActionScript 3, and the tools to support it are oftentimes more mature or complete because of that. This section of the topic will walk you through using Eclipse, ASDT, Ant, and swfmill to create an application.

Once you have an art asset from the designer in the form of a SWF to work with, you have two options for how to use it in an ActionScript 2-based application:

■    You could compile your code directly into the SWF from the designer. This will give you the benefit of a less complex application to write and a slightly faster download time.

■    You could compile your application into a separate SWF and load it at runtime. This gives the benefit that you can easily swap out art assets without rebuilding your application.

For the main application’s art asset, we will use the first option. Later in this topic, I will show you how to use the other option. However, the method of generating the SWF does not dictate how you must load it, and either way will work.

When I talk about compiling your code directly into the SWF delivered from the designer, I’m not talking about the way the Flash IDE works. In that environment, the developer would open the .fla file and add code and publish from there. In this scheme, the designer is the only one who works in the Flash IDE, publishing a SWF and handing it off. The developer then writes the code in Eclipse and compiles it into the SWF from the designer using MTASC. This removes issues with the traditional Flash development workflow where multiple people want to modify the same binary .fla file at the same time during development.

Adding the asset to your project

If you followed along, you can launch Eclipse and open that project.

Now, create a new folder in your project by right-clicking the project name and selecting New > Other; a dialog box will appear. From this dialog box, select the Folder option under the General section. Name the folder Assets, and click the Finish button. Now, copy the mocked-up SWF I talked about earlier in the topic into that directory. Once you’ve done this, you should have a directory structure similar to Figure 4-11 in your Eclipse Navigator.

The Eclipse Navigator after adding your asset to the project

Figure 4-11. The Eclipse Navigator after adding your asset to the project

Modifying the build process

You’ve already seen an Ant build script for the ActionScript 3 version of the program, and you’ve also created a simple ActionScript 2 build script.The only significant difference between the ActionScript 3 build script and the script for the ActionScript 2 version of the Recipe Viewer application is the method of compiling. Whereas you used the mxmlc task before, you will use the MTASC task here.

If you have a build.xml file,you can use that as a base for this section.

tmpeeee-101_thumb[2][2]

For a detailed explanation of this build script.

Right now, the MTASC compiler doesn’t know anything about the art asset you’ve added. You need to tell it how to build the application and use RecipeViewer.swf as a base. To do this, you need to edit the build target in the build script so it looks like the following:

tmpeeee-102_thumb[2][2]

You made the following modifications:

1.    First, you removed the header="800:600:30" parameter. This is required only when you want MTASC to create the SWF from scratch. Now, the dimensions and frame rate of the resulting SWF will be taken from the mocked-up RecipeViewer.swf.

2.    Then you modified the SWF line and pointed it to the premade SWF file. This is the file that will be read in when building.

3.    Lastly, you added an out parameter. This specifies where the resulting SWF should be placed. If you now execute the build task, you should get output similar to the following:

tmpeeee-103_thumb[2][2]

If you now double-click RecipeViewer.swf inside your bin folder, the application will launch. It should look exactly like the mocked-up interface (Figure 4-1) with the addition of a small FPS meter from Xray.

As you can see, the graphics from the input SWF appear, but your code was also run (evidenced by the Xray meter appearing). What happened is MTASC compiled your code and then embedded it within a copy of the RecipeViewer.swf file. In this manner, you can inject code into static SWF content.

Reading a list of recipes

Now that you have some graphical elements loading with your code, it’s time to make it do something useful. The first step is to add support for reading a list of recipes from an XML file and storing the results, and that’s what you’ll do over the next several sections.

Copying the input file

First you need to set up your build script so that it will copy your XML file to a location that the application will be able to find when it runs. So, open your build.xml file, and find the buildAndCopy target. Add a <copy> command to copy recipes.xml to your bin directory. Your resulting buildAndCopy target should look like the following:

tmpeeee-104_thumb[2][2]

 

tmpeeee-105_thumb[2][2]

Although it may be easier to simply create the XML file in the bin directory in the first place, this is a bad practice. You should consider anything in the bin directory as temporary and eligible to be deleted between builds. By using Ant to copy the XML file, you also open the possibility of retrieving it from a remote location through FTP, HTTP, or even a version control system, allowing content producers to author it outside your development environment.

When dealing with static XML files in a project, especially when those files are created by others, it can be helpful to create an XML schema to validate the document. By doing this, you can help to eliminate a source of bugs and save time in the long run. If you want to do this, you can use the xmlvalidate Ant task to automatically validate the XML when you build your application. You can read more about xmlvalidate at the Ant website:

http://ant.apache.org/manual/OptionalTasks/xmlvalidate.html

Create a Recipe class

Before you load that XML file, you need somewhere to store the information. Let’s create a class called Recipe to keep the various attributes associated with a recipe.

Create the Recipe class

1.    Right-click the recipeviewer directory in the Eclipse Navigator, and select New > ActionScript Class.

2.    Enter a class name of Recipe. Make sure the package is correctly set to com.friendsofed. recipeviewer.

3.    Click the Finish button.

A new ActionScript file called Recipe.as will be displayed in the main text edit window. You’ll need to know the preparation time, name, description, ingredient list, and directions to make the recipe. Create private variables to hold the various pieces of data.

tmpeeee-106_thumb[2][2]

Now, let’s use an ASDT feature to generate some getter and setter functions for all the members except ingredientList. For ingredientList, you will just automatically generate a getter function. To do this, select the Source > Generate Getters and Setters menu option. A dialog box like Figure 4-12 will appear. Select the check boxes to select the methods you want to generate, and click the OK button.

The Generate Getters and Setters dialog box is used to automatically create some boilerplate methods.

Figure 4-12. The Generate Getters and Setters dialog box is used to automatically create some boilerplate methods.

Once you do that, the following nine methods will be generated for you:

tmpeeee-108_thumb[2][2]

 

tmpeeee-109_thumb[2][2]

To handle ingredients, initialize the ingredientList array in the constructor, and create an addIngredient method:

tmpeeee-110_thumb[2][2]

Now save the file and make sure there are no syntax errors in your Problems panel at the bottom of Eclipse that may have been caused by a typo or other error.

Next post:

Previous post: