New debugging and profiling features in Flash Builder 4

New and exciting features are included in every successive release of the Adobe Flex IDE, and with many new and improved debugging and profiling features available, Flash Builder 4 is no exception. In this article you will learn about new features in the Debug perspective and Profile perspective as well as the new Network Monitor. Each feature will be demonstrated so that you can get started quickly. The example code is provided as a Flash Builder 4 project archive; be sure to download it so you can work along with this article.

The Flash Builder 4 Debug perspective has four major improvements over the previous version of the IDE:

• Support for expression types in the Expressions view has been enhanced.
• Watchpoints are available to help you debug variable instances.
• Conditional breakpoints support has been added.
• The run to line feature will help you strike a happy medium between coding manual trace statements in your code and having so many breakpoints in your code that debugging becomes ineffective.

Improved expression evaluation

The new Flash Builder 4 expression evaluator functionality provides a more robust view of variable states during a debugging session. In the past, for example, adding an expression containing a function call would not work. With Flash Builder 4 you can now call functions, evaluate most ECMAScript for XML (E4X) statements, use regular expressions in your expressions, and more.

The sample application makes a service call to get the Adobe Developer Connection RSS feed. In the following walkthrough I will demonstrate the ability to write E4X as an expression in the Expressions view.

Walkthrough 1: Using E4X in an expression

1. Extract the FXP Flex Project Archive from the sample file and import it into Flash Builder 4.
2. Open Devnet_FB4_New_Debugging_Profiling_Features.mxml located in src/(default package).
3. Set a breakpoint inside the for each loop by clicking on line 34 and choosing Run > Toggle Breakpoint.
4. Launch the sample application in debug mode by choosing Run > Debug > Devnet_FB4_New_Debugging_Profiling_Features
5. Wait for the breakpoint to halt the application.
6. When the application has halted make sure you are in the Flash Builder Debug perspective by choosing Window > Perspective > Flash Debug
7. Locate the Expressions view in the Flash Debug perspective.
8. Right-click in the Expressions view and select Add Watch Expression.
9. In the Add Watch Expression dialog box type item..* to view all XML descendents of item and click OK to add the watch expression.
10. When you see the E4X expression evaluated, expand the XMLList to view each of the descendents (see Figure 1).

Watchpoints

In previous versions of Flex Builder, there was no way to select a specific variable instance for monitoring during your debug session. Watchpoints are a new feature in Flash Builder 4 that let you do exactly that.

When you use watchpoints to monitor variable instances for change, there are two things to keep in mind. First, you have to set the watchpoint while the debug session is active. Second, the watchpoint will be removed when the debug session is terminated.

In the next walkthrough, you’ll set a watchpoint on the source property of an <mx:Image/> tag to monitor changes to that property.

Walkthrough 2: Setting a watchpoint on a variable instance

1. Keep the breakpoint that was set in walkthrough 1 and run the application again in debug mode.
2. Wait for the application to pause execution.
3. While the application is suspended, find the Variables view in the Debug perspective.
4. Expand the this instance in the variables view.
5. Locate rotatingImage.
6. Expand rotatingImage in the Variables view.
7. Right-click the source property of rotatingImage.
8. Select Toggle Watchpoint in the context menu.
9. A Toggle Watchpoint dialog box will appear because source is a getter. Select the _source variable instance to monitor and click OK.
10. Locate the Breakpoints view in the Debug perspective and find the new watchpoint.
11. While still in the Breakpoints view, clear the Line 34 breakpoint that had been set in Walkthrough 1.
12. Resume the execution of your application by choosing Run > Resume
13. After a short wait you will see the watchpoint suspend the application once more. You should also notice that the source code for SWFLoader is where the _source instance is being changed (see Figure 2).
14. Resume the application again and you will notice that the watchpoint is hit each time the _source instance for the <mx:Image/> tag is changed.

Conditional breakpoints

Debugging with breakpoints can quickly become cumbersome. Consider a situation in which you needed to troubleshoot an issue within a for loop. You may need to suspend the application only once during the debug session to verify your logic, but you’ll hit the breakpoint in the for loop each time through. You’ll then have to take the additional step of removing the breakpoint to continue the debug session without stopping on each iteration of the loop.

Using conditional breakpoints in Flash Builder 4 you can configure a breakpoint to trigger only after a certain number of loop iterations. For instance, you can halt the application on the third time a breakpoint is reached.

You can also use a conditional breakpoint to suspend the application when a particular expression either changes or evaluates to true. In the next walkthrough you will make the breakpoint that was set up in the first walkthrough conditional by adding an expression.

Walkthrough 3: Converting a standard breakpoint to a conditional breakpoint

1. Run the application normally by choosing Run > Run > Devnet_FB4_New_Debugging_Profiling_Features
2. Wait for the data to load and select a specific author name, for example "Adobe".
3. Close the application and enter the Flash Debug perspective.
4. Set a breakpoint inside the for each loop by clicking on line 34 and choosing Run > Toggle Breakpoint.
5. In the Flash Debug perspective, locate the Breakpoints view and right-click the breakpoint that you just created.
6. In the context menu select Breakpoint Properties
7. Take a quick look at the options available to you, and then select Enabled if not pre-selected for you.
8. Select Enable Condition.
9. In the Enable Condition text input, type a condition that will evaluate to true when the author's name that you identified in step 2 is present. For example, type item.author == "Adobe" (see Figure 3).

10. Click OK to exit Breakpoint Properties dialog box.
11. Run the application in debug mode and wait for the application to suspend.
12. When the application suspends, open the Variables view and click the item variable. If you look at the value of item you will see that the author node in the XML is equal to the author name that you had specified in the breakpoint condition in step 9 (see Figure 4).

13. Resume the application. If the author you chose had multiple articles, then the conditional breakpoint will be triggered each time that author is reached, but only when that author is reached.

Run to line

In the past, if you hit a breakpoint and wanted to know what would happen ten lines down through code execution, you would need to step debug until you got to the line you wanted to investigate. Other options would be to set another breakpoint, or even create a trace statement. Although all these options are valid, they can be inconvenient.

A better solution would be to use the run to line feature in Flash Builder 4 to quickly get to a line in the code below the breakpoint that the application had suspended on. In this walkthrough you will use run to line to get to the trace statement after the for each loop quickly.

Walkthrough 4: Using run to line

1. Keeping the conditional breakpoint from the last walkthrough, run the application in debug mode.
2. Wait for the conditional breakpoint to trigger and once the execution of the application has paused, look at devnetFeed_resultHandler() in the code editor.
3. To finish debugging the for each loop, disable the conditional breakpoint that was set on line 34 by deselecting it in the Breakpoints view.
4. Put the cursor on line 39 of the code, which reads var aNumber:int = 1974.
5. Right-click and select Run To Line.
6. You will see that the results are immediate. Figure 5 shows that code execution will halt on the line you chose to run to during the debug session without having to step debug or set another breakpoint.

The Profile perspective was introduced in Flex Builder 3. Incorporating feedback from the community, the Flash Builder 4 team has introduced optimized threading for better performance and created an improved Object References view to make profiling information easier to find.

Optimized threading for better performance

The threading in Flash Builder 4 has been optimized to speed up the profiling process, including analyzing objects in the Object References view after profiling. This comes in handy when you’re trying to track down a memory leak or do some optimization on your function calls or object allocations.

Improved Object References view

In the past I’ve heard from developers who had a difficult time figuring out what they were looking at in the Object Reference view, which happens to be among the most important profiler views.

In Flash Builder 4, the Object References view has been greatly improved. Not only is the display easier to read, but the Object References view will now identify any back reference path that is a path to a garbage collection root (GC root). It's good to know when a reference path can be traced to a GC root since this can indicate a memory leak.

In the following walkthrough you will use the Object Reference view to find a memory leak.

Walkthrough 5: Using the Flash Builder 4 Object References view

1. First, launch the sample application in Profile mode by choosing Run > Profile > Devnet_FB4_New_Debugging_Profiling_Features.
2. When the profiling session launches you will see a Connection Established dialog box.
3. Since you're trying to track down a memory leak, select Generate Object Allocation Stack Traces and click Resume. Flash Builder 4 will open the Flash Profile perspective.
4. Let the application run for several seconds so that it can generate profile data, and then look at the Live Objects view.

   If you see any objects in the Live Objects view that have more instances than you know there should be, those objects may indicate a memory leak–especially if the number of instances is equal to the number of cumulative instances.

   In the case of the sample application, it is highly suspect that there are so many instances of the BadTitleWindow class still in memory.

5. Select the “[Running]…” application in the Profile view and click the Take Memory Snapshot button in the Profile view toolbar.
6. Double-click the memory snapshot in the Profile view to open it, and then wait for Flash Builder to analyze the memory snapshot.
7. Once the memory snapshot is available, double-click the BadTitleWindow class to open the Object References view (see Figure 6).

8. Expand the first BadTitleWindow instance; you will see several paths.
9. Expand Path 1 (see Figure 7). Notice in the GC Root column that this back reference path does terminate at a GC Root (you may need to adjust the column widths).

   Note: There is a chance that the order in which your Paths are listed is different. If this is the case, find the instance with a Path that resembles Figure 7 before moving on to Step 10. Also, Flash Builder is configured not to show all paths by default. To enable Flash Builder to show all paths: Flash Builder --> Preferences... --> Flash Builder --> Profiler --> Object References --> check the "Show all back-reference paths" checkbox and apply your changes.

10. Click the BadTitleWindow instance in the path and look at the Allocation Trace in the right pane. You will see that this instance was created in the _onPopupTimer() method of the main application MXML file.
11. Now click the Function instance in the left pane.
12. In the Allocation Trace panel you can see that the Function instance was created in the BadTitleWindow constructor on line 16 (see Figure 8).

13. Double-click the row in the Allocation Trace that represents line 16 of the BadTitleWindow constructor. If the source code is available, double-clicking on a row in the Allocation Trace pane will take you to the line of code where the instantiation was initiated (see Figure 9).

14. Notice that line 16 creates a reference from the main application to the BadTitleWindow. Since this is not a weak reference, it will keep the BadTitleWindow object in memory even if this is the only reference to BadTitleWindow. In other words, this line of code is what caused this memory leak.
15. Comment out line 16, save your changes, and then build and run the application in profile mode once more. Let it run and watch the number of instances and the number of cumulative instances. You will see that the BadTitleWindow instances are no longer being leaked.

If the path that you had examined had not been the source of the memory leak, you would have continued through each path in the Object References view, looking at the allocation traces and the code as you did with the first path.

Flash Builder 4 contains a new tool, the Network Monitor, which enables you to watch network traffic between your Flex application and a remote server.

In the past you could use third-party tools such as ServiceCapture, Charles, or Wireshark to diagnose issues that occurred between your application and a remote server. Although these dedicated network monitoring tools are useful for diagnosing network traffic, it’s nice to know that some of that functionality is now a part of Flash Builder 4.

Using the Network Monitor, you can monitor traffic that takes place over an uncompressed, unencrypted HTTP channel. In addition, you can monitor AMF traffic between your application and the remote server. In this walkthrough you will take a brief look at how to use the Flash Builder 4 Network Monitor.

Walkthrough 6: Using the Network Monitor

1. First, make sure that the Network Monitor is enabled before using it. In the Flash perspective, click the tab to display the Network Monitor view.
2. The left-most button on the Network Monitor toolbar is the Enable/Disable Monitor button. If the Network Monitor is not already enabled, click the Enable Monitor button to turn it on.
3. Run the sample application by choosing Run > Run > Devnet_FB4_New_Debugging_Profiling_Features
4. Wait until the DataGrid is populated with the feed data, and then locate the Network Monitor view in the Flash perspective. (By default, it will be grouped with the other views under the code editor window.)
5. Click the URL in the left pane of the Network Monitor view (see Figure 10).

Each row in the left pane represents a request and response. In other words, if four data calls had been made from your application you would see four rows listed in the left pane along with the corresponding URL for each call. This pane also lists the type of service and operation along with request, response, and elapsed times for each call.

When you click on a row in the left pane, you can examine the actual request and response details for that data call in the right pane. You can use the right pane’s toolbar to select Tree View, Raw View, or Hex View.

You can double-click the entries in the left pane to go to the associated source code if it is available.

You can also click on the save button in the toolbar to save the captured data to an XML file for offline analysis.

Where to go from here

As you can see, Flash Builder 4 is full of exciting new features and improvements. The Debug perspective takes breakpoints to a new level with conditional breakpoints, watchpoints, and run to line functionality. The Profile perspective is faster than ever before with improved threading, and it is easier to use with an improved Object References view. With the Network Monitor, in many cases you will not have to leave your IDE when you need to diagnose network traffic between your application and a remote server. Used effectively, Flash Builder 4 will hands down be the premiere environment to debug and profile your Flex applications.

Here are some resources you can use to keep an eye on developments with Flash Builder 4 and find some good tips and tricks:

• Mike Morearty – Flash Builder Debugger Engineer
• Alex Harui – Flex SDK Engineer
• Kyle Quevillon – Adobe Engineer
• Using Flash Builder 4 – Debugging your applications
• Using Flash Builder 4 – Profiling Flex applications
• Using Flash Builder 4 – Monitoring applications that access data services