Programming Flex 3: Chapter 18, Application Debugging
Pages: 1, 2, 3, 4

Once a connection is established, you can set breakpoints or instruct the debugger to continue execution of the application. To continue execution you can issue the command. Application trace messages are shown in the debugger as they are encountered.

Breakpoints can be set using several methods. The most typical method of setting a breakpoint is to specify the class and line number for the breakpoint, which you can achieve by issuing the break command. For example, if you wanted to insert a breakpoint in line 56 of the class MainApp, you would input the command break MainApp.mxml:56. If you want a breakpoint when a button is pressed but you are not sure of the method that will be called when the event occurs, you could enter break button. This will return a list of methods that begin with the word button. From the list, you should see buttonPressed and the location of the method. With that information, you could set the breakpoint by calling break buttonPressed. Once you do that, you will need to call the command continue, which will tell the debugger to allow the player to continue executing the application. There are other methods of setting breakpoints with FDB, which you can find by issuing the command help breakpoint.

When an application is executing, the debugger will inform you when it encounters a breakpoint. Once a breakpoint is encountered, you have several options. You can issue the continue command, which will continue execution of the application, step through the application using the step command, and set the value of a variable using the set command. When done debugging, you can exit FDB to end the debugging session, which will automatically end the active connection with the Debug Player, or you can execute the kill command.

As discussed, FDB makes it easy to search for methods on which you want to set breakpoints. Some of the other nice features of FDB that Flex Builder's debugger doesn't support are the ability to set conditional breakpoints using the condition command, and the ability to review a list of all the loaded types and functions with the info functions command.

FDB can be a powerful tool and is worth exploring, but as you will see in the next section, Flex Builder provides a more practical method of application debugging, which you will likely opt for over FDB.

Section 18.3: Debugging with Flex Builder

One of the best selling points of Flex Builder is the integrated GUI debugger. FDB is free, but for day-to-day debugging, Flex Builder's debugger makes it much easier to debug applications.

A default Flex Builder installation (see Figure 18-2) will configure the tasks needed to get you up and running for debugging applications. To debug an application you are working on, you just need to select Run→Debug from the main menu (or press F11). This will compile the application if it is not already compiled, launch it within the browser, and connect the application to the debugger. The first time you debug an application you will be prompted to switch perspectives to the debugging perspective in Flex Builder, which usually is recommended.

Figure 18-2: Default debugging perspective

Figure 18-3: The Breakpoints panel

When in the debugging perspective, you will have access to the currently running application. Often you will set a breakpoint to stop the application at a point during the execution process in which you are interested. You can set breakpoints by double-clicking the left margin of a source line or by using the keyboard shortcut Ctrl-Shift-B. You can do this during a debug session or even before a session is started in the development perspective. You can navigate through a list of breakpoints by using the Breakpoints panel (see Figure 18-3). The Breakpoints panel contains a list of all breakpoints currently set and lets you navigate directly to a breakpoint or disable a breakpoint. This panel can also be very useful if you aren't sure what breakpoints you have set in your application as it allows you to view all breakpoints and manage them from one central location.

When Flash Player encounters a breakpoint, as in Figure 18-4, execution will halt, the debugger will gain focus, and the call stack will be displayed. You then will have the option of having the application continue execution, step through code, set variables, or evaluate expressions.

Figure 18-4: Debugging view when a breakpoint is reached

Note: Breakpoints can be set on both ActionScript and MXML code. Breakpoints on MXML code are valid only when ActionScript event handlers exist. In cases where you set a breakpoint on an invalid MXML line, Flex Builder will attempt to find the nearest valid breakpoint. It does so by scanning the next 10 lines of execution for points where a breakpoint would be valid, and automatically moving the breakpoint to that location.

To help speed up the debugging process, Flex Builder offers the following default keyboard shortcuts for stepping through code:

• Stepping into (F5)
• Stepping over (F6)
• Step return (F7)
• Resume execution (F8)

This excerpt is from Programming Flex 3. If you want to try your hand at developing rich Internet applications with Adobe's Flex 3, and already have experience with frameworks such as .NET or Java, this is the ideal book to get you started. Programming Flex 3 gives you a solid understanding of Flex 3's core concepts, and valuable insight into how, why, and when to use specific Flex features. Learn to get the most from this amazing and sophisticated technology.

While stepping through code, the debugger will have control over the player. At times, this may cause the player and browser to seem unresponsive. This is normal as you step through code. To suspend the debugger from having control until the next breakpoint, you have to tell the debugger to resume execution by clicking on the Play button or by using the F8 keyboard shortcut.

While debugging, you also have the ability to review values of variables. The Variables panel (see Figure 18-5) will list all object instances as well as their child properties and values. You can also review the values of variables right within the code editor by hovering above a variable within the code. This will display a tool tip with the current value of the variable. To change a value, click the Value column for the field that you wish to change, as shown in Figure 18-6, or right-click the property you wish to change and select Change Value.

Figure 18-5: Changing a value in the Variables panel

Changing variables will often result in other variables changing as well. To give you insight into the changes that occur as a result of changing a variable, the Variables panel will highlight in yellow the affected variables in the panel.

Note: When debugging an application, you also have the ability to set breakpoints in and step through Flex framework code. Stepping through Flex framework code will happen automatically when encountered. To set breakpoints within the framework, you will need to open the class file. An easy way to do this is to use the shortcut Ctrl-Shift-T within Flex Builder and select the appropriate type. Once the class file is opened, you can set breakpoints as you would normally.

To end a debug session you can either close Flash Player or your browser, or click the red square within the Debug panel. Caution should be taken when closing an active debug session by closing the browser when it is executing within a browser, as sessions that are in a halted state can cause a web browser to close unexpectedly.

This book does not fully cover all the functionality possible with the debugger within Flex Builder. For full coverage, you can review the documentation provided with Flex Builder.

Section 18.4: Remote Debugging

When attempting to isolate a bug in an application, it is possible that you will encounter a case where a bug is reproducible on only a specific machine. For such a case, you can use the Flash Debug Player's remote debugging feature. This feature can also be useful if you would want to use the Flex Builder debugger on a Windows or Mac-based machine while the application is executed under Linux, which does not have a native version of Flex Builder available.

As mentioned earlier, debugging occurs over a TCP connection on port 7935. Such a connection is typically established on the same machine transparently, but with remote debugging it is established from one machine to another. One machine will typically be running the debugger and can be referred to as the server, while the other will be running the application and can be referred to as the client machine. Once a connection is established between the client and the server, all of the features of using a debugger function in the same manner. It's important to remember that in a typical workstation, the client machine may not be configured properly for remote debugging. Remember that the Flash Debug Player is required for a debug session, so you will need to ensure that it is installed on the client machine. It is also important to keep in mind that the client machine will need to be executing a debug-enabled SWF in the same manner as we discussed earlier in the chapter.

To initiate a debug session, follow these steps:

1. Initialize the debugger on the server machine.
   1. With FDB: one benefit of using FDB when initializing a remote debugging session is that the steps for initializing FDB are exactly the same as those for initializing a local session. You initialize FDB by launching FDB and executing the run command.
   2. With Flex Builder's Debugger: initializing a remote debugging session with Flex Builder is more involved. Flex Builder's debugger doesn't formally support remote debugging, although it is possible. We will cover remote debugging with Flex Builder in the next section.
2. Initialize the debug-enabled SWF on the client machine and ensure that the Debug Player is installed.
3. Once initialized, the player will prompt you for a debugger, because the debugger is not running on the client machine. Input the IP address of the server running the debugger and select Connect.
4. If the server is running the debugger and listening for a connection, the client and server will connect. Note here that you will also need to ensure that the server is not blocking port 7935.

Once a connection has been established, debugging can be performed in the manner discussed earlier in this chapter.

Establishing a Remote Debugging Session with the Flex Builder Debugger

As mentioned earlier, debugging sessions—both local and remote—are established over a TCP connection on port 7935. Flex Builder uses the same connection to establish debug sessions. Although by default Flex Builder does not expose remote debugging capabilities, it still is possible to do so.

To initiate a remote debug session with Flex Builder, follow these steps:

1. Compiled a debug-enabled .swf.
2. Copy the debug-enabled .swf to the remote client machine.
3. On the machine that will run the Flex Builder debugger (server), create an empty HTML file (typically within your project's bin-debug folder). Since no content exists in an empty file, the Flex Builder debugger will launch a session that is empty and just wait for a remote connection.
4. Ensure that no firewall is actively blocking port 7935 on the client machine.
5. Edit the debug configuration within Flex Builder (select Run→Run).
6. Select the target debug configuration.
7. Uncheck the “Use defaults” checkbox.
8. Click the Browse button for the debug file path.
9. Select the blank HTML page created in step 3.
10. Click Debug in Flex Builder. You should see “Launching {application name}” and a progress bar in the bottom status bar of Flex Builder (at this point, Flex Builder is waiting for a remote connection, in the same manner FDB does).
11. Open the debug-enabled .swf on the remote machine and, when prompted for a remote host address, input the host address of the machine with the Flex Builder debugger.