13.1 Debugging Flash Remoting Applications

Flash is a complex environment, and adding Flash Remoting to the equation only increases the complexity. You must contend not only with the visual aspects of your Flash movie and the underlying ActionScript, but also the server-side code, the database code, and the HTTP connections. There are quite a few pieces that make up the client/server environment of a Flash Remoting application, and quite a few places where your application can go wrong. Debugging a Flash Remoting application involves complex interaction between all of these environments, as well as the ability to separate the parts of the application so that they can be examined without the added burden of the sum of all the parts. Refer to the best practices offered in Chapter 12 for ways to isolate the various portions of your program to ease development and testing.

13.1.1 Types of Errors

Errors in any programming environment can be divided into several logical categories (although see "Error Types" in Chapter 3 for additional discussion of potential sources of errors):

Syntax errors

Errors caused by incorrect use of code. This could be a simple use of a programming construct in the wrong way, or using some programming construct that doesn't exist in ActionScript. These are usually caught at compile time. Previewing in Flash is considered compile time.

Typographical errors

Errors caused by simply mistyping a piece of code. Color coding is a big help in finding these types of errors; many times a misspelled keyword does not have the correct color coding on it, which is a dead giveaway that something is rotten. These errors are occasionally caught at compile time, but the more insidious ones can slip through if they are otherwise valid code.

Logical errors

Errors caused by improper logic in your code. These are often the insidious errors that don't cause a total failure of the application, but instead introduce errors in program results or introduce only occasional errors. Intermittent bugs are often the hardest to detect and solve. They are hard to detect because they happen only under certain conditions, which may be hard to reproduce. They are hard to solve because if you can't reliably reproduce a bug in the first place, you can't confirm that your fixes have solved the problem.

All of these errors can be tracked down through the debugging process. Many times, having someone else look at your code can help you more than hours spent debugging alone. The fresh set of eyes can spot a problem that you have missed or don't realize is a problem. You can use a coworker or post a problem piece of code to a support newsgroup or forum. Getting this far, however, means that you know where the problem lies. Many times, this is not the case.

13.1.2 Dissecting the Application

A Flash Remoting application flows through the following processes:

Flash client
  ActionScript code
          HTTP server
                  Application server
                          Flash Remoting gateway
                                  Server-side code
                                        Database server
                                        Filesystem
                                        Email system
                                        Other server-side components
                                  Server-side code
                          Application server
                   HTTP server
          Flash Remoting gateway
  ActionScript code
Flash client

A bug can occur in any of these areas, but to find the bug you have to know where to look and how to look for it. The Flash authoring environment provides many of the tools that will help you pinpoint a problem, but it is only the messenger; the error messages can help you determine where to look for the real problem.

Beginners often flounder with guesses and suppositions, while experienced developers rely on their debugging tools. For Flash Remoting applications, you can start you investigation with the NetConnection Debugger panel, as discussed in this chapter. Of course, to use any debugger effectively, you must have the foundational knowledge of the technology (which you should have after getting this far in the book) and you must have some knowledge of what component of the application performs a particular task. This might sound a bit simplistic, but people coming from Flash-only backgrounds often have trouble determining where a particular error is occurring, such as on the server. (This is doubly true if you are not the original developer of part or all of the application.) For example, a typical error message might look like this:

"Error connecting to Northwind"

What does it mean? The reason for the error could be, but is not limited to, one of the following:

  • Bad username or password

  • No database driver

  • Wrong database driver

  • Wrong format for connection string

  • Bad server-side code calling the database

  • No permission to access a database object, such as a table or stored procedure

Therefore, one of the keys to being able to pinpoint problems is knowing what does what. You must be able to track the logical progression of your code to determine where the error originates. As with most error messages, there are several different reasons why the error may be occurring. A little detective work may be involved:

  • If your ActionScript code is passing anything to the database, you can start there.

  • If not, look at your server-side code. The error could be a mistyped piece of code or connection string.

  • You can also try logging on to your database directly and executing the code from there; many users log themselves on as an administrator when developing an application, only to find out that the permission levels they are using in an application are not working for all objects. Database servers like SQL Server allow you to set individual permission levels for each object. Make sure the permission levels are correct for the query you are running.

  • If you are running a file-based database like Microsoft Access, make sure your web server has the appropriate permissions to access the database file.

All of these different error situations can be tracked down with a little bit of know-how and some digging. The Flash environment contains two debuggers to aid in this detective work?the Flash ActionScript interactive debugger and the NetConnection debugger. The ActionScript debugger is always available during authoring by choosing Ctrl Debug Movie (or if you're already testing the movie, it's Window Debugger). The NetConnection debugger is used for Flash Remoting. To activate the NetConnection debugger during authoring, include the NetDebug.as file in your Flash movie. This allows the NetConnection Debugger panel to become active and report problems as they arrive from the server.

13.1.3 Consistency

One of the best ways to avoid extensive debugging periods is to write your code with consistency. This includes such things as coding styles and conventions, variable naming conventions, comments and documentation, and readability. The important thing is not which convention you decide on, but that you stick to a convention. For example, some people prefer to format their loops like this:

for (i=0; i < 10; i++)
{
  print("something");
}

This is a perfectly acceptable convention, as is this (which we use in this book to save vertical space):

for (i=0; i < 10; i++) {
  print("something");
}

I find that the second approach makes it easier to spot bugs like this, in which the semicolon ends the for loop unintentionally:

for (i=0; i < 10; i++); {
  print("something");
}

I find such bugs harder to spot when code is formatted like this:

for (i=0; i < 10; i++);
{
  print("something");
}

Consistency in variable naming is also important to debugging. If you have a convention of capitalizing the first letter in each word (except the first word), don't deviate from that in your code:

myFirstName = "Tom";
myLastName = "Muck";
myZIP = "22193";

The last variable does not follow my capitalization convention, so I might be prone to write it like this elsewhere in the code:

myZip = "22193";

In ActionScript 1.0 (when played in Flash Player 6), the case difference does not matter (at least with regard to variable names), and myZIP and myZip refer to the same variable. In other languages, like ActionScript 2.0, Server-Side ActionScript, ECMAScript, Java, or C#, myZIP and myZip refer to different variables, which could be difficult to debug. ActionScript 1.0 is also strictly case-sensitive when developed in Flash 2004 or Flash Pro and exported in Flash Player 7 format. See Reference Guide ActionScript Basics Syntax Case Sensitivity in the Flash 2004 and Flash Pro Help window for details.

Spacing is another key issue in writing code. Whitespace is in many ways just as important as the actual code; without whitespace, your code is unreadable. Consider this query:

SELECT c.CustomerID, c.CompanyName, c.ContactName FROM Customers c INNER JOIN Orders 
o ON c.CustomerID = o.CustomerID INNER JOIN [Order Details] od ON o.OrderID = od.
OrderID WHERE c.Country = 'USA' GROUP BY c.CustomerID, c.CompanyName, c.ContactName 
HAVING count(o.orderid) > 5

It's not very pretty, and it's not easy to spot where the bug is, or even if there is a bug. The query is supposed to retrieve all customers from the USA having at least five items in their order. When you run the query on the Northwind database, you get about 12 results. After reformatting the query with whitespace for readability, you spot the error more easily:

SELECT
  c.CustomerID
, c.CompanyName
, c.ContactName
FROM Customers c
  INNER JOIN Orders o
    ON
      c.CustomerID = o.CustomerID
  INNER JOIN [Order Details] od
    ON
      o.OrderID = od.OrderID
WHERE c.Country = 'USA'
GROUP BY
  c.CustomerID
, c.CompanyName
, c.ContactName

HAVING count(o.OrderID) > 5

The query should have been written with the OrderID column listed in the GROUP BY clause, as shown in bold (the initial portion of the query remains the same):

WHERE c.Country = 'USA'
GROUP BY
  o.OrderID
, c.CustomerID
, c.CompanyName
, c.ContactName

HAVING count(o.OrderID) > 5

Now the query returns three results, which is correct. Queries are much easier to debug when you write them clearly with whitespace. The first query might have taken a long time to debug, yet I have seen plenty of cases where people write their queries like this.

Commenting your code is extremely important as well. Sometimes, a well-placed comment can alert you to a bug in the code that you would normally not spot immediately. If the preceding query had included the following comment, containing the word "order," a trained developer would realize the order ID was missing from the GROUP BY clause:

-- Get all US orders that have more than 5 items

13.1.4 Feature Creep

Why is feature creep being discussed in a chapter about debugging and testing? Most projects have a plan in place that specifies exactly what the application will do and how it will do it. Feature creep happens when you don't stick to the plan. During the debugging and testing phase, adding a new feature increases the likelihood of new bugs being introduced into the application, causing delays in the entire process. For this reason it is usually best to note the new features and implement them in the next version of your software, rather than try to get them into the current version.



    Part III: Advanced Flash Remoting
     
    ASPTreeView.com
     
    Evaluation has ЪКИёЦexpired.
    Info...