He apparently managed to trigger a very obscure language bug, that no one has really posted about, though if you dig deep enough into Adobe’s bug tracking system, you can find some reports of, though it’s supposedly fixed as of some version of the compiler that I have no idea if it’s in production yet.

This is all it takes to break Actionscript with a nasty runtime error:

private function breakIt():void
{
    var arr:Array = [];
    for each (var obj:Object in arr) {
        switch ('s') {
            case 's':
                if (null) {
                }
            //break;
        }
    }
}

The key here is the nested for/switch/if and that the expression for the if statement evaluates to false, and that there is nothing in the case after the if.

Uncommenting the commented break statement will prevent the bug. Even a variable declaration on that line will prevent the bug. Removing the switch from inside the for loop will prevent the bug. Notice in this case the loop shouldn’t even be executing: the array is empty. Doesn’t matter, it crashes anyway.

The runtime error this triggers is “VerifyError: Error #1068: CLASSNAME and CLASSNAME cannot be reconciled.” where CLASSNAME is the name of the class that contains the above code.

So if you’re getting the above error in your code, check around for any constructs like the above.

You have an MXML component with multiple states. Each of these states has an associated error state that’s based on one of the other states. The overrides for each of the error states is identical – all that’s different is which state each error state is based on. Instead of duplicating the overrides for each error state, you can declare the overrides in an <mx:Array> tag, and use data binding to set the overrides property of each error state to the same array.

Alright, talking about this abstractly is kinda confusing. It will make perfect sense as soon as you see an example:

<mx:Array id="errorOverrides">
    <mx:AddChild relativeTo="{msgWrapper}">
        <mx:Label text="The following errors occurred:" styleName="popupMessageError"/>
    </mx:AddChild>
    <mx:AddChild relativeTo="{msgWrapper}">
        <mx:VBox paddingLeft="15">
            <mx:Repeater id="errorRepeater" dataProvider="{errors}" recycleChildren="true">
                <mx:Text width="{msgWrapper.width-45}" text="{errorRepeater.currentItem}"/>
            </mx:Repeater>
        </mx:VBox>
    </mx:AddChild>
</mx:Array>

<states>
    <mx:State name="twitterBroadcast">
        <mx:SetProperty target="{this}" name="bodyContent" value="{twitterBroadcastBodyContent}"/>
        <mx:SetProperty target="{this}" name="title" value="Broadcast to Twitter"/>
    </mx:State>

    <mx:State name="facebookBroadcast">
        <mx:SetProperty target="{this}" name="bodyContent" value="{facebookBroadcastBodyContent}"/>
        <mx:SetProperty target="{this}" name="title" value="Broadcast to Facebook"/>
    </mx:State>

    <mx:State name="shareError" overrides="{errorOverrides}"/>
    <mx:State name="twitterError" basedOn="twitterBroadcast" overrides="{errorOverrides}"/>
    <mx:State name="facebookError" basedOn="facebookBroadcast" overrides="{errorOverrides}"/>
</states>

This solution seems obvious as soon as you think about how you would go about declaring these states in Actionscript, but in MXML it’s really easy to feel like you would need to declare the overrides over again inside each <mx:State> tag.

Maybe I’m late to the party and everyone else figured this out already, but if not, hopefully this post will help you think about MXML in a new way.

At first I thought it must be something with the service call to the backend to fetch the list of playlists, but it was returning long before the list rendered.

So then I thought perhaps it was the class I wrote for paging lists of stuff from the backend, but no, parsing the data wasn’t taking that long either.

So I went to make sure I hadn’t done anything silly in the view, like, manually removed and replaced all the children in the box every time the list changed instead of just using a Repeater. But no, I was using a Repeater. Jay says, “What’s this recycleChildren property on the Repeater class?”

I said, “That shouldn’t matter, this is the first time that Repeater’s been rendered. There’s no children created yet *to* recycle. But I guess I’ll set it true anyway.”

And sure enough, now it renders in more like 1 second, as opposed to 4-5. I understand how recycleChildren increases performance when the data in the dataProvider changes. I think it’s silly that it defaults to false – I’d think that most common uses of the Repeater class would benefit from defaulting to true, and if you have a case where you need it false, then you can specify. But I still don’t understand how it’s faster when it’s the first time it’s created any children at all.

So if your Repeaters are slow – set recycleChildren to true!

And if anyone can give some insight into how it’s faster even on the initial creation of the component, let me know. I’m curious.

And for you Grooveshark Lite fans – that change is live, so if you were frustrated by long lag times on the “Add to Playlist” lightbox, the “Share” lightbox, or on opening a playlist or song info panel, it should be much better now.

Syntax Comparison of Java 5 and Actionscript 3

But today I went searching again for something better, and found a really great way to escape and unescape HTML entities. Not sure why I didn’t find his post the first time, I guess my Google-fu was weak that day.

Anyway, I’ve wrapped his methods up in a little helper class, and it works great:

package com.grooveshark.utils
{

    public class HTMLEntityUtils
    {
        import flash.xml.XMLDocument;
        import flash.xml.XMLNode;
        import flash.xml.XMLNodeType;

        public function HTMLEntityUtils()
        {
        }

        public static function htmlEscape(str:String):String
        {
            return XML(new XMLNode(XMLNodeType.TEXT_NODE, str)).toXMLString();
        }

        public static function htmlUnescape(str:String):String
        {
            return new XMLDocument(str).firstChild.nodeValue;
        }
    }
}

Hope it helps someone else!

Grooveshark Lite takes all the long-tail P2P musical goodness of Grooveshark.com and distills it in a handy quick interface to find and listen to whatever you want. Unlike the main Grooveshark site, you don’t have to have an account or install our Sharkbyte client in order to listen to music. However, signing up for an account (it’s super easy!) allows you to save playlists, and your login will work for both Lite and the main Grooveshark site.

We’re hoping that you’ll find Grooveshark Lite to be the easiest way to listen to whatever you can think of.

We have tons of things planned that didn’t quite make it into this iteration, so keep an eye out for exciting new features over the next few weeks. And if you have any comments, suggestions, ideas, wishlists, problems, or just want to say hi, drop us an email at feedback@grooveshark.com. Or you can leave me a comment here and I’ll do my best to answer you personally.

We just upgraded a few other systems at the same time, so if things are a little shaky, just give us a little time and things ought to smooth out.

I’d love to talk more about Grooveshark Lite, but I’ve been here at the office for over 18 hours straight now, trying to make sure my baby gets off the ground right, so I’m not entirely lucid anymore.

Enjoy the music!

So as you may know from my recent posts, I’ve been working on a huge Flex app for Grooveshark. We’re getting ready to launch it (probably in the next few hours actually), and our lead designer John and I were going through the app for some final visual tweaks. Button labels and input boxes were lovingly pushed a pixel here, a pixel there, until they looked just right.

Then we saw the app on Linux. It looked HORRIBLE. Half the text was far too low. You couldn’t even see the tails on letters like ‘g’ and ‘y’. Suspicious, we checked it on a Windows machine. The text was also lower than on my Mac, though not as bad as on Linux. Windows only was only lower by about 4 pixels, Linux more like 10-15. I was baffled. Flash is Flash is Flash, right? The font was an embedded OpenType version of Helvetica that we bought just for this purpose. Why would the font render differently depending on the operating system?

I read about Flash’s different font managers, and thought perhaps the issue was that using an OpenType font forces the use of the AFEFontManager instead of the BatikFontManager. So I tried embedding a TrueType font instead, but it made no difference. The text was still just as skewed in Linux and Windows as it was before.

Eventually I found this blog post and decided that embedding the font via SWF was worth a try. I had originally decided to embed via a font file instead of swf because swf seemed to add more bulk to the compiled app, and honestly, this app is already huge.

Anyway, I embedded Helvetica via SWF instead of OpenType, and it worked! The application now renders identically cross-platform. So if anyone else out there is having trouble with cross-platform font rendering in Flex, try embedding your fonts via SWF.

Average of 67.5 hours a week…

Over 21,000 lines of MXML and Actionscript 3…

Me and Jay have been working our asses off for the last month, and all that effort is about to pay off. I’m going to sleep for days…

First, naively, I tried just committing the whole project folder to the repo. Then I realized all the various hidden files that Eclipse makes (like .project, etc) would also be committed, and if any other developers also starting committing work, we’d break each others projects every time one of us updated after the other committed.

So then I committed only the /source folder where the actual code lives. However, then all the hidden .svn folders that SVN created showed up in the tree view of Flex Builder’s Navigator. I could ignore that, except it also completely broke Flex’s code hinting, Outline view said nothing but ! Root, and Design mode (which I almost never use, but still…) would say nothing but, “An unknown item is declared as the root of your MXML document. Switch to source mode to correct it.”

Looking up the Design mode error on Google found a lot of people mentioning it, but no real solutions, except really stupid stuff like, ‘delete all the whitespace in your code.’ (Which, when I tried it on a small test project, surprisingly did work, until you closed Flex Builder and opened it again. Then you’d have to delete all your whitespace all over again. Obviously, this is NOT a viable solution.)

The only solution I found that looked promising was to install Subclipse into Flex Builder, and create a new project by checking the code out from the repository. So I went about trying to install Subclipse.

At the time, I was using Flex Builder 2, for OS X. I’d never used Eclipse before I started using Flex Builder, and I have the stand-alone Flex Builder, not the Eclipse plugin. Everything I read about Subclipse seemed to imply that it required Tortoise SVN to work, which, as a Mac user, is obviously not an option. Now on the Subclipse site there is no mention of Tortoise. I don’t know if that’s something that’s changed in the past few months or not, cause I’m pretty sure I read all this on the official Subclipse site. Somewhere though, I remember reading that as long as I had the command-line svn client installed (I did) that it would still work for Mac.

I followed the instructions on the Subclipse site to install Subclipse, but whenever I got to the end, it would complain that I was missing some dependencies and that it could not install. I was not able to figure out exactly what dependencies I was missing, or where I could get them from, and I finally gave up.

I still needed version control, so instead I hacked together a little set of Automator scripts to help me get the job done. I had two copies of the /source folder for my Flex project: one was in the Flex project’s directory (~/Documents/Flex Builder 3/Grooveshark Lite/source), and one in a separate directory that I have the rest of our repo checked out into for local testing (/Applications/MAMP/htdocs/GS/trunk/flex/Grooveshark Lite/source). My Automator apps copy the files from one to the other and vice versa, dropping a numbered backup into a separate folder, just in case I screw up. Then I can commit my files using SmartSVN. I could have written a bash script to do the same thing, but Automator lets me add a pretty little confirmation box, just in case I hit one by accident.

They look a little something like this:

Copy Flex to SVN

Ask for Confirmation
tar -cvf /Users/krichard/Documents/Backups/FlexToSVN.tar --backup=numbered /Applications/MAMP/htdocs/GS/trunk/flex/Grooveshark\ Lite/
rsync -vrC --exclude=.DS_Store --delete /Users/krichard/Documents/Flex\ Builder\ 3/Grooveshark\ Lite/source/ /Applications/MAMP/htdocs/GS/trunk/flex/Grooveshark\ Lite/source/


Copy SVN to Flex

Ask for Confirmation (Twice! If I accidentally overwrite the SVN directory, I can just delete and re-check out. If I accidentally overwrite the Flex Builder directory, I've lost work. The backups prevent any real damage, but still...)
tar -cvf /Users/krichard/Documents/Backups/SVNToFlex.tar --backup=numbered /Users/krichard/Documents/Flex\ Builder\ 3/Grooveshark\ Lite/
rsync -vrC --exclude=.DS_Store --delete /Applications/MAMP/htdocs/GS/trunk/flex/Grooveshark\ Lite/source/ /Users/krichard/Documents/Flex\ Builder\ 3/Grooveshark\ Lite/source/


The nice part about using rsync is that the -C automatically excludes the .svn folders from being passed around. I’m also excluding the .DS_Store files that OS X likes to stick everywhere.

So fast forward a few months: I’d switched from Flex Builder 2 to Flex Builder 3, and was still using my Automator scripts. Today I was setting up Subversion on my Slice for a personal project I’m about to start working on. I *really* didn’t feel like writing another set of Automator scripts for this new project, especially as sometimes I’ll be working on it on my off hours at the office (so I can use the huge widescreen monitor), and sometimes just at home on my iBook. So I decided to give Flex Builder and SVN another shot.

Well, I still had all the same problems. However, this time my searching came up with a link to this article. I noticed the screenshots were obviously OS X, not Windows, and felt a sliver of hope.

I followed the instructions, and no errors this time! No complaining about dependencies. Everything installed just fine. I’m not sure what to attribute to the difference in my experience from a couple months ago. Is it a new version of Subclipse? Is it because I had Flex Builder 3 instead of 2? Were these instructions just flat out better than the ones I read before on Subclipse’s own site?

So now I had Subclipse installed. Getting to the import process was slightly different than in the given instructions, I assume because I’m using the stand-alone Flex Builder and not the plugin. Instead of just choosing File -> Import -> Checkout projects from SVN, I had to choose File -> Import -> Other -> Other (Yes, that’s two Others, not a typo) -> Checkout projects from SVN.

And… it worked! It checked out my folders, and I was able to commit changes with no problems. My code hinting still works. I backed up my Grooveshark Lite files, deleted the project, and checked it out as a new project from the Grooveshark repo too. Everything in that project is working fine as well. Bye-bye Automator scripts!

So for anyone out there who has tried in vain to get Flex Builder working with Subclipse on OS X, try the instructions at http://www-128.ibm.com/developerworks/opensource/library/os-ecl-subversion/ with Flex Builder 3. Hopefully you’ll be as pleasantly surprised as I was.