MAX Out

The MAX 2008 conference schedule and details are posted: http://max.adobe.com/na/experience/. I'll be giving a talk on "Filthy Rich [Flex] Clients," just one of many talks on Flex and other development goodies. Check it out and join us November 16-19 in San Francisco (non-US MAX conferences to follow later) to hear about Flex, Flash, tools, and all that designer/developer stuff.

Pulse of the Geek Nation

You saw it on Adobe TV, now you can see it in code....

Here is the running demo and source code for the Pulse application seen on the Developer channel of Adobe TV.

Rather than spend time here reiterating on what I said on the video, I'll just refer you to the video to get the motivation for the effect as well as the code walkthrough.

The Video

In case you didn't manage to make it to Adobe TV, here's the video presentation for Pulse:

The Demo

And here's the running demo itself:

The Code

And finally, here's the source code. I'm tempted to put snippets of the source code inline and go over them, but I would be basically duplicating what I already did in the video, so watch the video instead.

Thanks to Romain Guy for the original (Java) version of the demo, which he wrote for our book.

Video: Pulse

Adobe TV surprised me today by posting my Pulse demo much sooner than I thought they would. Four videos posted in just over a week. I feel like Ben Affleck, where everyone will probably get sick of me when I'm just getting started. Except that Ben has a way bigger jaw and whiter teeth. And I bet he can't program graphics applications. This demo is the first in a series of "Filthy Rich Client" applications, where I look at what it would take to enable specific graphical or animated effects on the Flex platform. The Pulse demo in particular is a Flex take on an application originally written in Java by Romain Guy. The only problem is that I wasn't quite ready to post the source (just have to go through it and make sure it's ready for leaving the nest: nicely commented, teeth brushed, lunch packed...). So watch the video for now and check back here soon if you're interested in seeing the source code and application. By the way, this kind of content is also being posted on the Flex Developer Center, so you might also put that site on your list of Flex learning bookmarks.

Video: Top Drawer (Parts II & III)

Adobe TV has posted the second and third installments of the Top Drawer videos that we made, showing how we turn mouse events (Part II) into graphical shapes (Part III). Be sure to also check out my original Top Drawer postings (here, here, here, and here) that link to the source code for the project.

Video: Top Drawer (Part I)

The folks at Adobe TV have been shooting some videos recently of Adobe people doing quick techy presentations and these are starting to get posted on the Developer area. I've done some episodes on "Top Drawer" (the same application that was the subject of some of my earlier blogs here, here, here, and here) and various "filthy rich" effects. My videos should be rolling out on the Adobe TV site in the next few days and weeks. I'll link to the videos as they get posted. For now, check out Top Drawer, Part I.

Splinterview

Sorry, nothing technical today. Lots of stuff in the works, but nothing ready. Instead, here's a tardy link to an interview I did with the JavaOne folks a couple of weeks ago: http://java.sun.com/javaone/sf/2008/articles/rockstar_chethaase.jsp By the way, "Rock Star" is a term that that conference uses to refer to speakers whose sessions were rated highly in previous years. Either that, or they were referring to my bad hair, sullen disposition, and penchant for destroying hotel rooms.

Properties: A Matter of Privacy

I'm going to take a weird tangent today and talk about something non-graphical. Odd, I know, and perhaps a bit disturbing. Like Britney Spears writing a book about effective parenting. Or a politicians working on legislation instead of their re-election campaigns. Nevertheless, I feel compelled to discuss this language feature thatI encountered into it in my recent transition to writing ActionScript3 code.

For someone coming from the Java world, the way that properties work in ActionScript3 requires a mental shift. AS3 properties are pretty cool, but they encourage a different pattern of programming that's new to me, so I thought I'd spend a few words on it for anyone that is also new to properties.

The Ways of Java

In Java, the general rule is to make the properties (or variables) of a class private, preserving encapsulation (if I were a better Java acolyte, I'd quote you the chapter and verse where Effective Java discusses this pattern). If you need to expose the properties through public or protected API, you should create a setter/getter for the property with the appropriate access. For example, instead of this:

    public class Blah {
        public Freen freen;
    }

you would typically do this:

    public class Blah {
        private int freen;
 
        public void setFreen(int newVal) {
            freen = newVal;
        }
        public int getFreen() {
            return freen;
        }
    }

Callers of the API would then call setFreen() and getFreen() instead of referring directly to the instance variable freen.

One good reason for taking this approach in Java, even for simple situations where the getter/setter do nothing besides getting/setting the value, is to make the API future-proof. That is, suppose you decided to track the number of times that freen is set. In the first example above, there is no obvious way to do this other than adding new API that callers must now use. But in the second example, all we have to do is add the necessary logic to our setter function, and we're set:

    public class Blah {
        private int freen;
        private int numSets;
 
        public void setFreen(int newVal) {
            freen = newVal;
            numSets++;
        }
        public int getFreen() {
            return freen;
        }
    }

Notice, in particular, that there is no change to the public API for Blah to add the functionality of incrementing numSets; we buried that new functionality inside the existing API that your users are already calling.

Taking Action[Script3]

Now consider the case of ActionScript3. You could take the approach above and implement setFreen() and getFreen() exactly as we've done in the Java code, modulo differences in how types and functions are declared:

    public class Blah {
        private var freen:int;
 
        public function setFreen(newVal:int):void {
            freen = newVal;
        }
        public function getFreen():int {
            return freen;
        }
    }

But this would be silly because you'd be missing out on all of the advantages of the built-in Property capabilities of the language. It would be like going to France and continuing to eat McDonalds every day because that's what you eat at home. Sure, it does the job, but there are probably better and more interesting ways of accomplishing that task in the new place. Besides, their ketchup tastes weird.

In ActionScript3, there are two special qualifiers on functions, set and get, that make dealing with properties much more flexible. When you declare a function with set as a qualifier, callers call that function by simply specifying the name of it as they would any instance variable. For example, given this class defintion:

    public class Frong {
        private var _glar:int;
 
        public function set glar(newVal:int):void {
            _glar = newVal;
        }
        public function get glar():int {
            return _glar;
        }
    }

callers would set and get the value of _glar like this:

    var frong:Frong = new Frong();
    frong.glar = 5;
    var someInt:int = frong.glar;

So how does this factor into our discussion of private/public API? Because we can migrate our class over time to use public properties and public setters/getters as appropriate, without affecting the API. Let's take the original example, where we simply wanted a public variable freen:

    public class Blah {
        public var freen:int;
    }

Now suppose, as before, we want to add a mechanism to track the number of times freen has been set by the caller. We can change the above code to the following:

    public class Blah {
        private var _freen:int;
        private var numSets:int;
 
        public function set freen(newVal:int):void {
            _freen = newVal;
            ++numSets;

        }
        public function get freen():int {
            return _freen;
        }
    }

This is almost like our earlier ActionScript example where we defined setFreen() and getFreen() functions, but here the function names are just the name of our original variable, freen. But the really important thing is that our public API did not change. We were able to go from a public variable, freen, to a public setter/getter pair for that variable with no perturbation in how the callers of our API interact with that API. With either approach above, callers would do the following to get and set freen:

    var blah:Blah = new Blah();
    blah.freen = 5;
    var someInt:int = blah.freen;

Why It Matters

The whole reason for this post, and perhaps for this capability in the language, is that ActionScript3 developers can just think in terms of properties in their API, instead of in setters and getters for those properties. Developers can, and probably should, use the more terse declaration of public properties, versus the Java approach of public setters/getters, knowing that if more functionality is needed at set/get time, it can be done without changing the API that callers use.

p.s.

As Josh pointed out in the comments after I first posted this entry, it is not possible to override a variable with a function in a subclass. So if you are developing an API and expect or want your developers to be able to modify the behavior of a property via set/get, then you should declare your properties via the set/get functions.