Happy New Year!

…of Flex Hell.

That would be the subtitle if it were possible to have one. Yes, it’s only one hour into the year 2010 and I already have new reasons to hate Flex.

Allow me to explain.

Matt and I talked a few days ago and agreed on what generally needs to be done with the UI. We concluded that, since cross-company functionality really doesn’t make any sense (and we don’t have plans to implement any such functionality even if it did) it makes sense to have the company be an application-wide setting. So, post-login, there are three possible situations we might be in:

1. The user is an active member of exactly one company. This is our sunshine case, where there’s nothing extra to do beyond simply shuffling the user off to our new, mostly unimplemented per-company Dashboard.
2. The user is an active member of more than one company. In this case, we have to prompt the user and ask which company they want to be working in.
3. The user is not an active member of any companies. In this case, we have to prompt the user and ask whether they want to create a company or join an existing one.

Simple enough, right?

Well, obviously not if I’m posting about it here. I managed to get path 3a (no companies, user wants to create one) working. There was just one catch: it worked too well. What I want to have happen is that, any time a user creates a new company, the application automatically makes that company the “current” company and then sends the user off to the Dashboard. And that was exactly what happened, which was fantastic… except that I hadn’t written the code to accomplish that yet.

A few minutes of investigation revealed that what actually happened was that the user was getting punted back to the post-login decision screen, then because they were only part of one company, that screen automatically navigated to the Dashboard. The reason lies in the event-driven architecture that I used to create the CompanyData singleton. Concerned that something like this would happen, I updated the code so that event listeners would be added as weak references. I figured that the decision screen would get garbage collected and then that reference would be removed at some point by the EventDispatcher code.

No such luck; the screen must still be being referenced somewhere, I guess. Of course, I didn’t really want to use weak references to begin with. I wanted to create a destructor that would remove the event listener when the screen got garbage collected. Since that apparently isn’t happening, this method wouldn’t have worked any better, but the reason that I didn’t use the destructor method is because you can’t. Why?

Because ActionScript, a supposedly object-oriented programming language, does not support destructors.

Yes, you read that right. Yet another feature that practically every other OO language under the sun has, but ActionScript lacks. I think I read somewhere that this is because the ECMAScript standard, which ActionScript is derived from, doesn’t support destructors. This means one of two things: either the standard sucks, or Adobe made a shitty decision when adopting a standard.

Actually, on second thought, that’s not an “or” situation.

So I’m not quite sure what to do about this now. I’m quitting for the night (or rather, morning) and I’ll pick up with this tomorrow. Odds are we’re going to have to make some changes to our whole “Screen” paradigm, although I’ve noticed some other potential shortcomings anyway. I’ll talk them over with Matt the next time we’re both online.

Oh, and for those wondering about all the stuff that I said I’d be posting about over break in my last post two weeks ago:

• IQP: check.
• Dishwasher’d parts: probably going to be too busy to examine them.
• That GalCiv2 game: turns out I can’t remember enough details for a truly interesting write-up, so not happening.
• What I got for Christmas: nothing worth talking about.
• Other stuff: there is other stuff happening, so maybe.