9 November 2009
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:
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.
for eachloop by clicking on line 34 and choosing Run > Toggle Breakpoint.
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.
thisinstance in the variables view.
rotatingImagein the Variables view.
sourceis a getter. Select the
_sourcevariable instance to monitor and click OK.
_sourceinstance is being changed (see Figure 2).
_sourceinstance for the
<mx:Image/>tag is changed.
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.
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).
itemvariable. If you look at the value of
itemyou 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).
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.
devnetFeed_resultHandler()in the code editor.
for eachloop, disable the conditional breakpoint that was set on line 34 by deselecting it in the Breakpoints view.
var aNumber:int = 1974.
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.
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.
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.
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.
Once the memory snapshot is available, double-click the BadTitleWindow class to open the Object References view (see Figure 6).
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.
_onPopupTimer()method of the main application MXML file.
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.
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