3.5. Testing and Debugging Network Connections
Networked applications present
some additional
difficulties when testing or debugging programs, as more than one
system is always involved. A connection attempt may fail for many
reasons, including the following:
The target URI may be incorrect (watch for typos). A username or password may be wrong. The maximum number of licensed clients or maximum licensed bandwidth
of the server may have been exceeded. The network may be down or unreliable. A connection that worked fine in a test environment may fail because
of a firewall or proxy server.
Often, the best way to understand why a network connection fails is
to display all the properties of the information object returned to
the onStatus( ) method. In addition, at least
until the target URI is proven to be correct, the return value of the
connect( ) method should always be checked. If
it is false, the URI was malformed and should be
corrected. It is a good idea to begin building a movie by always
creating a default, diagnostic onStatus( )
handler as in Example 3-1. When the
connection has been tested, you can replace the onStatus(
) handler with one more appropriate for your needs.
Unfortunately, problems aren't limited to the
beginning of development. As both client- and server-side scripts
evolve, diagnosing the cause of a sudden loss of connectivity is
difficult. To help diagnose the problem, build simple test movies
that can be run outside the development environment. In fact, this is
an important technique for testing much more than basic connectivity.
3.5.1. Test Client Movies
An excellent way to help debug connections is to write a test
movie
that includes a few basic components, such as:
A large scrolling text field with scrollbar Connect and Close buttons Fields for a target URI and other connect( )
method parameters, such as username and password
Instead of using trace(
)
statements, use a writeln(
) function such as the one in Example 3-2 to output information to the scrolling text
field. A sample test movie is supplied on the book's
web site (http://flash-communications.net).
3.5.2. Using the NetConnection Debugger
Separate from the Flash MX 2004 ActionScript
debugger, Macromedia supplies a NetConnection Debugger with the
FlashCom Server (and with Flash Remoting). The NetConnection Debugger
can display client- and server-side connection-related events such as
connect requests and remote method calls and their results. To obtain
the NetConnection Debugger, download and install the Macromedia Flash
Remoting MX Components from:
- http://www.macromedia.com/software/flashremoting/downloads/components
Once installed, to use the NetConnection Debugger, place the
following include instruction on the first frame
of the Scripts layer of your main timeline:
#include "NetDebug.as"
Then select Window
NetConnection Debugger from Flash's menu bar to
start the debugger. To see server-side events, you must log into the
administration server (Admin Service) using an administrator username
and password, as described in Chapter 1. If the
Filters section of the NetConnection Debugger, shown in the bottom
half of Figure 3-3, is not open, click on the small
triangle to open it. Enter the administrator's
username and password; make sure the Flashcom_server, RTMP, and Trace
checkboxes are all selected; and run your movie in the Flash
development environment. Figure 3-3 shows the
NetConnection Debugger after a failed attempt to connect to the
server.
Click on an event in the Events list and select the Details tab to
see the full details about each event. Client-side events are
indicated by the Flash logo, and server-side events are indicated by
the FlashCom logo. In Figure 3-3, the Close event
details are shown. Following it in the Events list is a server-side
event that reports that the application was eventually unloaded
because no other clients were connected to it. Provided a
.swf was compiled with the
NetDebug.as file included, it can be run outside
the authoring environment and its connection-related events will
still be displayed in the NetConnection Debugger. As your projects
evolve and you are debugging increasingly complex scripts, this is
another good reason to keep around some simple test movies.
 |
Remove the ActionScript to include NetDebug.as
in your final movie after you no longer need the debugging features.
It adds unnecessary file size to the published
.swf.
|
|
|
