While exploring the AS3 Language Reference today, I discovered a couple of potentially useful classes in the flash.errors package, ScriptTimeoutError and StackOverflowError. The package itself contains special classes specifically designed for the Flash Player.
By putting a try-catch block around a potentially long operation, you can catch a ScriptTimeoutError to stop Flash from the usual crash and burn. Now your application can fail gracefully if you need to run some heavy duty calculations. At first, I expected this to be more useful. I could see a Flash movie that would catch the timeout error, update the screen with it’s progress, then continue on with the calculations. Unfortunately, it looks like you’ll only have one opportunity to catch the error. According to the ASLR, the second time your script times out, you’re out of luck.
The StackOverflowError class can be used to catch problems with deep recursion. Like the timeout error, you’ll be able to fail gracefully without the potentially-confusing Flash Player message appearing. Even better, I believe that a clever programmer could use this one to run especially long recursive problems. Unlike the previous error, you don’t get one opportunity. Imagine saving the state of your calculations every time you make a recursive call. When you get a StackOverflowError, you can start over with the saved value and run your operation with a clean stack. As long as you keep saving the state, you may continue until the operation is done. Of course, you’ll have to be extra careful because you may end up receiving the pesky timeout error I described above. It seems to me, however, that you could let your Flash movie rest for a moment after each stack error to refresh itself. You can update a progress bar or something to visually indicate that progress has been made so the user isn’t left wondering if something bad happened.
Obviously, you won’t be using this technique often. Even with the new faster VM, Flash isn’t exactly the best choice for heavy calculation. Internet culture being what it is, you’ll need to consider that the user could get impatient if they have to wait too long. It’s all about balance. Just think of this as another tool that you may never use, but if you ever need it, it’s there, free of charge.
Important Note: I tried running some operations that should give timeout messages and stack overflow errors. For some reason, the movie completely stopped responding, and I needed to force-quit the browser via Windows Task Manager. Even when I tried catching the errors, nothing happened. I’m guessing this hasn’t been fully implemented, or this might be a particular behavior that only appears in a debug player like the one we’re working with now. File this technique away for future use.
Wednesday, March 1st, 2006
Actionscript isn’t exactly the language of choice among computer scientists. However, some of us who went through the algorithm-packed curriculum of the computer science major have somehow found ourselves enjoying Flash and it’s language. I believe there are a pretty decent number of artistically-inclined programmers out there with a creative side.
After seeing a bunch of sorting functions implemented in Actionscript today (you’ll see that in the list below), I took some time looking for some other concepts I studied in college. There’s something inherently interesting about seeing this stuff done in Actionscript. I’m not sure why. Maybe it’s because we’re not dealing with a hardcore language.
I spent several years diving head first into data structures, assembly language, finite state machines, and all sorts of interesting concepts like those. I tended to make it through some of the tough stuff by the seat of my pants. Sometimes I wish I had spent more time really getting to know some of these concepts better. Honestly, though, who’s gonna pass up all-night LAN parties and awesome house parties every weekend? Not me. Plus, I think I’ll enjoy this stuff more now that I’m learning it by choice rather than for the next exam.
Monday, February 27th, 2006
Update: This project has been updated for the official release of the free Flex 2 SDK.
That’s right, ladies and gentlemen. Today, I bring you the second release of my Flash-based client for AOL Instant Messenger. Since Adobe released Flex Builder Beta 1 a short while ago, I needed to change the project to work in the updated environment. Of course, I couldn’t leave it as-is, so I took some time to add a little more (much-needed) functionality.
I spent some time adding text-formatting. You can change the font size, color, and styling. The client can also handle formatting sent with messages from buddies. It’s all basic HTML, so the Flex components didn’t have too much trouble handling it. I just had to make a few tweaks, since AOL messages have weird font sizes (or is it Flex?).
I also added the ability to view buddy info, and I the client now connects to an AOL server that supports profiles. These are stored on the server in html, except it’s nowhere near standards-compliant. I had to do some extra parsing on what AOL sent my way to get Flex to like it.
Remember, you need the latest Flex Builder 2 Beta 1 and the pre-release 8.5 Flash player to try out the demo. If you aren’t a Flash/Flex programmer, you probably don’t have these. You’ve been warned. Now, head over to the downloads, and try it out.
Wednesday, February 22nd, 2006
I recently worked on a project for IFBIN where I created the same example in both AS2 and AS3. It’s an interesting experience, and I wanted to get my thoughts down about it.
-
Build everything in AS3 first. It’s a stricter language, and if you’re anything like me, if start out in AS2, you’ll probably take a few shortcuts. You’ll pay once you get to the AS3 version. In my case, I found it more important to write good code because it’s is going to be viewed by a lot of people.
-
You’ll hit some problems if you’re using components. Obviously, the components in Flash 8 and Flex 2 aren’t the same. DataProviders for Lists and DataGrids don’t work in quite the same way (Array for Flash 8 versus ArrayCollection in Flex 2). Likewise, text components don’t always work the same in regards to HTML.
-
AS2 events suck. Built-in classes like XML don’t really dispatch events, and events in components need things like Delegate. Whether you start with AS2 or AS3, if you use any native events, you’re going to have to rewrite some code.
-
AS3 uses the lowercase void instead of the uppercase Void
-
For-loops in AS3 should use the new integer type int instead of Number. It’s not required, but a good best practice.
-
XML is handled differently. In AS3, you’ll probably want to use the new E4X. If you’re interested, AS3 provides a legacy class to match the XML class in AS2.
A lot of classes moved around too. Check out the AS2 to AS3 migration guide for complete details. Can anyone think of other differences that someone should consider when developing for both platforms?
Sunday, February 19th, 2006
