Ted On Flash: Macromedia please add flash.util.Synchronous Class into AS3

Macromedia please add flash.util.Synchronous Class into AS3

DIGG IT! 13 Comments Published Monday, November 07, 2005 at 11:37 PM .

This is a feature request for Flash Player 8.5 in support of a new Class for handling synchronous behavior. Adding synchronous behavior into all Flash Player classes would be a massive undertaking but allowing a single function to execute in a structured manner would not. Let me explain.

First let�s define Synchronous within Flash Player to make sure we are all on the same page. I view Synchronous behavior in Flash as:

1. A Synchronous process is started
2. The Flash Player executes the process over and over until the process returns
3. The Player does not error or timeout or complain
4. When the process returns, AS execution starts from the exact point where it left off.

Here is some example Synchronous code examples:

// retrieve data from a URL and set it as a DataProvider property.
dataGrid.dataProvider = getData( url )

or

if( uploadFile( url ) ){
   \\file was browsed, selected, and uploaded to the url successfully
}else{
   \\an error occured
}

The key to making this work is providing a class within which a function can be executed over and over without causing the player to:

1. Reach the Script Timeout Limit
2. Reach the Recursion Limit

If Flash Player 8.5 provided a Class under which the above 2 rules were valid, we could execute a function over and over to provide Synchronous behavior. Here is an example that counts to 10,000,000 within function run Synchronously:

function timeTo10Million( ){

   import flash.util.Synchronous

   // define a function to be executed over and over
   // a single object argument is passed
   // with every execution to save data between calls
   var synchFunction = function( sdo:Object ){

      //if i is undefined, define it.
      if( sdo.i == undefined ) sdo.i=0

      //if startTime is undefined, define it.
      if( sdo.startTime == undefined ) sdo.startTime = flash.util.getTimer()

      //add 1 to i
      sdo.i++

      // if we have reached 10 Million return
      if( sdo.i >= 10000000 ){

         //return ms to count to 10 million
         //this will end execution of Synchronous.execute!!!
         return flash.util.getTimer() - sdo.startTime

      }

      //every million iterations, force an update to the DisplayList
      if( sdo.i % 1000000 == 0 ) Synchronous.updateAfterEvent()

   }

   //call Synchronous.execute with synchFunction and a new Object
   return Synchronous.execute( synchFunction , {} )

}

trace( timeTo10Million() ) // 55

When a function is executed under Synchronous.execute, the rules for AS execution change within the Flash Player. The player will execute the function over and over and if data is returned at any point, execution returns to the exact spot where Synchronous.execute was started. Synchronous.execute calls the passed function over and over, and passes a common object as a argument for storing data between executions. This allows you to avoid creating lots of temporary variables and allows other AS to execute during Synchronous execution. Within this function, you could fetch data remotely, listen for Socket AMF data to return, or just sit and wait for 100 ms without using events. Obviously use of Synchronous.execute is an advanced feature but it provides an opportunity to create lots of simplified tools very easily. I can think of lots of uses to simplify software development with Flash/Flex and I am sure you can think of allot more too.

The advantages here is that we can use AS3 language to extend the player synchronously without allot of muss or fuss. Thread management, specialized events, or advanced concepts of parallel execution are not needed. Also as a bonus, because Synchronous is a class, it is already ECMA compliant.

If you would like to see Synchronous behavior in Flash Player 8.5, say something!!! There is very little development time left as Flash Player 8.5 moves toward feature completion. I think this addition would revolutionize the use of Flash/Flex and simplify lots of concepts that make no sense to developers coming from other languages. It is about time we had an alternative to "waiting yet another frame".

Comments encouraged!

Cheers,

Ted :)

13 Responses to “Macromedia please add flash.util.Synchronous Class into AS3”

# Anonymous November 8, 2005 7:21 AM

Superb .. if only they would also bring that linux flash player ... how much time should we wait to play with these neat features on our workhorses ?
# iongion November 8, 2005 7:22 AM

talking about linux flash player .... where is the linux IDE ? where is the linux compatible eclipse plugin ?

It makes me cry!
# Ted Patrick November 8, 2005 7:49 AM

Unfortunately the players and tools ship to the largest markets first based on pure economics. In the land of server tools, I know Macromedia has a great record on supporting linux.

I think the port of the Flash Player is more specific to the video API of the OS Shell. My understanding is that porting to KDE vs Gnome are very different at the rendering level of the player.

Considering the players are moving toward hardware acceleration in the core renderer, this makes these ports all the more difficult moving forward and the number of manditory ports will rise with the addition of WinFX and OSX86.

I wish every platform would ship with equal players but the market is at work here and trival ports these are not.

Who knows maybe with the Flash Platform focus we will see renewed interest in porting the player.

Ted ;)
# JesterXL November 8, 2005 8:42 AM

All I feel is concern. Enabling "blocking" via a class as you describe makes me scared. The whole point of the script timeout rule was to prevent user generated errors that made a script hang. There were only an extreme few functions that did this in Flash; parseXML was the only real one that didn't scale well and caused this, but even that could be worked around via manual parsing in onData.

I guess, to me, this syncronous stuff makes me worry. I've become used to event based architectures over the years of learning Flash, so I guess I'm used to it, but I understand what you mean by others coming into Flash; coming misconception on Flexcoders is that server calls block, and this is repeated every 2 weeks as someone new learns this.

...still, I'd rather have events than freezing the AVM for 1 function; specially if I'm sharing code and some crackhead decides to use Syncronous on one trivial function.

Doesn't feel right to me, man.
# davidr November 8, 2005 10:19 AM

I believe the word you are looking for is 'Multithreaded' -- that is, they should put the display update in a separate thread from actionscript execution. This way actionscript could be running for a while, but not lock up the display.
# Ted Patrick November 8, 2005 12:18 PM

Jesse,

I hear ya but I think its time. It would enable the simlification and extension of so many things. It is simple in concept and works within what exists today. Writing synchronous functions would be a snap for solving the truely harder problems in Flex development. We spend so much time coding around the players behavior that it is so refreshing to code something synchronously.

I use Python allot and its synchronous behaviour is amazing:

# get a file and read it
# into the print statement
print( getURL(url).read() )

So simple, so clean and so feasable. I think it would be a mistake to not enable some sort of blocking in the AS portion of execution.

Ted :)
# Ted Patrick November 8, 2005 12:34 PM

davidr,

Actually the player is already multi-threaded in AS/Rendering/Networking. Parallel execution of AS code would make a horrible mess during synchonization. I think it would be simpler to maintain a single thread of execution and block. Python has worked this way for a long time (excluding the thread library for Python)

My 2 cents,

ted :)
# Arie November 9, 2005 12:18 AM

Am I right that in your proposal a user would have to wait and wait, without something happening (from his point of view)?
Wouldn't he, in that case, just quit your application?
# Ted Patrick November 9, 2005 1:20 AM

True and not true. In the example provided you can force update the stage by calling updateAfterEvent(). Ideally you would present a progressBar or dialog during the execution of a process. Part of the goal is to execute one process until it completes its cycle and return to the normal flow of the application.

Sometime the user needs to wait...

Ted ;)
# Matt May 24, 2007 11:56 PM

What happened to this class between 8.5 and 9? Its gone... :(
# Steven Chase March 17, 2008 8:31 AM

We are currently doing a large project for (hint) the largest IT company in the world. I am researching how to do asynchronous calls in Flash in order to complete this project. Needless to say, it's very disappointing the concept of an async function call is not built in.
# Wallville May 1, 2008 6:22 AM

So...what ever happened here with Adobe. Did they listen? Did they respond?

What I'm trying to understand with this thread is: You are asking for a test case for urlRequest or urlLoader calls?

If so...my concern still stands. Did they bite on this thread?

Historical Marker: I just bought the Raconteurs Album...they've got a good thing going there.
# Kris Hofmans June 12, 2008 11:25 AM

I could definitely understand where this would be usefull. I myself am looking at the option to do "real lazy loading" on getters that return associations or collections and want to fetch them from the server if needed. I like the async things, but there should be an option to do it synchronous if you really want too, adobe shouldn't hold my hand.

Btw synchronous doesn't mean it has to hang indefinitely, timeout's would suffice.

Stuff I am building:

Ted Patrick - Events & Community @ Adobe Systems

Note: This is the personal blog of Ted Patrick. The opinions and statements voiced here are my own.

Macromedia please add flash.util.Synchronous Class into AS3

13 Responses to “Macromedia please add flash.util.Synchronous Class into AS3”

Where to find me:

Latest

Lists

Links

Jobs

Archives