SpecialRelativity

There’s not really that much out there on errors in Actionscript 3.0 other then the documentation which can be found at this link: http://livedocs.adobe.com/flash/9.0/ActionScriptLangRefV3/Error.html

So the goal here is to provide you with a better understanding of errors in general. We will touch on why, when and where we throw errors as well as what we can do to make those errors more effective. When used appropriately errors can do a lot for your code. By forcing a situation to be handled (throwing the error) you are making your system more reliable. If those errors convey the issue properly you are making your system more maintainable. It seems odd to learn to love the things you hate… but work with me here…

I’m not going to go over the details of how you throw an error in code, check out the documentation as there is already plenty of info on that.

Errors are usually thrown from code that for some reason cannot complete execution. In most cases the situation is either the code not being used properly, or the code not being in a suitable state for execution. To illustrate this, suppose we are constructing the navigator of a website. The job of the navigator is to handle the details of moving between the pages in the website.

Our navigator’s navigateToPage( pageID ) method will throw two errors. One error will be thrown if you call navigateToPage with a pageID which does not exist, and the other error is thrown if you call navigateToPage while the navigator is already in the process of navigating to a page. The first error is an example of the code not being used properly, the second error is an example of the code not being in a suitable state for execution.

Errors themselves have two purposes. They notify the system that something has gone wrong, and provide the person maintaining the code in that system with information which helps them resolve that error. We can illustrate this by again taking a look at our navigator example from earlier.

Any time an error is thrown using throw the system is automatically notified. That means it’s really just about providing the right kind of information.

Remember that our navigateToPage method throws two errors. We could simply just provide a message for both errors that says “Navigator could not navigate to the page.”, or we could provide a little bit of information that helps narrow down the error. For instance, if an invalid page id is specified we could provide a message that says “Invalid page id specified”, and if the navigator is already navigating to a page we could say “Navigator is already navigating to a page”. Nothing new or complicated with any of this. It’s mostly just important that the issue that caused the error is immediately identifiable.

There is my view on errors. Here is a section on some basic things to think about regarding errors…

• Do NOT ignore errors by having an empty catch block. Respect the error for what it is, and resolve it.
• Remember that when you throw an error from a method of an object that the object and application can continue running. Always leave the object in a desirable state even if the desired state is some pre-defined undesirable state.
• If an error is not caught it will throw a dialogue which lists the error’s name, the message and then the stack trace of where the error occured. This means that when throwing an error there is no need to specify where the error was thrown from.

Actionscript 3 introduced a new system of events for dealing with when the user interacts with our applications. This system came in the form of InteractiveObjects and the various events that they broadcast. InteractiveObjects are what the user interacts with (go figure?). Interaction comes in a few flavors: mouse clicks, key presses, focus and tabbed. I’m not going to get into detail about any of these, we are going to talk about how we usually handle basic interactions and how to introduce a method for detecting key combinations that makes sense.

InteractiveObjects cannot be instantiated. They are instead integrated as part of the display api, which makes perfect sense.

Generally when you are listening for the usual interactions, such as key presses and mouse clicks, this is how it would go:

..

   addEventListener( MouseEvent.CLICK, clicked );

..

private function clicked( event:MouseEvent ):void
{
   trace( "Ack I was clicked!" );
}

This would usually be located somewhere within your subclass of one of the InteractiveObject types. To keep with this way of handling interactivity events here is the solution we are going to go with.

We will have a KeyComboDispatcher class. When you create an instance of KeyComboDispatcher you pass it the InteractiveObject instance which owns it. The KeyComboDispatcher class will listen to all events that its owner dispatches. When the KeyComboDispatcher recognizes a combination of keys that have been pressed it will dispatch a KeyComboEvent with information about the combination that was pressed.

You are able to register key combinations for the KeyComboDispatcher to listen for using its addKeyCombo method. The addKeyCombo method allows you to name the combination and set the key codes in their correct order. The KeyComboEvent that is broadcast if the combination is detected contains the name that you gave the combination, and the key codes that make up that combination.

And that’s pretty much how it works, the two classes are well commented so you should be able to learn their inner-workings by following the comments. You can find those classes here

KeyComboDispatcher.as
KeyComboEvent.as

A few days ago a good friend of mine Ruben and I were talking about Events. Ruben was putting together a post about events. While we we’re talking about it we got into a discussion about bubbling events and cases where it is appropriate. You should definitely check out Ruben’s post he makes good points and forwards you on to some good resources.

I’m just going to continue on with a conversation we were having while he was writing his post. Hopefully you have read Ruben’s post as well as the adobe documentation on event handling since I’m assuming you know what event bubbling is and how to work with it.

So how about we put together a situation? We are making a web site. One of our goals is to allow flexibility in the look and feel as I guess it always is right? Here is the approach we are taking.

We have a Main file which creates an instance of our site’s controller. The Main class adds the view of our site to the root display list and then runs our site. We will take all of this a little further by saying that the site’s controller has a navigator property (which we won’t discuss) that is used to navigate between the pages of your site and contains the current page being viewed. The role of the site controller then is to prepare the different elements of the site, the screen, the navigator, the pages, and to facilitate what communication is to happen between them.

We are going to leave out a lot of the boring details since we are talking about a pretty specific piece of this whole system. One thing that is assumed is that when you run the site it builds the landing page and then navigates to it. All user interface elements of the site exist within the site’s screen.

In our look at this website we are focusing on one section, how the UI interacts with the controller. If you take a look back at what the role of our site’s controller is you will notice that all we really need to communicate with is the navigator, since all of the look and feel details are part of the page system and not part of the site’s controller.

Read the rest of this entry »

The goal here is to get you communicating. I will provide you with an explanation of what I’m doing without exhausting what is happening. I hope to put you in a position to experiment with your own ideas, because really… that’s the best way to learn.

So the first thing we should ask ourselves is… what is really going on? I’m sure you know that you’re trying to talk to Java and you know that you want to do it using Actionscript 3, but I’m going to assume that you are reading this more because you don’t know how to communicate your own Java application back to Actionscript. Maybe you don’t know Java at all and don’t really have a reason to, but a way to communicate with your own application that can integrate multiple users in a more real time way may be a good reason, although we will not introduce multi-threading, and therefore multi-user support, until the second article. So… maybe I should should just get on with it…

If you are not familiar with Java you will probably need to get the sdk and learn how to compile a Java program. You can find that info here [insert link to tutorial on compiling java]

Basically this is what is going to be happening. Actionscript opens up a Socket to a port at some location. On that port at that location a program is listening and waiting to handle that connection. Actionscript will listen to that Socket for messages from the program as well as use that Socket to write messages back to the program. The program, which we will write in Java, will use a ServerSocket to communicate with the Socket.

With most of the crappy details removed that is what is going to happen in our system. I am going to step through how we get it running on both ends.

Read the rest of this entry »

… and soon I will have stuff.