Data Exchanging

[ LiB ]

It's quite possible that your application gathers data, processes it, and then presents itall based on information the user supplies . You'll take a giant leap, however, when you can make your app reach out and read data from an outside source. Another step in sophistication is when your app can then send data out for others to access or just to a repository for safekeeping. Chapters 6, "Basic Data Exchange," and 7, "Exchanging Data with Outside Services," discuss a wide range of ways Flash can consume or publish data. In this section, you'll learn why this is so cool.

Loading

It's sort of a chicken and the egg question as to which comes first: reading data or writing it. In fact, all data in your app can originate in the user's brain and get typed in. However, even in the most simple cases, loading some data from an outside source is useful becauseif nothing elseyou can separate the code (in your Flash movie) from the data (data you load from outside, for instance). It can be as simple as creating a text file with data and storing it adjacent to your Flash movie. Keeping data separate pays off when, for example, you can make updates for your client by just changing a couple values in a text file. Figure 3.4 shows the code for a matching game where I can change the values for " name " and "star" to create a whole new game. Naturally, planning for such changes is what makes changes easy. However, just externalizing data you expect to change is only one reason you need to load data.

Figure 3.4. The actual names used for this matching game are kept external (shown on the left).

Often you'll want to present timely data inside your app. In such cases, the data must load from outside Flash. In fact this means that Flash needs to get the data from a database (either at your location or remotely). The point is, you can't present the current temperature by reading in a flat text file (unless you're constantly resaving that file with new data). Imagine manually typing a number into a text file every time the temperature changesyou'd get pretty exhausted. The point is, Flash can tap an application server for this data.

There's an upcoming section on application servers that shows how they can produce timely data for Flash to consume. However, we can first consider how that data is formatted. Here's a list of the possible ways data can arrive into Flash:

• URL encoded. This form always contains pairs of names with matching valuesfor example, "first= phillip last=kerman." It's almost like how variables are assigned in Flash. The actual format looks like what was shown in Figure 3.4. There are other details regarding how this must be formatted, but the key limitation is the values always arrive as string. Even if the data were to contain "age=38," the value for age would be "38" not 38 . This can mean a lot of parsing and cleaning up after the data arrives.

• XML. This is similar to URL encoded in that all values are strings. However, XML is nicer in a couple of ways. First, you can structure the data contained in XML so that context is given to parts of the data. For example, you can effectively say "here is a list of cities where we have offices," and then proceed to list them. In this way, values are given context by appearing in categories. The second advantage is that XML is extensible, meaning you can add values to particular categories (called nodes ). When you load XML, it's easy to ascertain both the values and how many values are contained.

• AMF packet. The Action Message Format (AMF) is a protocol used with Flash Remoting. You need Flash, an application server (such as ColdFusion MX), and Remoting installed. When Flash requests data, your application server prepares a packet and sends it back to Flash via AMF. Although there is a bit of work on the application server side, when the data arrives in Flash it's always in a single variable. That variable can be a number, a string, or even an array or generic object that contains even more values. The great part is you don't have to convert strings to numbers , or any other data types for that matter. (You'll learn more about data types in Chapter 4; for now just consider how a number is fundamentally different from a string of characters .) Besides making your life easy by eliminating the need to parse data types, AMF is a binary format that puts data in small packets that travel over the Internet efficiently .

• SOAP packets. Simple Object Access Protocol (SOAP) is based in XML but contains standardized elements that describe what's contained inside the file. XML can include some context of what's contained; a requirement of SOAP is that it must contain a description of both what's contained as well as documentation of the rules for the particular file. Luckily, we don't have to produce SOAP-formatted data. SOAP happens to be the format by which all web services transmit data. You'll see web services later in this chapter, but basically it's just a way for other companies to open access to some of their databases in a standardized form. Anyway, Flash now supports SOAP/web services (although you still have to go through an application server to reach outside your domain). It's comparable to AMF in that the data can contain any data type. However, it's better than AMF because you don't have to buy Flash Remoting (although, to be fair, Remoting comes free with ColdFusion). On the downside, SOAP isn't as lightweight and efficient as AMF. Having said all this, I don't think you need to be clairvoyant to see web services (therefore SOAP) is the direction of lots of tools, including Flash.

Although it may seem the ways of loading data all climax with SOAP being the best, note that there are uses for all of these. For one thing, both URL-encoded text and XML will work with plain-text files that you create manuallysort of a low-tech approach, but quick and dirty for many uses. As you'll see in the "Writing" section, you do need an application server to send any data out of Flash. That is, you can't just write text files with Flash.

The data exchange chapters of this book concentrate primarily on the mechanics of getting the data into and out of Flash. The first step is always making sure the data is in the right format. One misplaced character can render a set of data useless. Another mechanical issue is ensuring the data fully loads before you begin to process it. That is, you can't just say "find out temperature in Portland, Oregon and display it in this text field." Instead, you must first define how to display that data onscreen (when it finally arrives), and then make a request to load. The sequence matters. The issue is that requests to load outside data are not immediately answered . You'll soon read the details of all of this, but it does help to understand the process before you plan something that's impossible .

Parsing

Although I said AMF (Remoting) and SOAP (web services) can send you any data type and thus alleviate you from needing to parse it, you'll still spend a fair bit of time parsing. Parsing can also mean extracting small portions. In the case of getting the temperature, you may find a web service that can give you the temperature, barometric pressure, and the dew point. If you just want to display the temperature, you must parse that from the data you receive. (If you can figure a way to just load the temperature, this might reduce bandwidthbut receiving a few extra details probably isn't that big of a deal.)

Other words come to mind when thinking of this topic: collating, pruning, formatting, extrapolating , plotting. I'm just going to generalize and call it all parsing. When you parse data, you step through line by line or sometimes letter by letter. Obviously, you can write loops that do this automatically, but the point I want to make here is that you shouldn't worry too much about preformatting the data before it arrives in Flash. It would be nice if data always arrived custom fitted to your needs, but you don't want a single project to dictate that your remote functions are less generic. It's really not a big deal to do a bit of parsing; in addition, it's really common.

Writing

Reading data from outside sources connects your application to the world. But sending data from Flash connects your users to the outside world. There are many ways Flash lets you write data. Generally, it's just a matter of changing the direction of flow in the four "reading" methods described earlier. The only catch is when sending data out of Flash you'll usually need someone listening on the other endnot so much a person, but rather an application server that can take the data and insert it into a database, for example.

This discussion doesn't cover all the ways your application server can process data. Instead, this discussion just covers how to get it out of Flash. In fact, Flash Pro ships with several data components that automate this process. It's pretty cool because they can even send just the portion of data that changes in order to reduce bandwidth. The thing is, you don't need Flash Pro to write data to a database, but the alternatives are so much more cumbersome that I think it would be a disservice to cover anything except the best way possible.

Keep in mind there are other reasons to write data in addition just to dumping information into a database. Perhaps you want to let the user fire off an email to a friend with a link to the greeting card the user just produced (with your app). In this case, you have to get the data out of Flash, but it doesn't need to go any further than an email that gets sent out. My point is it's really up to you what you do with the data after it leaves Flash. This discussion focuses on the mechanics of preparing the data and then sending it.

In addition to writing data in "traditional" ways, you'll spend a fair bit of time in Chapter 6 using SharedObject Local and the local connection objects. The SharedObject Local enables you to save data on the user's hard drive, so that when the user returns you can pick up where he left off or recall other data he saved locally. The local connection object enables you to send message data to other movies running on the user's machine. This makes multiwindow applications possible in browsers as well as in Macromedia Central (discussed later this chapter).

Synchronizing

The concept of synchronization involves ensuring everyone is looking at the right data. If you're talking about a live application where multiple people are connected simultaneously , you'll likely want to make sure they're all in sync. In more traditional applications, the user may be making adjustments to data, but you don't necessarily want to send an updates over the Internet for every tiny change. For example, as users edit a text field, you probably don't need to send an update for every character they typewaiting until they click submit is fine.

Selecting a logical time to send updates is just a matter of analyzing your application. The challenge arises, however, when you must resolve a conflict. If any user is allowed to change the title of a shared document, for example, and two people both try to change it, you've got to handle the situation gracefully. Being aware of the potential is half the work. Addressing this issue is really just a matter of letting users "request" to make a change, and then, if there's a conflict, giving them the information that their attempt failed. You'll see the technical issues with this approach in Chapters 8 and 9 during the coverage of the Flash Communication Server. But like I say, being aware is half the workso you'll be able to apply the same concept to any application. The general tip I'll give you now is to try to identify areas of possible conflict and think of ways to address these cases (functionally, not technically).

Ensuring Successful Data Exchange

Any time you read or write data, there's a chance it will fail. If the user loses her Internet connection, for example, obviously data can't transmit. It's really easy to build an app without considering such possibilities. Try to resist that temptation .

There are two general problems for which you should account: A known error is encountered , or such a long delay persists that you should cancel the operation. Both Flash and most outside tools have a set of known possible errors for which they'll notify you. If you attempt to load a JPG file that doesn't exist, for instance, an error displays in the output window. (There's actually a new feature in Flash MX 2004coincidentally called the Error objectthat enables you to write your own runtime error messages, along with the code that reacts to it.) The two sides to dealing with error messages are, first, the operation must have a built-in set of error codes, and, second, you need to write code that follows up when such errors occur.

As for timeouts, many operations have a built-in timeout error. If you attempt to connect to the Flash Communication Server and the server was turned off, for example, Flash generates its own error message after about 10 seconds. Quite often, however, if the Internet connection is down or you attempt to read data that just doesn't exist, Flash just quietly waits, and waits, and waits. Because such operations are asynchronous, your movie will, thankfully, continue to run while it waits. However, you really ought to account for the possibility that an operation will fail.

Ensuring data is exchanged comes down to the following general approach:

1. Define the script that receives data when successful.
   
   
2. Define the scripts that react to possible errors.
   
   
3. If you're using an outside application server, make sure the scripts you are calling always return either an error, the data you were seeking, or just a "success" notification (if no data was supposed to get sent back).
   
   
4. Start a timer that will trigger after some acceptable timeout period (and scripts 1 and 2 above clear that timeout, because it won't be needed if either of those trigger).
   
   
5. Finally, attempt to send or request data.
   
   

Like I say, it's easier to just do steps 1 and 5. In fact, that's all you needwhen everything is working. Suppose you prefer to make your app "silently fail" and just continue like nothing happened . If users click login and nothing happens, for example, they'll probably attempt again. Although you could certainly improve this experience by giving users more information, there are definitely times when no error trapping is necessary. Having said that, you really ought to try to account for every potential failure.

Web Services

I've mentioned web services already because they're so darn useful, but I think it makes sense to define them here. Consider how a company might make a web site that gives you access to its data. Building such a site requires more than just structuring the data; the presentation must be designed. For users to access the data, they must visit the site and interact with the given interface. That's fine, but web services make that general task (accessing information) possible without the visual interface.

The way it works is a company can make available any or all of its data via a web service. This involves a definition file (WSDL, for Web Service Definition Language) that defines how an outside developer can make requests for data. This file mainly defines the methods, the parameters they accept, and the sorts of data that get returned. Then a developer can make a SOAP request (over standard HTTP), and the data will be returned. Without getting into more details, consider what this means. Through web services, I can track my UPS package and I can search Amazon's book collection. Of course I can do all that through the respective companies' web sites, too. If I use Flash as the user interface and a web service behind the scenes, however, I can take the data returned and present it however I choose inside Flash. For a company that makes its data available, it means that data may reach more people than would otherwise be possible through its main web site. In fact, many web services are free, but many require that you first register for an ID number (called a key or token) so that they can track your activityor, where you agree, charge you accordingly .

Generally, I think companies correctly see web services as a way to give their data more reachnot so much a direct moneymaker. This may change. For now, however, web services make it possible for you to put a "Flash face" on any data available. Visit www.xmethods.net to see just some the available web services. A memorable moment for me was building a quick Flash app (while sitting in my rocking chair ) that let me type a message and my own phone number, which then rang and a computer voice read my message. Maybe I'm a geek, but I thought this was sort of profound.

One quick note: Using Macromedia Central you can build an app that connects directly with an outside web service. Users need to first acknowledge the operation (or set a preference not to ask again). In Flash you always need to go through your own application server to reach out to other web services.

(Actually, exceptions to that restriction are when you test movies and when users run a Flash projector or SWF on their desktop.)

[ LiB ]