9 November 2009
To make the most of this article, you should have a basic knowledge of Flex development. You should also have a basic understanding of how to use the Flash Builder 4 IDE and how to import FXP Flex project archives.
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.
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.
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.
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.
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.
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.
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: