In the main Debug view in the Flex Debugging perspective, you will find a row of buttons. These buttons provide the ability to resume, suspend, terminate, step into, step over, and step return. Breakpoints provide single points in the code to automatically stop when debugging. The question is what to do when you need to continue. This is where you have multiple options, especially the stepping functionality. Continue reading ‘Learn Flex Breakpoints and Stepping’
Archive for the 'Flex Error' Category
Testing and debugging an application go hand in hand. The basic requirement to debug is to receive or view in real time messages from the system regarding the state of the execution stack. From logging simple messages to viewing the state of the execution stack, this chapter will help you debug and test both on the client side and the server side of development.
Logging Overview
There are two areas of logging in an application’s life cycle. The first is application- and compiler-generated messages, and the second is developer-created messages. To be effective in debugging and testing, you need to learn both areas and how they overlap. Most logging is something that is done during development, and should be disabled when put into production, but that doesn’t mean certain critical messages shouldn’t be taken out of live production applications. Continue reading ‘Flex Debugging and Testing’
With the exception of the FDS2 deployment that was discussed earlier, the deployment of a Flex 2 application is very similar to Flash deployment. Flex Builder, by default, sets up a deployment directory that is used when debugging, although you can customize your deployment as you see fit. The only thing to keep in mind when customizing a deployment is that you must keep your pathing correct – meaning that, if you nest your XML files in an /xml folder for run-time parsing, you must ensure that your Flex application is pointing to that /xml folder. This applies to any external, nonembedded assets.
The following table shows a basic customized deployment directory structure.
| Directory/File | Description |
|---|---|
| deploy/ | The location of the root directory. Many developers choose a /source, /deploy directory structure, although you can use whatever you’d like. |
| /images | The location of any nonembedded images such as PNG, JPG, and GIF. |
| /xml | The location of any nonembedded, run-time-specific data that is wrapped in XML. |
| /swfs | The location of any nonembedded SWFs used by your application. |
| /js | The location of any JavaScript files. |
| myApp.swf | Your application. |
| myApp.html | Your application’s HTML wrapper. |
Deployment with Flex Builder 2
If you are using Flex Builder 2 or the Flex Builder plugin for Eclipse, as mentioned before, both create a deployment directory for you. Located in your application project’s root directory is a /bin directory. This is where all of the wrappers are kept. The following table describes this structure.
| Directory/File | Description |
|---|---|
| {appName}/bin/ | Your application deployment root directory |
| AppName.swf | The default SWF file for your application |
| AppName.html | The default HTML wrapper for your application |
| AppName-debug.swf | The default debugger SWF for your application that is used by the debugging version of Flash Player 9 |
| AppName-debug.html | The default HTML wrapper for your application’s debug file |
| history.htm | The default wrapper for the history-management SWF |
| history.swf | The history-management SWF |
| history.js | The history-management JavaScript file |
| playerProductInstall.swf | The Flash player detection/installation SWF for Express install |
As you can see, by default, Flex Builder’s deployment isn’t very organized, but it works well for testing. However, if you’re going to use your own wrappers and directory structure with Flex Builder, keep in mind that you have to tell Flex Builder to not build out the wrappers by default, and redirect Flex Builder’s RUN and DEBUG commands to your custom wrappers.
Figure 18-9 illustrates how to disable HTML wrapper generation within the properties of your application. To do so, uncheck “Generate HTML wrapper file.”
The first step in building an application using any IDE (Flex included) is to start off with a plan. Although you could dive right into building out your application with a predetermined goal in mind, chances are that you will encounter problems throughout the build phase that you never considered. With a little planning, you will be able to minimize those unforeseen problems. Following are a few things to consider before you open up your preferred Flex editor and dive into the building phase:
- Code for reusability – Your goal as a developer should be to create reusable code through inheritance, polymorphism, and abstraction. Reusability will save you development time. Although this discussion does not address the basics of object-oriented programming (OOP), a good place to start with code planning is to outline your application using a Unified Modeling Language (UML) diagram. Because Flex 2 MXML components are essentially classes, you can outline them in the same fashion as you would a standard class. As you map out your application using UML, you will see where inheritance may provide an easier solution. Following are some useful online UML resources:
- http://www.eclipseplugincentral.com/ – If you’re using Flex Builder or the Flex plugin for the Eclipse SDK, look into different UML plugins. Several popular UML tools for Eclipse are available for free or for a small fee. You should look at the user comments for each plugin before downloading and installing.
- http://www.gskinner.com/gmodeler/app/run.html – gModeler is a Flash-based UML diagramming tool created by Grant Skinner. It’s easy to use and it’s free. Although it was originally created for ActionScript 2, it is possible to also lay out ActionScript 3 classes.
- http://www.sparxsystems.com/ – Sparx Systems offers a product called Enterprise Architect specifically for UML modeling. You can download a free, limited-access demo of the program. Enterprise Architect allows you to forward- and reverse-engineer ActionScript 3 as well as other object-oriented languages.
- Choose a design pattern(s) – Choosing the right pattern fits into “coding for reusability,” but it’s worth mentioning on its own and isn’t completely necessary for all applications. A design pattern is a prebuilt solution to recurring problems in application design. If a design pattern fits in well with your application design, it could save you valuable development time. The Model View Controller (MVC) pattern is an excellent place to start and works well with the Flex Framework. For example, in the MVC pattern, the model will contain data provided by XML files or remote services, the view is any interface component that may include Flex components, and the controller is the logic that interfaces with the model and the view. As with all design patterns, the MVC pattern deserves more understanding and explaining than this overview chapter will allow. For more information on design patterns, refer to the following books:
- Design Patterns: Elements of Reusable Object-Oriented Software (Upper Saddle River, NJ: Addison-Wesley Professional Computer Series, 1995), by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides – Also referred to as the “Gang of Four” book and considered to be the source of design patterns. Though this book covers design for Java and C++, the structure of each pattern can translate to ActionScript 3.
- Head First Design Patterns (Sebastopol, CA: O’Reilly, 2004), by Elisabeth Freeman, Eric Freeman, Bert Bates, and Kathy Sierra – This is a terrific place to start, especially if programming is new to you. It’s written for Java, but can translate to ActionScript 3.
- Advanced ActionScript 3 with Design Patterns (Berkeley, CA: Adobe Press, 2006), by Joey Lott and Danny Patterson – This book is great if you have had prior experience with ActionScript and would like to know more about ActionScript 3 while learning about design patterns.
- Plan for the deployment environment – Consider where your finished application is going to reside when you’re done. Will you be using any data services, such as ASP.NET, PHP, or a J2EE-compliant technology? Will you be using any Web services, such as XML? Does your application have rich media like audio or video and, if so, will the server be able to handle the bandwidth? Does your project require declarative or programmatic security? Planning for your deployment server may require some homework on your behalf, but it will greatly decrease the odds of a development bottleneck at the tail end of your project.
- Determine a good directory structure for both development and deployment – If you’re using Flex Builder and you’ve started a new project from within the project navigator, by default, Flex Builder will set up a basic /bin directory for the deployable SWFs, HTML files, and whatever else may be associated with your project. Source files will be placed in the root directory of your new project. Although this is fine for small applications that do not require many custom classes and components, you may find that the project calls for more of a development and deployment folder approach, where /src (source) is your development folder and /bin is your deployment folder. As an application grows, it will become clear how important setting up a directory structure can be. Directory structure is discussed in more detail later in this chapter.
Building for Flex 2 SDK
When building for the Flex 2 SDK, it is helpful to understand the process in which your application will be built, compiled, and distributed.
If you have had prior experience with building projects and applications with Adobe Flash Professional 8, or one of the previous versions of Flash, this process will seem familiar. Both Flash and the Flex 2 SDK compilers build a single SWF file that is run through Flash Player. The key difference (at least as far as development is concerned) is that the Flex 2 Framework includes packages not available through Flash.
Hopefully, you have decided on whether you will be using Flex Builder, the Flex 2 plugin for Eclipse, or a third-party editor with the free Flex 2 SDK. Differences between the software configurations were discussed in Chapter 1. Differences aside, all three configurations have the same single resulting SWF that will be deployed on your Web server.
In a typical development environment, you will be developing and testing the SWF locally as you go. Figure 18-1 illustrates a common deployment environment. However, if you are developing a secured, nonpublic application, or an application with a large development group, you may want to mirror your server setup so that you are not interacting with the live servers, or secure the outgoing and incoming traffic.
As you can see in Figure 18-1, when you’re developing your application, you must keep in mind that your server (or the client’s machine) may be behind a firewall, limiting access. Also, during development, you may be able to interact with all of the development servers, but when deployed, the client’s interaction should be limited through a server proxy. Lastly, when development is completed, the end SWF will be uploaded to the Web server, which is within the same domain as the other servers (application server and Web services server, if any are used), and downloaded through HTTP by the client.
Now that you have an idea of how the deployment structure could work, it will be easier to proceed with the rest of the development of your application. As mentioned in the previous section, you will want to consider security and optimization. Both will rely heavily on the type of application you are building and how you deploy it. These topics are discussed in more detail throughout the chapter.
Everything that you can do with regular expressions expressed as literal values can be done with the RegExp class. It provides a wrapper class that helps construct and retrieve information about regular expressions. For example, the five flags are defined as properties and can be read at any time. These properties are global, ignoreCase, multiline, dotall, and extended. There are two methods to create RegExp objects: using the constructor or using a literal regular expression.
Continue reading 'flex Using the RegExp Class'

