XML Sockets in Flash

The purpose of this tutorial is to familiarize readers with the XMLSocket object in Flash, it’s methods and properties. Teach the reader the more common methods of using the XMLSocket object, and then open the reader up to the possibilities allowed by the XMLSocket Object.

In this article, the XML language is not explained at all. For a tutorial on XML, see XML Basics. I do plan on discussing certain methods of formatting your XML so that parsing in the Flash Player 5.04 is faster. Flash has always been meant to facilitate SVG, primarily for web delivery, and recently also for other mediums of presentation. With any presentation there will be data that needs to be conveyed. Be it through a web site shopping cart, or an ATM infomercial – data is the heart of the matter.

XML was introduced as a means of freeing the languages we use to define the data we traffic in. Since XML is more a way of defining data rather than a strict method of defining data, there have been many *MLs introduced in an effort to best define the data particular to a given industry. While this massive effort to define data is laudable, we need to remember that sometimes it doesn’t really matter how we define it, as long as all of the members of the conversation understand the language that is being spoken. To this end Flash’s XMLSocket object works wonders.

True XML is often accompanied by a DTD, to help foreign environments interpret and manipulate the accompanying XML. Flash currently does not support a DTD. While it can interpret the DTD tag, and return the information contained therein, Flash does not validate XML from the DTD. While this could hamper Flash’s ability to survive in an increasingly ‘XMLish’ world of data, we’ll see how it really doesn’t matter.

Another important point to consider when speaking of Flash and its XMLSocket object is that Flash has a history of being the tool easiest to produce great works of non-usability. Many first impressions of Flash were of it’s pointless self-aggrandizing intros, or maybe of inescapable pre-loaders. As I said – Flash’s development environment facilitates the creation of unusable content. As we approach the XMLSocket object, we must then keep in mind that Flash (currently) has limitations to its true usability. But there are many developers who have helped rid us of many of those limitations, if we choose to use their tools, and the upcoming versions of Flash appear promising indeed.

In the end, Flash is preparing to dominate a market that did not exist before. Used properly, and effectively, the XMLSocket object will play a key role in that future. The web will not exist in its current form for long. Already we see changes in the fundamental uses of the sprawling Internet, and yet there are purposes that drive that change which will remain forever. Data will need to be exchanged. Through one language or another, using a web services platform or a web server, data will need to be conveyed.

The XMLSocket object brings about the marriage of both data and presentation in an environment not possible before. Those on the client end, and those with their hands on the stirring spoons can see changes as the bi-directional exchange of data is presented in the robust and warm environment Flash has to offer.

That having been said… let’s examine the beast that’s known as the XMLSocket object.{mospagebreak title=Methods and Properties} I’ll enumerate the different methods and properties that this object contains, and then explain common coding practices.

close() – This method allows you to cleanly terminate an open socket from the client’s end of communication.

connect() – This method allows you to connect to a server running a socket server that is able to interpret the EOL character that is currently standard for Flash sockets (the ASCII null character, or ‘’). It will also eventually invoke the onConnect event-handler. This method accepts two parameters: a string as the URL of the server to connect to, and an integer as the port that the socket server is waiting on.

send() – This method allows you to send a string of characters through the socket connection. While the string is usually in XML format it does not have to be. This string can either be constructed using the XML object within Flash, or manually if size permits. Flash will also automatically append the terminating null character for you.

onConnect() – This event-handler is invoked either on success or failure for the connection attempt. It will return a Boolean based on the connections status (not to be confused with the ‘status’ property of a parsed XML object).

onXML() – This event-handler is invoked upon receipt of a null character. When this event is triggered the data that was received since the last null character has already been parsed, and placed into a hierarchy that you can use to retrieve the data – again using the XML object in Flash.

onData() – This event is similar to the onXML event, but it is triggered before any parsing. This allows for manual parsing or custom string handling (which can be quite useful as we’ll see near the end of this article).

onClose() – This event is not as intuitive as it might seem. It is triggered when the server terminates the connection – not when the client terminates. This is generally used to handle an unexpected disconnection from the server. {mospagebreak title=Common Utilizations} Having outlined the methods and event handlers common to the XMLSocket object, let’s discuss how they all work together. Here is some sample code for a connection from Flash to a server with no functionality for sending, receiving, or parsing.

myXML = new XMLSocket; myXML.onConnect = handleConnect; myXML.connect(“http://www.yourServer.com”, 12345); function handleConnect(connectionStatus){ connectionStatus ? trace(“Connected.”) : trace(“Connection failed.”); }
As you can see, there really isn’t that much to initiating a socket connection to your server.

So that you can test your Flash code, here is a very condensed socket server written in Perl. This server has no special functionality built in. It simply echoes anything it receives from any client to all clients connected. Notice that the only real change needed from a standard basic socket server is the setting of the null character as the EOL indicator (in Perl: $/=””;).

use IO::Socket; use IO::Select; $SIG{PIPE}=’IGNORE’; $m=new IO::Socket::INET(Listen=>1,LocalPort=>2229); $O=new IO::Select($m); $/=””; while(@S=$O->can_read){ foreach(@S){ if($_==$m){ $C=$m->accept;$O->add($C); }else{ my $R=sysread($_, $i, 2048); if($R==0){ $T=syswrite($_, ‘

‘, 2048); if($T==undef){ $O->remove($_); } }else{ foreach $C($O->handles){ $T=syswrite($C, $i,2048); } } } } }

As was mentioned in the previous section, any language can handle Flash’s sockets, as long as it can open ports, and recognize the null character as an EOL character. Socket apps have been written in Perl, PHP, Java, C++, and I’m sure in many other languages.

Since there really isn’t any need to explain the above ActionScript code, we will provide an example that uses most of the functionality the object has to offer.

myXML = new XMLSocket; myXML.onConnect = handleConnect; myXML.onXML = handleXML; myXML.onClose = handleDisconnect; myXML.connect(“http://www.yourServer.com”, 12345); function handleConnect(connectionStatus){ connectionStatus ? trace(“Connected.”) : trace(“Connection failed.”); } function handleXML(xmlObject){ trace(“Object recieved:: “+xmlObject); } function sendXML(textToSend){ myXML.send(new XML(‘“+textToSend+”“)); } function handleDisconnect(){ trace(“Connection lost.”); } function closeConnection(){ trace(“Closing connection to server.”); myXML.close(); }
That pretty much covers the basic implementation of the methods, and event handlers. But that’s only the starting point. Where you take it from here will depend on the solution you’re working to implement. {mospagebreak title=Possibilities} As I mentioned – where you go from here is up to you. XML has strength where other markup languages do not, in that it is a framework, not a finished product. You can define your data any way you’d like. As long as you code so that the clients and/or the server understand the language they speak, you can do anything, anyway you’d like.

For example, how about your own graphical presentation of the newest article from your favorite web site?? Simple. Write your server app to accept a string like, “<infoRequest client=’mySessionID’/>”, grab the HTML page, filter out the content needed, and send back a reply to that client like, “<infoReply client=’mySessionID’>The info you requested</infoReply>”. Then it would be a simple matter in Flash to parse the XML reply from the server into the graphical representation you designed. Tied to personalization, a user can visit your web site, and see ‘live’ updates of the content they want – presented the way you/they wanted it.

Speaking of requesting information and replying – how about minimizing the load your server experiences through HTTP requests for database information?? Many sites currently submit a new request for each segment of data that the client needs. Using Flash to maintain a persistent socket connection to your server, while the socket app running on your server also maintains a persistent connection to the database might allow you to funnel data to the client in ‘real-time’ with out the overhead of either page reloads, or new requests.

There are other advantages as well. Since this entire system is simply a socket connection on each end, with XML being the preferred language, you could send strings of numbers that each end could interpret as actions/reactions to situations. Many websites have designed full server engines, and client environments that allow for ‘real-time’ multi-user content. Until a few months ago the main focus of a multi-user app has been for chat, but many others are looking to more diverse methods of enabling client interaction. While Quake has yet to make an appearance in Flash, multi-user 3D, as well as 2D and ISO environments exist.

A benefit to the separation of ActionScript from other languages is that ActionScript can focus on the presentation of the data, and not necessarily the manipulation of it. If you’ve ever had some killer app that grabbed the data by the tail and swung it around, you might also want a simple means of delivering that data to others. Flash’s graphical abilities combined with other languages data power though the XMLSocket object could be the answer.{mospagebreak title=Summary} All in all the XMLSocket object allows for an increased vocabulary between clients and/or server. This allows the developer to bring about more dynamic ‘real-time-capable’ data. The XMLSocket object also facilitates the transferal of information from storage to use. The XMLSocket object is only one of many methods available for this transferal, yet it’s advantages give the developer an increased range of motion in delivering that data to the client.

There are precautions that need to be taken, as Flash does not currently support encoding of a robust nature. There are Flash developers who have scripted objects that deal with MD5 encryption, yet they tend to be bulky, and unwieldy. Care must also be taken when addressing issues of usability in Animated representation of data. The Flash Player version 5 needs code snippets to deal with a loss of frame rate when parsing larger XML documents, yet the Flash Player 6 Beta release does not.

Attention should also be focused on the structuring of the XML document or string that is to be sent to Flash. Flash tends to favor less parent/child node structure, and more an attribute type of structure. For instance, the string:

<top> <firstChild> <insideDescription1> Text1 </insideDescription1> </firstChild> <secondChild> <insideDescription2> Text2 </insideDescription2> </secondChild> </top>
Would be better defined like this:

<top> <firstChild type=’insideDescription1’ text=’TEXT1’/> <secondChild type=’insideDescription2’ text=’TEXT2’/> </top>
if at all possible. There are circumstances that do not allow for this style of structure, but it should be used if it can.

It should also be remembered that Flash does not have to accept only XML formatted data. By using the ‘onData()’ event handler we can process other forms of information. Why send a string like this:

<top> <xPosition> 234 </xPosition> <yPosition> 34 </yPosition> <zPosition> 4 </zPosition> </top>
When the string: “234|34|4” would more than suffice? The XMLSocket does not use ‘headers’ like standard HTML does, nor does it require bulky tag explanations if you don’t want it to. The joy in the XMLSocket implementation is that you can define your data anyway you wish and display it from your server to anywhere you can squeeze Flash!
[gp-comments width="770" linklove="off" ]

chat sex hikayeleri Ensest hikaye