Setting Up a Flash Development Sandbox: Part 2

Setting Up a Flash Development Sandbox: Part 2: "

This is part 2 of how to set up a Flash Development Sandbox. You can read part 1 here. In this tutorial we’re going to go over how to set up a local testing environment, look at the Debugger, Flex Builder’s Profiler, talk about project organization, and setting up/using AS Docs.

Step 1 – Choosing a AMP (Apache MySQL and PHP) Solution

For as long as I can remember, I have always worked in a LAMP (Linux, Apache, MySQL, PHP) environment. This is probably one of the most common sever setups because it’s free, open source, and easy to set up. One of the goals of setting up my own development sandbox is to have a local server on my computer that matches the production environment. We’re going to cover two solutions which will get you up and running quickly. If you’re using a PC, go to Step 2. If you’re using a Mac, go to Step 3.

Step 2 – PC Setup (XAMP)

Installing AMP is as easy as downloading the pre-bundled package XAMP and installing it. Here are a few of the things I did when installing the program.

I used the standard install location..

..with the default install options.

Looks like everything installed correctly.

After I installed XAMP, I used the control panel to activate the server and I was up and running. You can follow these instructions as well.

It’s important to note that you’ll be placing all of your web files inside of your XAMP directory here \xampp\htdocs. Make sure you pay attention to where you’ve installed XAMP.

Step 3 – Mac Setup

There are many ways you can setup your mac to run a local server. Luckily, the basic setup is built into the OS. Just go into the “System Preferences” then look for “Sharing” under “Internet & Network”.

Once you’re in the Sharing panel, click on the Web Sharing option and Apache is started for you.

Pay attention to the personal website url you are given. This is what you’ll need as your base url when configuring Flex Builder to work with your local server. In my case it’s http://10.0.1.4/~jessefreeman/. Here’s a trick though, you can replace your ip address with “localhost”. Therefore, the url I will use for the remainder of this tutorial will be http://localhost/~jessefreeman.

If you want to set up PHP and MySQL I would suggest following this tutorial.

If you need PHP and MySQL but are not comfortable with the command line, you can check out this all-in-one software package similar to XAMP called MAMP. I reviewed it when making this tutorial and I wasn’t happy with where they placed the htdocs directory. By using the built in Apache you can keep all of your files in your Sites folder, this way they’re linked directly to your user account and in a simple place to back up. MAMP keeps the files in the main Library directory, a place I don’t really want to be working in. It’s important that you pick the solution that works best for you.

Step 4 – Setting Up Our Site

In this tutorial we only touch on getting Apache up and running. As I mentioned before, there are many things you can do to customize your local server. In this step we’re going to create an empty folder called “HelloWorld” in our htdocs folder.

On a PC:

c:\xampp\htdocs

On a Mac:

/users/YOUR-USER-NAME/Sites

This HelloWorld folder will contain our Flash site and become the base url for us to use when testing/debugging our ActionScript project. As you start to add more projects to Flex Builder you’ll want to add additional directories to test each project. Let’s look at how we can configure Flex Builder to move our swf and supporting assets over to our host folder.

Step 5 – Configure Flex Builder for Local Testing

We want to tell Flex Builder how to move files to our local server so we’ll need to right-click on our HelloWorld project and select “Properties”. From there, go to the “ActionScript Build Path” section. Here we can change the path to the Output folder. Click “Browse” and find the directory on your computer where we created our empty HelloWorld folder.

You’ll notice that the “bin-debug” folder now has a icon with an arrow on it. This indicates that the directory is linked outside of the current workspace.

Now we’re going to want to modify our Run. If you go to Run (in the menu) > Run > Other…, you’ll be able to configure the URL that gets launched when testing your project. Select the HelloWorld Run from under the Flex Application drop down.

Now if you look at the URL or path to launch, you’ll see that the default url matches the file path that you chose in the output path. This will work, but in order to test this from the local server we’re going to need to request it through our localhost. Remember when we set up Apache, we we given a base url that represented our localhost url? On the PC it was http://localhost and on the mac it was http://localhost/~username/. We’re going to want to update the URLs here by unchecking “Use defaults” and putting in the path to your HelloWorld folder:

It’s important to note that one of the main reasons we run our ActionScript project through Apache and not directly from the file off the computer is to expose any server side security errors or production issues before they pop up when you try to launch the site. By recreating our hosting environment we can insure that our file will run exactly how it would on the live server. This will cut down hours of frustration when trying to get a site out the door. Plus, when you need to start adding in PHP or other server side scripting you can test it locally and not be dependent on the production server.

Make sure you hit “Apply”, then try to Run or Debug to see if it worked. Now you should see the same page open up but this time it’s running from Apache locally on your computer.

Step 6 – SVN Organization

Keeping your SVN repository organized is very important, especially when working in a team of developers or making your projects open source. First up, we’re going to take a quick look at my personal svn repo. Google Code allows use to explore any repo through the website so let’s open up Flashbum’s Cardboard Box and poke around the folder structure.

As you can see, I keep all my projects in the trunk of the repo. The trunk represents working copies of code. Next, I break up each project based on its type: “experiments”, “sandboxes”, and “sites”. Let me go over each directory and what they’re meant for:

Experiments represents the bulk of what I create. To me, an experiment is a stand alone application with a clear end result. I actually organize these into sub folders such as 3d, Camo2, games, etc. An experiment is anything as simple as a proof of concept to a fully working program. The only difference is that experiments are not fully functional sites. Generally, my sites are derivatives of these experiments.

Sandboxes are projects where I test code. They’re kind of like experiments, but they generally have no direction or end product. Most of the time they don’t even fully work. I use sandboxes a lot when I’m learning a new technique or trying to understand someone else’s code.

Sites are straight forward and are fully realized projects that will be hosted on a server. In most cases, if a site is big enough, you may have an entire repo exclusively dedicated to it. For my personal stuff, I just keep it all mixed together with my other code.

You’re free to organize your directory however you see fit. This setup works nicely for me and keeping things organized based on the project’s end result helps others get a basic idea of what they can expect when checking anything out. The goal in a public SVN repository it to allow others to quickly find what they’re looking for without knowing much about your own personal way of categorizing/organizing your projects.

Now let’s take a look at my framework, Flash Camouflage. This is a Library of code on a public open source SVN repo . You can explore the entire repo by clicking here.

As you can see this is structured a little differently. There is a clear emphasis on the tags directory and the trunk represents the entire project. This is also similar to how I would set up a large Flash site in its own repo. Earlier I mentioned the notion of Tags and Branches but let’s do a recap:

Tags represent a particular revision of the code in a repository. This is used to mark stable builds and is easier to checkout than a particular revision number.

Branches represent a specific direction of development. If you have a new feature or refactoring you want to do without disturbing other developers it would go in a branch. Also, the branches folder is a great place to give each of your developers their own area to contribute to the project. When their changes are stable they can merge them back into the trunk.

It’s important to understand the ramifications of code changes to a library that is shared by several developers or several hundred developers. That’s why using tags and branches is crucial to the stability of a project. As you can see in Flash Camo, I’ve tagged each version of the Framework. Large number increments such as 1 or 2 mark major differences in the code base. Minor revisions such as 1.x.x represent smaller incremental changes.

When dealing with active projects from other developers it’s important to build your project off a particular tag or revision. It helps to know what build you are working off when you want to upgrade by switching to a new version. In the next step we’ll go over how to switch between branches and tags in Flex Builder.

Step 7 – Switching To a Branch/Tag

From time to time you may need to switch over to a new tag in a svn repo. Flex Builder makes this really easy with the built in support for version control. Since I wrote part 1 of this tutorial, I have released a new version of Flash Camouflage. we’re going to switch our FlashCamo 2.0 Beta to the new 2.1 Beta tag.

To get started, right click on the FlashCamo2 project we created in part 1 . Go down to the team option in the contextual menu and select Switch to another Branch/Tag/Revision.

By now you should be looking at a window with the project’s svn checkout path. If you know the url, you can enter it by hand or click Select to find it. Let’s hit select.

Now you’re looking at the Repository Browser. From here you’ll see the contents of your current check out depth, or you can click on Root and explore the full svn repo. Click Root > tags > FlashCamo_2.1_beta and hit OK.

Now when you return to the Switch window the “To URL” should be filled in.

http://flash-camouflage.googlecode.com/svn/tags/FlashCamo_2.1_beta

Now you can press “OK” to have Flex Builder replace your current checkout with the new contents from the 2.1 tag.

When you get back to your workspace you may see the following error:

When switching between tags or branches, some of the new classes may not be selected in the project’s source path. This only happens when we’re dealing with Flex Library Projects. You can fix this by right-clicking on the project, in this case “FlashCamo2″ and selecting Properties. Then go to the Flex Library Build Path. If you scroll around you’ll notice that some of the new classes are not checked off.

To quickly fix this, press “Select All” then hit “OK”. This will rebuild the Library with all the selected classes. Sometimes you may not want to use all the classes, especially if they have an error or dependency on another library you may not have. By being able to select only the classes you need, you’re able to custom build the SWC for your needs. Flash Camo needs all of these classes, so make sure you’ve selected them and are error free in your workspace.

Step 8 – Creating Classes

Now we’re ready to start adding to our HelloWorld project. Flex Builder has a great wizard for creating Classes. You can pull it up by right-clicking on your src folder in HelloWorld and selecting New > ActionScript Class.

Here we’re going to create a “DemoLabelComponent” and put it into a com.tutsplus.flash.components package. In the next step I’ll talk about package organization, but before you hit OK you’ll want to click on the “Superclass Browse” button. This is a great feature in Flex Builder that lets us pick from all of the classes and libraries our project has access to. We want to extend off the “CamoDisplay”.

Once you’ve selected the CamoDisplay, your configure wizard look like this:

Next, let’s talk about package naming conventions.

Step 9 – Packages

In ActionScript 3 we use packages to organize our classes and help avoid naming conflicts. If you have two libraries of code and each has a utility you would need a way of differentiating them. Since Java makes use of packages I try to follow the basics of their naming convention.

In the above step we created a new package called com.tutsplus.flash.components. In Java, packages begin with the top level domain name of the organization, in this case I’m writing a tutorial for flash.tutsplus.com so we use this domain name but in reverse. We also added our sub package “components” that will be a holding place for all of our component classes. It’s important to follow unified package naming conventions so here are some from Java and my own that I try to stick to:

util – a base package name for Utility classes

net – for network connections

math – for math classes

model/view/controller – You may have heard about MVC (Model View Controller) and a lot of people use those for package names. A model represents data, a controller is something that manages other classes/user input and the view is anything that can be displayed. This is a very loose interpretation of the design pattern and I used to break my classes up like this. Although I don’t do it anymore, it’s clear to see what kind of functionality to expect from Classes in each package.

components – this is where I store all of my visual classes now. It makes sense to think of all display classes a type of component. Even a video player can be considered a component made up of many little components. You may have sub packages for your components such as “buttons” or “layout”.

Now that we’ve gone over the basics of package naming, let’s take a look at creating a single component for our Hello World project.

Step 10 – The DemoLabelComponent

To save some time, I’ve already created a Class for us to use. Copy and paste the following code into the new class you just created:

view plaincopy to clipboardprint?

package com.tutsplus.flash.components

{

import camo.core.display.CamoDisplay;

import flash.text.TextField;

public class DemoLabelComponent extends CamoDisplay

{

protected static const FIRST_WORD:String = “Hello”;

protected var words:Array = new Array(“World”, “People”, “Flash”, “Flash Tuts”);

protected var label:TextField;

public function get totalWords():Number

{

return words.length;

}

public function DemoLabelComponent()

{

super();

init();

}

protected function init():void

{

label = createTextField();

addChild(label);

}

protected function createTextField():TextField

{

var tempTextField:TextField = new TextField();

tempTextField.selectable = false;

return tempTextField;

}

public function changeWords(id:Number):void

{

label.text = FIRST_WORD + “ ” + words[id];

}

}

}

package com.tutsplus.flash.components
{
 import camo.core.display.CamoDisplay;

 import flash.text.TextField;

 public class DemoLabelComponent extends CamoDisplay
 {

  protected static const FIRST_WORD:String = 'Hello';
  protected var words:Array = new Array('World', 'People', 'Flash', 'Flash Tuts');
  protected var label:TextField;

  public function get totalWords():Number
  {
   return words.length;
  }

  public function DemoLabelComponent()
  {
   super();
   init();
  }

  protected function init():void
  {
   label = createTextField();
   addChild(label);
  }

  protected function createTextField():TextField
  {
   var tempTextField:TextField = new TextField();
    tempTextField.selectable = false;

   return tempTextField;
  }

  public function changeWords(id:Number):void
  {
   label.text = FIRST_WORD + ' ' + words[id];
  }

 }
}

We’re also going to want to update the Doc class, so go into the HelloWorld Class from part 1 and replace it with the following:

view plaincopy to clipboardprint?

package {

import com.tutsplus.flash.components.DemoLabelComponent;

import flash.display.Sprite;

import flash.events.TimerEvent;

import flash.utils.Timer;

public class HelloWorld extends Sprite

{

private var counter:Number = 0;

private var label:DemoLabelComponent;

public function HelloWorld()

{

label = new DemoLabelComponent();

addChild(label);

var timer:Timer = new Timer(1000, 0);

timer.addEventListener(TimerEvent.TIMER, onTimer);

timer.start();

}

private function onTimer(event:TimerEvent):void

{

counter ++;

if(counter > (label.totalWords - 1))

counter = 0;

label.changeWords(counter);

}

}

}

package {
 import com.tutsplus.flash.components.DemoLabelComponent;

 import flash.display.Sprite;
 import flash.events.TimerEvent;
 import flash.utils.Timer;

 public class HelloWorld extends Sprite
 {
  private var counter:Number = 0;
  private var label:DemoLabelComponent;

  public function HelloWorld()
  {
   label = new DemoLabelComponent();
   addChild(label);

   var timer:Timer = new Timer(1000, 0);
    timer.addEventListener(TimerEvent.TIMER, onTimer);
    timer.start();
  }

  private function onTimer(event:TimerEvent):void
  {
   counter ++;

   if(counter > (label.totalWords - 1))
    counter = 0;

   label.changeWords(counter);
  }
 }
}

Now when you run the class you should see a simple TextField which randomly changes text. I know it’s not much, but it’s all we need to really explain the last few steps.

Step 11 – The Debugger

Flex Builder has an amazing debugger and is a crucial part in any workflow. Earlier I talked about how you can see traces in the console when you hit Debug. Well now we’re going to talk about “breakpoints” and using the full Debugger.

A breakpoint is a marker in your code that tells the player to stop at that point. It gives you an excellent opportunity to check out what is going on under the hood. To add a breakpoint you simply double click on the line number. Let’s go into the DemoLabelComponent and add a breakpoint at line 41:

Now let’s run debug. Remember, debug is the bug icon next to the green play button.

After you accept the notice to start the debugger, you’ll be presented with a frozen browser at which point Flex Builder will be in full debug mode. You should be familiar with the basics of this from part 1 of the tutorial. Let’s talk about each of the three main windows.

The main window contains the class where the breakpoint was created. Notice how line 40 is highlighted and there is a blue arrow over the breakpoint. This indicates that you’re currently stopped at this point. Above this window you’ll see the debug panel.

The debug panel is very important and will help you backtrack all of the functions called until this point in time. When there’s an error you’ll be able to use this stack to backtrack exactly what went wrong. As you move backwards through previously called methods, you’ll be able to see each set of values at that point in time. You can explore the properties of objects in the “Variable” panel to its right.

The Variable panel shows you all the active variables and their values. You should see two variables now “this” and “id”. Notice how “this” has a tick next to it? Click it and let’s explore “this”. This is the current instance of the DemoLabelComponent. Notice at the top you have [inherited] and below that all of the variables in the class? This is important because you can use it to figure out where variables came from as well as the class that contains them. Let’s look at the variable “words” by clicking on it..

The “words” variable is an Array. Here we can explore all of its values as well as seeing what the length value is.

I can’t stress how important this tool is. I used to trace everything out and I had a custom utility that would recessively trace out the contents of classes’ properties, but now all I have to do is add a breakpoint and I can explore any variable at any moment in time.

Let’s talk about what happened here. We added a breakpoint in the DemoLabelComponent’s changeWords method. If we go to the debugger panel and click on the action which happened before this HelloWorld/onTimer, you’ll see that we’ve jumped into the HelloWorld class and line 30 is highlighted. We just went back to the source of the caller of the changeWords method.

Remember that the debugger and the browser are now paused. You can step to the next action by pressing the play button at the top right of the Debug Tab.

When you press it, the code will execute and then pause again. Since we added our breakpoint in a loop it will continue to stop at the same breakpoint each time. If you check the id variable you’ll notice it now has a value of “2″. We just saw the value incremented.

You can exit the Debugger by hitting the red stop or the disconnect icon next to it. “Disconnect” will keep the application running, but disconnect the debugger. You should also remove the breakpoint; you can do this by double clicking on it. That covers the Debugger, let’s take a look at the “Profiler”.

Step 13 – The Profiler

Just like the Debugger, this is another tool I can’t live without. The “Profiler” is key to watching the memory footprint of your application. The Profiler also allows you to monitor the total instances of each class as well as track any possible instances that are not being freed up by the garbage collector. Make sure you’re out of the Debugger and click on the profiler; it’s the button to the right of the bug which looks like a play button with lines under it. Once you press it and accept the notice to switch views, you’ll be taken into the profiler.

As the profiler launches you’ll see a series of options, just accept the default setup and click “Resume”.

Now Flex Builder will load up the profiler, so let’s take a look at our windows. The main window at the bottom is the “Live Objects” list. In the Live Objects tab you’ll see all the instances running in your application. You can filter them or sort them by “Cumulative Instances” or “Memory”. Here you can see in detail just how many instances are being created and track down memory leaks caused by incorrectly destroyed classes.

Next up is the “Memory Usage” chart. This will show you spikes in memory over time. Not much is going on in our HelloWorld project, so things should stay at around 91k. As you load more and more objects and assets into your app, this graph will grow. Eventually the Garbage collector should remove the unused resources from memory. You can speed up the process by clicking on the icon of the Trash Can with a play button.

Finally, you can take “Memory Snapshots” or Find loitering objects in the Profile tab on the upper left. Each time you take a memory snapshot it will appear as a child under the running thread. You can then compare each snapshot to match performance over time.

This just touches the surface of the Profiler, but as you can see, having these tools can help take the guess work out of memory management and help you fine tune your application. Next let’s talk about refactoring.

Step 14 – Refactoring

“Refactoring” or “restructuring” your code is a big part of development. Now that all of our code is in external class files and each class is dependent on the paths in each package we can’t just move things around if we’re unhappy with the setup. Flex Builder offers two good tools for modifying Class names as well as making large changes across your project. First let’s look at how to perform a simple refactor.

Go back to the Flex Development prospective and right-click on the DemoLabelComponent.as file. From here we’ll see an option to rename the class. Let’s click on it. Now we have two places that reference this class; the HelloWorld class as well as the DemoLabelComponent itself. Normally, if you renamed a class, you would have to go back through each class and fix the name. Let’s give this class a new name of “LabelComponent”. Instead of hitting “OK”, lets press “Preview”.

Flex Builder will now go through and show you all the references to this class and how the change will affect the project. Take a moment to look through and see what Flex Builder found. When you’re done hit OK and all of the references to DemoLabelComponent will be changed to LabelComponent. Double check that you don’t have any errors in the “Problems” panel and you’ll see that the class was renamed. This is a big time saver, but what if you want to move it to another package?

Right-click on the LabelComponent and use the “Move” option to move the file up one level out of the components package and into com.tutsplus.flash in the HelloWorld src folder. Hit OK when you’re done. The class was moved, but we now have three problems.

This is because moving doesn’t rename the packages. We’re going to use the advanced “Find and Replace” to finish the job. Go to Edit > Find in Files or Shift + Command + F.

We’ve just opened up the advanced Search panel. Let’s change com.tutsplus.flash.components to com.tutsplus.flash. We can do this by searching for the containing text “com.tutsplus.flash.components”.

Notice how you can fine tune your search across projects or workspaces. We’re going to keep everything at default and hit “Replace…”. We’re now presented with a standard Replace dialog, add “com.tutsplus.flash” into the “With” field then hit “Replace All”.

Now all of our problems are gone and we can continue on our way. Delete the components folder and let’s talk about Code Documentation.

Step 15 – Code Documentation

Documenting code is one of the most important things you should do. Luckily, if you use Flex Builder everything you need to create nicely formatted html documents like Adobe’s own ActionScript documentation is already on your computer. We’re going to set up a quick External Tool to run “ASDoc” (the command line code documentation program). This will work on a PC or a Mac and once it’s set up, you can reuse it on any project.

First let’s open the “External Tools Wizard”. You can do this by going to Run > External Tools > Open External Tools Dialog or click on the run shortcut in the Flex Development Window.

From here you’ll need to click on the “Launch New Configuration” or double-click on the Program Icon in the list.

Now you should be able to edit your new Program, start by giving it a name. We’re going to set up a generic program that can be run on any project and which doesn’t have shared libraries. I gave it the name “ASDoc Generator”.

Next we’ll need to point the location to where you have the asdoc program. On a mac it’s in “Application/Adobe Flex Builder 3/sdks/” then SDKs you are using (for me, I have a 3.2 build) “bin/asdoc”.

Here is my full path:

/Applications/Adobe Flex Builder 3/sdks/3.2.0/bin/asdoc

/Applications/Adobe Flex Builder 3/sdks/3.2.0/bin/asdoc

You can use the Browse File System to find it if your path is different. On a PC you’ll be looking for the asdoc.exe.

Now we need to define a Working Directory. This can be done by selecting “Browse Workspace…” and pointing to the project, or “Browse the File System” if you don’t keep your projects in your workspace. The last option is the one we’re going to use called “Variables”. Eclipse has built in support for shortcutting paths and values in your workspace. They’re formatted like this ${TOKEN} where TOKEN is the variable name. When you click the Variable option, a list of all supported variable is shown. We want ASDoc to use the current project we’re in, so type the following into the Working Directory field:

${project_loc}

${project_loc}

Finally we need to supply arguments to ASDoc. This is common with command line programs so let’s look at the basic setup of what you need to get running.

view plaincopy to clipboardprint?

-doc-sources src -output docs -window-title “${project_name}” -main-title “${project_name}”

-doc-sources src -output docs -window-title '${project_name}' -main-title '${project_name}'

Here is what each parameter does:

-doc-sources represents the folder where your source code is.

-output represents the folder where your docs will go.

-window-title I use the project’s name as the title for the HTML Window

-main-title again I use the project name for the main title of the HTML docs

Before we run this Program we’re going to add one extra param to the Arguments:

view plain copy to clipboard print ?

-external-library-path “/Users/jessefreeman/Documents/Flex Builder 3 Demo/FlashCamo2/bin”

-external-library-path '/Users/jessefreeman/Documents/Flex Builder 3 Demo/FlashCamo2/bin'

Make sure you replace the path to your own computer’s path to the Flash Camo checkout. This is very important; it tells ASDoc where the Camo library code is and not to include it in the documentation. You can add this as many times as you need for each external library you have.

For a full list of supported options check out Adobe’s ASDoc documentation. Now you should have the following configuration:

Let’s replace the code in our LabelComponent Class with the following documented code:

view plain copy to clipboard print ?

package com.tutsplus.flash

{

import camo.core.display.CamoDisplay;

import flash.text.TextField;

public class LabelComponent extends CamoDisplay

{

protected static const FIRST_WORD:String = “Hello”;

protected var words:Array = new Array(“World”, “People”, “Flash”, “Flash Tuts”);

protected var label:TextField;

* @return Total number of words.

public function get totalWords():Number

{

return words.length;

}

* Class Constructor.

public function LabelComponent()

{

super();

init();

}

* Class init function

protected function init():void

{

label = createTextField();

addChild(label);

}

* @return TextField for displaying a message on.

protected function createTextField():TextField

{

var tempTextField:TextField = new TextField();

tempTextField.selectable = false;

return tempTextField;

}

* Changes a word based on an ID.

* @param id index related to the words Array.

public function changeWords(id:Number):void

{

label.text = FIRST_WORD + “ ” + words[id];

}

}

}

package com.tutsplus.flash
{
 import camo.core.display.CamoDisplay;

 import flash.text.TextField;

 public class LabelComponent extends CamoDisplay
 {

  protected static const FIRST_WORD:String = 'Hello';
  protected var words:Array = new Array('World', 'People', 'Flash', 'Flash Tuts');
  protected var label:TextField;

  /**
   *
   * @return Total number of words.
   *
   */
  public function get totalWords():Number
  {
   return words.length;
  }

  /**
   * Class Constructor.
   *
   */
  public function LabelComponent()
  {
   super();
   init();
  }

  /**
   * Class init function
   *
   */
  protected function init():void
  {
   label = createTextField();
   addChild(label);
  }

  /**
   *
   * @return TextField for displaying a message on.
   *
   */
  protected function createTextField():TextField
  {
   var tempTextField:TextField = new TextField();
    tempTextField.selectable = false;

   return tempTextField;
  }

  /**
   * Changes a word based on an ID.
   * @param id index related to the words Array.
   *
   */
  public function changeWords(id:Number):void
  {
   label.text = FIRST_WORD + ' ' + words[id];
  }

 }
}

On a side note, you can quickly comment any function by putting the cursor on the line before and hitting Shift + Command + D. It will even set up the @params and @returns for you as well. Now let’s run the Documentation script and see what happens. A new “docs” folder will be created and inside you’ll find an index.html you can open in your web browser.

If by any chance you were lucky enough to get the following error, here is the solution:

command line: Error: ambiguous argument list; unable to determine where ‘compiler.external-library-path’ parameters end, and default ‘doc-classes’ parameters begin. Use ‘–’ to terminate the parameter list, or perhaps use the ‘-compiler.external-library-path=val[,val]+’ syntax instead.

Use ‘asdoc -help’ for information about using the command line.

Command line apps, especially Mac ones which run on Unix, hate spaces in folder names. You have to make sure you wrap paths with spaces in the names inside of quotes.

Open up the index.html of your documentation and check it out. It looks like our Doc Class was documented in there by accident.

Since we don’t want to have that class as part of our docs we can add the following code above the package declaration on line 7:

view plain copy to clipboard print ?

* @private

/**
* @private
*/

Like so:

Now if you rerun the ASDoc Program, the Doc Class will be omitted from the docs. Let’s look at saving these changes back to the SVN Repo.

See how easy it was to set up ASDocs? Now there’s no excuse not to document your code!

Step 16 – SVN Team Synchronize

It looks like we’ve finished our HelloWorld and it’s time to commit it back to the SVN repo. Flex Builder has an incredible tool called “Synchronize with Repository”, which helps you manage changes between files and shows you in a visual way what is going to happen when you make large commits. Right-click on your project and select Team > Synchronize with Repository.

Here you’ll be presented with a list of files that were changed,are new to the project, or conflict with files already in the repo.

As you can see, each file has an icon to help identify the action need to be taken. Grey arrows are changes, arrows with + icons are new files that need to be added to svn then committed. In this example you shouldn’t see any red arrows, but if and when you do have them they indicate that there’s a conflict with the svn repo and the local copy you are trying to commit. Likewise blue arrows are files that need to be updated on your local copy. The direction of the arrow denotes where it is going; to the right is the SVN repo, to the left is your workspace. Before we commit a file, let’s check out the differences between a local and svn copy.

Step 17 – SVN Compare

An “SVN Compare” or “Diff” is a tool that will show you exactly what’s changing when you perform a commit based on the latest file in the repository. Let’s click on HelloWorld.as and take a look.

Here you can see your local file on the left and the remote file on the right. Flex Builder also uses blocks and lines to show you exactly what’s different and what’s going to change. You can still edit your local file in case there are changes you want to remove or revert back to. You can actually go block by block and accept changes by using the icons on the top right of the Text Compare window. Let’s close out of this file since everything looks good. We can commit the entire set of changes by right-clicking on the HelloWorld parent folder and choosing “commit”. You’ll be presented with a comment box.

Now we’re done and ready to deploy our project.

Step 18 – Deployment

When our application is ready to be deployed we’ll need to do a special build called a “Release Build”. You can run this by going into the Project > Export Release Build… menu option.

After selecting it you’ll be presented with a few configuration settings such as the project you want to release from and the main class in the project. Also, you can choose where to put the release; for now let’s leave it in the default bin-release as the output location. Click “finish” to run the compile.

You’ll now see a bin-release folder in your HelloWorld project. It should look exactly the same as your bin-debug folder. If you right-click on the two HelloWorld.swfs and check out the size of each swf you’ll notice the difference.

bin-debug HelloWorld.swf

bin-release HelloWorld.swf

As you can see, the bin-release build is 7032 bytes smaller then the bin-debug build. I know you’re thinking that 7k isn’t very much but I have seen the difference quickly become a couple of hundred k based on the size of your app. The reason for this is all of the Debug code. When you create a release build, Flex Builder strips out all of the extra code it uses to debug your app. This is probably one of the most overlooked parts of compiling a site from Flex Builder 3 and can easily make a difference in load times.

Now that you have seen how to create the release build, you can simply push the bin-release folder to your staging or production server. With one project down, let’s talk about what happens when your workload increases.

Step 19 – Workspace Organization

As the amount of projects grow in your workspace you’ll quickly find it hard to keep everything organized. You can take two steps in managing your workspace and projects; one is to use “Working Sets” and the other is to create “multiple Workspaces”. Let’s explore our options.

The simplest way to stay organized is by creating Working Sets. These are filters that only show you a particular set of projects. You can create a new working set by clicking on the downward pointing arrow on the Flex Navigator tool bar:

From here click on “Select Working Set”. Now you’ll see a list of previously created sets or you can create a new one. Click on “New…” and start the process. As you can see you’ll have a few options for creating working sets, we’re only going to focus on “Resources” so select that and hit “next”.

Here you’ll name your set and check off the projects you want to see when in the set. Once you’re done with that, click “finish” and you’ll be back at the Select Working Set screen. Check the set you just created and click OK. Now you’ll only see the projects you selected in the set.

If you ever want to exit a set or go back to seeing all of your projects, click the arrow icon again, choose “Deselect Working Set” and you’ll be back at the default set of your workspace. You can also filter out files from sets and perform lots of other customization options, so take some time and play around with the feature to find the right setup for you.

The other option for keeping organized is to start new Workspaces for each group of projects you work on. For example; I keep a workspace for my Papervision work and another for my Flash Camouflage Framework development. Each time you create a new workspace you’ll need to re-setup all of your svn paths, however the ability to separate projects is crucial when working on different client/personal work. At any time you can switch to a new Workspace by going to File > Switch Workspace. From there you can see a list of the latest workspaces you’ve used or browse for a new one.

I tend to keep my Workspaces in a folder, ironically enough called “Workspaces” in my documents folder. This way all of my work is easy to backup and in one place. I tend to ignore the default Flex Builder 3 workspace. You’ll also have to set up all of your custom key commands in each Workspace. There is an option to copy over some of the preferences when making a new workspace, but I don’t normally do it.

One last thing you should keep in mind is to close projects you’re not using. You can do this by simply right-clicking on a project and selecting “close”. This tells eclipse that you’re no longer working in the project and it will stop error checking its content. If your workspace is running incredibly slow you may want to try this out.

Step 20 – Resources

The final crucial piece to any Flash Developer’s toolkit is your RSS reader. Here is the list of what’s in my RSS reader. We can’t develop in a black box and I encourage you all to go out and leave comments, be part of the community and follow the works of others. You can’t go wrong with these sites:

http://blogs.adobe.com/aharui/

http://www.as3dp.com/

http://labs.bigspaceship.com/

http://drawlogic.com/

http://blog.flexexamples.com/

http://www.gskinner.com/blog/

http://www.guahanweb.com/

http://www.igorcosta.org/

http://jessewarden.com/

http://www.jodieorourke.com/blog.php

http://madowney.com/blog/

http://maohao.wordpress.com/

http://www.morearty.com/blog/

http://www.blog.noponies.com/

http://pixelwelders.com/blog/

http://lab.polygonal.de/

http://blog.onebyonedesign.com/

http://www.reflektions.com/miniml/

http://www.rogue-development.com/blog2/

http://blog.soulwire.co.uk/

http://theflashblog.com/

http://www.unitzeroone.com/blog/

http://www.websector.de/blog/

http://www.warmforestflash.com/blog/

http://visiblearea.com/blog/bin/view/VisibleArea

Conclusion

We can easily spend hours going over configuring the perfect Flash Sandbox for all of your development needs but the reality is that no setup is 100% perfect. Hopefully these two tutorials have given you a good start in the right direction. Although I spent the majority of the time talking about Flex Builder 3, you can easily apply most of this workflow to FDT or Flash Develop. The important thing to remember is that you need to be organized, learn the common tools all good developers must know like SVN, naming conventions and how to set up a local test environment. Also, a lot can be learned by studying workflows of other programming languages such as Java and PHP. Now go and create something amazing with your new sandbox!