After taking a year away from the Flash world entirely (to reno and flip houses...that's a story for another day), I've returned to experience a sense of excitement and energy that I haven't felt personally since the days of Flash 3. Sure, there were other periods in Flash history that produced moments of near euphoria:

• ActionScript introduced in Flash 5
• Flash Video introduced in Flash MX
• AS2 in Flash MX2004
• Bitmap effects in Flash 8

However, the era that I look back on with the most warm fuzzies was back in the day when nrg.be and matinee.co.uk made heads spin with their sheer slickness and everyone hung on the edge of their chairs for the new version of Gabocorp. You know...the days when motion tweens were in, and TellTarget was for "real" coders. That was what birthed in me a REAL passion for Flash, and I knew back then it was what I wanted to do. Now it's 10 years later and things have changed substantially in a way that few of us would have predicted. A lot of Flash designers have moved into the role of "developer" and learned a thing or two about programming through this thing called ActionScript. And now we even have our own "developer" IDE in FlexBuilder. Who would've thunk it?

Yet, as I read the blog posts and see the excitement over Flash/Flex/Apollo/etc. I can't help but feel somewhat the same as I did 10 years ago. A sense of buzz over what the future holds for Flash, centred largely around this framework called Flex. A lot of people talk about how Flex has changed the Flash ecosystem (some wonder where designers are left in all of this). I can't help but think of the possibilities the future holds for us. At what point in the past have we had:

• Flash player being adopted as quickly as it is now.
• A framework and component set as rich and robust as that of Flex (having worked extensively on Flash frameworks before, I know that to build something that everyone - or at least a majority of developers - will find useful isn't an easy task)
• Flash being taken more and more as a serious platform
• A Flash based runtime that allows cross platform development of desktop apps!
• The explosion of new Flash/Flex jobs
• The financial backing of a company like Adobe to further move this thing in the right direction.
• A "real" developer IDE that Adobe has committed to improving upon (remember that the next version of Flex will target Flash player 9 - so this next version will be entirely IDE and framework improvements and not new player features)
• A build of the Flash IDE that will tightly integrate with Photoshop and Illustrator (though details on this are still unknown)
• The capability of even approaching realtime 3-D rendering in a practical way(rock on guys \m/ ;).

I think it's a great time to be a Flash/Flex developer. Even though we're far removed from the days of Flash 3, I anticipate looking back on these days 10 years from now with the same fondness as I do those days 10 years ago, knowing that we were on the verge of going somewhere bigger than we were (at least if I'm not off flipping houses... :)

I look forward to posting useful tidbits on anything Flash related in the coming days and weeks...

In Flex 2, it's pretty safe to say that we are presented with the largest framework ever developed for the Flash platform. What that means for us as developers is that we have more power at our fingertips than ever before to build larger, more robust applications. At the same time, it means that in order to use the framework at more than a surface level, we need to learn a lot about the framework API, as well as how to use the framework to build the custom bits and pieces that every project requires (i.e., components). If you've looked at the number of components and classes in the Flex framework, this appears to be a daunting task.

Adobe has done a great job of documenting the framework (my new best friend is the Flex Language Reference), but sometimes you need to muck around a bit to make the framework do what you need it to do in any given situation.

[Flexcerpts 201] is a series of posts that aims to break down the framework into bits (excerpts) and try to understand these bits better. If we can understand enough of these bits, hopefully we'll have gained a stronger understanding of the framework as a whole and how we can do things like extend components or maximize the use of existing ones.

Watch this space for posts in the coming days and weeks...

Not really an official Flexcerpt, but something that might be useful when embedding assets...

One thing that's been discussed a lot is the hassle of embedding assets in Flex and then adding them to the stage. At the core of the issue is that everything in the Flex world IS a UIComponent. This is necessary so that the framework can "talk" to components within it through a known API (particularly with respect to Containers). So if you try to create a custom class that extends, say flash.display.Sprite, and try to add it to the stage, you get a runtime error called something like "Type Coercion Failed". This is due to line 3301 in mx.core.Container (in the addingChild method):

// Throw an RTE if child is not an IUIComponent
var uiChild:IUIComponent = IUIComponent(child);

As you can see, a check is made to see if the child being added implements IUIComponent, and if it fails that check, then the error occurs. The sole purpose of that line of code is to throw a runtime error (uiChild isn't actually used elsewhere in that method). Grant has a very simple and effective solution to this called DisplayObjectWrapper. Head on over there and grab it, but basically, the premise is that since ALL Container based components in the framework require children to implement IUIComponent (ie., extend UIComponent), you can first wrap the asset in a UIComponent before adding it to the stage. Note that NON-Container based components don't have that same requirement for its children, which is why this works.

In Grant's example, he uses a DisplayObjectWrapper mxml tag to draw the asset to the stage. Works great. Then I tought, ok, let's use ActionScript instead of mxml to add it to the stage. Problem is that for some reason which I couldn't figure out, I couldn't access my asset's class from AS (to be honest, I haven't really done this as I generally use mxml to add assets). Then I stumbled upon this...

It appears that when the asset is embedded into the swf, it gets assigned a classname that looks like "ProjectName_AssetClass". So for example, let's say you have a project called "PhilterBlog", and you embed the following asset:

[Embed(source="assets.swf#Logo")]
public var Logo:Class;

Then you would do something like this:

import com.gskinner.ui.DisplayObjectWrapper;
var wrapper:DisplayObjectWrapper = new DisplayObjectWrapper(PhilterBlog_Logo);
addChild(wrapper);

Note the class name of the asset I used (PhilterBlog_Logo). Also note that you don't need to create an instance of your asset because DisplayObjectWrapper does it for you :)

Anyway, this is as much for my own reference as it is for others as I hadn't seen this elsewhere, but feel free to point me to other urls if this is widely known about embedding assets.

Since everything in the Flex framework essentially must be a UIComponent, we'll start with examining some of the inner workings of this class. In this Flexcerpt, we discuss how invalidation is implemented in UIComponent and why it is important when extending existing components or creating your own.

Invalidation is based on the premise that all displayable objects (anything that is a DisplayObject) are only drawn to the stage once every frame (since Flash is timeline based). In a nutshell, invalidation refers to delaying the drawing of a component until the next frame, so that we save processor cycles by only running that draw code once. "Drawing" can refer to things such as sizing (including measuring), displaying text, updating a skin, or changing any visible property of a component.

For example, what if the height value of a component was set 3 times during the same frame? If the component were to "redraw" itself immediately every time the height value was changed, it would be drawing 3 times, when it really only needs to draw itself once based on the last value that was set in that code block. This is a simple example, but when you consider that within the framework, there may be hundreds of lines of code executing when components are drawn (depending upon the complexity of your app), obviously, we want to prevent unnecessary redraws whenever we can. Enter invalidation...

There are 3 invalidation methods implemented in the framework:

• invalidateProperties (commits properties)
• invalidateSize (does measuring)
• invalidateDisplayList (does layout)

These methods are called interally within Flex components when the component has something done to it that requires it to be redrawn. Often, more than one of these will be called within the same method. Here is an overview of the code execution that occurs with each of the invalidation methods (not all called methods are shown here to simplify things a bit):

> UIComponent.invalidateProperties() > LayoutManager.invalidateProperties() > enterFrame/render > LayoutManager.validateProperties() > UIComponent.validateProperties() > UIComponent.commitProperties()

>UIComponent.invalidateSize() > LayoutManager.invalidateSize() > enterFrame/render > LayoutManager.validateSize() > UIComponent.validateSize() > UIComponent.measureSizes() > UIComponent.measure()

>UIComponent.invalidateDisplayList() > LayoutManager.invalidateDisplayList() > enterFrame/render > LayoutManager.validateDisplayList() > UIComponent.validateDisplayList() > UIComponent.updateDisplayList()

As you can see, the flow is very similar among these methods. So why does this really matter? Well, here are a few things I took from this:

• When extending components, the methods that you want to override if you want to draw things to your custom components are the ones at the END of the execution order, so specifically, "measure", "updateDisplayList" and "commitProperties". You can be assured that these methods will be called when needed to redraw the component. Don't forget to call the super's overriden method.
• When creating methods/properties in your component that will result in needing to redraw the component, make sure you call one of the invalidation methods. If the size is changing, call invalidateSize. If you want to update a text label, call invalidateProperties (and possibly invalidateSize and invalidateDisplayList if your label could have an impact on how your component is sized).
• Its important to note that if more than 1 of these invalidation methods gets called before the next frame, they will execute in the order above (ie., commit properties, then measure, then layout).
• Layout management plays a big role in all of this and is definitely worthy of a set of posts on its own. However, gist of it appears to be that measurement occurs "inside-out" and layout occurs "outside-in". So when measuring components for resize, the framework starts with the deepest nested child component and works up the parent chain, and once that's complete, it starts with the topmost parent and lays out its children, who then lay out their children, etc.
• Container based components also call Container.layoutChrome() from within updateDisplayList(). This is the method that draws any appropriate chrome around the container. Override this method when creating a container with custom graphics.
• Skins are generally drawn in the updateDisplayList method.
• Delaying drawing until the next frame is fine, but delaying properties (for example, TextInput.maxChars) could pose a problem because there will often be times when you need to set the value of a property then access that property's value before the next frame. So the solution is to store the value as a private variable that the getter will return, so if you need to retrieve the value, you're getting the correct value back. Once the next frame rolls around, then the value is actually set on the component (for example, maxChars gets set on the TextField contained within the TextInput).
• Related to the previous, when commitProperties is run, we need to know WHICH properties have been updated so that we don't do a wholesale property update on the component, and again use unnecessary cycles. The solution used in the framework is to set a flag within the component telling it which property has been updated (in the above example, "maxCharsChanged" is the flag), and then put your property commit code inside of an "if" statement that only runs if the flag is set to true. Could result in some longwinded code if you have a lot of properties, but it works.

To follow are more tidbits on UIComponent and examples of how to utilize these bits.

Please feel free to add your thoughts in the comments.

Previously, i discussed observations on UIComponent drawing. Before I follow with a simple example of how to apply that knowledge into extending a component, let's look at some of the other bits in UIComponent that might help you as you extend or build your own components (and that are used in the example I'll give):

• If your component contains other components or displayable classes that only need to get added once, you should set them up in the createChildren() method. This method gets run once, when the component is initializing.
• One of the things I love about Flex 2 is that it allows the creation of custom component styles with minimal effort. Basically, all you need to know is this:

  To create a new style, you use the "Style" metadata tag as follows in your component:
  

  [Style(name="myCustomStyle", type="uint", format="Color", inherit="no")]

  
  I won't go into details regarding all of the values for each of these tag attributes, but essentially, inserting this tag into your component automatically generates the style for you as well as events associated with style changes. The only thing left for you to do is capture the event and draw your component based on the value of the style. In order to do that, you use the styleChanged() method which looks as follows:
  

  UIComponent.styleChanged(styleProp:String):void

  
  When a style changes, this method is fired and gets passed the name of the style that has been changed (as you set in your metadata tag). Within this method you can use the new style value to draw the component. To access the value of your style, use:
  

  UIComponent.getStyle(styleProp:String):*

  
  This returns the value for your style.


• Unlike AS2, AS3 allows you to override internal player methods and getter/setters. UIComponent does this on many occasions (for example, x, y, width, height, addChild, removeChild, ...) so that it can capture changes in value and dispatch events or add additional functionality where needed. This is cool, but there are times when extending UIComponent or any Flex component that you want to directly access those overridden methods/properties. The Flex framework exposes those within UIComponent in the mx_internal namespace using the "$" prefix. If you extend a component, you can access those by doing something like:
  

  mx_internal::$height = value;

  
  For example, your component might draw a simple box that you just want to size using width and height rather than redrawing the graphics every time. In that case you can use $width and $height. Not often used, but still handy to know.

One of the biggest issues for me in the Flash/Flex workflow has been bringing graphics created in Flash into Flex. Don't get me wrong...I don't think the workflow is hugely painful. All you need to do is draw in Flash, compile, embed the swf in your Flex app and you're good to go. However, if you need to tweak your graphics, resize a few pixels here, tweak a gradient there, for some reason, it just felt uncomfortable to have to go back to the Flash IDE, tweak, recompile, etc.

However, after reading the FXG spec, I'm excited about what this will add to our arsenal. A markup for graphics is something already implemented in Silverlight and was something we were sorely missing. Degrafa got the ball rolling in that arena, and it showed the capability to do some pretty amazing stuff. That team continues to work with Adobe in the implementation of FXG.

This new feature brings to bear a few questions in my mind:

• Will we get additional UI controls in the Flex 4 IDE that allow manipulation of the markup (changing shape properties, applying/editing filters, changing text)? Considering that the Flex IDE initially was created to make developers feel more at home by removing that "extraneous" stuff, it should be interesting to see what happens. Or is Thermo solely the tool that will allow this capability?
• For more complex graphics that can be created in the Flash IDE (or even in Illustrator and imported into Flash), will there be an option to export to FXG? I know there are inherent problems with this since the IDE supports things that FXG does not (i.e., timeline animation), but even the ability to select one or more graphics on stage and have it output FXG would be a cool feature.
• How will creating/manipulating the graphics via UI controls bloat the markup. In working with Blend and XAML, you could draw a rectangle to the stage and change a few settings and all of a sudden you get something that looks like this:

  

  Then try changing some of that XAML manually and it blows up if you're not careful.
  

I'm excited about the potential this has for improving workflow.

This is old news for some, but seriously, after reading the skinning architecture docs and building a couple of sample skins using the Flex 4 SDK, I have to say that it completely rocks!

Up until Flex 4, the approach for architecting UI components (starting back with MX2004 all the way up to Flex 3) has been largely the same. The result has generally been robust components with an amazingly wide feature set but that could take quite a bit of work to customize, particularly in regards to skinning. Each generation of components has improved upon the previous one, but after looking at the Gumbo components, I absolutely love the new true MVC approach. The fact that the view (skin) is pretty much completely decoupled from the controller makes customization more flexible and easier than ever.

Here is a simple button skin built entirely in MXML (Flash player 10 required). Not super complex, yet it shows how easy skinning really is. This example contains small customizations like animated transitions between states, lots of layered gradients, multiline label, label with glow, and others which could take quite a bit of work to implement in the existing framework.

Here is the MXML for the skin.
Here is the entire source package.

Here are my top 10 things to love about skinning in Flex 4:

• FXG - A lot of this just wouldn't be possible without graphics tags introduced in Flex 4.
• hostComponent - The ability to bind anything in your skin to any property in the component allows the skin to pull the data it requires and display itself accordingly.
• States and Selectors - The ability to define states that correspond to states in the controller is made hugely powerful by the introduction of "state-selectors." In MXML, you can now define values for any state your component implements (for example, in button, you can do alpha.over="0.5").
• Integration with the Flex 3 framework - the Gumbo components extend the existing UIComponent class so things you are already familiar with like component lifecycle, events, and tabbing all still apply.
• Skin parts - The ability to break up your skin into parts, each defined in your controller to have it's own behavior.
• Layout Agnostic - You can quickly snap in different layout classes to display the component in different ways. No longer is the layout tied into the component.
• Flexibility - Using all of the above techniques, Ely has already demonstrated that you can customize a list to act like an Accordion or a TabBar without much difficulty.
• Building via composition - In this new architecture, it's super simple to just snap new pieces into a skin and wire them up to the hostComponent properties to create more complex components. For example, List doesn't contain a ScrollBar by default, but to add one and make it work is fairly trivial.
• Lightweight - Since all of the non-essentials have been pulled out of these components, there is far less code which should mean improved performance. Can they do as much as the Flex 3 component set? No, but I don't think that's the intent initially, as these don't appear to be a replacement for those components, rather an alternative.
• Thermo - ever since I was blown away by the initial Thermo demo video (particularly the parts on converting artwork to components), I was skeptical about how they would be able to support skinning in that way using the existing Flex component framework. However, after seeing how skinning works in Gumbo, it now makes tie in with a tool like Thermo much more obvious.

Flex 4 rocks!

Having done several CSS skins for various projects in the past, recently, I had the opportunity to create a set of almost entirely graphical skins. Having stepped through that process, I wanted to write down some tips when attempting to create graphical skins. All of these skins were created using Flash CS3 as opposed to Photoshop or Fireworks. This isn’t so much a step by step tutorial (a good tutorial by Narciso Jaramillo can be found on DevNet) as it is a list of pointers as there are a few issues you may run into when implementing graphical skins.

I’ll start by saying that my experience in general was positive and in large part, the tutorial was a great resource. For a large number of the components, skinning was super simple and Adobe really did a good job (though skinning in Gumbo is that much better). However, there are some little things that needed massaging in order to work. I’ll touch on each of those below.

As mentioned in the tutorial, install the Flex Component Kit for Flash CS3 as well as the Flex Design Extensions. These will make your life a whole lot easier as they include template files for most components (New > Templates > Flex Skins). Once you publish from the template file as a swc, you can import them easily into Flex Builder.

When modifying graphics in Flash, here are a few tips:

• Try to make the size of your graphics match the size of the default graphics in the template fla. If you change the size and position of graphics, you may get unexpected results.
• Make sure the size of graphics in all states is the same. If sizes change across states, it will likely result in text labels or other parts of your component moving when the state changes. This includes things like keeping the “check” in your checkbox inside the bounds of your “box.”
• When importing a slider skin into Flex from your template, you’ll need to add a CSS style definition for both HSlider and VSlider. By default, the swc imports a definition for Slider only which doesn’t change skins for either Slider component.
• When customizing the shape of your skin, you can round or unround corners, but if you do, make sure you use the “focusRoundedCorners” style along with “cornerRadius” for that component to either round or unround the focus rectangle.
• When customizing the indeterminate graphic for ProgressBar, be careful with the spacing of your barber pole or you’ll get skipping during the animation. Going with the same spacing in the template file of course is the easiest way to go.
• An obvious one, but make sure that you don’t use MovieClip symbols inside of your skin clips that require 9-slice scaling as they won’t scale properly. I’ve also found that using Graphic symbols can also cause weirdness. In general, it’s best to just use shapes in your skin clips.
• The skin for the MenuBar_itemSkin doesn’t work properly. By default, the template contains a single clip with separate states for up/over/down. However, in order to get it to work properly in Flex, I had to break it into separate clips (MenuBar_itemUpSkin, MenuBar_itemOverSkin, MenuBar_itemDownSkin), each representing a single state only.
• When customizing background skins for List based components, keep in mind that by default, the ItemRenderer background extends to the edge of the component, so that it will obscure your border at the very least in over and selected states. In order to have your ItemRenderer background sit inside your component border, you need to create a custom renderer. The other options are to either have no border or to make your ItemRenderer backgroundColor style the same color as your border.
• Remember that some component skins are used by other components either via inheritance or composition (i.e., NumericStepper uses the TextInput borderSkin, ComboBox uses List’s, TextArea uses ScrollBars, etc.). So if your TextInput skin graphic has rounded corners, take that into account when creating your stepper button skins.
• Another obvious one, but remember that CSS styles don’t work with custom skin graphics. Unfortunately, this means that creating a set of graphical skins that can be styled using CSS isn’t possible by default (i.e., backgroundColor, borderColor, etc.). Not sure if anyone has implemented this ability with graphical skins, but I’ve started looking into it so stay tuned.
• Unfortunately, there isn’t a simple way to graphically skin the DateChooser background as it’s baked into updateDisplayList of the DateChooser class, so your easiest bet is via CSS.
• ComboBox’s editableSkin doesn’t work properly. The symbol actually needs to be broken down into 4 separate symbols (ComboBox_editableUpSkin, ComboBox_editableOverSkin, ComboBox_editableDownSkin, ComboBox_editableDisabledSkin) and imported into Flex that way in order to work properly. Also note that even though the template symbol is 21 pixels wide, the default width for the editable ComboBox's button is 22 pixels so you may want to resize the symbol so your arrow doesn't get stretched.
• Unfortunately, using graphical skins for Panel can result in a bit of a mess as discussed here. Basically, the contents of the panel don't respect the padding values. One workaround is to set up the panel contents in a container and set the top/bottom/left/right values of that container to the same as the border in your panel graphic.

iCandy was my entry into the ScaleNine Skin to Win competition. It took third place and a copy of CS4 Web Premium. There were some hiccups in the process of getting these graphical skins into a Flex app, which anyone doing graphical skinning should be aware of (I've documented here), but overall I was happy with the result.

Thanks to Juan for putting this on, and to Adobe and EffectiveUI for sponsoring with some great prizes.

The skins should be available for download on ScaleNine shortly, but you can preview the skins here. Congrats to the other winners, the team from Undefined for their Undefined skin, and Nahuel Faronda for his Brownie skin.

[UPDATE: The iCandy project files as well as the source FLA are now available on ScaleNine. Enjoy!]