New 3.5 SDK released to fix AIR updater bug

Some of you might have noticed that we broke the AIR auto-update UI packaged with the Flex SDK with our release of the 3.5 Flex SDK. We got about 10 bugs all related to this subject. Oops…  Anyways, the problem has been resolved and a new 3.5a SDK has been released. Here is the official word:

“The Flex team has released an update to the 3.5 SDK that addresses an issue with the Flex-based AIR auto-update UI packaged within the SDK (SDK-24766). The refreshed build, SDK 3.5a,  has only a few files modified in order to fix this issue and this change does not affect the signing and caching of the SDK 3.5 RSLs originally released in December.

We encourage all developers using SDK 3.5 to upgrade their build to SDK 3.5a to continue their development. The SDK 3.5a can be found in the “Latest Milestone Release Build” table here: http://opensource.adobe.com/wiki/display/flexsdk/Download+Flex+3.”

Flex Bug Database upgraded to JIRA 4

Adobe finally did the upgrade to JIRA 4. Because we had so many customizations and teams using the same bug database, this upgrade took us a while. However, as of today, our instance of JIRA is now JIRA 4.

I have to say, the performance seems a lot faster. I hope you have the same experience!

http://bugs.adobe.com/flex

Avoiding a Flex 4 error when using PopUpManager.addPopUp()

There is a problem in Flex 4 when you using the PopUpManager’s addPopUp() method to create a pop up that has a Spark container parent. This problem was reported in a JIRA bug: SDK-25082. If you call addPopUp(), you will get the runtime error:

Error: removeChild() is not available in this class. Instead, use removeElement() or modify the skin, if you have one.
at spark.components::Group/removeChild()

Unfortunately, we didn’t have time to fix this bug in the Flex 4 time frame. So, the bug was deferred. However, there is a pretty simple workaround for the bug. In your code, you just need to parent the component that you want to pop up with an MX component.

Here are a couple of examples:

Error Example: AddPopUpErrorExample.swf, AddPopUpErrorExample.mxml

Workaround for Error: AddPopUpExample.swf, AddPopUpExample.mxml

If you would like this bug fixed in the future, please go to it and vote on it. Otherwise, this may stay a bug in the framework for all of eternity.

Compiler error with selectedChild in Flex 4 with code that worked in Flex 3

A customer filed a bug recently about a backwards compatibility issue that they ran into when trying to compile their Flex 3 application in Flex 4. Normally, your application should compile just fine, but, you might run into some behavioral differences between the two releases.  However, in the case described in bug SDK-25021, your application won’t even compile! When using the ’selectedChild’ property for any of the MX Navigators like TabNavigator, ViewStack or Accordion, you will get the following error in Flex 4:

Error: Implicit coercion of a value of type mx.core:INavigatorContent to an unrelated type flash.display:DisplayObject.

myViewStack.removeChild(myViewStack.selectedChild)

This code compiled fine in Flex 3, but, won’t compile in Flex 4. Unfortunately, we had to loosen the type of the selectedChild property to get the MX navigators working with Flex 4 Spark content. The type of selectedChild was ‘Container’, now it is ‘INavigatorContent’. In Flex 4, both the Container and NavigatorContent classes implement INavigatorContent. You will need to make some minor tweaks to your Flex 3 code to have it compiling in Flex 4.

To resolve the compile error, just cast your selectedChild property to a Container. For example, here is the Flex 3 code converted to Flex 4 code:

Flex 3: myViewStack.removeChild(myViewStack.selectedChild)

Flex 4: myViewStack.removeChild(Container(myViewStack.selectedChild))
I hope this makes the migration easier. Good luck!

MAX Talk: Moving from Flex 3 to Flex 4

MAX started off today a bit bumpy for me. I had a talk about “Moving from Flex 3 to Flex 4″ at 11:30 which was directly after the first keynote of the conference. Unfortunately, the keynote started 20 mins. late and ended 45 mins. late, so, while my session was supposed to be at max capacity (about 175 people), only about 25 people were in the room at 11:40 when I decided to start. By about noon, they asked me stop my presentation and restart it at 12:25 so that people coming from the keynote could still attend. Ahhh! What a pain. Anyways, thanks to the people who showed up on time to my talk and apologies that you had to wait so long for the talk to complete.

Finally, at 1:30 or so, the session ended.

Here are the slides for the presentation for those who are interested:

Slides: FlexMigration_shorter.pptx

I’m hoping for a smoother session on Wednesday at 11!

Update (10/9/09) – I’ve updated the slides since my presentation on Wednesday. I added more details about using TLFTextfield with Beta 2 to avoid embedding fonts twice when using MX and Spark components. I also fixed a typo I had in the States slide excludeIn -> excludeFrom.

Optimized FXG vs Runtime FXG (aka MXML Graphics)

Flex 4 offers you some new tools to draw graphic primitives like lines, curves, ellipses and rectangles. These new classes are all found in the spark.primitives.* package. They all subclass GraphicElement rather than UIComponent (like all of the other Flex components), therefore, they are more lightweight.

However, there are actually two different ways to include graphics in a Flex 4 application. You can include graphics in your application or skins using “optimized FXG” or MXML Graphics. Optimized FXG refers to the use of .fxg files as mxml components. These .fxg files can be exported from Fireworks, Flash Catalyst (when this product is available to the public), Illustrator and Photoshop. For example, here is a simple png that I created in Fireworks:

If you use are using Fireworks CS4, you can use the menu option Command -> Export to FXG.

This will produce an FXG file like: Star.fxg

Then, in your Flex application, you can simple use this as a custom component.

<s:Application xmlns:fx=”http://ns.adobe.com/mxml/2009″
xmlns:s=”library://ns.adobe.com/flex/spark” >

<g:Star id=”fxg_star” x=”10″ y=”10″ xmlns:g=”*” />

</s:Application>

There are some limitations to using optimized FXG, however. While, you can scale, resize and move it, you cannot change any attribute of the graphic. For example, if you wanted to change the colors in the LinearGradient of this star, you would not be able to. The base class that wraps .fxg is spark.core.SpriteVisualElement.

If you want to create graphics where you can change attributes at runtime, then, you will want to use MXML Graphics. Here are the mxml tags that you would use to create the same star:

<s:Graphic y=”20″ horizontalCenter=”0″>
<s:Path winding=”evenOdd” data=”M 50 13 L 65 33 L 90 39 L 74 58 L 75 82 L 50 74 L 24 82 L 25 58 L 9 39 L 34 33 L 50 13 Z ” blendMode=”normal” alpha=”1″>
<s:fill>
<s:RadialGradient x = “56″ y = “52″ scaleX = “81″ scaleY = “81″ rotation = “0″>
<s:GradientEntry id=”gradientColor1″ color=”#666666″ ratio=”0″ alpha=”1″/>
<s:GradientEntry id=”gradientColor2″ color=”#339999″ ratio=”1″ alpha=”1″/>
</s:RadialGradient>
</s:fill>
<s:stroke>
<s:SolidColorStroke color=”#ffff33″ weight=”2″/>
</s:stroke>
</s:Path>
</s:Graphic>

Now, that this is defined in an application, you can edit any of the colors of the fill or stroke or the data for the Path at runtime.

In this sample, you can change the gradient colors of the star at runtime using the ColorPickers.

Sample Application: MXMLGraphic_Star.swf

Sample Code: MXMLGraphic_Star.mxml

Speaking at MAX 2009 – Moving from Flex 3 to Flex 4

I’ll be speaking at this year’s Adobe MAX Conference in Los Angeles from Oct 4-7 on the topic “Moving from Flex 3 to Flex 4″. Here is the official description on the catalog:

“Learn about the new features in Flex 4 from the perspective of someone who has been doing Flex 3 development. We’ll discuss changes in MXML, states, effects, and CSS, as well as the new component model. This session is a must for developers who know Flex 3 and want to understand the best way to move forward with Flex.”

I’m not sure who came up with this description, but, I don’t think its that accurate saying that this is from the perspective of someone who has been doing Flex 3 development. It should probably say, “from someone who has been testing the Flex framework since Flex 1.5″. But, oh well…  The talk will be on Monday, Oct 5 at 11:30 AM and Wed, Oct. 7 at 11:00 AM. I hope to touch on all of the topics that Flex 3 developers may find challenging when moving to our next version of Flex including the new namespaces, set of components, skinning architecture, layouts and states. If you have a particular topic that you want me to address, let me know. I’ll see you at MAX!

Supported Styles for Spark in Flex 4 – New Spec Posted

Once people got their hands dirty in Flex 4, one of the first road blocks that they hit was in styling. Our philosophy was that Flex 4 and its new Spark theme would provide people a much more flexible (no pun intended) way of skinning. Out of the box, we only provided a couple of global styles including baseColor, focusColor, color, symbolColor, contentBackgroundColor, rollOver, selectionColor and the text supported styles.  These knobs were supposed to allow you to change the overall look of your entire application very quickly. However, if you wanted to do anything else, you had to create a custom skin using our new mxml graphics and states syntax.

People coming from Flex 3 were wondering… “How do I change a border?”, “Can I change a background?”, “What about cornerRadius?”… “Why didn’t fillColors work anymore?”. All of the these styles that made making small tweaks easy, were now gone in the Spark skins. (They are still all available if you use the Halo skin, btw).

After much thinking, pondering, and looking over schedules, it was decided that we would bring back support for some of the styles (definitely not ALL of them).  Glenn just posted a spec yesterday discussing this upcoming work and is looking for feedback:

http://opensource.adobe.com/wiki/display/flexsdk/More+Styles+for+Spark+Skins

We are trying to find the compromise between keeping the skins flexible and lightweight and providing enough convenience knobs to change appearance easily.  Again…. we are looking to the community to provide some feedback on whether the right styles were chosen to support.

Happy Reading!

MXML Graphics: Verbose syntax for Path is gone

As of last week, the Flex SDK removed support for the ‘verbose’ syntax for creating Path data. In the past, you could create a Path using two methods:

short syntax, just using the ‘data’ property:

<s:Path data=”M  9 0 L 9 55 L 70 55 z” />

and the long “verbose” syntax which was more readable:

<Path>
<segments>
<MoveSegment x=”9″ y=”0″ />
<LineSegment x=”9″ y=”55″ />
<LineSegment x=”70″ y=”55″ />
<CloseSegment />
</segments>
</Path>

The long syntax is no longer supported. Here is more information, if you want to know the reasoning behind this change:

http://opensource.adobe.com/wiki/display/flexsdk/Verbose+Path+Syntax

Also, here are additional changes that Deepa mentioned in her check-in notes for svn 8589.

1. Path.segments property removed. In its place, there is private variable (segments) which holds the path data parsed into the correct segment objects.

2. Path.segmentChanged() removed ?\226?\128?\147 Segments do not need to notify the parent path when their properties have changed since they are now not individually accessible.

3. PathSegment.segmentHost property removed ?\226?\128?\147 Segments do not need a pointer back to the parent Path since now they are now not individually accessible.

4. PathSegment.notifySegmentChanged() removed ?\226?\128?\147 Segments do not need to notify the parent Path they have changed since they are now not individually accessible.

5. PathSegment.dispatchSegmentChanged() removed ?\226?\128?\147 Path segments do not need to dispatch propertyChange events since they are now not individually accessible. As part of this, I have removed the [Bindable] and   [Inspectable] metadata from all PathSegment properties.

6. PathSegment no longer extends EventDispatcher, instead it extends Object.

7. All of the PathSegment and derivative classes no longer have getters/setters for their properties (like x, y, etc) since these properties are now not dispatching property change events.

8. A variety of checkintests/sparkTest project files have been updated to use the compact syntax as they are drawn/transitioned between state changes. Refer to sparkTest/AddItemsTest.mxml and RemoveItemsTest.mxml for examples on how to use states and transitions to transform Paths through the data they are bound to (as opposed to modifying individual segments).

RSLs on by default in Flex 4

As of last week’s Flex 4 builds, using the framework RSL has now been turned on by default. If you compile with one of these builds, you will probably notice a difference in your start up time. If you are compiling a small Flex 4 application, the start up may be slower than it used to be. This is because the RSL takes some time to get parsed int he beginning. But, in the end, when you are building real life applications which are much larger, using the framework RSL should be extremely beneficial.

One problem that I did run into was when having RSLs on by default was when I had an application using runtime CSS. I documented this in bug SDK-22172. Not thinking, I compiled my css file with the defaults. Apparently, this is not recommended. My bug was marked “Not a Bug” and I was given this advice:

“CSS modules are loaded into the same application domain as the application that loads them. Assuming the application has loaded all the needed RSLs, then CSS modules do not need to load RSLs. In this scenario the CSS modules should be statically linked and also externalize the swcs linked as RSLs in the main application. Swcs are externalized by adding them to the compiler’s “-external-library-path” option. The amount of benefit depends on how many classes are referenced in the css file.”

By the way, if you want to compile an application without using rsls, you would add the compiler argument: -static-link-runtime-shared-libraries=true