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

Flex 4 Rename week is complete

We have completed the scrubbing of our Flex 4 classes and completed the rename. Moving forward, no APIs should be renamed unless someone gives up their first born child and does a little jig on top of Mt. Kilamanjaro.

If you are interested in what was checked in during this rename, check out our open source site at:

http://opensource.adobe.com/wiki/display/flexsdk/Rename+List

By the way, the final rename that went in today was that the flex4.swc was renamed to spark.swc. (This might affect a few folks, so, I thought I’d call it out.)

Flex 4 List of Renames and API Changes

We have posted a list of API changes that we’ve been making to the Flex 4 API (this week) on the open source site at:

http://opensource.adobe.com/wiki/display/flexsdk/Rename+List

I will be updating this list as things change or get added. These API changes should not change, add or remove functionality,  in general. All of the changes fall into one of the following categories:

1) Direct rename of APIs, classes or package names

2) Removing properties or methods that are redundant with other methods or properties.

3) Moving some API from protected to private or vice versa.

4) Moving some properties or methods to base classes.

5) Changing the type of some properties.

You can grab these latest builds on the open source site, but, as I said in my last post, I wouldn’t recommend it until at least Monday when these renames should be over.

A messy week of renames for the Flex SDK

In case you are watching the SVN commits of the Flex SDK team, you might notice a lot of “renames” going in this week. This is actually a week reserved for the final “renames” of our Flex 4 (Gumbo) API. After this week, we are trying to NOT change the API for any reason before Flex 4 goes out.

But, in the meantime, this week is messy. I wouldn’t recommend grabbing one of our builds this week. Most of the documentation and many samples out in the wild have not caught up with these renames, so, you’ll have a tough time figuring out what changed to what unless you go and read all the SVN diffs and logs.

As the week comes to a close, we should finish our renames and I’ll publish a list of changes.

An easy vertical Spark ButtonBar skin

The default skin for the Spark ButtonBar was not really created for a vertical layout. It is suited for a horizontal layout where the first button and the last button look mildly different. The middle buttons will be all the same. Therefore, when you use a Spark ButtonBar and assign a VerticalLayout:

<s:ButtonBar dataProvider=”{myData}”>

<s:layout> <s:VerticalLayout /> </s:layout>

</s:ButtonBar>

your components doesn’t look that great. You will get something like this:

Notice that the first button has rounded corners on the left side and the last button has rounded corners on the right.

For a vertical ButtonBar, you probably actually want all of your buttons to look identical. In this case, you would create a custom skin and remove the optional skin parts for ‘firstButton’ and ‘lastButton’. The skin part ‘middleButton’ is required. The ‘middleButton’ is used for all of the buttons in a ButtonBar if no ‘firstButton’ or ‘lastButton’ exist.

Here is the code for my custom vertical ButtonBar skin:
<?xml version=”1.0″ encoding=”utf-8″?>

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

<fx:Metadata>
<![CDATA[
/**
* @copy spark.skins.default.ApplicationSkin#hostComponent
*/
[HostComponent("spark.components.ButtonBar")]
]]>
</fx:Metadata>

<s:states>
<s:State name=”normal” />
<s:State name=”disabled” />
</s:states>

<fx:Declarations>
<!– There is no skin part declared for firstButton or lastButton –>
<fx:Component id=”middleButton” >
<s:ButtonBarButton skinClass=”CustomButtonSkin” left=”0″ right=”0″ >
<s:filters>
<s:GlowFilter color=”0xFFFF66″ strength=”5″ />
</s:filters>
</s:ButtonBarButton>
</fx:Component>

</fx:Declarations>

<!—
@copy spark.components.SkinnableDataContainer#dataGroup
–>
<s:DataGroup id=”dataGroup” width=”100%” height=”100%” />

</s:Skin>
The differences in this custom skin are:

1) There is no firstButton and lastButton skin part.

2) I have chosen to use a custom skin for my middleButton ButtonBarButton because I wanted to change the cornerRadius of the buttons.

3) I’ve added a yellow glow to each button using a GlowFilter.

4) I’ve removed the layout assignment in the DataGroup of this skin.

Here is the resulting vertical ButtonBar. All of the buttons have a cornerRadius of 10 and a yellow glow.

Run the sample: ButtonBarExample.swf

Download the application and custom skins: VerticalButtonBar.zip

Note, I’ve customized the colors on the buttons of the ButtonBar using Advanced CSS (pseudo selectors and descendant selectors).