Protecting your Actionscript

Jason forwarded me this article reviewing SWF Encrypt, a $99 Flash SWF encryption tool that, so far, is able to defeat those SWF decompilers that can be used to rip off your code by reverse-engineering the bytecode (the SWF file) into readable source code. This is also useful for trying to find interesting tidbits like database server passwords, if you've happened to hardcode it into your SWF.

Flash Player 8 Niftiness

Was browsing the very cool Open Source Flash website just now, and came across their Undocumented Flash Player 8 wiki page, covering tidbits of new actionscript. Neat! Note that this covers the beta version of the player, so it's not known how much of this will make it into release.

Still, two things were of interest to me:

• Script-level access to bitmap data. That's very cool. It looks like you'll be able to composite bitmap data on-the-fly too, and apply those new glow and shadow filters programmatically. That is super cool.

• ExternalInterface API for Javascript-to-Flash and Flash-to-Javascript Communication. Right now, this functionality is not supported very consistently at all in different browsers, making QA a bear. I am hoping that this gets fixed.

And I came across this fabulous Debugger tip to help make the asinine Debugger in MX 2004 more useful. Ordinarily, you can't set persistent breakpoints in your .as files; you get to load the debugger and reset them every single time you want to have a breakpoint. Yes, this is incredibly lame. You can, however, set them in frame scripts, so the workaround is to define a function in frame 1 of your .FLA file called doBreak() and set the breakpoint there. Then whenever you want to implement a programmatic breakpoint, call doBreak() and the Debugger will kick in. StepOut, and you actually can do something useful in the Debugger without all that tedious and unwarranted pointing and clicking. Sheesh! You still have to "Debug Movie" with the stub .FLA file in the foreground, using CONTROL-SHIFT-ENTER and not "Test Project" via CONTROL-ALT-P. Bah.

Actionscript Bootcamp: The Final Week

Jason is going to finish up what he's got going this week. It's going to be quite a challenge...he's dealing with new concepts like event-driven programming, object-oriented design, time-based simulation, and just learning how to pull it all together. Very exciting, though it is an awful lot to absorb in a short time. What I hope he takes away from this is the basic Flash Actionscripting environment, some sense of how to write code in this environment, and just get going in some of these concepts. If he can get a solid, working, debugged screen-based interactive workflow, some time-based animation, and some kind of event-managed application architecture, I think he'll be in good shape for further pursuit. We may do this again next year, since we seem to be having a good time with it. Perhaps I will expand the program.

Next week, we will be doing our formal review of the entire two-month process. The first month was design, which he did in Chicago. The second month was implementation, here in Nashua. I'm going to ask him to fill out some formal evaluation forms of what he thought about the material, the style of presentation, and what else he might have found useful.

TextField Nitpicking

So I'm making what it supposed to be a straightforward fix...I have to align 2 columns of 2 text fields on two movieclips that are next to each other. The tricky part is that each textfield can have a variable numbers of lines, so the layout rules are a little more complicated; I have to do a bit of on-the-fly runtime calculation.

What's making this particularly aggravating is that the TextField class is one of messiest classes in all of Actionscript-dom. To be fair, text is a pretty complex thing to manage, so I should cut it some slack. But I'm going to bitch about it anyway :-)

Irritant #1:
Awful documentation entry for TextField.textHeight.

The documentation for the TextField.textHeight property reads as this in its entirety:

        Usage
            TextField.textHeight

        Description  
            Property; indicates the height of the text.

What kind of terrible documentation is this? Fortunately, Colin Moock describes this in more detail: it actually returns how high in pixels the content of the TextField is; "the text" as in TextField.text, as displayed in the TextField. In fact, this is the long-thought missing property I needed to calculate the number of lines in a TextField. This is important for implementing things like scrollbars with proportional thumbwheels. I had previously used an incredibly indirect way of determining the # of lines in a TextField by scrolling it to the beginning and end, and looking at the maxScroll property. Unfortunately, the maxScroll property is apparently only updated when a screen refresh occurs (as determined by the framerate of your movie, as far as I can tell), so it seemed somewhat unreliable in practice.

Irritant #2:
TextFormat.getTextExtent() surprises!

Judging from the LiveDocs threads on the Macromedia site, this command is just plain buggy. You use this command to hopefully figure out how big a TextField needs to be based on a given TextFormat, string, and desired width. Surprise! It doesn't work with whitespace or linefeeds! It's not documented anywhere, except in Moock's ActionScript for FlashMX: The The Definitive Guide. We have apparently avoided the other big bug with embedded fonts and cross-platform woes because we are using device fonts in our application (for Unicode support).

So between figuring out how to make TextFields behave reliably and feeling a little under the weather, it's been one of those days. And hooray for Colin Moock. Again.

Actionscript Bootcamp Week 3

It's already been two weeks, and Jason is now ready to fly on his project design!

Jason has worked out a design with his mentors at **Inquirium**, so I am not going to focus on that. Besides, it's **good to make a few mistakes** when you build your first real interactive; this is what will build programming character. I'll step in when it's time for **feedback**.

Additionally, since Jason is a video enthusiast, we will do a little discount usability testing as described in Steve Krug's book, Don't Make Me Think. There's nothing quite so deflating as actual user confusion when faced with your design! I am sure it will be quite instructive for the both of us.

Anyway, let's recap what we've done so far.

• Week 1: AS 1.0 and MovieClip Concepts, Implement some basic components from scratch, then hook them together.
• Week 2: AS 2.0 and OOP Concepts. Convert Week 1 to AS 2.0. Add some screen management.
• Week 3: Code Review. How to Quiz a Client. Pre-production methodologies. Build the skeleton app for this Friday.

In case this sounds incredibly aggressive, it's boot camp! And Colin Moock would've been way tougher! Besides, Jason has actually taken a couple of C++ courses, so he is already familiar with the basic ideas behind procedural and object-oriented programming. Maybe not rock solid on it yet, but he will attain mastery through doing and my benevolent goading.

One decision I made was not to critique his interactive design before implementing it. I think he needs to code something at least twice, and we don't have a lot of time to waste dilly-dallying on the design details. Plus, it is also a lot easier to make points by using his own implementation than a piece of paper that is easily rationalized away ("Oh, that is part of the design. I just forgot to write it down.")

So instead of doing a critique, I pretended Jason was my client. We sat down in our comfy chairs, and I proceeded to read through and make notes. I thought aloud for his benefit, expressed confusion when appropriate and genuine, and ran him through my client "what are we doing" interview procedure. I base it around three key words: Intention, Expectation, and Motivation. I'll have to write up that article sometime, but the basic idea is that many clients ask for a thing but don't tell you why they're making that specific thing, right now and what they expect will happen as a result of making that thing. I thought that this might be interesting for Jason to experience by example; next time, he'll do it himself.

Next step: the production breakdown. For me this means figuring out the general architecture / technical strategy, and generating at minimum a screen list / functional diagram / storyboard / wireframe (so many names for the same thing) and an asset list complete with asset numbers assigned. I had Jason create his own rather than doing it for him; he found it very clarifying.

Jason has enough information to get going, so I'm setting him free. Some of his immediate challenges are to structure an object-oriented application architecture for the more complex design he has, but the past two weeks have given him most of the code for what he needs to do. We may have to discuss more advanced data structures at some point, and also missing is the strategy for implementing a visual simulation in Flash. We did talk a bit about Model-View-Controller patterns, but not the specifics of frame-rate independent, parametric time-based simulation. I told him to take a first pass at it and see what happens; I have the feeling that he will get more out of it if he comes across the difficulties first-hand rather than me just telling him what to do. We'll see how that goes. So far, he's doing pretty well.