But I am now certain that you all are correct in that the answer the test was looking for was 2. Asynchronous execution. The question was referencing the fact that calling certain methods does not provide immediate results, but rather the result (or error) is returned via an event that is dispatched at some future, arbitrary time — hence asynchronous execution. Did I get it?

Alan, what you describe as allowing an app to run asynchronously are server calls. I’ve seen the word “asynchronous” used many times in the official documentation for HTTPService, WebService, and RemoteObject in Flex. For example, when you call the send() method on HTTPService, the Flash player calls the service and then continues to execute code, not waiting around for the result. The HTTPService’s ResultEvent is dispatched only when the server call returns successfully at some future time. (For anyone following this discussion, here is a forum post where Adobe employee Tom Lane explains it better than I can.)

Kim, point taken. Event-driven programming versus old-school BASIC and other languages where code execution flowed from line 1 to the end of the program and then it looped back. However, what I wondered about the question was what I demonstrated — that dispatchEvent() is a synchronous operation. Assigning an event handler function to an event and then dispatching that event is exactly the same as calling the event handler function directly (not taking into account such things as the priority argument passed in via addEventListener, or the capture/bubble phases, or event.stopPropagation(), etc.) Do you agree?

I chose to say ‘best’ and not ‘correct’, because I believe that you just demonstrated how an event can be used in a synchronous manner, but the purpose of events is to enable an app to execute asynchronously.

Example: When using an app like Photoshop, when I save an image the app will pause while it writes the file to disk – locking out any user interaction until it is complete. This is synchronous behavior. In a Java or Flash app, the user may be constantly reading and writing to a remote database. If Flash was synchronous, then the app would pause until a database read or write was completed.

I see that question as a bad question. As you pointed out, Flash’s event structure may work synchronously, but I believe the intent is for an app to run synchronously.

The correct answer is 2. Asynchronous Execution.

This is a good concept to understand.

The order of the traces in your example did not have to be in that order. For instance, if you replace your dispatchEvent with a statement to load an external file, the latency of the network call may result in the complete event being after the subsequent statements like your trace(“hello”);

Synchronous means blocking. When a synchronous operation is being performed, the code pauses and waits for the completion of the synchronous operation before moving on to execute subsequent statements.

Oddly, one of the best explanations is in the AIR docs (because developers can choose to execute AIR database calls either synchronously or asynchronously). See this page in the docs:
Using synchronous and asynchronous database operations
http://help.adobe.com/en_US/AIR/1.1/devappsflex/WS5b3ccc516d4fbf351e63e3d118666ade46-7d39.html

The “Programming Adobe ActionScript 3.0″ doc does include this:
http://livedocs.adobe.com/flash/9.0/main/00000096.html
Asynchronous: A program command such as a method call that doesn’t provide an immediate result; instead it gives a result (or error) in the form of an event.

And the earlier, but still great Colin Moock’s “ActionScript for Flash MX: The Definitive Guide” has the following:

Event-Based Asynchronous Code Execution
http://www.adobe.com/devnet/flash/articles/actionscript.html

Event-Based Asynchronous Code Execution
“Some code does not execute in a predetermined sequence. Instead, it executes when the ActionScript interpreter notices that an event has occurred. Many events involve a user action, such as clicking the mouse, resizing the movie, or pressing a key. Other events happen without user intervention, such as a sound completing or an XML document loading. Just as the playhead entering a new frame executes synchronous code attached to the frame, events can cause event-based code to execute. Event-based code (code that executes in response to an event) is said to be executed asynchronously because the triggering of events can occur at arbitrary times.

hth,

g