Paratrooper Digital

Gateways for server communication.

Flash allows multiple different ways to load data and content, but if you need to go through and change what server you are on? Make the connection string a variable and pull it in; easy. What about needing to add debugging information to your xml requests? That could be quite difficult on a wide scale application level. Whats a possible solution? Develop a gateway that all server requests go through.
I’m started working a dataManager class that is a wrapper for a series of other classes that generalize the type of request for that item. So far, I’ve only implemented a generalization for xml connections (Send, Load, and SendAndLoad), but css, xmlsocket and loadVariables work in very similar ways. Import another class into the dataManger wrapper and boom. Now all your css, xml/xmlsocket and loadVariables connections are being routed through one central place, easy to maintain/extend if you need to change the way all your connections are occuring
Why stop there right? Seems that you could generalize all loading of all content, progressive flv, netconnection flv, swfs, jpgs, sounds. Adding these other elements
Something I’ve also included in my implementation of the dataManager class is queueing. Usage involves pushing a request object to the dataManager; it returns a connection ID which is the receiptID for your entry. Later on or directly after storing this request you can ProcessRequestByID( receiptID ); While for most projects this is not needed, this allows for a sequential loading of elements to be created, might be needed for later implementations. (i’ve created sequential load mechanisms for several projects) When loading lots of elements it is often a good idea to stagger your requests so that you don’t drown the webserver or the clients machine with too many simultaneous requests.
Currently the dataManager keeps a record of all load transactions, but I’m still working on flushing processed requests out of the queue(as an optional feature)
On a recent project I found that running all xml requests through a central spot was totally important. The guy that developed the php backend for this project made his xml generators with an optional debug method. With all of my xml requests running through one central location all I have to do was flip a swtich and the proper flags for debug were sent. The flash movies carried out their normal SendAndLoad’s, but made a secondary request to a different window revealing all the server debug information that was needed. It was an excellent way of being able to see what was going on. All centralized and easy to turn off for the live server. Yet on a different project the team had to work with an obscure mirrioring system which required a dynamic set of links to different servers to load different content. These are just two reasons for centralizing your data communications.
Perhaps on smaller data driven applications this might not be so beneficial, but the dataManager class is only a mere 4 kb right now, and can greatly simplify the loading of content at run time.
Actionscript 3.0 also features a change in the way that items are added to the stage, treating all/most loading operations in the same manner. I haven’t looked at it too much (no flex2 server to compile any code on), but I’ve seen great things.

About Nate Frank

Nate is currently a Senior Presentation Layer Architect at Razorfish Chicago. As an SPLA Nate: participates in technology leadership team and resource allocations, manage fulltime and contractor resources, represents technology for groups of brands across multiple clients, furthers development of standards within the office, architects project implementations and fosters community and mentoring.

View all posts by Nate Frank