Students
Students get a Tuts+ subscription for just $45! Hurry limited offer.
Advertisement

Loading Data with Commands

by

It's very common to load external data (such as SWF files) during runtime, but only when the data is completely loaded can we read or manipulate its content. Usually we have to listen to the complete event dispatched by a Loader or URLLoader object that loads the data for completion handling. Oftentimes, we write code that loads the data in one function, and write code that handles the completion of the loading in another function, but this can be improved by grouping the whole loading process together..

This tutorial demonstrates how to create a loading extension to the command framework in my previous tutorial, Thinking in Commands part 1 of 2, to pack the loading the completion handling into one place. This loading extension can also be combined with the scene management framework covered in Thinking in Commands part 2 of 2. Many classes used in this tutorial are covered in the previous tutorial, so I highly recommend that you read the previous tutorials before going on.

Additionally, this tutorial introduces the concept of data manager, a central "bank" that stores references to data objects. You can register data to the data manger with a unique key string, and later access the data by providing the corresponding key string. This spares you the trouble of keeping references of data objects and some variable scope issues.

By the way, you'll need the GreenSock Tweening Platform in order to complete these examples.


Why Load Data with Commands?

Normally, we handle the loaded data inside the complete event listener function. This breaks apart two chunks of code that are logically connected. And by looking at the code, your flow of thought might be interrupted as your sight jumps from the loading function to the complete event listener.

Let's look at the logic flow of a naive SWF loading approach.

The loader loads a SWF from a URL, and the onComplete() function is invoked by the dispatchEvent() method that dispatches a complete event, where the dispatchEvent() method is invoked internally by the loader. Well, actually, it's invoked by the LoaderInfo object that belongs to the Loader object, but for simplicity, let's just say the dispatchEvent() method is invoked by the Loader.

Next, within the onComplete() function, the doMoreStuff() function is invoked after the loading completion handling is done and, as the function's name suggests, does more stuff.

The high-level logic flow is very linear: invoke the Loader.load() method first, onComplete() second, and doMoreStuff() third. However, as you'll notice from the diagram, each function's invocation is embedded within the function body of the previous one, resulting in a "nested" code. In my own opinion, if the logic flow of a certain functionality is linear, the associated code should be written in a linear manner, not nested. Otherwise, the code could sometimes become confusing if the invocation nest level is too high.

This is when the Command approach comes into play. From the diagram below, we can see that the code is pretty linear using commands, in that all the commands are linearly chained together by a serial command. Although the program "diverts" into the setProperties(), addChildLoader(), and doMoreStuff() functions; their invocation is linear.


Data Manager

Alright, before we get down to anything further about loading, let's first take a look at the DataManager class. A data manager lets you associate a key string with a data object, and you can obtain a reference to this data object everywhere in your code. With the data manager, you don't have to worry about keeping data references and variable scopes. All you have to do is register a piece of data to the manager with a key string.

The coding is pretty straightforward, as shown below:

So when we want to register a key string "myData" with a data object - say, a sprite - we could write the code as follows:

Later, anywhere in the code, we could write the following code to obtain a reference of the sprite and add it to a display list. It's that simple, no more issues about maintaining object references and variable scopes.


Naive Loading Approach

Now let's take a look at how the naive loading approach loads an external image. The loading code lies in one function and the completion handling code lies in another. We are going to load three images and add them to the stage when the loading is complete. Also, we'll monitor the loading progress by listening to the progress events.


Step 1: Create a Flash Document

Open Flash and create a new Flash Document.

Step 2: Create a Progress Bar

Draw a progress bar on the stage; this is for representing the loading progress. Convert the entire progress bar into a symbol and give it an instance name of "progressBar_mc". Within the progress bar symbol, convert the inner progress bar into another symbol, and give it an instance name of "innerBar_mc".


Step 3: Prepare the Images

Place three images in the same folder as the FLA file, named "image1.jpg", "image2.jpg", and "image3.jpg". Here's what the three images look like.


Step 4: Create the Document Class

Create a new AS file for the document class for the FLA file. The code is pretty straightforward, and all the details are explained in the comments. First, three loaders are created and the loading begins. On each progress event, the progress bar is updated. When the loading is complete, the progress bar fades out and the three images fade in one-by-one.


Step 5: Test the Movie

Press CTRL+ENTER to test the movie. You'll see that the progress bar immediately fades out and the three images fade in. That is because the images are local files, meaning they can be loaded almost immediately. To simulate online download speed, first select the View > Download Settings > DSL as the simulated download speed, and then press CTRL+ENTER again without closing the test window to start simulating online downloading. This time you shall see the progress grow progressively wider before it fades out.

Okay, it's time to load the images with the command framework.


Utility Commands

Before we proceed, let's create some utility commands that will be used later in the example. Again, these command classes are based on the command framework presented in my previous tutorial (Part 1), and I highly recommend that you go through them before going on. If you've read the tutorial before, you can always head back if you need your memory refreshed.

Data Managers Commands

Here we are going to create two commands for registering and unregistering data for the data manager class. The RegisterData command registers data to the manager, while the UnregisterData command unregisters data.

The LoaderLoad Command

This command encapsulates a Loader instance's load() method. You may provide an onProgress command that is executed upon each progress event and an onComplete executed when the loading is complete. Note that the complete() method is invoked when the loading is complete. This line of code is extremely crucial. If you do not invoke the method, the command will never be regarded as complete, jamming your entire application in the worst case scenario.

The InvokeFunction Command

This command encapsulates the invocation of another function. It is designed to allow you to provide an extra parameter array for the function to be invoked.

That's it. Time for the example.


Step 1: Copy the Flash Document File

Copy the FLA file from the previous example to a new folder and copy the image files along with it.


Step 2: Create the Document Class

Create a new AS file for the document class of the copied FLA file, named "LoadingDataWithCommands". Remember to change the document class name in the FLA file to this new one.

The code for the document class is pretty clean. It simply sets the current scene to a LoadingScene with a scene manager. We are using the scene framework presented in my previous tutorial (Part 2). You can check it out if you've forgotten how to use it.

There are two scenes in total. The LoadingScene loads the images and updates the progress bar. After the loading is complete, the scene transits to the MainScene, which fades in the loaded images.


Step 3: The Loading Scene

Extend the Scene class to create a new class named LoadingScene. The container property holds a reference to the main sprite. This allows us to access the progress bar later.

Now, create the intro command for the loading scene. The intro will create three loaders and begin the loading process. This is done by overriding the createIntroCommand() method. The following code goes into the class body, same as the constructor.

Next, override the onSceneSet() method. This method is invoked when the intro command is complete, indicating that the loading is complete. Within this method, we tell the scene manager to transit to the main scene. Before the scene transition, the outro command is executed first.

And then override the createOutroCommand. This command shall fade out the progress bar.

Finally, create the onProgress method invoked by the InvokeFunction commands.


Step 4: The Main Scene

Now create a new class for the main scene, extending the Scene class.

Override the createIntroCommand() method. This method will add the loaders to the display list, and fade them in one-by-one. In addition, the data key strings are unregistered from the data manager.


Step 5: Test the Movie

Alright. We're done! Test the movie and simulate online downloading. You will see the exact same result as in the previous example, but this time it's all done with the command framework and the scene framework.


Summary

In this tutorial, I've shown you how to load external images with the command framework. The LoaderLoad command can be used to load external SWF files, too. Moreover, you can create your own commands to load external data other than images and SWF files, by encapsulating the URLLoader class into your commands.

We've written more code in the second example than the first one. Remember, the purpose of using the command framework and the scene framework is not to achieve the same result with less code, but to manage the code in a systematic and modular approach, making your life easier when it comes to future maintenance and modification.

The first example squeezes all the code into one single class, making it difficult for future maintenance if the code amount should grow extremely large. The second example, on the other hand, separates logically independent code into different scenes, making it easier for future modification. Also, by integrating with the command framework and the scene framework, we've made room for future extension, where we can add more scenes and intro/outro commands without disrupting irrelevant code.

This is the end of this tutorial. I hope you enjoyed it. Thanks for reading!

Advertisement