The Demo

The purpose of the demonstration was to provide Simpleton with a visual understanding of the email application. This would help answer questions about how the application works, along with what was done and why. Initially, the application was demonstrated from one of Simpleton's development servers running locally. Once FlashFusion receives approval of the application, it will be moved to a production server and made accessible to Simpleton's employees and clients. It is always good practice to make a newly deployed application accessible to a small group of beta users, so FlashFusion will suggest this to Simpleton.

Flash UI

For demonstration purposes, a temporary email account was created on the mail server. The purpose of this was for Simpleton to become familiar with the email client before using it to access a live email account. This account will be used to test logging in to the application as well as sending and receiving email. Once the application is initialized, the first screen displayed is the account-settings dialog box (Figure III-4.1).

Figure III-4.1. Account settings dialog.

The user can add his email information and choose whether or not to have his information stored locally. The CheckBox component ("Remember my account settings") is checked by default; it tells the application to save the user's information. This can just as easily be turned off by default. If the user wishes to have his information stored, this is accomplished through a local shared object, which can access information on the user's machine (similar to cookies). This will make it easier for returning users who do not wish to enter their information every time they access the application. If a user has selected to have her information stored, she can reverse this by deselecting the CheckBox component and proceeding with the account setup. All information will be deleted and her settings will only exist for the current session.

The account-settings dialog box is also accessible throughout the application by clicking the Account Settings button. If a user wishes to change information or even decides to have information stored or removed, she can do so here. This process is similar to configuring account settings in other desktop email applications.

After the user has successfully logged in, his email is displayed in the Flash user interface. A status message is displayed in the lower-right corner of the interface, showing how many email messages reside on the server (Figure III-4.2).

Figure III-4.2. Status message displaying number of email messages.

After the email has been retrieved from the server, it is stored and accessed locally until the next time the user checks her mail. When this happens, the local data is overwritten with the new data from the server. This allows the user to have the most up-to-date information stored locally. The next time the user needs to view her email without an Internet connection, the information is retrieved from the local shared object. Storing information locally speeds up data access times while minimizing the number of trips to the server.

The limitation of not having an Internet connection is that email messages can only be read. The user cannot save a draft of a message until the next time he is connected to the Internet. This will be considered in future revisions and can be accomplished fairly easily using a local shared object.

Now that the user has logged in, the email data is queried from the server and is used to populate the ListBox component. This component is perfect for handling the email header information. The component scrolls based on the number of messages displayed in the ListBox. Users have the ability to interact with the ListBox by using the mouse or the up and down arrow keys. Multiple messages can be selected using Shift-click (Macintosh) or Ctrl-click (Windows). This is convenient when selecting messages to move to specific folders.

Once an email message is selected, the user can reply, forward, or delete it. If the user clicks Forward or Reply, the correct message fields are pre-filled, allowing the user to fill in the rest of the information (Figure III-4.3). The same component ("messageClip_mc") is used for creating, replying, and forwarding messages. If the Delete button is clicked, the message is deleted from both the Flash UI and the mail server.

Figure III-4.3. Reply window with fields pre-filled.

The Tree component is used to handle the user's email folders. Initially the only folder available is the user's Inbox. The user has the ability to add and remove folders at her leisure. The folders are sorted alphabetically within the Tree component, with the Inbox always being listed first. The folders are also stored in a local shared object so that the user doesn't have to manually create folders each time the application is accessed. When messages are moved to folders, they are linked behind the scenes so that this information is also recorded. By default, all messages are displayed in the Inbox when the application is first initialized.

When messages are to be moved to a folder, the user clicks the IconButton ("moveButton_mc") component. The IconButton displays an arrow pointing to the folder tree. The button is not enabled if no messages are selected in the ListBox. If one or more messages are selected, the IconButton is enabled. Once this button is clicked, a pop-up dialog box appears, prompting the user to select a folder to which the messages should be moved (Figure III-4.4).

Figure III-4.4. Pop-up dialog for moving emails to certain folders.

After the messages have been moved to their respective folders, they can be accessed by selecting the folder from the Tree component. The messages in the folder will then be displayed in the ListBox component.

This is a brief overview covering the client side of the application. The order of procedure is not important here as long as the user has logged in to the application and it has been initialized. After initialization, it is up to the user to interact with the application to provide an effective means of communication via email.

FlashFusion used components extensively throughout the application to provide increased functionality that can be reused in future applications. The components also helped speed up the development process. The project, which only took a month to develop, could have taken several months if many of the components had to be developed from scratch.Simpleton's developers will be able to drag and drop these components into future applications to help speed the development process while providing functionality that has been tested and performs correctly.

ColdFusion CFCs

The CFCs developed for this application can be leveraged in future Simpleton applications. FlashFusion developed the CFCs with this in mind, along with providing the ability to access the components from services other than Flash. This will be useful if Simpleton decides to build an application that uses the POP or SMTP protocols. Both the Pop and Smtp CFCs will allow remote services to access component methods to receive and send email (Figure III-4.5).

Figure III-4.5. Component interaction with Flash, Web Services, and the mail server.

Since the code for the CFCs is encapsulated, it will allow Simpleton's junior-level developers to pass information to the components. They don't have to know what is going on inside the CFC but just need to know what parameters are required. Simpleton is excited about the doors ColdFusion MX will open, and its developers will be able to start building the next generation of Web applications.