Blog

Can’t sleep, so here are a couple trends I keep noticing I do in my Flash Lite 2 development.

First off, I keep running out of RAM. The forms I had the designer create from my wireframes won’t work because the wireframes were flawed. In designing them, I had no idea that some of the designs simply wouldn’t work based on the fact that there were too many GUI controls on the screen at one time. The negative is that I am forced to create more classes that represent forms… which actually use RAM by their very existence. Classes in ActionScript 2 are actual prototype objects vs. blueprints like in other languages, and thus physically exist as objects. In effect, I’m merely delaying the inevitable, and making it harder for others to play later. The positive is, my GUI’s are forced to be extremely simple. Simple is good, right? Screen 7 of the wizard? *sigh*…

Related to the above, some controls I’ve been creating hit limits mainly with regards to CPU before RAM. When I fix the CPU problems, which usually are stack overflows or script timeout limits (which on my phone feel like 2 seconds, not 15), I then start to run out of RAM again. Thus, I have to start optimizing my code before it’s even written.

How do you optimize ActionScript 2? Same way you optimize ActionScript 1, with the addition that you have to “drop the ego” as Branden Hall said to me in the past. I’m not sure he meant it in this context, but it fits. This hurts more in AS2 than in AS1. Ego meaning, “loyalty to good programming practices”.

For example, using vector vs. bitmap graphics because vectors use less RAM doesn’t make me hurt. But, these do:

Less Inheritance

Prototype chain lookups are slow. Therefore, the more inheritance I use, the more I hurt myself. Huh!?!?!

For example, I wrote a Calendar component. Getting that S.O.B. to run on a variety of phones out there and NOT CRASH was a feat unto itself. While neato, it still didn’t play nice with others… since it used about 1200k of RAM; that’s a meg and 200k. My Nokia 6680 only has 2 megs. So, putting a design + a button and some labels wouldn’t fly if a developer wanted to do so. That’s just uncool. A component set should make the developer feel happy to use various controls together, not scared. I must crush all fear.

Solution? Reduce the OOP’ness of CalendarDay. What’s CalendarDay? A Calendar is typically a control that draws a bunch of weeks in rows, and each row has a bunch of days, like Sunday, Monday, Tuesday, etc. These 7 days are put in 6 rows. That way, you can safely show most months with last month’s week at the top, and next month’s week at the bottom. These day’s are effectively a bunch of MovieClip’s, 42 to be precise, drawn in a grid. The CPU required to draw 30 of anything in Flash is insane pre-Flash Player 9, let alone 42. …and this is on an ARM processor.

So, it takes me 5 passes to draw things. Create data, attach mc’s, position mc’s, set mc’s data, and finally color mc’s. That equates to 14 seconds in total on my phone (you see it draw at 9), and 8 seconds total on faster N90’s and E70 models.

These mc’s are an instance of CalendarDay. He originally was all cool, had public setters for his data and colors, which all would invalidate at the proper time, and were extremely flexible; ripe for use in a Calendar. Problem? They were cool. I ripped it all out, extended MovieClip instead of my (custom) base UIComponent class, and provided simple methods with no invalidation. I refused to change the package name, though. That, plus some other minor modifications & optimizations netted me:

342k total used RAM.

w00t! In my drunken stupor of celebrating, I notice the code was… well, it sucked. But it works. I’ve always been the biggest proponent that the metric for cool code is code that works vs. code that looks great, but doesn’t do anything. Why, then, do I have such a problem not smiling when I dive into that “class” now?

EventDispatcher is Slow

Almost a second or more dispatching events; remember, I only have about 2 seconds per stack process per frame, so I’ve been trying to use callbacks where possible which equate to only 1 object capable of listening for the event vs. multiple like EventDispatcher supports. Thankfully, this is a rare use case, but… more code for me to write, and still have 2 extra variables + method call to make. EventDispatcher via it’s decoration of objects actually adds enough stuff to equate to this, but at least I don’t have to see it, hehe.

I haven’t succumbed to having children calling known methods on parents yet via _parent.onSomeEvent. I don’t think interfaces could even justify that move… but… it’d save writing 2 properties and a method. That’s 3 slots, per instance used… ugh.

There was a reason EventDispatcher was ported to native C code in Flash Player 9; it’s the main workhorse for GUI coders and was the main bottleneck in pre-Flash Player 9 large projects.

Shorter Method and Property Names

Since Flash Lite 2 runs in the interpreted AVM, the length of the string name used to find the method / property name directly affects the speed in which it takes to run. Shorter method names? Faster to run. Less RAM, and more compact bytecode which equals faster code.

Problem? When I started programming, I read in books, blogs, and websites that encourage short, concise method names that used abbreviations and said those were good to do. Now, I think all the people who wrote the books, blogs, and websites are crackheads and I pray to God I never have to maintain their code in a future project. My methods and properties are about as verbose as can be without being audacious. If you ever question what a property is, or what a method does, I consider that a failure on the programmer’s part in naming.

…yet, here I am thinking of changing setCurrentFromDate to setCurFrD, or even scfd. Properties are even worse; __currentDate to cd. The only thing left to make sense of the cryptic hieroglyphics I’ll write will be the strong typing, but that merely helps confirm suspicions, not convey facts. Horrible… but hey, it’s compact, low RAM, and runs well right? Did anyone get a post-processor for ActionScript 1 / 2 bytecode for Christmas they don’t want? I could use one. Flasm doesn’t count.

What the 3 main issues above effectively make me do is constantly have to re-work my UI. For example, Google Calendar has these text fields for choosing a date. It shows something like “11/5/2006” in the field. If you click it, a Calendar component drops down below it so you can choose a value for the field to hold. I can do that in Flash. I can do that in Flex.

Flash Lite 2? Hah, you’re smokin’ dope, dude. Well, sure, I could do it… if those were the ONLY 2 components on stage. Bleh.

…thus, I have to beg the designer to discuss “solutions”. It’s rough, I’ve already ravaged the design enough, and will have to devote at least a week (last week in February) to make sure the design is up to the designer’s standards before I submit to the Flash Lite contest.

I swear, I’m this close to making a branch in SVN, and creating a “AS2 coder friendly” branch and a “AS1, fugly but optimized” branch for the component framework. This stuff is hard, yo. Purely masochistic at this point. I wanted a challenge and I sure got one. It’d be easier if I could just drop the ego like Branden said, and code lightweight AS1. So… hard… to let… go…

Flash Lite 2/2.1 has an fscommand2 called “SetInputTextType”. One of the reasons for its existence is that TextField.restrict is not supported in Flash Lite 2 / 2.1. My guess is, to make it easier for the Flash Lite Player engineers to support some forms of TextField restriction values, they found what was commonly supported on devices, and gave those as options. That way, they don’t have to write crazy parsing routines to translate your restrict values, which are typically just a string of accepted characters in a semi-RegEx like format.

Instead, you pick from 6 options like “Numeric”, “Alphanumeric”, etc. and make sure your phone actually supports the mode you are using.

For example, I’m creating a NumericStepper. Normally, one would assume you could go TextField.restrict = “0-9”. If you export for ActionScript 2 or 1, this will allow only numbers to be entered into the TextField by the user. However, as previously stated, it’s not supported in Flash Lite 2 / 2.1.

The problem with SetInputTextType, though, is that it relys on the Flash 4 targeting syntax which we all love to loathe (even though it made most of our careers). While the docs give an example, it’s on _root, and doesn’t take into account the way variables work in slash syntax vs. dot syntax. As soon as you nest yourTextField into another MovieClip, you need to take this into account.

Basic steps:

– give your textfield’s variable property a name with a suffix of “_var”
– for the 2nd argument of SetInputTextType, go:

_target + ":" + yourTextField.variable

The _target property will hold the old slash syntax to get to your component, and the colon is used for accessing variables in slash syntax (vs. a dot like in dot syntax).

So, in my case:

__valueField.variable = "__valueField_var";
fscommand2("SetInputTextType", _target + ":" + __valueField.variable, "Numeric");

I sure hope if they make Flash Lite 3 use ActionScript 3, it also uses the ActionScript 3 clean api mentality of abandoning this slash syntax crud. Currently, it makes all the new fscommand2 calls feel legacy. Slash syntax throws me for a loop every time.