Flex and the City

A quick update

2009-07-02T15:34:00.002+10:00

Updates:

The Degrafa Skin project is progressing. I've added a skin for Application, which shows off a few nice features of Degrafa. I'll be blogging about this soon.
I've been doing quite a bit of work with BlazeDS recently, and the experience is nowhere near as pleasant as it should be. More to come on this front over the next couple of months.
As usual, I've been hacking Degrafa, although not as often as I'd like. I'll be committing the Filters package in the next few days, and I'll blog about it again with more details. I'll also be checking in support for Ant soon as well.

A complete skin for Flex applications using Degrafa (part 1)

2009-05-19T22:55:00.001+10:00

Overview

I’ve been working with Degrafa for a while now, using it to build new components and skin the old. I’ve fixed a few bugs, and contributed some new features, which will hopefully see light sooner rather than later. There’s a few blog posts and tutorials around the net on skinning various individual components, but nothing really comprehensive.

To address this, I’ll be building a complete Flex skin using Degrafa, one component at a time through my blog. Download the source code from Google code, and I’ll try to get a component a week added until the entire standard Flex 3 component set is thoroughly skinned.

So with that out of the way, let’s begin, with TabNavigator!

TabNavigator

The core of any skin is of course, the CSS file. Here’s a snippet of what we’re interested in:

TabNavigator
{
 border-skin:ClassReference("parade.TabNavigatorSkin");
 padding-top:0px;
 padding-right:0px;
 padding-bottom:0px;
 padding-left:0px;
 tabStyleName:"navigatorTab";
 firstTabStyleName:"navigatorTab";
 lastTabStyleName:"navigatorTab";
 selectedTabTextStyleName:"selectedTabText";
}

Button.navigatorTab
{
 skin:ClassReference("parade.TabSkin");
 paddingTop:1;
 paddingRight:10;
 paddingBottom:1;
 paddingLeft:10;
}

As you can see, we’re referencing two custom skins: TabNavigatorSkin and TabSkin. One to skin the ViewStack.

The TabNavigator skin source code isn’t particularly exciting, so I won’t reproduce it here. The interesting part that will be new for a lot of readers, is the leveraging of Degrafa’s new states support. Here’s the code in question, taken from TabSkin.mxml:

<degrafa:states>
    
    <!-- Hover -->
    <degrafa:State name="overSkin">
        <degrafa:SetProperty target="{mainFill}" name="color" value="#dddddd"/>
    </degrafa:State>

    <!-- Selected -->
    <degrafa:State name="selectedUpSkin">
        <degrafa:SetProperty target="{outlineShape}" name="top" value="0"/>
        <degrafa:SetProperty target="{notch}" name="top" value="1"/>
        <degrafa:SetProperty target="{notch}" name="visible" value="true"/>
        <degrafa:SetProperty target="{notchOutline}" name="top" value="1"/>
        <degrafa:SetProperty target="{notchOutline}" name="visible" value="true"/>
        <degrafa:SetProperty target="{fillShape}" name="top" value="1"/>
        <degrafa:SetProperty target="{fillShape}" name="bottom" value="-2"/>
        <degrafa:SetProperty target="{bling}" name="top" value="1"/>
        <degrafa:SetProperty target="{bling}" name="visible" value="false"/>
        <degrafa:SetProperty target="{mainFill}" name="color" value="#dddddd"/>
    </degrafa:State>
    <degrafa:State name="selectedOverSkin" basedOn="selectedUpSkin"/>
    <degrafa:State name="selectedDownSkin" basedOn="selectedUpSkin"/>
    <degrafa:State name="selectedDisabledSkin" basedOn="selectedUpSkin"/>
    
</degrafa:states>

If this syntax looks familiar, it’s because it should - it’s based on the existing syntax you’re used to seeing to set up states in regular old MXML components.

A key difference you should pay attention to is that in Degrafa the property that identifies the current selected state is not "currentState", as with regular UIComponents. For Degrafa skins, it’s stored in the "name" field. This is because that’s the way the Halo component model is designed, and in 99% of cases it’s Halo components we’re skinning.

The state names you see above are also just part of Halo’s way of doing things. They’re not consistent across different components, but that’s simply how it is. Adobe have no plans on changing the names to be more sensible, because they’re throwing out the whole thing for Spark, the component model and library that will be in Flash Builder / Flex 4.

To see the skin in action, click the image below (view source enabled):

View the example app

Next week: Checkboxes! Do you have preferences as to which components you’d like to see examples for earlier than others? Email me, [catch me on Twitter], or leave a comment here on my blog.

On using "if(foo)" vs "if(foo != null)"

2009-03-18T22:17:00.002+10:00

I was going to leave this topic for a planned series of posts detailing (and explaining) my personal coding style, as it differs somewhat to that laid out by Adobe. But, a few people noticed a comment I made about the subject, so I thought I'd rant on the subject here, where I can explain myself.

Adobe's guidelines tell us that to test if foo is not null, we should use something like the following:

if (foo)
    doSomething();

This does work, and I find it makes for nice readable code. My coding style is based around readability and "pretty", so I do this all the time.

However, there are a lot of places where we're forced by ActionScript's limited overloading capabilities to declare method parameters as Object or *. And this is where bugs creep in.

Let's say you have a method like so:

public function doStuf(howMany : Number, usefulObject : MyClass = null) : void
{
    //Do some stuff

    if (usefulObject)
        doOtherStuff(usefulObject);
}

As it is, this will work fine. You have a howMany argument, and an optional usefulObject argument.

Everything is going fine, and one day you decide that you can actually use the doStuff() function on all sorts of different objects, as well as instances of MyClass - but you'd like to keep the semantics of it the same, so the parameter is still optional.

You've just introduced a bug. One that you won't trip up any existing unit tests, too.

If you're lucky you'll find it soon, but probably not. If it's a week or two before you need to pass in an empty string, or the number 0, or false, you'll be left scratching your head wondering why it's not doing what it's supposed to.

This is why I think it's not necessarily a good practice to be recommending to ActionScript beginners.

I still do it, but I'm trying to weed it out. Once I break the habit, it'll definitely cut down on the syntax errors I put in my Java, anyway ;-)

Using "protected" as a namespace

2009-02-19T16:28:00.003+10:00

I'm a big fan of certain aspects of Object-Oriented software development, one being information hiding. Not in a way that makes it hard to extend classes, but in order to keep the public API as small and neat as possible. That means favouring protected over private, but often I want a read-only or write-only property in the public API, while still supporting binding (or any other processing on set). This can be a problem at compile time when you'd like to be able to use both internally, however. Take the following code snippet of real code:

//----------------------------------
// selectedUser
//----------------------------------

private var _selectedUser : User;

[Bindable("selectedUserChanged")]
public function get selectedUser() : User
{
    return _selectedUser;
}

protected function set selectedUser(value : User) : void
{
    if (_selectedUser == value)
        return;

    _selectedUser = value;
    dispatchEvent(new Event("selectedUserChanged"));
}

//----------------------------------
// Selection callback
//----------------------------------

public function selected(item : Object) : void
{
    if (item == null || displayUsers.contains(item))
        selectedUser = User(item);
}

MXMLC will give us "Error 1000: Ambiguous reference to selectedUser" when we try to compile this code. Namespaces to the rescue! Did you know you can use public, package, protected and private just as you would a normal namespace in most cases? The solution to this particular problem then becomes:

public function selected(item : Object) : void
{
    if (item == null || displayUsers.contains(item))
        protected::selectedUser = User(item);
}

You may note that instead of a protected accessor, I could have cooked up a protected setSelectedUser() function. Which is true, but using the namespace prefix allows me to retain the assignment operator, which I find clearer.

A small request...

2009-02-13T11:26:00.001+10:00

I have a small request:

I'd like to know what grinds your gears, and what makes you smile about the Flex library, and about whatever other libraries you use on a daily basis to get your work done. If you have time, please post here or to me off-list a quick summary of your thoughts, some bullet points, or even a link to somebody else's blog posting that sums up your ideas. Anything you've got to say, even if it's no more than "PureMVC ftw!", I'd like to hear it.

I have a keen interest in frameworks, and I'm planning on building something that takes the best ideas I can find (and cook up) from these and my experiences maintaining a mostly-closed-source framework at my 9-5. It's for my own apps, I'll be dog-fooding it, but it will be open source. It's going to be a full-stack framework with an optional Java+Warp+BlazeDS component, so if you think you've got some good ideas, or would like to help, please drop me a line.

Excuses - er, I mean, an announcement!

2009-01-23T20:29:00.002+10:00

No code this week! But I have been doing some hacking - I'm very happy to say that I've joined the Degrafa team, and I'm hard at work on some new features, starting with bindable filters. What's that mean? Well the short of it is that you'll be able to bind filter parameters to data in MXML, and Degrafa will know about the updates and re-render when appropriate. No more: "var tmp:Array = foo.filters; foo.filters=null; foo.filters = tmp;". I don't know about you guys, but I'm *sick* of doing that :)

It's not much, and the changes aren't ready to go upstream into SVN yet so you can't use the features, but you can see an example of what I'm talking about here. For some reason it's much smoother on Mac than Windows (at least with Player 9), but it's just a work-in-progress.

It's not final, but I'm trying to find a nice way to let you use the Degrafa bindable filters on regular DisplayObjects. No promises, but I'm trying!

Painless CSS support for Flex components

2009-01-15T12:37:00.001+10:00

As I'm sure you can tell, I've been doing a lot with Degrafa and custom components recently. One thing I've found frustrating while doing so is supporting styles, both custom and built-in. To combat this, I've cooked up a little something I call the StyleProxy.

Usage is simple. First, you'll need an instance of StyleProxy for your component:

<utils:StyleProxy id="styleProxy"/>

Second, make sure you have a <mx:Script> section in your MXML file and add this function:

override public function styleChanged(styleProp : String) : void
{
    super.styleChanged(styleProp);
    styleProxy.handleStyleChange(styleProp);
}

And you're done! Now, all you need to do is bind to properties on styleProxy using the style name. StyleProxy will take care of the rest.

Bonus: I've uploaded the source code for a simple button skin combining Degrafa and StyleProxy: View the example code.

StyleProxy is available for download from Google Code.

More Degrafa madness - Scrollbars and Illustrator

2009-01-03T13:14:00.001+10:00

The holidays are almost over! I've been doing some bludging, some swimming, spent some time at the beach, watched some cricket, ate (too much) pudding and brandy sauce, and finally finished my damned scrollbars to a satisfactory level. To jump right in and see the final product, click the image below:

Click to view (view-source enabled)

NB: This works with Degrafa SVN, I haven't tested it against the pre-compiled .swf.

You'll find included in the package the Adobe Illustrator File I created for the artwork, as well as the individual SVG files for the resources.

A few things to note:

I had to copy-and-paste each element of the scrollbar into a temporary new document in Illustrator before exporting as SVG, just to keep things simple.
The gradients and path data have been a little hand-tweaked for positioning.
Illustrator will use commas for all whitespace when exporting path data, but will default to no whitespace at all when it's not needed (negative numbers for example don't need whitespace to separate them from their predecessors). This is valid SVG (and Degrafa path data), but I just prefer to separate coordinate pairs with spaces, and x/y values with commas.

As always, your feedback is appreciated! Please let me know if you've got any questions, corrections, or suggestions!

Happy holidays!

2008-12-19T14:16:00.003+10:00

Happy Holidays, all! Going offline for a week or so, but I've got big plans for the new year! Hopefully I'll get connected once or twice and publish a half-done post or two I've got lying around, but there's an awful lot of drinking, fishing, swimming, barbecuing, and cricket-watching to be done.

Have a happy and safe break guys :)

A useful tool

2008-12-04T12:41:00.001+10:00

I'd like to take a moment to recommend Screen Calipers. I'm a perfectionist when I'm working on custom interfaces, components and skins, so I use it all the time. It helps me check padding values, sizing, spacing, border widths, you name it. It's definitely worth the US$30.

What do you use to get things done, besides builder? I'm always looking for ways to improve my productivity and cut down on the boring parts of my day!

A slightly more thorough introduction to Smartypants-IOC

2008-11-26T00:30:00.001+10:00

I'm writing up some info on Smartypants-IOC which will hopefully make it into @dhanji's upcoming book on Dependency Injection, so I figured I'd kill two birds with one stone, and finally update my damned blog while I'm at it.

First I'll introduce a couple of key concepts:

The class+name key

Whether you're telling Smartypants what to provide, or sitting around with your hand out asking for a dependency, the key is the same. A combination of a class and a name. You need to specify the class, but the name is optional.

Injection annotations

How do you actually request a field be injected, you ask? In most circumstances you just need to annotate your fields with some ActionScript metadata. If you just want to request an instance of IServiceInterface, the syntax is simple:

[Inject]
public var myService : IServiceInterface;

As I mentioned above, the injector works using a compound key of both Class and Name. Let's say you want to look up a particular String, rather than just anything. For a WSDL URL, or something along those lines:

[Inject(name="mainWSDL")]
public var myServiceWSDL : String;

These fields will be injected into your object when it is constructed for you by Smartypants-IOC, or when you call injector.injectInto(myInstance).

We also have live injections, which when coupled with live rules behave like the Flex SDK's data binding functionality:

//This will be set whenever the source changes
[Inject(name="userName",live)]
public var currentUsername : String;

Injector Rules

Smartypants injector rules are akin to Guice's bindings. We simply use another term to avoid confusion with the Flex SDK's data-binding mechanism. You just tell the injector what you'd like it to do. Here's a couple of examples:

//Simple singleton rules:
injector.newRule().whenAskedFor(String).named("wsdl").useInstance("http://www.server.com/soap/service.wsdl");
injector.newRule().whenAskedFor(IServiceInterface).useSingletonOf(MyServiceImpl);
injector.newRule().whenAskedFor(MyConcreteClass).useSingleton();

//"Live" rules act just like <mx:Binding>
injector.newRule().whenAskedFor(String).named("userId").useBindableProperty(this, "userId");

But how do I kickstart the whole thing?

Good question! Two ways. First, in an MXML component:

<?xml version="1.0" encoding="utf-8"?>
<mx:Canvas xmlns:mx="http://www.adobe.com/2006/mxml" xmlns:smartypants="http://net.expantra.smartypants/2008">

    <smartypants:RequestInjection/>

    <!-- ...Regular code and MXML... -->

</mx:Canvas>

And in ActionScript it's even simpler:

var injector : Injector = Smartypants.getOrCreateInjectorFor(this);
injector.injectInto(this);

Hopefully this gives a little more insight into the style and ideas behind Smartypants-IOC. Be sure to check it out on the Google Code site, and I'd love to hear your thoughts and ideas for the future!

DSLs in MXML

2008-11-07T08:37:00.002+10:00

I like DSLs, and god-help me I like MXML. Mainly for the auto-complete features we get from Builder. I've recently built a new application framework at Pathways (my 9-5), which uses an MXML file as the core of the application to map events, services, actions(think commands), etc. This has got me thinking I'd like to have a tool that'll let me define an MXML DSL and have it spit out a bunch of AS3 classes to implement it. I'd like to hear from anybody who's got any thoughts on the idea, or things they'd like to see included. I probably won't get started on it just yet, but it's floating around in my head with the rest of the crazy ideas waiting to escape into code.

Free Book! Giggity!

2008-11-06T18:51:00.000+10:00

I forgot to brag! About a week or so ago, I received my free copy of Flex 3 Cookbook in the mail, courtesy of the Flex team @ Adobe! An unnecessary but welcome reward for getting 3 SDK patches accepted!

Anyway, enough bragging, and a big thanks to Matt and the rest of the Flex team for building the badass platform we use every day!

Skinning Flex apps with Degrafa

2008-11-05T09:50:00.001+10:00

I've been a lazy bastich, but here's the promised post on skinning with Degrafa. Note: this is based on Degrafa Beta 2. Beta 3 is expected rather soon, and there'll be a couple of changes such as the new namespace etc.

OK, for this example, we're going to skin a simple little <mx:Box> to dress it up some. Here's our MXML for the component we'd like to skin:

<mx:Canvas styleName="skinnedBox" width="250" horizontalCenter="0" verticalCenter="0">
    <mx:Text width="100%">
        <mx:text>
            Aliquam et nisl vel ligula consectetuer suscipit. Morbi euismod enim eget neque. Donec sagittis
            massa. Vestibulum quis augue sit amet ipsum laoreet pretium. Nulla facilisi. Duis tincidunt,
            felis et luctus placerat, ipsum libero vestibulum sem, vitae elementum wisi ipsum a metus.
            Nulla a enim sed dui hendrerit lobortis. Donec lacinia vulputate magna. Vivamus suscipit lectus
            consectetuer adipiscing elit.
        </mx:text>
    </mx:Text>
</mx:Canvas>

And a simple "before" CSS:

/* CSS file */
.skinnedBox
{
    border-style:solid;
    border-thickness:1;
    border-color:black;
    background-color:#cccccc;
}

Giving us this:

And we're going to skin it so it looks like this:

If we were skinning a Button, we'd use things like up-skin, down-skin, etc. But, we're just skinning a box, so we'll use border-skin:

/* CSS file */
.skinnedBox
{
    border-skin:ClassReference("skinningInDegrafa.ShinySkin");
}

We want to specify the borderMetrics of our skin (to add the padding), so we'll subclass <degrafa:GraphicRectangularBorderSkin>:

<?xml version="1.0" encoding="utf-8"?>
<degrafa:GraphicRectangularBorderSkin xmlns:mx="http://www.adobe.com/2006/mxml" width="400" height="300" xmlns:degrafa="http://www.degrafa.com/2007">

    <mx:Script>
        <![CDATA[
            import mx.core.EdgeMetrics;

We need to keep a copy of the width and height which is set by the framework. The actual height and width are set on updateDisplayList, which is as good a place as any to take note of them, and we'll have less unnecessary updates that way:

            [Bindable]
            private var skinWidth : Number = 0;

            [Bindable]
            private var skinHeight : Number = 0;

            private var edges : EdgeMetrics = new EdgeMetrics(20, 5, 20, 5);

            override protected function updateDisplayList(unscaledWidth : Number, unscaledHeight : Number) : void
            {
                skinWidth = unscaledWidth;
                skinHeight = unscaledHeight;
                super.updateDisplayList(unscaledWidth, unscaledHeight);
            }

            override public function get borderMetrics() : EdgeMetrics
            {
                return edges;
            }

        ]]>
    </mx:Script>

Below is the exciting part that defines the shapes and fills! A how-to on Degrafa in general is out of scope for this post, so see the Degrafa site for documentation and more examples.

    <degrafa:fills>
        <degrafa:LinearGradientFill angle="90" id="f">
            <degrafa:GradientStop ratio="0" color="#dde4ee"/>
            <degrafa:GradientStop ratio="1" color="#aaa0bb"/>
        </degrafa:LinearGradientFill>

        <degrafa:LinearGradientFill angle="90" id="f2">
            <degrafa:GradientStop ratio="0.3" alpha="0.02" color="#ffffff"/>
            <degrafa:GradientStop ratio="1" alpha="0.3" color="#ffffff"/>
        </degrafa:LinearGradientFill>
    </degrafa:fills>

    <degrafa:geometry>

        <degrafa:Path fill="{f}">
            <degrafa:MoveTo x="0" y="{ skinHeight / 2 }"/>
            <degrafa:CubicBezierTo x="20" y="0" cx="0" cy="{skinHeight * 0.25}" cx1="1" cy1="1"/>
            <degrafa:LineTo x="{ skinWidth - 20}" y="0"/>
            <degrafa:CubicBezierTo x="{ skinWidth }" y="{ skinHeight / 2 }" cx="{ skinWidth - 1}" cy="1" cx1="{ skinWidth }" cy1="{ skinHeight * 0.25 }"/>
            <degrafa:CubicBezierTo x="{ skinWidth - 20 }" y="{ skinHeight }" cx="{ skinWidth }" cy="{ skinHeight * 0.75 }" cx1="{ skinWidth - 1 }" cy1="{ skinHeight - 1 }"/>
            <degrafa:LineTo x="20" y="{ skinHeight }"/>
            <degrafa:CubicBezierTo x="0" y="{ skinHeight / 2 }" cx="1" cy="{ skinHeight - 1 }" cx1="0" cy1="{ skinHeight * 0.75 }"/>
            <degrafa:ClosePath/>
        </degrafa:Path>

        <degrafa:Path fill="{f2}">
            <degrafa:MoveTo x="10" y="{ skinHeight / 2 }"/>
            <degrafa:CubicBezierTo x="20" y="0" cx="0" cy="{skinHeight * 0.25}" cx1="1" cy1="1"/>
            <degrafa:LineTo x="{ skinWidth - 20}" y="0"/>
            <degrafa:CubicBezierTo x="{ skinWidth - 10 }" y="{ skinHeight / 2 }" cx="{ skinWidth - 1}" cy="1" cx1="{ skinWidth }" cy1="{ skinHeight * 0.25 }"/>
            <degrafa:CubicBezierTo x="10" y="{ skinHeight / 2 }" cx="{ skinWidth * 0.75 }" cy="{ skinHeight * 0.4}" cx1="{ skinWidth * 0.25 }" cy1="{ skinHeight * 0.4}"/>
            <degrafa:ClosePath/>
        </degrafa:Path>

    </degrafa:geometry>

    <degrafa:filters>
        <mx:GlowFilter inner="true" color="#000000" blurX="3" blurY="3" alpha="0.3"/>
        <mx:DropShadowFilter alpha="0.3" angle="90" distance="5" blurX="8" blurY="8"/>
    </degrafa:filters>

</degrafa:GraphicRectangularBorderSkin>

And that's a pretty simple example of skinning with Degrafa! Here's the complete example (with view-source enabled).

Selecting the right value from a ComboBox or List

2008-10-16T21:12:00.002+10:00

I know, I promised Degrafa skinning, and I'm skipping out. It'll be next, if I can find the time!

In other news, there's been some talk as there always is regarding the difficulty some have been having due to the fact ComboBox (and others like it) work with identity rather than contents when choosing which item within the dataProvider is the "selected" value. There are various solutions, usually involving subclassing ComboBox or something along those lines. Well, that's kinda unnecessary. I maintained that you could cook up a util to achieve the same thing across any list-style control, and by golly I like to stand up to my word.

You can download the source for the util here. I'll add it to SVN soon, I'm kinda busy atm tho. Lousy sleep eating up 8 hours of productivity a day!

For an example of how to use the <FindIndex> code:

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute" xmlns:pkg="pkg.*">

    <mx:ArrayCollection id="src1">
        <mx:Object label="Ken" objid="1"/>
        <mx:Object label="Ryu" objid="2"/>
        <mx:Object label="Chun-Li" objid="3"/>
        <mx:Object label="Dhalsim" objid="4"/>
        <mx:Object label="E. Honda" objid="5"/>
        <mx:Object label="Blanka" objid="6"/>
        <mx:Object label="Zangief" objid="7"/>
        <mx:Object label="Guile" objid="8"/>
    </mx:ArrayCollection>

    <mx:ArrayCollection id="src2">
        <mx:Object label="Ken" objid="1"/>
        <mx:Object label="Ryu" objid="2"/>
        <mx:Object label="Chun-Li" objid="3"/>
        <mx:Object label="Dhalsim" objid="4"/>
        <mx:Object label="E. Honda" objid="5"/>
        <mx:Object label="Blanka" objid="6"/>
        <mx:Object label="Zangief" objid="7"/>
        <mx:Object label="Guile" objid="8"/>
    </mx:ArrayCollection>

    <pkg:FindIndex source="{src2}" keyField="objid" searchFor="{ left.selectedItem }" id="fi"/>

    <mx:HBox horizontalCenter="0" verticalCenter="0">

        <mx:List id="left" dataProvider="{src1}" width="120"/>

        <mx:List id="right" dataProvider="{src2}" selectedIndex="{ fi.matchingIndex }" width="120"/>

    </mx:HBox>
</mx:Application>

Degrafa skinning next week! Honest!

Typesafe ActionScript Enums

2008-10-09T21:20:00.002+10:00

A busy week, with some client work and a 4-day weekend away (starting in about 12 hours, woot!), so a quick post.

Typesafe Enums are something we take for granted these days in a lot of programming languages, but unfortunately ActionScript isn't yet one of them. However, there are a few solutions out there to provide this functionality, and of course since none of them met my needs exatly, this is mine!

First, let's jump into how we use the damn things - here's how you would create a new Enum type:

package demo
{
    import info.joshmcdonald.barra.utils.Enum;

    public class CompassPoint extends Enum
    {
        public static const NORTH      : CompassPoint = Enum.create(CompassPoint, "N",  "Towards Santa");
        public static const NORTH_EAST : CompassPoint = Enum.create(CompassPoint, "NE", "North East");
        public static const EAST       : CompassPoint = Enum.create(CompassPoint, "E",  "East");
        public static const SOUTH_EAST : CompassPoint = Enum.create(CompassPoint, "SE", "South East");
        public static const SOUTH      : CompassPoint = Enum.create(CompassPoint, "S",  "Towards Penguins");
        public static const SOUTH_WEST : CompassPoint = Enum.create(CompassPoint, "SW", "South West");
        public static const WEST       : CompassPoint = Enum.create(CompassPoint, "W",  "West");
        public static const NORTH_WEST : CompassPoint = Enum.create(CompassPoint, "NW", "North West").close();
    }
}

Seems simple enough, right?

Wait, hold on, "what the hell is that on the end?" I hear you cry? Why, I'm terribly glad you asked! That my friends, combined with using Enum.create() is how we stop people from instantiating new instances willy-nilly, which of course leads to anarchy! When you call close(), no more instances of Compass can be instantiated, and if you try, you'll get a run-time error.

Now, some "client" code that makes use of our new CompassPoint class:

<mx:Script>
    <![CDATA[
        import info.joshmcdonald.barra.utils.Enum;
        import demo.CompassPoint;

        private function cc() : void
        {
            var towardsPerth : CompassPoint = CompassPoint.SOUTH_WEST;

            trace("Direction to Perth is", towardsPerth);

            trace("What are all the Compass points?");
            trace("   * " + Enum.valuesOf(CompassPoint).join("\n   * "));
        }

    ]]>
</mx:Script>
</mx:Application>

As usual, I've added Enum.as to my blog's google code repository.

Next week: Skinning with Degrafa!

Announcing Smartypants IOC, Dependency Injection for Flex!

2008-10-02T19:25:00.003+10:00

I'm happy to announce the public release of the Smartypants IOC dependency-injection framework for Flex! Inspired by the likes of Guice, it features annotations to specify dependencies, and a simple internal DSL to wire everything together.

Dependency Injection, Flex style!

Normally, dependency injection is a static thing. Once your object has been populated and handed over, you and your injection framework are through. However, Smartypants' live injection functionality acts as a mediator allowing bindings between un-coupled classes, without keeping any hard-references to either that can lead to troublesome memory leaks.

Grab the source or binary over at Google Code, check out the API reference, join the discussion group and hack away! I'm looking forward to your feedback, opinions, and thoughts on the direction in which you'd like to see Smartypants IOC heading in the future?

Screenweaver - an open source alternative to AIR?

2008-09-25T21:18:00.002+10:00

I don't have a detailed post this week as I've been working on cleaning up and refactoring my IOC project for launch next week (I hope). However here's a few interesting links:

haXe - A multi-platform language with a fairly pleasant syntax based on ECMAScript. You can write code in haXe and compile to SWF (Flash 6 to Flash 9), ActionScript (this isn't too good, I've run into problems), JavaScript, and PHP. It also compiles to NekoVM...
Screenweaver Open Source - This is a bridge between Flash and NekoVM, for Windows and Mac OS. You can do all your GUI code in ActionScript, or you can do it all in haXe as it compiles to SWF as well as NekoVM.

I Haven't played with Screenweaver yet, but I plan on it in the near future! And of course when I do I'll be posting my progress here :)

Internet Explorer

2008-09-22T19:38:00.003+10:00

Groan. I think the site's working in IE6 now. Debugging HTML on Explorer (without parallels or a Windows box handy) is pain. This is why I do Flex these days.

Vertical Scrollbars and 100% width content

2008-09-18T21:03:00.002+10:00

I've often wished Flex would simply shrink the available width of my containers when their contents grow too tall, but alas, often you'll find yourself with a horizontal scrollbar that only exists to show you the content that's just been hidden by the vertical scrollbar that wasn't there a minute ago!

It's a common question, and the Adobe guys had their reasons for making it how it is. Not much consolation for the rest of us though! So, a (perhaps not the, but a) solution:

package info.joshmcdonald.barra.components
{

Shameless self-promotion: I've created a google code project for code examples and utils from my blog.

    import flash.display.DisplayObject;

    import mx.containers.Canvas;
    import mx.core.UIComponent;

    public class SmartVerticalScroll extends Canvas
    {
        override public function addChild(child : DisplayObject) : DisplayObject
        {
            return addChildAt(child, numChildren);
        }

        override public function addChildAt(child : DisplayObject, index : int) : DisplayObject
        {
            if (numChildren > 0)
                throw new Error("Only one child, stick a canvas or something in here");

            return super.addChildAt(child, index);
        }

Just to keep thing simple, and this example small, we're limiting this to a single child. Not ideal, but we can get away with it by simply using it as a container for a Canvas or a VBox or similar.

        override protected function updateDisplayList(unscaledWidth : Number, unscaledHeight : Number) : void
        {
            var innerWidth : Number = unscaledWidth - borderMetrics.left - borderMetrics.right;

            super.updateDisplayList(unscaledWidth, unscaledHeight);

            if (numChildren == 1)
            {
                var child : DisplayObject = getChildAt(0);
                var uic : UIComponent = child as UIComponent;

                if (uic)
                {
                    if (verticalScrollBar)
                    {
                        var newWidth : Number = Math.max(Math.min(uic.width + uic.x , innerWidth - verticalScrollBar.width), uic.measuredMinWidth);
                        uic.setActualSize(newWidth, uic.height);
                    }
                }
                else
                {
                    child.x = 0;
                    child.y = 0;
                }
            }
        }

Here's where half the magic lies. If we have a vertical scrollbar, we'll shrink our child component to fit within it, unless that would violate its minWidth requirement.

        override public function validateDisplayList() : void
        {
            var before : Boolean = verticalScrollBar == null;
            super.validateDisplayList();
            var after : Boolean = verticalScrollBar == null;

            if (after != before)
            {
                //Scrollbar added or removed - repaint and resize inner component
                invalidateDisplayList();
            }
        }
    }
}

Here's the other half of the magic. When we determine that Flex's built in layout code has decided to add a vertical scrollbar, we make sure to schedule another call to our updateDisplayList() so we can shrink the content down to get out of the way.

Bindings, Changewatcher, and memory leaks

2008-09-11T16:57:00.005+10:00

I'm building some stuff with a serious potential to leak memory (but it's hella cool, watch this space). Specifically, dealing with binding to and from objects without keeping hard references to them, which is easier said than done! I've been going through the source code to the binding system, and all bindings eventually come down to ChangeWatcher.watch().

When you call watch(), you get returned the first of a chain of watchers, one for every host in the chain.
Every watcher in the chain with a non-null host has a hard-reference from the host object to itself.
Every watcher has a hard-ref to the handler function.

This of course leads to the fact that if you ever throw away your watcher reference before calling unWatch(), you're stuck with a zombie reference from the root of your chain to your handler function. Which means in turn that the host object is hard-referenced to anything within the handler function's scope. If the root of your chain happens to be Application, or anything else that lives the life of your app, you're almost certainly leaking memory.

I'd love to be wrong about my conclusions, but I don't think I am. I'll have to create a test some time over the weekend to prove it though, so I can file a bug (and a fix) with Adobe.

So in conclusion: Be awfully careful what you're putting in the handler function for any hand-created ChangeWatcher, or using BindingUtils!

Note that I don't think it's a problem for MXML bindings: Off the top of my head, if the root host of a binding chain defined in MXML is "A" then the handler function is generated as a member function of "A".

Using the Proxy class (part 2)

2008-09-04T18:51:00.001+10:00

In the first part of this article I demonstrated using the basic Proxy functionality. Now we get to the fun stuff, which we need to support for..in and for each..in constructs.

//Gets the next index. When you return 0, for..in and for each..in will quit.
override flash_proxy function nextNameIndex(index : int) : int
{
    if (index < propertyNames.length)
        return index + 1;

    return 0;
}

Here's where the Flex docs get kinda confusing :) The first thing the VM does when you're iterating your Proxy object with for..in or for each..in is call nextNameIndex(0). The docs tell you the input is zero-based, but that's not the case, 0 isn't "first", 1 is. So when flex asks for the "next name from zero" it's actually asking if there's a first name at all. If you've got more properties to iterate, return index + 1. Otherwise, return 0 and the loop will end.

Note that you don't *have* to return index +1. This is how ArrayCollection, ListCollectionView and the like implement filters. But that's another post :)

//Get name[i] where i is 1-based
override flash_proxy function nextName(index : int) : String
{
    return propertyNames[index - 1];
}

//Get value[i] where index is 1-based.
override flash_proxy function nextValue(index : int) : *
{
 return properties[propertyNames[index - 1]];
}

These two functions are the other half of the for..in and for each..in loops. After the VM gets the next index from nextNameIndex() it will call one of these two functions. In the case of for..in it will call nextName(), and for for each..in it will call nextValue(). Because we're not doing anything complicated in this example, we just return "properties[index - 1]" (remember Array is 0-based, the Proxy functions are 1-based). If there were more logic in our getProperty() method from the first part of this article, then we'd want to defer to that method rather than duplicate that login in the nextValue() method.

And that's how you use the Proxy class. Now, go build something bad-ass with it :)

Download source.

Using the Proxy class (part 1)

2008-09-04T07:48:00.000+10:00

When I first came across the Proxy class, I got rather excited. Dreams of mock objects, cross-cuts, and various other cglib shenanigans danced in my vision. Sadly, it was not to be, and the VM doesn't let you cast Proxy as another class (or interface). However, it has its uses, and I'd like to explain how to use it.

I know it's been done before, but for this example I'm going to re-invent the "bindable dynamic object". The point is to explain the Proxy class :)

Let's get started:

[Bindable(event="propertyChange")]
public dynamic class BindableDynamic extends Proxy implements IEventDispatcher
{
    //Actual contents
    private var properties : Object = {};

    //Property names
    private var propertyNames : Array = [];

A few things here:

We've annotated the class with [Bindable(event="propertyChange")]. This marks the class as bindable, and because we specify the event name, MXMLC assumes we know what we're doing and doesn't generate any Binding boilerplate for us, which is what we want :)
We've got two private variables here: properties, which holds our actual values, and propertyNames, which we'll use as a list of (guess what?) property names!

The Flex docs don't use the propertyNames variable, and instead use a temporary array when iterating the fields using for..in or for each..in, but I like keeping the list around.

Some more code:

//Simple getProperty by name
override flash_proxy function getProperty(name : *) : *
{
    if (!name)
        return undefined;

    if (!(name in properties))
        return undefined;

    return properties[name];
}

//Do we have property x?
override flash_proxy function hasProperty(name : *) : Boolean
{
    return (name in properties);
}

//Set Property
override flash_proxy function setProperty(name : *, value : *) : void
{
    var oldValue : *;

    //Check for existing value
    if (name in properties)
    {
        //We do have one, we need to retrieve it for comparison and a useful PropertyChangeEvent
        oldValue = properties[name];

        //Check to see if there's no change (in which case we're out like 3 stripes)
        if (oldValue === value)
            return;
    }
    else
    {
        //If we're here, then this is a new property (not an update)
        propertyNames.push(name);
    }

    //Set property
    properties[name] = value;

    //Announce!
    dispatchEvent(PropertyChangeEvent.createUpdateEvent(this, name, oldValue, value));
}

These functions are pretty self-explanatory. A couple of things might jump out at you if you're new(ish) to ActionScript though:

The use of flash_proxy in place of private, public, or internal: In Actionscript, private, public and internal are simply namespaces (but built in and with special meaning). Proxy uses its own namespace so that its methods don't clash with anything you might be trying to intercept. You can also define your own namespaces, and there's an entire blog post (or 8) for me to write about mx_internal and the various fun stuff we can do with it!
The in operator: It's not used so much, but I love its elegance. For our intent at the moment, think of it as an analogue to .hasOwnProperty(). There are differences, but for our current purpose either would do, I just prefer it stylistically. If you'd like to read more, check here and here.
Finally, we dispatch our own PropertyChangeEvent, which is how we let Binding know it's time to do its thing.

…I'll post part 2 tomorrow, where we get to the fun stuff!

Design...

2008-09-04T07:47:00.001+10:00

...If this looks borked in IE, email me! I've not had the time to test it since I re-jigged some stuff.

[Mixin]

2008-09-01T15:44:00.002+10:00

Trivia: The [Mixin] metadata is great, I use it all the time when doing framework stuff. Check it out if you've never heard of it, or if you're calling static code some other way. But make sure you only annotate public classes with [Mixin], or your SWF will explode on frame1 inside of SystemManager :)