Object-Oriented Implementation

There are alternatives to the technique we chose in the highscore MovieClip. Our technique was not a sophisticated approach: we call the load action and then run through a loop, testing the data to see if it arrived or not. This solution, known as polling, is not object-oriented. Modern object-oriented coding is associated instead with event-driven methods .

In the polling design, the calling function constantly tests the status ”both functions are locked together. In an event-driven method, event handlers must be set up. After that, it is the actual occurrence of the event that calls the function. The rest of the software runs absolutely independently.

There are a variety of events that Flash recognizes and to which we can attach handlers. In this case, we will create a method that is triggered by the data event. But before doing so, the code must be rearranged.

Building the highscore Feature with Objects

We can easily change the highscore clip. It now has three static frames :

  • StartLoad frame

  • LoadedOK frame

  • LoadFailure frame

The last two have no code, although LoadedOK has text that displays the value of the score variable.

The StartLoad frame has this code:

 function dataLoaded( ok ) {    score=highscore;    gotoAndStop( ok?  "LoadedOK":"LoadingError" ); } loadVariables ("highscore.txt", this); stop(); 

The first frame defines the event handler for the Flash data event. (The data event occurs when the loadVariables function is complete.) The script then calls loadVariables, and stops.

Now we need to assign the event handler to an instance of this object. We go to the Scene (or wherever it has been placed) and click on the highscore object. If the first frame is free of graphics, this object is tough to see. It is represented by a white dot when it is not selected and tiny crosshair when it is.

Clicking on the highscore instance allows us to program Object Actions. We want to attach our event handler:

 onClipEvent(data){     dataLoaded( true  ); } 

When we compile it, it works. It is object-oriented and event-driven, and we are committed to those techniques. But is it a better solution? Object orientation is an approach to programming, not a religion. It is usually a cleaner, safer path . But sometimes it is not the best way to solve the problem.

This design has two shortcomings. First, it has no timeout event. This oversight prevents us from gracefully managing a load failure. Such problems are hardly uncommon, and software that cannot detect load failure is going to look stupid. It cannot tell the user that there is a problem, nor can it effectively hide the problem. It is poorly positioned to present a preloader display, since it might never come back to clear the display.

Of course, this problem can be fixed. A loop can be created that will maintain a preloader display and test for success while decrementing a time-out counter. This loop would pretty much recreate the loop code that we built in our polling example, and it would have the extra burden of building, installing, and uninstalling an event handler.

Second, the object-oriented design is more fragile. In our previous version, we made a neat plug-and-play highscore board. Any artist could drag an instance of this MovieClip right out of the library and stick it in any level of his own movie. As long as the server provides a score, this high score board will find and display it. Such a simple encapsulated MovieClip would get a lot of use. The object-oriented version isn't so easily incorporated. The user of this object must know that there is work to do after the instance is dragged out of the library. The user must open the object actions of this instance and write code to hook the data event handler to a function in highscore called dataLoaded(). How is the user supposed to know this and have the skills to do it?

A skilled programmer works around this problem by creating a wrapper for the highscore board. The wrapper is another MovieClip within which the instance of highscore appears and which can hide the required housekeeping. It is this wrapper object that is shared with artists and others.

Unfortunately, by the time we have added these extra components , which mimic the natural features of the polling approach, we have lost the usual advantages of object orientation: simplicity, clarity, and reliability. Instead, it is decidedly more complex than its unsophisticated cousin, more difficult to understand, and easier to break (Figure 7.4).

Figure 7.4. Polling vs. Object-Oriented Approach


Flash and XML[c] A Developer[ap]s Guide
Flash and XML[c] A Developer[ap]s Guide
ISBN: 201729202
Year: 2005
Pages: 160

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