Codedependent

Video: Stretch and Squash in Flex 4

2009-07-10T14:46:00.000-07:00

Stretch and Squash in Flex 4, the next and episode in the gripping and suspenseful series CodeDependent, is now available from Adobe TV.

This show is a continuation of the episode (can you guess?) Stretch and Squash in Flex 3, in which we saw how to use Flex 3 to create deforming bouncing effects for more life-like motion with Flex 3. This time, we'll see how the same effects can be created in Flex 4 (with less code!).

Here's the video:

Here is the demo application:

And here is the source code. Note that the code has changed to match the current APIs (we had some class/package/namespace renames along the way - Flex 4 is still in Beta, after all...).

Have a (squashy) ball.

Video: Stretch & Squash

2009-06-26T09:35:00.000-07:00

Stretch & Squash in Flex 3, the next episode in CodeDependent series, is now available from Adobe TV.

This show is a continuation of the episode Bouncing Ball Behavior, in which we saw how to use easing functions in Flex 3 to add bouncing motion to a bal in Flex 3. This time, we'll see how to apply some techniques from traditional cartoon animation to make the bouncing ball seem more lifelike.

Here's the video:

Here is the demo application:

And here is the source code.

Have a (stretchy) ball.

Video: Bouncing Ball Behavior

2009-06-19T16:39:00.000-07:00

Bouncing Ball Behavior, the next and bountifully alliterative episode in the gripping and suspenseful series CodeDependent, is now available from Adobe TV.

This show is a continuation of the episode Easing Does It, in which we saw how to use easing functions in Flex 3 to create different kinds of motion. This time, we'll see how to use what we now know about easing functions to add bouncing behavior to our ball using Flex 3.

Here's the video:

Here is the demo application:

And here is the source code.

Have a ball.

JavaOne slides posted

2009-06-18T07:49:00.000-07:00

Sun has posted the PDF for the presentation that I did at JavaOne this year with Romain Guy, Move Your Users: Animation Principles for Great User Experiences (you'll have to join the Sun Developer Network to access that URL, but it's easy and free).

The demos were a big part of the presentation, of course (as was Romain doing a running jump off the stage and blowing the microphone), and those aren't in the slides. But most of the demos either already exist online (we showed a few from Filthy Rich Clients) or (in the case of the Flex demos) will be shown here as I post blogs and videos that talk about those applications in detail.

Enjoy...

Video: Flashcamp Presentation on Flex 4

2009-06-15T07:48:00.000-07:00

I gave a quick talk at a recent Flashcamp at the SF Adobe building. If you want a (very) quick overview of the Flex 4 effects architecture and some examples of how to use the various new effects, check out the verbosely-named Using Effects and Animation in Flex 4. Actually, there were a lot of great, quick talks that evening by other folks on the Flex, AIR, and tools teams: you'll probably want to grab some popcorn and watch more: http://labs.adobe.com/technologies/flash/videos/#flashcamp In face, that same page has other video tutorials on Flex, Flash Builder, and Flash Catalyst. What the heck, just watch them all. You don't have work to do today, do you? http://labs.adobe.com/technologies/flash/videos/

Effects in Flex 4 SDK Beta: Part 2

2009-06-08T14:29:00.000-07:00

Finally, the long-awaited cliff-hanger ending to the extensive, rich, and diverse series that began with Part 1: allow me to introduce Part 2.

This second article on the new effects in Flex 4 concludes my discussion of the new effects. This second article covers the new effects based on the new 3D and Pixel Bender shader capabilities in Flash Player 10.

As with Part 1, there are code snippets throughout the article and all of the demos are packaged up in SWFs and source form for convenient download.

Enjoy...

Video: Easing Does It

2009-06-08T07:47:00.000-07:00

Easing Does It, the next episode in the gripping and suspenseful series CodeDependent, is now available from Adobe TV.

This show is a continuation of the episode A Moving Comparison, in which we saw how to create simple animations in Flex 3 and Flex 4. This time, we'll see how to add 'easing' behavior to our Flex 3 animation to create non-linear motion.

Here's the video:

Here is the demo application:

And here is the source code.

Enjoy.

Interview: InformIT

2009-06-03T08:51:00.000-07:00

InformIT has just published an interview that they did recently with me and Romain Guy. We talk about Java, Flex, our book, and random client-y stuff.

Effects in Flex 4 SDK Beta: Part 1

2009-06-01T08:14:00.001-07:00

As part of the beta launch, I wrote an article about the new effects that are part of Flex 4.

They asked for a single article of about 2500 words, and I churned out a monster weighing in at over 10,000 words. Apparently, I have a way with words: way too much.

After much gnashing of teeth and painful whittling down, we compromised on 2 articles. Part one, which covers the Animate superclass of the new effects and a handful of the more basic effects, is now live. Look for Part 2 soon. (Update: Part 2 is now live)

Check out the other articles while you're there - my articles focus specifically on effects and ignore a lot of the other great changes in the release (because I knew other articles would cover them and because I was having a hard enough time getting the article down to a reasonable size without trying to explain more). For example, Matt Chotin (Flex Product Manager) wrote an overview of the new features in What's New in Flex 4 SDK beta and Joan Lafferty (on the Flex SDK QA team) covers differences in this release and the last one in Differences between Flex 3 SDK and Flex 4 SDK beta.

Lots of stuff to read. Should keep you busy while we keep working on finishing the release.

Flex 4 SDK: Beta than Eva

2009-06-01T08:06:00.000-07:00

It's here, it's hot, and it's beta than ever - it's the Flex 4 SDK Beta release!

This release has it all, including a new component model, new states syntax, declarative graphics, and new effects. Check out the articles on the Flex Devnet Site for more information about the release. Flex 4 Beta represents what we've been aiming at for the Flex 4 release. For the most party, we just have some minor tweaks left on some of the features, some bug fixing to make it rock solid, and of course fixing any issues that come from beta feedback.

Go grab the beta build, try it out, and let us know what you think.

JavaOne, Too

2009-05-26T08:17:00.000-07:00

For those not following my Java blog (what, one post per year isn't enough?), I thought I'd mention that I'll be back at the JavaOne conference this year, speaking about Flex, Java, and fun graphics/animation stuff.

The main thing for me this year is the presentation that I'm doing with Romain Guy, called "Move Your Users: Animation Principles for Great User Experiences". We'll be presenting at 11:05 on Wednesday (June 3rd), and again at a repeat session on Friday afternoon (June 5th). This year's talk will be less about code and more about concepts and design principles. Should be fun.

I will also be assisting Duane Nickull in his lab on creating PDFs with LC ES and other server-side stuff that I should really learn one of these days. There is also an Adobe event at Jillian's on Wednesday from 6:30-9:30 PM - stop by the Adobe booth for more information. Speaking of the booth, I'll be spending some quality time there when not in sessions doing some small talks, demos, and generally hanging out trying to look like I work for Marketing. Stop by if you're around the show floor.

Video: CodeDependent #2, er, 7

2009-05-22T07:29:00.000-07:00

Now things are really moving...

The next episode of CodeDependent, "A Moving Comparison," is out. There are actually 7 episodes in the show so far, but 5 of those are reruns, rendered onto the spiffy new CodeDependent set. (I suspect that the earlier versions of those episodes, rendered on the standard Aodbe Developer Connection backdrop, will become collectors' items. Somewhere. Sometime. Perhaps they will be re-master and re-released someday, as "Codedependent Classics").

This latest show is a brand new one, starting right where the first one, "Graphics in Flex 3 and Gumbo", left off. In the first episode, I compared simple custom graphics in Flex 3 to simple graphics in Flex 4 (codename Gumbo). In this episode, I compare simple animations in Flex 3 and Gumbo on those same graphics objects.

Here's the video:

Here are the demos:

And here is the source code.

Enjoy.

Video: Codedependent Reruns Already?

2009-05-12T08:30:00.000-07:00

Usually, a show has reruns after at least one successful season, when everyone's on vacation and the actors are playing hardball for contract renewals and the public is demanding content that just isn't there. But with CodeDependent, we have reruns after just one show. It's either that popular or the producers are just trying to amortize the costs for that amazingly expensive and glamorous CG set backdrop.

In case anyone's checking out the CodeDependent video page, or the Codedependent show on iTunes, I wanted to point out that there are a small number of reruns in the pipe. That is, there are a few videos that came out in the last several weeks on Adobe TV before the CodeDependent show existed (our people were still talking to their people, the unions were on strike, the writers wanted more donuts, and we were all doing the usual bickering and negotiating that is a natural part of any major show production) that have been sucked up under the CodeDependent banner. The producers have taken the old content and basically re-rendered it with the nifty new grayscale backdrop. Same content, different look, like plastic surgery without the cost, wider smile, and mortality risks.

There will be a handful of these reruns coming out in the next few days, then it's back to new content. I think this is probably the only time there will be reruns on CodeDependent, but maybe if there's a writers' strike next year, we'll see old home movies of me pushed as CodeDependent shows.

In the meantime, I'll continue to post items here on this blog when there is new content. Look for a new show in a few days...

Video: CodeDependent #1

2009-05-11T07:27:00.000-07:00

Adobe TV has just posted the first in what I hope to be a very long run of my new show, “CodeDependent”. Fortunately, the show is not on the Fox network, so that may give it a better chance of not being canceled.

The CodeDependent show is not that different from the videos I’ve been doing already: short tutorials on various aspects of Flex and Flash that I find interesting. The biggest change is that they should be more regular (we’re aiming for an every-other-week schedule as we settle into it). Also, they producers gave me a nifty new grayscale CG set design to match my nifty old grayscale CG personality.

This first show is a simple tutorial on Flex 3 and Flex 4 (codename Gumbo) graphics. For the Flex 3 demo, you'll see how to drop down into ActionScript code to draw simple graphics through the Flash APIs into your Flex application. For the Flex 4 version, you'll see you to do the same thing through MXML graphics tags. In future episodes, we'll build on these simple examples and see how to animate the objectsand how to get more realistic animations. (Can you feel the suspense of this cliff-hanger? I’m trying to incorporate standard television series techniques into the show. Look for a laughtrack soon.) But I’m getting way ahead of myself.

Here’s the video:

Here’s the awesome demo application:

And here’s the source code.

Enjoy. And welcome to my show…

Effects and other Flex Stuff at Flash Camp SF: May 29th

2009-05-05T10:57:00.000-07:00

Mike Chambers just posted info about Flash Camp San Francisco on the evening of Friday, May 29th at the Adobe offices in SF. I'll be talking about Flex 4 effects at 9:10 PM. That's about 10 minutes past my bedtime, so I'll probably hit the coffee harder than the beer that evening. This gathering is primarly about Flex 4, Flex Builder 4, and Flash Catalyst. Go read about the event, check out the schedule, and register. It's free, but space is limited, so register now.

Video: Interview on Parleys.com

2009-04-09T11:26:00.000-07:00

The Java Posse interviewed James Ward and I during the Devoxx conference last December. Catch it on the excellent parleys.com site or watch it here:

Post: Fix Prefix

2009-04-01T10:34:00.000-07:00

Update 4/2/09: Hopefully it is obvious, but in case anyone stumbles upon this post unknowingly, please note that it was an April Fools joke.

I hate explaining or pointing out jokes. It's like having to bribe the teacher to pass your child because the kid couldn't master Kindergarten on their own merits. But in this case, I'd like to be clear to avoid any confusion over what Flex actually supports and why.

Like any good joke and some former presidents, there is a small bit of truth behind it, but a lot of it's just hooey. Except for item 6, which really is the current state of the Spark component names. And the part about the community. We really do have posters of them up on our walls, at work and at home. Every one of 'em.

What's in a name? A rose by any other name would still draw blood...

If you’ve paid any attention to the development of Gumbo, the next release of the Flex platform, you probably know that there was a dust-up about the naming of the new components and effects in Gumbo. In technical terms, this is known as a ‘kerfluffle’, but it generally boiled down to a process of the community beating up the Flex team on a regular basis.

Now we on the Flex team love the community: we have pictures of them in our cubes, we try to friend them on FaceBook (though they usually reject us), and we generally suck up to them every chance we get. In fact, we have an internal contest of collecting signatures of community members. Deepa’s currently ahead, but we suspect some are forgeries.

Because of our abiding, nearly predatory love for the community, we wanted to make things right. So when people found fault with our proposed component names, we pissed and moaned and generally felt sorry for ourselves. Then, in a feat of maturity heretofore unknown to engineers, we sucked it up and tried to fix it.

I’d like to lay out the general history of the naming proposals, and then show the final result. I’m sure you’ll agree with us that it’s really fantastic now and that you now respect and admire us for the changes we’ve made. And who knows – maybe we can even get your autograph.

For the descriptions below, I’ll focus (get it? focus! Just another in a hilarious serious of UI toolkit-related word plays. God, I love working on this technology!) on the ‘button’ component, as it’s representative of everything else in the toolkit, from components to effects to that utility class that calculates Pi to 1,547 digits (using the circular reasoning algorithm).

1. First attempt: Button

In the beginning, there was a word, and the word was Button. Unfortunately, that word was already taken by Button in Halo. But surely nobody would care when the new Spark button was going to be so magnificent that nobody would ever care about the old Button again, right? So we named our new Spark button ‘Button’ and went on our merry way. But the tools, Lo did the chafe and grumble. What about applications that used both Halo and Spark components? What to hint? What to complete? How to distinguish? Clearly, another solution was desired.

2. Second attempt: Synonym for Button

Well, since Button was taken, we needed a different name for the same darned thing. We considered several alternatives, including:

ThingThatPushes
RectangularClickyThing
BetterButton
OnButt
PressMe
Presser
ComponentFormerlyKnownAsButton

The last of these was the leading contender for some time. We even developed a custom glyph for the object, but it turned out the glyph could not be represented in unicode and that the class became so long that it bloated our SWF sizes by 10x, so we sadly gave up on this angle and searched for something else.

3. Attempt the Third: Suffix

It turned out that ‘Button’ really was the best name for something that was, well, a button. We realized that we needed something distinguish the new from the old button, however, so we considered suffix text, including:

ButtonNew
Buttonn (repeat the last letter, like Panell, Checkboxx, etc. This broke down when legal objected to our use of ‘Canvass’ as being obscene and derogatory toward Canvas-like objects).
ButtonSpark
ButtonButton
Button2

All of these would have been possible, but we gave up on this path due to what we in the trade call “The Icky Factor.” We did try out these various alternatives in front of a live studio audience. They threw up.

4. The Fourth Attempt: Prefix

Well, if a suffix wouldn’t do it, surely a prefix would. So we tried several, including:

JButton: Hans suggested this one. It seemed very familiar to some of us, like coming home. But execs rejected it on the paltry basis that the letter J has nothing to do with Flex.
SparkButton: This variation had several advantages:

It would promote the branding of the new Spark theme in Gumbo.
It had a perky ring to it
It would help developers practice their typing skills by requiring these extra five letters for every component and effect.

Nonetheless, this variation was killed in committee for being too easily confused with the UI components released by the Scatological Processes of Anitomically Correct Koalas agency.

SButton: This was a leading contender for a while, but finally withered and died when someone realized that the new HitTester component would suffer with the preceding S.
FxButton: Finally we had a winner.

FxButton had clearly won. It had the multiple merits of being easy to type, indicative of the Flex platform, and having that cool letter "x" in it that all hip products nowadays must have. Obviously people would love FxButton and would shower praise and autographs upon us.

5. The Fifth Attempt: The Community Hates It

It's not clear what happened: Do international keyboards lack the F or x keys? Did people not enjoy the extra typing practice it gave them? Did they not enjoy the clever but subtle pun that the new component was a "fix" for the old one (we laughed for weeks over that one. Oh, we have a jolly old time in the Flex offices, that's for sure!).

Whatever the reason, the community hated it. They railed upon our decision, they cast aspersions on the Fx prefix, and they scrawled mean words about us on bathroom walls in engineering institutions everywhere.

So we swallowed our pride, along with a case of scotch, and headed back to the planning room for

6. The Sixth Attempt: Goto (1)

It turned out that 'Button' was really the best name for Button after all. The nuance was that we needed to set up separate namespaces, a common pattern in Flex applications already, to deal with the name collisions. So we did this, setting up a namespace for the core language, another for the old Halo components, and a third for the Spark components, and then went through the joys and pleasures of renaming all of our classes again, enabling our QE department to rewrite tests and generally feel fulfilled and fully employed. As a result, we ended up with a Halo button that you would use by calling <mx:Button/> and a Spark button that you would create by calling <s:Button/>. They're both buttons, they just live in different namespaces. Like twins that are raised in different cultures, one that grows up to be a cop, the other a criminal. Then they meet by chance during a bank job and wind up pointing guns at each other, each having to make his own choice whether to take out his brother for the sake of the life he's chosen, yet clearly hearkening for the shared bonds and experiences that genes bring.

7. The Final Chapter

So that's it, that's the state of the renames: We now have the same names for the same components in Halo and Spark, except for the different namespaces to qualify them accordingly.

But that was yesterday. Then, just today, someone suggested something that is so huge, so fundamentally awesomely stunning and cool that we're rewriting the SDK and all the tests again and have now checked in the final fix to the whole thing: self-obfuscating code.

The original problem to solve was that we didn't want to confuse people by having the same name for different things. In the meantime, developers of web applications like to obfuscate their code to make it harder for shady engineers (perhaps their twins, raised in a different culture to a life of high-tech crime) to steal their ideas. In the interest of both of these goals, we now introduce:

<mx:Bxgthnr5gl!8x/>

Every night, the build auto-generates a random series of ASCII characters for each Spark component, thus guaranteeing that each component name is different from other Spark component names, from the old Halo component names, and from anything else that might otherwise confuse developers. Developers can now be assured that component names are completely unique. And since the generation is done as part of the build, we also auto-generate the ASDocs at the same time, making it easy for developers to figure out what the correct component names are for the build that they are using.

No more "Which Button do I use?" or "What was that prefix again?" or "I hate when other people can read my code!" or "Gee, I wish names were randomly generated so that I could practice my random keystroke typing speed!" Now, with the new Fully Obfuscated Occasionally Long component names, we expect Spark and the Flex Gumbo platform to be the favorite platform for RIA developers everywhere.

Video: A Moment of Reflexion

2009-03-24T08:13:00.000-07:00

Finally, after great suspense and bitings of nails, Adobe TV has posted my Reflexion Container video. This video was meant to be Part 1 in a sequence of 2 parts, but for reasons that escape me, Part 2 (What a Drag) got posted first. Many things in life are beyond our control: the weather, the things our children say in public, and our cravings for bacon. Apparently, the order of videos posted on Adobe TV is just another random factor in life.

This video shows a container that displays an image along with its reflection. The application has sliders to control the various parameters of the reflection, so that you can see how these parameters affect the realism of the reflection. The reflected image can be changed by clicking on a different thumbnail or, as we saw in the previous Drag and Drop video, by dragging and dropping that thumbnail onto the reflection container.

The techniques used in creating the reflection are not new; I wanted to create this demo to show how they might be used in a sample application container. Also, I wanted to expose the controls to the reflection parameters so that we could see how the various mechanisms affect the result. A couple of resources that I consulted for the reflection technique include the ReflectionPanel demo by Romain Guy (also the photographer of the pictures used in the demo) in a Java book that I've read entitled Filthy Rich Clients and, a bit closer to Flex, an article by Ben Pritchard on the Adobe Devleoper Connection site..

Video being what it is, you may not be able to see some of the impact of the reflection parameters that clearly. For example, when I talk about blurring the reflection to make it more realistic, it actually looks kind of blurry to begin with. Here is the demo itself so that you can play with it directly:

And here is the source code for anyone wishing to see how it actually works. I should point out that it's not the cleanest code, since it was written in a conference rush. The reflection code is the main point of it all, and it's pretty striaghtforward, but the mechanisms of updating the image and recreating the reflection sprite could definitely be cleaner. But in the interests of getting the code out there for people to see, I'm posting it earlier than I might otherwise.

Here's the video - enjoy:

Animation Spawning

2009-03-17T07:29:00.000-07:00

A developer posted an issue on one of the Flex forums last week that the new Gumbo effects had choppy artifacts when running his test case, especially when compared to similar code that used the Tweener animation library. Being of a sensitive and insecure nature, and wanting to fix any bugs in my effects code, I looked into the problem and discovered some things about animation seemed worth this post.

The Test Case

The original test case used a 3D rotation effect. But between different behavior between Tweener and our FxRotate3D effect and my workspace being a tad torn apart at the moment, I simplified the case down to animating a small square to the current mouse position. Specifically, as you move the mouse around you set a new position to which the the square will animate. If the mouse stops moving, the square will animate toward that position and stop when it gets there. Otherwise, the square will keep animating toward whatever the new position is, changing direction a sthe mouse moves around.

The original test case was set up to start a new animation every time the mouse moved, in a mouse movement handler. Here's that code for the Tweener version:

       private function mouseMoveHandler(event:MouseEvent):void
       {
           Tweener.addTween(rect,
               {x:event.stageX,y:event.stageY,time:2});
       }

where this call animates the rectangle's x and y properties from their current values to the new x/y location of the mouse over a duration of 2 seconds.

Here is similar code for the Flex effects version:

       private function mouseMoveHandler(event:MouseEvent):void
       {
           mover.xTo = event.stageX;
           mover.yTo = event.stageY;
           mover.stop();
           mover.play();
       }

where the Flex mover effect is declared like this:

    <Declarations>
       <easing:Exponential id="exponentialEase" easeInFraction="0"/>
       <FxMove id="mover" target="{rect}" easer="{exponentialEase}" duration="2000"
           animationUpdate="updateHandler(event)"/>
   </Declarations>

Note that the Exponential ease is not in the SDK yet - I created one for this example to mimic the behavior of Tweener's default easing. I will be adding that class sometime soon, along with more of the old easing classes for the Flex3 effects.

The Demos

Here's the Tweener version of the application. If you move the mouse constantly in a particular direction, you can see the square hopping to keep up with it. It's not smooth, but it does aggressively try to keep up, and gets smoother when the mouse stops:

And here's the Flex effects version of the application:

Note that the square seems to move much more slowly when the mouse is in constant motion. In fact, inside of browsers on the Mac (which was the test platform for the person that submitted the original issue), sometimes the square doesn't move at all until the mouse stops moving, at which point the animation engine kicks in and we get a smooth animation of the square.

Now notice that the Flex effects test has a checkbox in the upper-right, cunningly labeled "Smooth Moves." If you check that, you may notice that the animations are a bit snappier, and closer to what you are seeing in the Tweener version. (In fact, I see smoother performance in general with this version than the Tweener version, probably because we force a higher frame rate on animations by posting an updateAfterEvent request whenever there is a Timer event, which will force a render event between the usual enterFrame events). And on the Mac, you should notice that you no longer get complete freezing or jarring delays while the mouse is moving around. All in all, the app is much better behaved when that box is checked.

So what was the fix?

The Fix

It turns out that the original method of spawning new animations for every mouse move is not just more overhead than you really want or need in your animation - it's actually bad practice. Depending on the platform you're on, the frame rate you're getting, the event at which Timer events (which are currently the basis for the Flex effects animation updates) are coming in, and the rate at which mouse events are coming in, you're going to get somewhat unpredictable behavior. What's happening is this:

Between actual animation updates, whether they happen because of a Timer (in the case of Flex effects) or the enterFrame event (in the case of Tweener), you may be restarting your animation one or more times. And depending on when those restarts happen relative to the next animation update, the behavior of those animations may not be what you want. In the case of Flex effects, imagine that you restart your animation 4 times between animation updates because mouse move events came in that many times between updates. When the system finally gets to update the animation, it will use the last one started, which may have started just prior to, or even at the same time as, the current update time. So you may get no movement whatsoever from your animation because according to the time elapsed between the time that you started it and the time you measured it, no time has passed, so the object shouldn't move. Then you start getting mouse events again, and spawning new animations, and you eventually reach the next animation update event only to find that, once again, you are processing an animation that hasn't had any time pass since it was begun.

"But, but, but, " you may justifiably be stuttering, "What about Tweener? Why is that system able to handle this situation better and keep that object moving?"

Why, indeed? The answer is that it does not actually record the true start time for any animation, but rather uses the time used at the last animation update, which is the previous enterFrame event. So when you restart an animation just prior to the next enterFrame event, it doesn't matter that very little or no real time passes between starting it and processing it the first time - the system will process it as if it had been started at the previous enterFrame time. So our little square is able to keep moving around on the screen because the constantly restarted animations are using inflated elapsed times for every calculation.

Note: I'm not saying that Tweener should or should not do it this way; it's just the way that that system happens to work, just as Flex effects work differently by assigning a real start time based on when the effect is started.

But when I realized that that was the key that was causing the stutter I was seeing on Mac browsers for the Flex effects version, I realized that the problem was not in the way that we were handling animations (because I do want Flex effects to reflect the real elapsed time, regardless of when they are started), but rather in how and when these animations were being launched. In particular, it doesn't make sense to launch several animations in between times when we're actually updating the animation. Instead, it makes more sense, both because of the issues here and from the "don't do so freaking much work" standpoint, to track the mouse movement but only cause it to restart animations at other, less frequent intervals.

The "fix" embedded in the "Smooth Moves" variation in the application above does just that: it tracks the mouse movement constantly and then uses the last known position to launch a new animation in the next enterFrame handler (if the position has changed since we started the last animation). In this way, we can be assured that we're letting our animation run at least a little bit before we clobber and restart it with new values, potentially stalling out because we're not allowing things to move at all before we restart a new animation in place of the older one.

Here's the complete code for the Flex effects version - you can see how we handle the animation-spawning logic differently based on the setting of the checkbox. By default, we restart the effect every time the mouse moves. But when the checkbox is selected (smoothMoves.selected == true), then we only record the last mouse position in mouseMoveHandler(), and we defer spawning a new animation until the next enterFrame() call.

<?xml version="1.0" encoding="utf-8"?>
<FxApplication xmlns="http://ns.adobe.com/mxml/2009" width="100%" height="100%"
   enterFrame="enterFrame(event)" mouseMove="mouseMoveHandler(event)"
   xmlns:easing="easing.*">
   <Script>
       <![CDATA[
       import mx.events.AnimationEvent;
      
       private var lastMouseX:int;
       private var lastMouseY:int;
       private var mouseMoved:Boolean;
      
       private function mouseMoveHandler(event:MouseEvent):void
       {
           if (smoothMoves.selected)
           {
               lastMouseX = event.stageX;
               lastMouseY = event.stageY;
               mouseMoved = true;
               if (!mover.isPlaying)
                   mover.play();
           }
           else
           {
               mover.xTo = event.stageX;
               mover.yTo = event.stageY;
               mover.stop();
               mover.play();
           }
       }
       private function enterFrame(event:Event):void
       {
           if (mouseMoved)
           {
               mover.xTo = lastMouseX;
               mover.yTo = lastMouseY;
               mover.stop();
               mover.play();
               mouseMoved = false;
           }
       }
       ]]>
   </Script>
   <Declarations>
       <Power id="powerEase" easeInFraction="0" exponent="7"/>
       <easing:Exponential id="exponentialEase" easeInFraction="0"/>
       <FxMove id="mover" target="{rect}" easer="{exponentialEase}" duration="2000"/>
   </Declarations>
   <Rect id="rect" width="20" height="20">
       <fill>
           <SolidColor color="0xff0000"/>
       </fill>
   </Rect>
   <HBox top="10" right="10">
       <Label text="Smooth Moves"/>
       <CheckBox id="smoothMoves"/>
   </HBox>
</FxApplication>

So: don't spawn animations too aggressively; you may not get the effect you're after from the effect. And note that this approach should work just as well for Tweener (or any other animation engine) as for Flex effects; Tweener only happened to look better in this situation because of its inherent timing behavior, but there would be no reason not to back off and have it spawn less animations too.

p.s.

As a side note, I should point out that another artifact that the original poster ran into was caused by playing the Flex effect multiple times without stopping the previous one(s). You should always, at least in the current Flex effects system, stop() currently playing effects on the same target/property, because otherwise you're effectively giving that property multiple, conflicting instructions at every animation update, as all of the active animations on that property may try to assign different values to it. Tweener does not have this issue because it auto-stops any animations running on that target/property, but Flex effects require you to stop the effect itself. Note that this doesn't mean that you need to stop all effects in the system when you play a new one, or even all effects running on a particular target; the only time that it's an issue is when there are multiple effects running on the same property of the same target(s), as is the case in the example here, where we are always changing the same target's x and y properties.

If you're interested in the full source code, which includes the simple examples above plus the supporting Exponential and Tweener classes used by the examples, here it is. Note that building the Flex effects example requires some recent build of the Gumbo SDK, as it uses classs that only exist in that version of the platform. If you really want to, you should be able to run similar tests with Flex 3 effects (using components instead of the new Gumbo Rect object), since they use the same underlying Timer facility. But the main point of the article was in the demos and explanations; the code is just provided to give a sense of closure.

Video: Flex 3 Effects

2009-03-13T07:37:00.000-07:00

Adobe TV has posted a video of me talking about Flex 3 effects. This is basically a subset of the material I covered in my MAX presentation, specifically about the Flex 3 effects architecture: Tween, Effects, Transitions, and so on. No demos this time, just slides, but hopefully helpful if you're trying to figure out how all of these classes and capabilities work together.

Effects are, I think, one of the cooler things about the Flex platform, especially when they make it so easy to provide simple state transitions for a richer user experience. Understanding how they all fit together can help you make more 'effective' use of them.

Enjoy....

AS34J2: ActionScript for Java Developers, Part Two

2009-03-12T13:06:00.000-07:00

The suspense is over, life can return to normal: JavaWorld has posted the second and final installment of my two-part article, ActionScript for Java Developers, which is based on a presentation that James Ward and I did at the Devoxx conference in December.

Part 2 is a bit deeper than Part 1. Now that we've gotten past some of the basic syntax issues in the languages, we're able to get into more complex topics, including Properties, Dynamic aspects of ActionScript, and Functions.

Enjoy...

Devoxx Talk Posted on Parleys.com: 'The Future of Rich Internet Applications'

2009-03-05T11:39:00.000-08:00

The Parleys.com site has just posted the talk that I did at Devoxx in December with Matt Chotin (Flex SDK Product Manager) and James Ward (Flex Evangelist).

Go check out the presentation on the parleys site itself. Parleys is a fantastic Flex application, from the player that you watch the videos in to the publisher that they use to actually create these video/slide/demo-rich presentations. Nice work by Stephan Janssen (founder of Devoxx and Parleys.com) and Benjamin Dobler (developer of the Flex viewer and publisher).

Enjoy...

Video: Smarter Effects in Gumbo

2009-02-25T12:22:00.001-08:00

Here's another video from Adobe TV. In this one, I'm showing a couple of applications that demonstrate some of the intelligence that we're building into the new effects in Gumbo (the codename for the next release of Flex). Specifically, these demos show some of the new automatic behavior of the Fade effect and the new "autoReverse" capability of transitions.

As with any Gumbo demos, you should not get too locked into the specific APIs, since we're still very much mid-development. For example, all of the effects currently have an "Fx" prefix in the classnames which should be going away soon. But the point of the applications is to show the functionality and behavior of the effects, which is here to stay.

I should/will post the code and applications soon, but my workspace is a bit torn up at the moment, since I'm in the middle of more cool-o effects features. As soon as that's cleared up, I'll update this post to have the code available. Meanwhile, grab the popcorn, sit back, and enjoy all 6 minutes and 8 seconds of:

AS34J1

2009-02-17T11:26:00.000-08:00

JavaWorld has just published Part 1 of a two part article entitled ActionScript for Java Developers (though I prefer the more unparsable name AS34J). It's based on a presentation that James Ward and I did at the Devoxx conference in December, walking through various aspects of similarity and differences between Java and AS3. The point is not to promote one language or platform over the other, but rather to take a closer look at AS3 with Java-tinted glasses. Enjoy...

Really Live Cycle Data Services

2009-02-13T07:24:00.000-08:00

I don't usually go in for PR announcements here; I figure that kind of stuff is covered pretty well in other places. But I had to mention this one that I just saw:

Amgen Tour of California Leverages Adobe Flash Platform

Apparently, the race will be streamed live over the web using Flash.

Pretty excellent, but my favorite part is the product name of the Adobe server software that's helping to enable it: "Live Cycle Data Services"

Perfect.

It's like Flash being used for photography, or Flex for applications in the rubber industry, or AIR applications for atmospheric monitoring. I'll be on the lookout for more product name-appropriate partnerships. Brand reinforcement is so critical.