Note that these are basic demos so if you know pretty much anything about animation in ActionScript, these may not teach you anything.

All these scripts do pretty much the same thing. They draw a square on the stage. When you click on it, it moves horizontally from x=100 to x=400. Each of these is a class that you can run as the main class of an AS3 application.

1. The wrong way

The wrong way, of course, is to use a for loop:

package
{
    import flash.events.Event;
    import flash.events.MouseEvent;
    import flash.display.Sprite;
    public class BasicAnimation extends Sprite
    {
        // ------- Constructor -------

        public function BasicAnimation()
        {
            _createChildren();
        }

        // ------- Child display objects -------

        private var _rect:Sprite;

        // ------- Private constants -------

        private const START:int = 100;
        private const END:int = 400;

        // ------- Private methods -------

        private function _createChildren():void
        {
            _rect = new Sprite();
            _rect.graphics.beginFill(0xff0000, 1);
            _rect.graphics.drawRect(0, 0, 100, 100);
            _rect.graphics.endFill();
            _rect.x = START;
            addChild(_rect);
            _rect.addEventListener(MouseEvent.CLICK, _rect_click);
        }

        // ------- Event handling -------

        private function _rect_click(event:MouseEvent):void
        {
            // wrong way:
            _rect.x = START;
            while (_rect.x < END)
            {
                _rect.x++;
            }
        }
    }
}

The right way (most basic)

Of course, this one runs very slow since it’s moving at a rate of 1 pixel per frame.

package
{
    import flash.events.Event;
    import flash.events.MouseEvent;
    import flash.display.Sprite;
    public class BasicAnimation extends Sprite
    {
        // ------- Constructor -------

        public function BasicAnimation()
        {
            _createChildren();
        }

        // ------- Child display objects -------

        private var _rect:Sprite;

        // ------- Private constants -------

        private const START:int = 100;
        private const END:int = 400;

        // ------- Private methods -------

        private function _createChildren():void
        {
            _rect = new Sprite();
            _rect.graphics.beginFill(0xff0000, 1);
            _rect.graphics.drawRect(0, 0, 100, 100);
            _rect.graphics.endFill();
            _rect.x = START;
            addChild(_rect);
            _rect.addEventListener(MouseEvent.CLICK, _rect_click);
        }

        // ------- Event handling -------

        private function _rect_click(event:MouseEvent):void
        {
            // right way (very basic):
            addEventListener(Event.ENTER_FRAME, _enterFrameBasic);
        }

        private function _enterFrameBasic(event:Event):void
        {
            if (_rect.x < END)
            {
                _rect.x++;
            }
            else
            {
                removeEventListener(Event.ENTER_FRAME, _enterFrameBasic);
            }
        }
    }
}

Adding velocity as a variable

The solution to the slowness is to add a velocity variable. The value (in units of pixels per frame) will determine how quickly the animation moves. Basically you just try different values until you’re happy with something. Like the previous example, this is a purely linear animation — the velocity stays constant.

package
{
    import flash.events.Event;
    import flash.events.MouseEvent;
    import flash.display.Sprite;
    public class BasicAnimation extends Sprite
    {
        // ------- Constructor -------

        public function BasicAnimation()
        {
            _createChildren();
        }

        // ------- Child display objects -------

        private var _rect:Sprite;

        // ------- Private constants -------

        private const START:int = 100;
        private const END:int = 400;

        // ------- Private methods -------

        private function _createChildren():void
        {
            _rect = new Sprite();
            _rect.graphics.beginFill(0xff0000, 1);
            _rect.graphics.drawRect(0, 0, 100, 100);
            _rect.graphics.endFill();
            _rect.x = START;
            addChild(_rect);
            _rect.addEventListener(MouseEvent.CLICK, _rect_click);
        }

        // ------- Event handling -------

        private function _rect_click(event:MouseEvent):void
        {
            // right way (very basic):
            addEventListener(Event.ENTER_FRAME, _enterFrameBasic);
        }

        private function _enterFrameBasic(event:Event):void
        {
            if (_rect.x < END)
            {
                var velocity:int = 5;
                _rect.x += velocity;
            }
            else
            {
                removeEventListener(Event.ENTER_FRAME, _enterFrameBasic);
            }
        }
    }
}

Adding acceleration

Once you’ve separated out velocity, it becomes easy to make the animation non-linear by adding an acceleration value that causes the velocity to change over time. We’re just stepping back one level of complexity — the acceleration is now linear instead of the velocity.

package
{
    import flash.events.Event;
    import flash.events.MouseEvent;
    import flash.display.Sprite;
    public class BasicAnimation extends Sprite
    {
        // ------- Constructor -------

        public function BasicAnimation()
        {
            _createChildren();
        }

        // ------- Child display objects -------

        private var _rect:Sprite;

        // ------- Private constants -------

        private const START:int = 100;
        private const END:int = 400;

        // ------- Private methods -------

        private function _createChildren():void
        {
            _rect = new Sprite();
            _rect.graphics.beginFill(0xff0000, 1);
            _rect.graphics.drawRect(0, 0, 100, 100);
            _rect.graphics.endFill();
            _rect.x = START;
            addChild(_rect);
            _rect.addEventListener(MouseEvent.CLICK, _rect_click);
        }

        // ------- Event handling -------

        private function _rect_click(event:MouseEvent):void
        {
            // right way (very basic):
            addEventListener(Event.ENTER_FRAME, _enterFrameBasic);
        }

        private var _velocity:int = 0;

        private function _enterFrameBasic(event:Event):void
        {
            if (_rect.x < END)
            {
                var accel:int = 3;
                _velocity += accel;
                _rect.x += _velocity;
            }
            else
            {
                removeEventListener(Event.ENTER_FRAME, _enterFrameBasic);
            }
        }
    }
}

Interpolating values over time

This next example doesn’t build on the previous ones but instead takes a completely separate approach to creating animation. This animation is time-driven rather than frame-driven. Instead of adding a particular number of pixels to the x value each frame, it calculates how much time has elapsed since the start and what the x value should be at that moment in time, then sets the x property to that value. A consequence of this approach is that regardless of the frame rate of the SWF, the animation will always last the same amount of time.

package
{
    import flash.utils.getTimer;
    import flash.events.Event;
    import flash.events.MouseEvent;
    import flash.display.Sprite;
    public class AnimationIntermediate extends Sprite
    {
        // ------- Constructor -------

        public function AnimationIntermediate()
        {
            _createChildren();
        }

        // ------- Child display objects -------

        private var _rect:Sprite;

        // ------- Private constants -------

        private const START:int = 100;
        private const END:int = 400;
        private const TOTAL_TIME:int = 5000;

        // ------- Private methods -------

        private function _createChildren():void
        {
            _rect = new Sprite();
            _rect.graphics.beginFill(0xff0000, 1);
            _rect.graphics.drawRect(0, 0, 100, 100);
            _rect.graphics.endFill();
            _rect.x = START;
            addChild(_rect);
            _rect.addEventListener(MouseEvent.CLICK, _rect_click);
        }

        // ------- Event handling -------

        private var _startTime:int = 0;

        private function _rect_click(event:MouseEvent):void
        {
            // right way (intermediate):
            _startTime = getTimer();
            addEventListener(Event.ENTER_FRAME, _enterFrameIntermediate);
        }

        private function _enterFrameIntermediate(event:Event):void
        {
            var elapsedTime:int = getTimer() - _startTime;
            var fractionComplete:Number = elapsedTime / TOTAL_TIME;

            if (fractionComplete < 1)
            {
                var totalDistance:int = END - START;
                var offset:int = Math.round(fractionComplete * totalDistance);
                _rect.x = START + offset;
            }
            else
            {
                _rect.x = END;
                removeEventListener(Event.ENTER_FRAME, _enterFrameIntermediate);
            }
        }
    }
}

The main point of this example is to demonstrate the idea that you can plug in an algorithm that calculates position given time, and by varying the algorithm you can vary the animation. This is a direct lead-in to the idea of using tweening functions to vary an animation, as demonstrated in the next example.

Using an animation library

This example shows the use of a third-party animation library (in this case Grant Skinner’s GTween library). The commented-out lines demonstrate how a library makes it easy to synchronize animation and vary the animation. Note that this is only meant as a very basic demonstration of the concept of using a library for animation — GTween and the many other animation libraries that are out there all provide many additional features.

package
{
    import com.gskinner.motion.easing.Bounce;
    import com.gskinner.motion.easing.Sine;
    import com.gskinner.motion.GTween;
    import flash.events.MouseEvent;
    import flash.display.Sprite;
    public class AnimationTween extends Sprite
    {
        // ------- Constructor -------

        public function AnimationTween()
        {
            _createChildren();
        }

        // ------- Child display objects -------

        private var _rect:Sprite;

        // ------- Private constants -------

        private const START:int = 100;
        private const END:int = 400;
        private const TOTAL_TIME:int = 5;

        // ------- Private methods -------

        private function _createChildren():void
        {
            _rect = new Sprite();
            _rect.graphics.beginFill(0xff0000, 1);
            _rect.graphics.drawRect(0, 0, 100, 100);
            _rect.graphics.endFill();
            _rect.x = START;
            addChild(_rect);
            _rect.addEventListener(MouseEvent.CLICK, _rect_click);
        }

        // ------- Event handling -------

        private function _rect_click(event:MouseEvent):void
        {
            var tween:GTween = new GTween(_rect, TOTAL_TIME);
            tween.setValue("x", END);
//            tween.setValue("alpha", .5);
//            tween.ease = Sine.easeInOut;
//            tween.ease = Bounce.easeOut;
        }
    }
}

Last week I gave a presentation at 360|Flex 2010 (San Jose) on “Developing iPhone apps with the Flash Platform.” As always, I wanted to make my slides, notes, reference links, and example code available to those who were there and those who couldn’t make it:

Download slides, links, and example code (3.1 MB .zip)

I’ve been traveling since the conference so I didn’t flesh out my notes as thoroughly as I have for past presentations. If you have a question about a slide, feel free to ask in the comments and I’ll try to explain it better. The 360|Flex folks recorded video of my presentation as well as a screen capture. I believe the plan is to make those recordings available to attendees as well as people who couldn’t make it (though they may charge a fee if you didn’t attend the conference).

Acknowledgments

This is in the slides, but I wanted to once again thank all the people who helped me prepare this presentation (some knowingly, others just by virtue of content they’ve shared):

• Tom Krcha
• Renaun Erickson
• Jeff Swartz
• Aditya Bansod
• Ted Patrick
• Mike Chambers
• Lee Brimelow
• Chiedo Acholonu
• Greg Burch

For lack of a better name, I call it my “AIR SQLite utility library”

The code currently contains one major piece of functionality (well, two different variations on one bit of functionality), which is a SQL “query runner” library. This is a wrapper for the AIR SQL classes that allows you to run a SQL statement by just passing a few bits of information:

• The text of the SQL statement itself
• An object containing properties with the values for any statement parameters in the SQL
• A Function to call when the operation completes
• A failure Function
• (optionally) a class to use as the data type for the data returned from a SELECT statement

The library does all the work of creating SQLStatement objects and caching prepared queries, as well as pooling SQLConnection instances so you can execute multiple statements simultaneously. It also has a variation that allows you to specify a “batch” of statements to execute, and they are executed in order in a transaction.

I’ve also got an additional utility to add to the library. It’s a “database copy” utility that allows you to create a “deep copy” of a database — all it’s tables, views, etc. — with or without data. The key reason why this is useful is that you can use it to create an encrypted database from an unencrypted database (and vice-versa). It’s written and tested, but I decided to modify the structure slightly before releasing it, so it’s not checked in yet.

I’ve put the details about how it works and why it’s designed that way in the project page. In case you’ve ever wondered how I design apps, I think the examples and this library give some insight into how I actually do my database-driven AIR app development. At least, how I structure the data-access part of my apps.

On (another) personal note, this project is also my first project that I’ve posted to my Github repository (as opposed to projects I’ve forked). It was actually posted-but-not-advertised on Google code for a month or so, but I decided to move to Github because the collaboration and checkin-without-network-connection features are so awesome.

• First thing first: if you haven’t seen the MythHackers video about Flash on the iPhone, you must go watch it. I laughed so hard my eyes were watering.
• Aditya Bansod’s ADC article “Developing for the Apple iPhone using Flash,” from the Product Manager who’s in charge of the Flash Platform development for iPhone effort. Includes some technicial details on how it actually works and how you build the apps.
• Adobe Labs: Apps for iPhone: Video demo and list of apps that are already in the app store today
• Adobe Labs developer FAQ: this has the most information about what this really means for developers
• Mike Chambers is, as always, a great resource for information on this topic. He has a nice summary blog post, plus I know he’s collecting questions to answer in his MAX session (on Wednesday, I believe).
• Arno Gourdol, engineering manager for Adobe AIR (and huge iPhone fan and former Apple employee) talks briefly about the underlying technology, with a focus on MAX sessions where you can learn more.
• Never one to hold back his enthusiasm, Ted Patrick has posted the source code for three different Flash Platform iPhone apps he wrote, that can be seen on the demo phones in the Adobe booth at MAX. (He says it’s four apps in the blog title, but he explains that two of them are the same app with and without hardware acceleration.)

That’s all for now. I’ll keep updating the list as I find more resources.

Apparently the article got lost in the shuffle, and about a week ago they found it and asked me to review their changes. I just found out that the article was published today.

Although it’s grouped under the “quick starts” category, it has a lot of detail. Also, it’s included in the Flash developer center but Flex developers shouldn’t be put off by that. It’s really about a core ActionScript class that’s available anywhere you’re writing ActionScript. (I’ve always found the ADC’s forced boundaries between Flash, Flex, and AIR to be too constraining for reality.)

I personally think the article provides a good, in-depth introduction to various aspects of working with the Vector class. In particular, it has guidance on areas that some people find problematic, such as the type parameter syntax and the fact that you have to provide your own custom sorting code (and of course the article includes examples to copy). I personally think it’s better than the developer guide documentation on the Vector class. (And I wrote them both so I’m not just showing a bias for my own work =)

• FlexUnit 4. Wow. Big update. Very nice new features. Time to get (back) into it. (presentation by Michael Labriola)
• Renaun Erickson’s Structured Log Testing framework. Another great, unexpected surprise. I didn’t really have plans to go to this session except that Renaun’s such a smart, friendly guy. And frankly, I’ve never really had enough interest to take a look at his work on this project so far. Boy am I glad I changed my mind. This is definitely a testing approach I can get into — much less overhead than other approaches I’ve seen. Getting going with it is only barely more work than adding trace() calls. And the result is certainly infinitely more valuable.

Considering I didn’t come to Indianapolis with any real interest in hearing more about testing…I’m surprised to find myself so excited by what I saw today. Today is a great day for Flex testing, that’s for sure.

I also got to hear some interesting ideas and future plans from Jacob Wright and Tyler Wright. (They made me a bit jealous — I wish I had a Flex programmer brother that I could see at conferences.) If you’re in Indianapolis, I recommend checking out their “write-in” session on the Flight Framework at 10am Tuesday in the Illinois East room.

Other less code-centric, but interesting, tidbits:

• Joe Berkovitz is an avid mountain biker.
• Ben Stucki has a sweet five-year-old daughter who likes deep-fried calamari and pasta, although she wasn’t able to finish her macaroni and cheese at Buca di Beppo, where apparently even the child meals are sized to feed 3-4 people.

But not any more. A few days ago I checked in a beta (barely tested) version of that adds support for Flash Player 10 (browser) projects. It’s not linked from the main google code project page yet, but you can get to it from the GZIP encoder project downloads page.

The download that adds Flash Player 10 support is “ascompress-.2.0.zip”. It now includes two SWC files:

• GZIPEncoder_AIR.swc is the full package, with all the same features as the previous release (.1.0.2).

• GZIPEncoder_Flash.swc is the Flash-Player-only version. It only compresses/uncompresses ByteArrays, and doesn’t have any support for files.

  Of course, since Flash Player 10 also adds local file opening/saving support that uses ByteArray data for the files, you could easily write your own code to prompt the user for a gzip file, or compress a file and prompt the user to save it. For an example of opening and saving files from Flash Player 10, see my quick start article: “”

As I implied when I described this as “beta (barely tested)” I haven’t done a lot of testing of this code yet. I don’t actually anticipate that there will be issues — really all I did was refactor the code into two classes instead of one — but that doesn’t mean there won’t be any issues, of course. =) If you’re interested, and especially if you’re one of the people who’s asked for this support, I would love it if you try it out and let me know how it works for you. If you’re willing to test it out, I’ll be happy to quickly make any fixes necessary.

One thing I’ve been wishing for the last week or so is undo/redo functionality as I’m editing query text. Coincidentally, I just found out that my 360|Flex friend Jac Wright has written a library for undo and redo in Flash Player (ActionScript) text fields. The previous link is to the Google Code project; here’s his introductory blog post about the “undo textfields” library. (via Tyler Wright via Gilles Guillemin/Twitter)

Admittedly I haven’t tried this yet, and I’ve asked whether it’s been tested in AIR so I don’t know whether it will actually be feasible as-is. But I’ve got my fingers crossed! =)

Like so many people, my work goes in cycles (from “busy” to “crazy” to “desperate crunch”). If you’re someone who follows this site (if in fact there is anybody who does), you may have figured out that any time I go for a long time without posting, it means I’m near the end of a project (and consequently, that new documentation is coming soon).

Well, that time has arrived. With the public announcement of Adobe Creative Suite 4, we’re doing something different in terms of the schedule for releasing documentation. This time the documentation has been released ahead of time, before the product actually ships. (Primarily for the sake of search engine indexing — but hey, let’s not complain.)

Of course, a draft version of the Flash Player 10 language reference has been around for a while now, but if you haven’t had a chance to take a look (or if you want to know how things turned out in their final form), you can now view the final Flash CS4 (including ActionScript for Flash Player 10) documentation. Also, this includes several significant additions to the content in Programming ActionScript 3.0, so if you prefer to learn by reading about a topic rather than by piecing things together from the reference, then you’ll find this content useful.

Here are a few top-level links to get you started:

• Programming ActionScript 3.0
• ActionScript 3.0 Language and Components reference
• Using Flash (including what’s new in Flash CS4)

Just for fun, here is the new content that I wrote:

• Vector class (strongly-typed arrays):

  • Vector class in Programming ActionScript 3.0 (new content is interspersed with the previous content on the Array class)
  • Vector class reference

• Pixel Bender (“custom filters” — although it’s a lot more than filters)

  • Working with Pixel Bender shaders (in Programming ActionScript 3.0) - plus other sections that are linked to from there, about using a shader as a drawing fill, a filter, a blend mode, etc.
  • Shader class reference
  • ShaderJob class reference
  • ShaderParameter and ShaderInput class references
  • ShaderFilter class
  • plus new content in the DisplayObject class, the BlendMode class, the Graphics class, etc.

And here are some of the other new topics that I think are the most interesting:

• Working in three dimensions (3D) in Programming ActionScript 3.0
• Inverse Kinematics (IK) in Programming ActionScript 3.0
• Using the new drawing api (aka “drawing api 2”) in Programming ActionScript 3.0

So, what’s next for me? (Thanks for asking!) Since finishing the final versions of the Flash CS4 documentation, I’ve been working on some “quick start” articles around the new features. Those articles will appear in the Flash developer center soon — probably when Flash CS4 actually ships. (I’ve done one on the Vector class and one on the new FileReference functionality for accessing local files without a server round trip. Other colleagues have done cool things with dynamically generating audio and Pixel Bender — so I think it’ll definitely be worth a look.) Along with that, I’m working on new features for the next version of Adobe AIR. I also have a few side projects that I’ve been trying to make progress on as I can sneak in a minute here and there.

On a personal note, the screenshot that Lee posted for the Vector class documentation was written by me. So that was fun to see =)

My conclusion (not original by any means) was that unit testing is an important tool for ActionScript developers. I’ve tried a couple of ActionScript unit testing frameworks (ASUnit and FlexUnit). And finally getting to the point of this post, I was interested to learn today that the crew at Digital Primates is releasing an open source unit testing framework for Flex, known as “dpunit”.

(via Jesse Warden via Twitter)

The current “favorite” is the Flex Visual Graph Library (FVGL) Open Source Project.

Their Visual Graph explorer sample gives a nice overview of the functionality that’s available.

Anyway, I forgot to note this earlier, so I’m adding it now, though there’s a good chance this isn’t news to anyone who’s interested in this sort of thing.

(via email from Ted Patrick)

Since the majority of the time when someone’s using an Array in ActionScript, they really want all the elements to be the same type anyway, this is a really great addition and I think it will be used heavily. The Vector class allows (requires) you to specify the type it will contain at compile time — both for variable declarations and when creating instances. In both cases the syntax you use is a “type parameter” suffix .<T>:

var names:Vector.<String> = new Vector.<String>();

The type parameter syntax is part of a separate EcmaScript 4th edition proposal. Sadly they couldn’t make the syntax identical to that for generics in C# (and I believe Java does it the same way), which is almost the same but without the initial . (period). (For an interesting read, take a look at the history of the various options the committee members considered for representing type parameters.)

Anyway, because you specify the type at compile time, the idea is that the compiler can do the type checking for you for adding and getting elements from a Vector instance. In addition, since using Array (and the runtime type checking and type casting that array access involves) has always been a bottleneck in ActionScript performance, I expect that performance improvements can be expected. (Okay, I’ve heard anecdotal reports around the office of much better performance for Vector than for Array.)

Francis Cheng (who’s on the EcmaScript committee) has a couple of nice articles about the Vector class and type parameters, so I won’t bother recreating everything he’s written. Definitely worth a read (like everything he writes).

As an (almost) final note, I should point out that I haven’t seen anything indicating that type parameters will be generally available in “Astro” — just Matt’s announcement about the Vector class specifically.

And finally, on a personal note, I’m excited because I get to do the documentation for the Vector class. It’s always fun getting to write about new features that are personally valuable. And this is one that I’ve definitely been interested in for a while!

http://blogs.adobe.com/fcheng/

Francis is a former engineer on the Flash Authoring team (and before that, a lawyer). He’s been in his current position on the ActionScript documentation team for several years. He’s also one of Adobe’s representatives on the ECMAScript language committee, so he’s got a better idea than anyone else I know of the internals and future of the core ActionScript language.

So far his posts have been really great if, like me, you’re interested in knowing more about the less-used features of ActionScript and also getting an early look at new features that will probably be in future versions of ActionScript.

In spite of the bad timing, it’s a nice, thorough article that gives a good view of things that we can do to make our apps more secure, in addition to security updates that Adobe continues to make to Flash Player.

(via email from Jeff Swartz)