Interrogating Objects

Have you wanted to know more about a object and been a bit stymied by instanceof? I know I don't want to have to test the object against every possiblity - I just want to know what class it comes from!

Then I looked into the flash.utils package. We now have getQualifiedClassName, getQualifiedSuperclassName, and the quite amazing describeType - which returns a full XML description of an object.

If it turns out you need to go in the other direction - you have the name of a class as a string and need to get a reference to actual class you can use the new getDefinitionByName.

Ninox: A Regular Expressions Explorer

Continuing on the "money for nothin' and code for free" train - here's our second code drop of the week! (Don't expect this kind of service in the future!)

I'm finally getting around to learning regular expressions. Yeah, you can commence pointing and laughing now.

Now I'm the kind of person who learns things by futzing with them. So, I wanted to make a quick way to futz with regular expressions - but it turns out a pretty cool one already exists - Kodos. Plus, it's written in one of my favorite languages - python!

However, I also want to learn Flex (again, finally) so I decided for forge ahead and just copy Kodos in Flex. The result is Ninox. The silly name is shared by a type of owl (which if you are a true geek, you will know graces the venerated O'Reilly RegEx book).

Now this is my first Flex app. I'm sure I screwed somethings up - but it does work, and Keenan vetted at least the basic design (so blame him!).

Rocks In Space: Asteroids in ActionScript 3

As promised in my last post, though a little late, I just finished up a quick-n-dirty version of the game Asteroids in ActionScript 3. The actual zip file is a Flex project - so you can import it directly into Flex if you so desire (File -> Import, General -> Existing Projects into Workspace, Select Archive).

It's all nice and object-oriented and should be fairly easy to understand. However, if you have any questions please feel free to post them in the comments.

Wherefore Art Thou onReleaseOutside?

My wife and I both work, we have a toddler, and neither of us are good about cleaning. Consequently after a good amount of debate my wife finally managed to convince me to get a housekeeper. Now this nice woman named Marta comes to our house every other wednesday and gets the top two floors of our house spic and span.

Ok - so how does that apply to ActionScript you ask? Well, because I know on the thursday following Marta's visit there will be two absolute truths - the house will be awesomely clean and something of mine will be missing. Whatever it is isn't really "missing", just put somewhere I wouldn't have thought to look. (Like in it's proper place!)

Like Marta does with our living room, Adobe did a major housecleaning with ActionScript 3 - so some features we're used to seeing have moved or changed in non-obvious ways. The first of which I ran across was that onReleaseOutside seems to have disappeared.

There just isn't an onReleaseOutside event anymore - so what do you do? It turns out that the answer lies in the way that events now work. GUI-related events now bubble - that is they travel up the display tree from the place where the events were first captured all the way up to the top of the tree (aka the stage).

Lets think about how that works - particularly with mouse events. If you press on a movieclip, and it doesn't capture the event, it bubbles up to that movieclips parent, and so on until it reaches the root. That means that unless an event is captured, the root (known now as the stage) will get the event. That's perfect for our needs!

So - that works, but we're not differentiating between onRelease and onReleaseOutside. Luckily for us, the MouseEvent object that our onReleaseBox function receives contains a property named target that tells us what object sent the event. All we have to do is to see if the event is coming from our box or not.

function onPressBox(evt:MouseEvent):void {

stage.addEventListener(MouseEvent.MOUSE_UP, onReleaseBox);

trace("press");

}

function onReleaseBox(evt:MouseEvent):void {

stage.removeEventListener(MouseEvent.MOUSE_UP, onReleaseBox);

trace("release");

}

box.addEventListener(MouseEvent.MOUSE_DOWN, onPressBox);

Now it's important to note that there is more than one way to skin this paricular cat. With the combination of the new event bubbling system along with a bunch of new actual events (double-click - woo hoo!) you can almost always sculpt a perfect solution for your particular problem.

Using FlexUnit with Pure ActionScript

Now that I'm starting to develop non-trivial applications with ActionScript 3 I figured I should hop onto the test-driven-design bus and get down with FlexUnit. I've use JUnit in the past, and since it follows the xUnit style, I've had no problem getting used to FlexUnit... until I wanted to use it on a pure ActionScript project.

I had read on Darron Schall's FlexUnit tutorial and other places that FlexUnit could be used on non-Flex projects, but I couldn't find anyone who expanded on the concept to show how to do it.

It turns out it's quite easy! Essentially all you have to do is to follow Darron's excellent instructions and then take your main class and turn it into a separate application. To do this you just open the properties of your project (right click, select Properties) and then select Flex Applications from the list on the left. You then just click the Add button and specify the main class of your application. I usually make that the default application as well.

Now you have all of the niceties of FlexUnit without having to use Flex in your actual application. In our case this is very, very handy for making specialized, highly error prone code libraries.

Stop. Think. Play!

I'm sitting here on my couch waiting for my wife to come back from delivering a pitcher back to our neighbors. (They brought over a pitcher of yummy sangria last night for cinco de mayo - and just managed to stumble home, let alone take their pitcher with them!)

So anyways, I'm sitting here and as usual when I don't have anything immediate to do I kind of well - fret. Like a lot of folks right now I'm feeling a bit overwhelmed. There is just so much new stuff pouring out RIGHT NOW. Everything from ActionScript 3 and Flex 2, to Apollo, to Microsoft's new Silverlight thingie. It's enough to make you want to either lock yourself in a room with a pile of binders full of documentation or just run screaming from the whole industry.

Then, I just thought about it some more and calmed down. Sure, like most people I have a lot of work ahead of me to catch up with everything. But you know what thats going to take? Some playing and some thinking - that's what!

What made me calm down was trying to remember how I felt when ActionScript first appeared. That very first day I got my hands on the Flash 5 alpha I was so wigged out - but in a good way! I couldn't think of what to play with first! I was on a business trip at the time and while I was in the airport waiting for my flight home I think I coded up 3-4 different small games (pong, mastermind, minesweeper - those kinds of things). I picked a problem and just tried to solve it with ActionScript.

Now, I need to do the same thing - with ActionScript 3, Flex 2, Apollo, Silverlight, and all of the other random bits of technology I've been meaning to learn for a long time now. Yeah, I already know some AS3, but if I just stick with my real "work" for it, it will take me forever to really be 100% fluent. So I got started on an asteroids-style game. It's not terribly difficult, but it's making me really take a hard look at parts of AS3 I haven't even touched yet.

Here's the best part (for you at least!) when I'm done with these little fun examples I'll be posting the source code and run down of how it works here on our blog. Maybe then we'll have a few more readers than just the two of us and my wife!

One Destination, Many Paths

As I mentioned in the opening post, I'm not a Flex-head. I just haven't had a chance yet to really dig into the API. This fact, combined with Keenan's knowlege of Flex just resulted in a very funny argument.

Keenan is building a small Flex app for one of our clients to allow them to create levels for an education game we wrote for them. The game reads in XML files that follow a specialized schema we created. Whoop-de-doo, right?

Well, it got interesting when Keenan was loading the data. Since I really only know AS3 I assumed he was using the 1-2 punch of URLRequest and URLLoader. I then assumed he was taking the raw data from that load and create a new XML object. Nope.

Keenan was using Flex's HTTPService class. With that class you need to specify how you want it to treat the data it pulls down - the resultFormat. By default it takes XML and turns it into a simple object structure and Keenan was just using the default.

That simple object structure is just enough like E4X it was throwing me off. You can step right through the structure just like it was E4X. Since the code wasn't using any of the specialized E4X stuff like @ or filtering I couldn't tell just by looking that he wasn't actually using E4X.

The problem was that HTTPService, when it runs into a single tag that doesn't repeat, just creates a single object - while E4X will still create a XMLList. So, when Keenan was trying to access a tag there just happened to be one of, the length property didn't exist.

I was thinking he hadn't ever created an actual XML object (he hadn't) so that's why it wasn't working. Keenan thought that he should be getting an array - and he should of - if he was using XML!

Yes! Another Freakin’ Blog!

As if there weren't enough out there already, right? Well, no actually!

Your two valiant authors (Keenan and myself) are a bit, shall we say, different. While both of us come from a computer science background, I tend to be the more "Flash" guy and Keenan tends to be the more "Flex" guy. I honestly don't know a lick of MXML and lets just say that we don't let Keenan draw - ever.

That being said, we are both huge fans of ActionScript 3. We've both been working with since it's early days in Macromedia Adobe Labs, but we're still learning new things everyday - and that's where this blog comes in. We hoping for this blog to become a window into our everyday process of learning, discovering and creating.