Flowcharts


Now that the UI is in place, my team is ready to create a flowchart diagram that will map out the typical flow of the application. It is not meant to encompass all possible scenarios; rather, it will be used to start off the development process and provide an outline for functionality. The flowchart that my team came up with represents the flow a user might encounter when playing a song (Figure I-2.9).

Figure I-2.9. Typical flow of a user playing a song.

graphics/01fig09.gif

To begin, a user will launch the jukebox, and then the jukebox will look for a SharedObject, which will store user preferences.

SharedObject

A SharedObject is a powerful new feature with Flash MX. Shared Objects can exist on either the client or the server and can be used to share and store data. SharedObjects on a server can be used for real-time communication, such as maintaining a buddy list in a chat session or collaborating on a whiteboard. To use SharedObjects on the server, the Flash Communication Server is required. When SharedObjects are stored on the client, as in this case, they can be used to maintain locally persistent data. What this means is that when a movie is closed, the user will be able to save data locally so that the next time the movie is opened, the data will persist. For the jukebox, we'll be using a SharedObject to store a user's jukebox settings. The settings will include volume level and balance, information about the last song played, and the playlist. The next section covers another use of SharedObject, whereby a user will be able to enter expense reports offline. We discussed storing the user settings in a database on the server but realized that this wasn't necessary with the introduction of SharedObjects. By storing the settings on the client, we're able to avoid taxing server resources such as bandwidth and data storage and retrieval. In order to store data locally without the use of SharedObjects, one would have to create the jukebox as an executable that is made to read/write from the file system, something that is not in the realm of ActionScripting and the Flash Player.

SharedObjects will work well with the jukebox and other applications for local storage of nonessential data. For critical or private information such as inventory levels, passwords or credit card information, storing the information in a database would be better than storing information in a SharedObject. By storing critical information in a database this ensures that users do not have to sync up with the database, as would be the case with SharedObjects, rather the critical information would be coming directly from the database. For security reasons, it's safer to store private information on the database since parts of a SharedObject file can be read by opening the local file.

NOTE When my team first heard of shared objects in Flash MX, we were very excited. SharedObjects opened Flash to the realm of offline applications. In addition to the expense-report application mentioned above, other applications could include a presentation builder that saves slide shows, a scheduling calendar, or an order-tracking system for delivery people.

In the flow of the jukebox, the first step is to check for a SharedObject containing the jukebox settings. If the user has a SharedObject, then the data from the SharedObject will be transferred to the jukebox. After the settings are moved to the jukebox, the playlist is also transferred to the jukebox. If the user has a playlist, then he or she can proceed with playing a song. If the user does not have either a SharedObject or a playlist, then he or she must search to retrieve a song. When a user initiates a search, a ColdFusion component is called to return the search results via Flash Remoting.

ColdFusion Component

A ColdFusion component (CFC) is a file written in CFML that contains application functionality. The functionality can include querying a database for a list of employees, updating a record in the database, or authenticating a user. CFCs can also be made available to a number of clients, such as the Flash Player or CFML, or exposed as a Web service. A component performs one or more functions that are accessed by calling a method. CFCs are an awesome and much needed feature of ColdFusion MX. CFCs enable the separation of business logic from the presentation layer and can be used from a variety of requestors, resulting in a more optimized architecture that results in easier maintenance and scalability.

For the jukebox, a CFC will be used to query the database and return the results based on a search string. If the search returns results, the user will be able to add the song to the playlist and then play it from there. If the search does not return any songs, then the user can enter another search string to search for songs to add to the playlist.

Macromedia Flash Remoting

Macromedia Flash Remoting is new with ColdFusion MX but is also available with Macromedia Jrun 4, a Java application server, and as a stand-alone product. Flash Remoting simplifies the development of Flash applications by allowing a developer to connect to remote services using ActionScript. Flash Remoting enables a developer to exchange data with remote services including ColdFusion components and pages, EJBs, Java classes, and .NET components.

What this means is that an ActionScript object can be associated with a service object on the server and hence can call any of the methods defined in the service object. For example, if a car manufacturer wants to create a Flash MX movie that displays details about a car, the Flash developer can first assign an ActionScript object to a CFC service object, Car, and then directly call one of its methods, getDetail(), from the ActionScript object. The results will then be returned to the Flash movie and can be displayed.

For the jukebox, Flash Remoting will be used to access a ColdFusion component that will return the search results. Flash Remoting also includes a debugger that allows a developer to see client and server communications. This is extremely helpful when trying to figure out what is being sent between the client and server.

Before Flash Remoting, my team would use loadVariables() or XML.load() to send data between the client and server. Using loadVariables() entailed working with name/value pairs and oftentimes splitting a string using a delimiter into an array. Using XML required preparing the XML on the server, which tied up server resources, and then parsing through it on the client. In addition, with the Flash 5 Player there were performance problems with parsing XML documents. Although, the problems have been addressed with the Flash 6 Player, Flash Remoting is still preferable over XML files. With Flash Remoting, a result is returned from the server, and retrieving the values from the result is as easy as looping through an array. In addition, data is sent between the client and server using the Action Message Format (AMF) over HTTP, which provides a lightweight binary transfer. Initially we considered using loadVariables() with the jukebox but after investigating Flash Remoting in conjunction with CFCs we saw how easy and efficient it was to use over the old ways of sending and receiving data.

Although Flash Remoting and many of the UI elements discussed for the jukebox require the Flash 6 Player, this hurdle was fortunately avoided since the main Morning Records site requires the Flash 6 Player.

With the UI and flowchart done, my team can now begin the development work on the jukebox.



Reality Macromedia ColdFusion MX. Macromedia Flash MX Integration
Reality Macromedia ColdFusion MX: Macromedia Flash MX Integration
ISBN: 0321125150
EAN: 2147483647
Year: 2002
Pages: 114

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net