How to Debug an App with App Inventor

Tracing an app step by step is one way to understand programming; it’s also a time-tested method of debugging an app when it has problems. The following excerpt from the recent publication App Inventor will help you use App Inventor to debug your application.

---

Tools like App Inventor (which are often referred to as interactive development environments, or IDEs) provide the high-tech version of pen-and-paper tracing through debugging tools that automate some of the process. Such tools improve the app development process by providing an illuminated view of an app in action. These tools allow the programmer to:

• Pause an app at any point and examine its variables and properties.
  
  
• Perform individual instructions (blocks) to examine their effects.

Watching Variables

Probably the most important capability a debugger can provide is to let you examine the value of variables and properties as an app executes—in essence, making the internal memory of the computer visible to the software developer.

App Inventor lets you do just that with its Watch mechanism, shown in Figure 15-4. (The variable definition block hidden from view is for currentQuestionIndex.) As you are live testing on the phone or emulator, you simply right-click any variable definition block within the Blocks Editor and choose Watch.




A box appears that’s connected to the “watched” variable, showing its current value. If you then play the role of the end user and initiate some events in the app, you’ll see the variable’s value change in the Blocks Editor as the user interface changes.

For example, if you were testing the NextButton behavior of a quiz app, you could watch the currentQuestionIndex variable, as shown in Figure 15-5. When the app starts, the variable should contain the value 1.

If you then click the NextButton in the user interface (on either the emulator or phone), the NextButton.Click event handler will be triggered, and the watch box will change when the variable is incremented, as shown in Figure 15-6.







Note that the value in the white watch box is the dynamic value of the variable as the app runs. The number 1 block slotted into the variable definition never changes unless the programmer changes it; it is the initialization value, the value at which the variable will begin if you relaunch the app.

You could continue in this way, clicking the NextButton to test that the event handler works even when the boundary condition (arriving at the last question) is met. For our buggy blocks, you’d see that the index switched to 1 a step too early.

In essence, the Watch mechanism performs the pen-and-paper trace for you and lets you see the “hidden” memory of the app as it runs. It’s a great way to really understand your app and discover bugs!

Testing Individual Blocks

While the Watch mechanism allows you to examine variables during an app’s execution, another tool called Do It lets you try out individual blocks outside the ordinary execution sequence. Right-click any block and choose Do It, and the block will be performed. If the block is an expression that returns a value, App Inventor will show that value in a box above the block.

Do It is very useful in debugging logic problems in your blocks. Consider the quiz’s NextButton.Click event handler again, and suppose it has a logic problem in which you don’t navigate through all the questions. You could test the program by clicking Next in the user interface and checking to see if the appropriate question appears each time. You might even watch the currentQuestionIndex to see how each click changes it.

But this type of testing only allows you to examine the effect of entire event handlers. The app will perform all the blocks in the event handler for the button click before allowing you to examine your watch variables or the user interface.

The Do It tool lets you slow down the testing process and examine the state of the app after any block. The general scheme is to initiate user interface events until you get to the problem point in the app. After discovering that the third question wasn’t appearing in the quiz app, you might click the NextButton once to get to the second question. Then, instead of clicking the NextButton again and having the entire event handler performed in one swoop, you could use Do It to perform the blocks within the NextButton.Click event handler one at a time. You’d start by right-clicking the top row of blocks (the increment of currentQuestionIndex) and choosing Do It, as illustrated in Figure 15-7.

This would change the index to 3. App execution would then stop—Do It causes only the chosen block and any subordinate blocks to be performed. This allows you, the tester, to examine the watched variables and the user interface. When you’re ready, you can choose the next row of blocks (the if test) and select Do It so that it’s performed. At every step of the way, you can see the effect of each block.




Incremental Development with Do It

It’s important to note that performing individual blocks is not just for debugging. It can also be used during development to test blocks as you go. For instance, if you were creating a long formula to compute the distance in miles between two GPS coordinates, you might test the formula at each step to verify that the blocks make sense.

Activating and Deactivating Blocks

Another way to help you debug and test your app incrementally is to activate and deactivate blocks. This allows you to leave problematic or untested blocks in an app but tell the system to ignore them temporarily as the app runs. You can then test the activated blocks and get them to work fully without worrying about the problematic ones.

You can deactivate any block by right-clicking it and choosing Deactivate. The block will be grayed out, and when you run the app it will be ignored. When you’re ready, you can activate the block by right-clicking it again and choosing Activate.