Dispatching Events

I'm thinking I'm probably extra stupid, but I kind of got the impression from the Event handling docs that if you wanted to send out your own events, you had to have your own events class. It seemed to me there was something magical in the constants defining event names in your events class that somehow made the events so named "your" events. It turns out that if you want to dispatch an event "this is an event" then it really is as simple as

dispatchEvent(new Event("this is an event"));

Then all you have to do is add an event listener for "this is an event". There's no more magic to it than that. The event just needs to be called the same thing on both sides, and that is what the constants make sure of. But they're not required.

Now, if you want to pass more information in an event, such as whether a click on a Multiple Choice Question is right or wrong, then you'd need your own Event class. But for simply broadcasting an event you know is yours, you just send out an event as above. Duh.

I figure most people reading this are not as "challenged" as I am, but hopefully this helps someone anyway.

Update 7/3/2008: When a component is dispatching events, it should also "announce" what events are available on it with an Event metadata tag, such as [Event (name="thisIsAnEvent" type="flash.events.Event")]. This allows you to use it in MXML without a compiler error. I honestly don't know whether multi-word event name, as stated in my original example, would cause an error or not.

Modules for eLearning

I've written before about how difficult I've found it to figure out how to use Modules for eLearning style structures within Flex. It seems to me I may have hit upon an approach that works. The new documentation on Modules has an example that shows creating an Interface so that you have a known "contract" between the Module and the parent container. The example shows how to pass information into the Module, but didn't seem at all concerned about passing information back out. So I put my thinking cap on, and went to researching.

The first thing that seemed obvious to me was that you'd need to have some sort of event that would be propogated from the Module to tell the parent container that something had happened. So, I went and looked at the documentation about how to handle events. And I really, really tried to figure out a way to do it just with the implementation of the functions from the Interface. But functions in an Interface are kinda tricky. They're fairly plain Jane (in the Interface itself they're just stubs, with no implementation) and are really designed to be called from whatever is Interfacing with the Interfacee (as it were). I couldn't figure out a way to use them to push information out with them.

Instead, what I did was create a function that will return the name of the event that the Module expects to send out to the container. This allows the container to attach an event listener for that event without having to know up front what it will be called. So, for instance you could have an ElearningEvent.MENU_CLICK or an ElearningEvent.MC_SELECTION.

Where did the names for these events come from? Well, let me back up. I wrote a custom event class called ElearningEvent, specifically for handling events from my own eLearning Modules. I imported this class both into the Module file and into the Container file. It had public static constants in it that defined the ELearningEvent types. Ultimately, I plan to extend it so that more custom events can convey more information, such as whether a question was right or wrong (right now, it just publishes a value and ID).

So now that I've rambled all over the map, let me distill the process into a nutshell:

1. First, I wrote the Interface .as file (IELearning.as), which essentially said "these are the functions you can use to access me, and here are the arguments I expect and what I will return."
2. Next, I wrote the ELearningEvent class, which defined my custom event, including constants covering the event types included in it. I made it Inspectable so that Flex Builder would help with the typing.
3. I added the implements element to the Module to specify that it implemented IELearning. I added the implementation of the Interface functions, including the one that published the specific event for this Module (in this case, a MENU_CLICK). And I added logic to listen for a click on the menu and generate my ElearningEvent.
4. In the containing Application, I added logic similar to the logic in the Module docs to retrieve a reference to the Module child when it loaded. The difference is, I also asked for the name of the event that the Module child was planning to generate, and attached an event listener to the child.

The Module file was already inserted into the Application file, and I'd already worked out its base functionality before I started the process above.

I'm still not sure why an Interface is the suggested solution for this. I would think that maybe just writing an ordinary class, might be better, or even a fake abstract class.

AS3 Basics

I've been struggling a lot with the Flex documentation (can ya tell?), and a lot of it, I think, is because the people who write docs know the whole thing inside and out. So they don't realize that before they go off all half cocked telling you how to write the code in a package, they should probably take a moment or two to tell you where to put the package, what to call the package so it will work, and how you refer to it from within your code and MXML. That's just an example of my "issues" with the docs, but a very pertinent one.

I'd pretty much worked all those things out with a little creative "reading between the lines" and reading the same articles on the Developer's Center over and over. However, I finally stumbled across the free ActionScript 3 Cookbook Excerpts from O'Reilly, and let me tell you, it has really codified a lot of stuff I thought I'd figured out, as well as correcting some misconceptions as a result of the roundabout route I took to the figurin'. I have only read up to Chapter 2, which, incidentally, explains all that stuff about packaging. I think I'll be ordering this book tomorrow! Wonder if it comes in MS Reader format...?

ELearning Approaches

I'm trying to get my head around the best way to use Flex for eLearning, and I'm truly having to start with the basics. The average computer based course has an interface which may show some front matter, usually shows a menu, and then will show the content. After that, it may show a summary or have a quiz. But all of these things "live" in the same interface. Sounds simple, right?

In Authorware, it pretty much is. But in Flex it's another story. Flex has the ability to do this kind of thing with several different techniques. For instance, you can use a ViewStack, View States, or Modules. All seem to have their own advantages and disadvantages, but it feels like they're all totally different ways of doing business. Ah, what to choose, what to choose?

My first experiments have been with Modules. I find myself really frustrated (again), because it seems like it's hard to find information at all, and then when you do find it, it may or may not tell you about all the "gotchas" that seem to lurk under every rock in Flex. But I've found a decent reference for Modules and several of the other Flex features you might find useful. The links on the right seem to point to chapters in the upcoming Flex Builder 3 manual.