Usually you would add an event listener on the scrollers verticalScrollBar but due to a bug it does not fire events [...]]]> If you want to implement lazy loading (when the user scrolls to the end of the list it triggers to fetch more items) for a spark List control you have to use a workaround right now.

Usually you would add an event listener on the scrollers verticalScrollBar but due to a bug it does not fire events if the user scroll with the mouse wheel or uses the arrow buttons. The bug shows a workaround by listening to the PropertyChangeEvent of the scrollers viewport.

Here a little example app:

The bug has been fixed for Flex 4.5. If there is a better workaround for Flex 4.1 please let me know.

“FXG is a declarative XML syntax for defining vector graphics in applications built with Flex.”

When you declare FXG within your MXML it is computed at runtime but there is also a way to use compile [...]]]> FXG was introduced with Flex 4 and offers a great way to skin and style your application without relying on bitmaps like PNGs.

“FXG is a declarative XML syntax for defining vector graphics in applications built with Flex.”

When you declare FXG within your MXML it is computed at runtime but there is also a way to use compile time FXG. There is up to 10x improvement in memory consumption and start-up time when converting complex MXML Graphics (with lots of Paths) into FXG.

Deepa explains it like this:

“This is an optimization scheme which takes advantage of the fact that a lot of FXG content is simply static assets that do not need to be updatd or re-rendered at runtime. In cases like that, you could imagine that instead of creating ActionScript objects to represent those graphic elements, the Flex compiler could instead create SWF graphic primitive tags to draw the static FXG asset”

So there is some benefit in using compile time FXG and in many cases you can just copy and paste the FXG to an .fxg file with some minor syntactical changes. The downside of compile time FXG is that you have to specify fix dimensions. This means you cannot use percentage values for the width and height.

Let’s look at an example which uses FXG to define the background of a Group.
Comparison:

Runtime FXG

Compile-time FXG

You see that you can instantiate the Background.fxg like any other class.
The differences between compile and runtime are fairly simple:

• Add a Graphic tag
• Replace spark namespace with default namespace
• Change numeric values 0x to #
• Define fix width and height

Another difference is that you have to apply a scale-9-grid for the background in case of rounded corners and filters. This would like like this:

These are still simple examples and it can get way more complex and you will run into limitations. Compile time FXG was developed by Peter Farland from the Flex side and he gave some inside about the limitations of compile time FXG in combination with scale-9-grid:

• An item with a scaling grid cannot have child <Group> elements (because ata lower level a scaling grid cannot be applied to a DefineSprite that has a child DefineSprite(s)… this also means that you can’t use a scaling grid with children that are ultimately DefineSprite based including <RichText>,or a custom Library Definition, and I think if alpha masks, luminosity masks, or pixel-bender based blend modes (such as colordodge, colorburn,exclusion, softlight, hue, saturation, color, luminosity) are applied).
• A scaling grid must be a valid rectangle – i.e. the resulting rect must have a non-zero width and height and the left extent must be to the left of the right extend, and the top extent must be above the bottom extent.
• The scaling grid¹s center rectangle must be wholly within the bounds ofthe item(s) being scaled.
• Rotated items cannot be scaled with a scaling grid (I think? though notethat restriction doesn’t apply to rotated gradient fills applied to shapesbeing scaled, for instance).
• There are several bugs when applying a scaling grid to a collection of child shapes – adding a transparent Rect underneath that spans the bounds of all of the child shapes can help.
• When manually calculating the dimensions of a scaling grid you need to consider the total bounds of the item(s) being scaled. This must take into account the stroke width, miter and joint types. Watch out for fractionalpixels of strokes that apply once an item is scaled.

Conclusion
Try to use compile-time FXG when possible. The performance of your application will improve and you have a better separation of design and code which is one step further for the designer/developer workflow.
For further reference check the FXG 2.0 Specification

.

To apply a custom skin to the ActionBar you first have to define a [...]]]> It took me a bit to figure out how to skin the ActionBar in a mobile AIR application so here a short tutorial. There are also two small bugs when you want to skin the ActionBar but there are decent workarounds for now.

To apply a custom skin to the ActionBar you first have to define a skin for the MobileApplication itself.

In the ApplicationSkin.mxml you have to define a ViewNavigator component with the id navigagor:

The ViewNavigatorSkin.mxml contains the push and pop transition, the ActionBar component and the content group.
Due to a small bug in the SlideViewTransition.as you have to set the direction to right on creationComplete:

Finally we can create the ActionBarSkin. There is another small bug so for now you have to define an empty Group at the 1st position.

So right now you have to create 4 different skins to change the dimensions and look of the ActionBar. From an architectural standpoint this looks very clean but having to create 4 skins to just change the height is kind of overkill.
MobileApplication should expose a style to define the dimensions of the ActionBar and should support to set the actionBarSkin right away.

You can download the example project here. The example uses compile-time FXG for the ActionBar background. More on that in a later post.

Since 1.5.3 the publisherID works differently so [...]]]> Now that Adobe 2.0 is released it’s time to update some older apps to use the new APIs.
The process to update seems kind of complicated and definitely worth a blog post. In my special case I am upgrading from an self signed 1.5.2 app to a self signed 2.0 app.

Since 1.5.3 the publisherID works differently so you have to add the publisherID to the XML descriptor like also described here. If you are not using EncryptedLocalStore you might be fine by now but otherwise you get this error when you debug the application: EncryptedLocalStore may not use publisher IDs passed in from ADL

A quick search lead me to add the publisherID to the debug configuration but then you get the error that the publisherID can’t be passed anymore by ADL since 1.5.3, damn.

More research brought me to this forum thread. So it looks like this bug is in the AIR 2.0 final so the only solution is to remove the publisherID from the descriptor while debugging the application. Before packaging the app you then have to add it to not break the update for your users who still have the older version of your app.

Ok, I removed the publisherID and finally could run my app with AIR 2.0, not! My next runtime exception is TypeError: Error #1034: Type Coercion failed: cannot convert flashx.textLayout.formats::TextLayoutFormat@184eb041 to flashx.textLayout.formats.TextLayoutFormatValueHolder.

Solution is to change TextLayoutFormat to TextLayoutFormatValueHolder like here:

var cfg : Configuration = TextFlow.defaultConfiguration;
var normalTLF : TextLayoutFormat = new TextLayoutFormat( cfg.defaultLinkNormalFormat );
cfg.defaultLinkNormalFormat = normalTLF;

to

var normalTLF : TextLayoutFormatValueHolder = new TextLayoutFormatValueHolder( cfg.defaultLinkNormalFormat );

Now I can finally run the app with AIR 2.0 without any runtime exceptions or other errors, uhh!
The TextArea default height seems to have changed though but that’s for another time.

If you want to let something only happen if the event wasn’t canceled it should [...]]]> When you dispatch events I bet that most Flash/Flex devs don’t take advantage of the fact that dispatchEvent returns a Boolean value indicating wether or not the event has been canceled. Normally your code looks similar to this:

var event:MyEvent = new MyEvent(MyEvent.FOO);
dispatchEvent(event)

If you want to let something only happen if the event wasn’t canceled it should look like this:

// The second "true" sets the event cancelable, first one sets bubbles
var event:MyEvent = new MyEvent(MyEvent.FOO, true, true);
if(dispatchEvent(event)){
   // do the actual task
}

With the code above the event listener can control if the actual task gets executed or not:

dispatchingInstance.addEventListener(MyEvent.FOO, fooHandler);
function fooHandler(event:MyEvent):void{
   // depending on what you want to achieve you can cancel the event by calling preventDefault
   event.preventDefault();
   // this will cause dispatchEvent to return false so the actual task doesn't get executed
}

A real life usecase for UI related events could be dispatching an event before closing a popup window:

function closeButtonHandler(event:Event):void{
   if(dispatchEvent(new MyWindowEvent(MyWindowEvent.CLOSE, true, true)){
      PopUpManager.closePopup(this);
   }
}

Cancelable events are also very interesting when you develop APIs because it offers powerful and easy to use hooks for the API user.
I am making heavy use of cancelable events in my swizdesktop lib. Catching the different update phase events you get hooks to stop the update process by calling preventDefault on the listened event.

Description Resource Path Location Type 1044: Interface method invalidateParentSizeAndDisplayList in namespace mx.managers:ISystemManager not implemented by class _Main_mx_managers_SystemManager. example-project line 23 Flex Problem

Description Resource Path Location Type 1144: Interface method callInContext in namespace mx.core:IFlexModuleFactory is implemented with an incompatible signature in class _Main_mx_managers_SystemManager. example-project line 23 Flex Problem

The location/resource for these errors is the main MXML itself [...]]]> I ended up a few times with these kind of errors while migrating to newer Flex 4 builds:

Description Resource Path Location Type
1044: Interface method invalidateParentSizeAndDisplayList in namespace mx.managers:ISystemManager not implemented by class _Main_mx_managers_SystemManager. example-project line 23 Flex Problem

Description Resource Path Location Type
1144: Interface method callInContext in namespace mx.core:IFlexModuleFactory is implemented with an incompatible signature in class _Main_mx_managers_SystemManager. example-project line 23 Flex Problem

The location/resource for these errors is the main MXML itself but that’s all you get. So you ask yourself what went wrong? A quick Google search does not help (until I blogged this hopefully) so where to start?

The problem is that you are mixing different SDK versions. In my case my project linked to a library which was compiled with a different SDK version and now the important thing: the framework linkage in the library was set to “Merge into code“. Change it to “Use default (external)” and you are fine.

Uploaded with plasq‘s Skitch!

Halo is now mx

The namespace for halo (Flex 3) components changed from xmlns:mx=”library://ns.adobe.com/flex/halo” to xmlns:mx=”library://ns.adobe.com/flex/mx”. Just [...]]]> I have a project based on Flex 4 Beta 2 and now I wanted to migrate to the latest nightly build since there were many important fixes.
Things have changed so here what I did to get my project up and running again:

Halo is now mx

The namespace for halo (Flex 3) components changed from xmlns:mx=”library://ns.adobe.com/flex/halo” to xmlns:mx=”library://ns.adobe.com/flex/mx”. Just do a quick search and replace and this one is solved. Also do not forget to update you CSS file namespace to @namespace mx “library://ns.adobe.com/flex/mx”;

Flex 3 compatibility mode is gone

My project originally was based on Flex 3 so I used the Flex 3 compatibility option in Flex 4 Beta 2. This does not seem supported anymore and you get lots of dependency errors for halo/mx components that they require at least 4.0.0. So disable the Flex 3 mode and select the halo theme to be still compatible with Flex 3 aka halo components.

Ant

I build my AIR project with Ant so I had to define to use the halo theme:

<compiler.theme dir="${flex.sdk.dir}/frameworks/themes/Halo/">
	<include name="halo.swc" />
</compiler.theme>

In my case I switched to build 4.0.0.13323 and it looks pretty cool. The compiler seems faster and my app in general performed well. There is now also a Spark ToggleButton but a few things are still missing like IconButton, SparkAlert and so on. Anyway, I use Flex 4 for production already and feel pretty solid about it. The workflow is way better than with Flex 3 because of the new state syntax, better skinning, FXG, light weight groups etc.