Prerequisites:

• Debug version of Flash Player
• SWF file that has been compiled in debug mode
• The preloaded SWF must be local trusted.

Following is how you can ensure that the prerequisites are being met and possible resolutions:

I. To ensure that you are using the debug version of flash player, you can simply compile and run the following mxml code and it should list the version and also if it supports debugging or not:

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="horizontal" creationComplete="application1_creationCompleteHandler(event)">
	<mx:Script>
		<![CDATA[
			import mx.events.FlexEvent;
			protected function application1_creationCompleteHandler(event:FlexEvent):void
			{
				playerVersion.text = Capabilities.version;
				isDebugger.text = String(Capabilities.isDebugger);
			}
		]]>
	</mx:Script>
	<mx:Label text="Version"/><mx:Label id="playerVersion"/><mx:Label text="Supports Debugging? "/><mx:Label id="isDebugger"/>
</mx:Application>

Resolution: Reinstall debug version of flash player.

II. To ensure that you are using the debug version of the SWF, you can run swfdump on the swf file. The swfdump generates an XML report. Look for tags like EnableDebugger2 and DebugID in the report. If these tags are missing then you are probably running a release mode swf.

Resolution: Recompile SWF with debug info. To do this from command line add -debug=true to mxmlc command. To do this from Flash builder, make sure debug is not set to false in additional compiler arguments or a local config file.

III. To ensure that PreloadSwf is local trusted, you can follow the following steps:

1. Run tail -f command on the mm.cfg file and then click the start button in code coverage plug-in.
   The mm.cfg file is present at the following location:

   XP: C:\Documents and Settings\username
   Vista/Win7: C:\Users\username
   Mac: /home/username or if that doesn’t exist: /Library/Application Support/Macromedia

   After you click the start button, the plugin should add a PreloadSwf entry to the mm.cfg file. If it doesn’t then you should make sure that mm.cfg is writable and that the user has permissions.

   An example of PreloadSwf entry:
   PreloadSwf=/Users/username/Documents/Adobe Flash Builder 4/.metadata/.plugins/com.adobe.flash.codecoverage/CodeCoverageAgent.swf?host=localhost&port=9900&level=0

   Note down the absolute path of folder containing CodeCoverageAgent.swf. It should be in your FB workspace at <workspace>/.metadata/.plugins/com.adobe.flash.codecoverage

   Also the plug-in removes the PreloadSwf entry when you click the stop button

2. Inspect at the trust files.
   Location of trust file (per-user):
   XP C:\Documents and Settings\username\Application Data\Macromedia\Flash Player\#Security\FlashPlayerTrust
   Vista/Win7: C:\Users\username\AppData\Roaming\Macromedia\Flash Player\#Security\FlashPlayerTrust
   Mac: /Users/username/Library/Preferences/Macromedia/Flash Player/#Security/FlashPlayerTrust

   Location of trust file (global):
   XP/Vista/Win7 C:\WINDOWS\system32\Macromed\Flash\FlashPlayerTrust
   Mac /Library/Application Support/Macromedia/FlashPlayerTrust

   The trust file is usually called flashbuilder.cfg. Make sure that the path of folder containing CodeCoverageAgent.swf is present in the trust file.

Resolution: Add parent folder of CodeCoverageAgent.swf to the trust file. If the trust file is not present create a new trust file. Also it is important to restart your browser/AIR after changes to the trust file.

If all the prerequisites are being satisfied then make sure that the port number (9900) is free for use by code coverage plug-in. In case 9900 is not available then you should update the port number in the code coverage preferences.

These enhancements should provide the following benefits:

• Applications will only load RSLs that are required
• Modules (and sub applications) will use RSLs which are already loaded by the parent application (or module)
• Enable sharing of RSLs between modules (and sub applications)
• Simply usage of Monkey Patch with Flex RSLs

Only load what’s needed

In Flex 4, all RSLs that were listed in the flex-config.xml (at compile time) were loaded by the app when it was launched. But with the Hero release the compiler will remove any RSLs which are not needed by your application. This means that the load time for your app should improve because it won’t load any extra RSL. The RSLs removed by the compiler will be the placeholder RSLs. This feature is controlled by a new compiler switch called -remove-unused-rsls which defaults to true.

Also if you compile your app using the command line compiler, then it will print the names of the RSLs that are needed by your application. The following is an example of compiler output where the app uses 3 out of the 10 RSLs listed in flex-config.xml

There could be cases where the compiler may remove RSL which is needed by your app (say if you used soft-linking to load classes from a swc). If you run into such a situation then you can override the compiler’s decision, to remove the RSL, by using the -force-rsls compiler switch. This option takes the path of the swcs for which the RSLs should be force loaded.

Use what’s already loaded

Starting with Hero, modules and sub-applications will use the RSLs loaded by the parent app instead of loading a duplicate copy.

When a module or sub-application loads a new RSL, the RSL will be loaded into the default application domain and if this was the placeholder RSL for the parent app then it will be loaded into the parent’s application domain. Now if the parent app loads another module or sub-app which needs the same RSL then it will be able to use the RSL loaded by previous module or sub app.

The image below is an example of application where the OSMF RSL is removed by the compiler and so it becomes the placeholder RSL for the main app.

In the following image, the main app loads a module that uses spark video player. The module needs OSMF RSL so it loads it into the app domain of the parent application because OSMF RSL is a placeholder RSL. The module does not load the Framework or Spark RSLs because those were already loaded by the parent app.

Now if the main app loads another sub app which needs OSMF RSL, then the sub-app will simply be able to use the OSMF RSL loaded by the module.

You can also specify the application domain where the module should load the RSL. The -application-domain compiler option takes the path of the swc and then the name of the application domain. The valid values for application domain are ‘current’, ‘default’, ‘parent’, or ‘top-level’

Smaller Framework RSL

In Hero, we also reduced the size of the framework RSL. This was done by removing all mx components from framework.swc and moving them to a separate swc called mx.swc. So if you are creating pure spark apps then you don’t need to load any mx classes.

Monkey Patch RSL

The only way to use monkey patches with Flex RSLs is to load monkey patched file as RSL itself. But again it was quite tedious to create a monkey patched RSL, so to simplify that a new compiler option (called -include-inheritance-dependencies-only) was added. This option can be used when compiling the monkey patched library. This options works with -include-classes flag and it only pulls dependencies which are of type inheritance. An example for usage of this option:

bin/compc -include-classes=spark.components.Button -sp=frameworks/projects/spark/src/ -include-inheritance-dependencies-only=true -output=patch.swc

In the above example, the output swc will contain spark.components.Button and only it’s inheritance dependencies. And the library.swf contained in the output swc can be used as an RSL if you were to monkey patch the spark button component.

Most of these changes (except for the -application-domain compiler option) are already available in the latest Hero preview build.

For documentation related to the tool you can go here

This tool allows for the following:

• Choose between line and/or method level coverage
• Apply filters on the view – so you can hide packages in which you are not interested
• Save detailed reports – so you can view them later and compare with other coverage reports for your code base
• Export high level coverage summary – This is a csv based summary of coverage for your code base

When you save a detailed report, it creates two files on your system .ascc and .ascs. The .ascs file is a compressed file that contains the sources on which the coverage was performed. So if you want another engineers on your team to look at the coverage data, just give them the two files and they won’t need to sync to the sources on their computer (because the sources for the report will come from .ascs file).

It can even be used to perform code coverage for more than one applications at the same time (may be you have a library or framework for which you have a ton of test cases).

I encourage you to try the tool, and if you have any questions or feedback please use the forum.

Flex 4 has multiple themes:

1. Spark: The default theme for Flex 4. It contains the skins for Spark and MX Components
2. Halo: The default theme for MX components (if you set -compatibility-version=3.0.0)

Some style can be valid for only one theme but not the other. So if an app uses such a style(valid for one a specific theme), the style won’t work if the theme is switched. This could lead to confusion. To help avoid such situation the Flex 4 compiler is stricter than then Flex 3 compiler.

Flex 4 compiler now validates the styles against the theme.

So for example, if you have an app like:

<?xml version="1.0" encoding="utf-8"?>
<s:Application xmlns:fx="http://ns.adobe.com/mxml/2009" 
			   xmlns:s="library://ns.adobe.com/flex/spark" 
			   xmlns:mx="library://ns.adobe.com/flex/mx">
	<mx:Button label="Hello World !!" borderColor="#FF0000" />	
</s:Application>

Compiling it with the Flex 4 will generate an error like: Error: The style ‘borderColor’ is only supported by type ‘mx.controls.Button’ with the theme(s) ‘halo’.

If however, you had specified the “borderStyle” using an external css file or the <Style> block , for example:

<?xml version="1.0" encoding="utf-8"?>
<s:Application xmlns:fx="http://ns.adobe.com/mxml/2009" 
			   xmlns:s="library://ns.adobe.com/flex/spark" 
			   xmlns:mx="library://ns.adobe.com/flex/mx">
	<fx:Style>
		@namespace mx "library://ns.adobe.com/flex/mx";
 
		mx|Button#buttonId
		{
			borderColor: #FFFF00;
		}
	</fx:Style>
	<mx:Button label="Hello" id="buttonId" /><mx:Button label="World" />		
</s:Application>

Compiling it with the Flex 4 would generate a warning like: Warning: The style ‘borderColor’ is only supported by type ‘mx.controls.Button’ with the theme(s) ‘halo’.

So the rule is “error if invalid style specified inline”, and “warning if invalid style is specified using css/<Style> block”

The recommended way of resolving these warnings/errors is to update the code.

But there may be situations where you would want to re-use some of the components written for your flex 3 apps into the flex 4 apps. If for some reason you can not update those components, you can make use of the newly introduced compiler switches (and buy yourself some time)

The new switches are:

1. -report-invalid-styles-as-warnings: this can be used if your app specified styles inline, and those styles are not valid for the current theme. The default value for this is false, and setting it to true will enables reporting of invalid styles as warnings.
2. show-invalid-css-property-warnings: this can be used if you app specified styles using the css files/<Style> block, and those styles are not valid for the current theme. The default value for this is false, and this switch can be used to toggle whether invalid css property warnings are reported.

You can download the latest nightly builds for Flex 4 from http://opensource.adobe.com/wiki/display/flexsdk/Download+Flex+4