Debugging your Code in App Inventor

As you’re busy building your apps with MIT App Inventor, you’ll definitely run into moments where things don’t quite work as expected. This is totally normal! We call these errors “bugs,” and the process of finding and fixing them is called Debugging.

Let’s learn some tips and tricks for debugging specifically in App Inventor. Mastering this skill will save you a lot of time and frustration!

Lesson Topic: Debugging your Code in App Inventor

Part 1: What is Debugging? (The Moth Story!)

Debugging is the essential process programmers use to figure out why their code isn’t behaving correctly and then fix it.

The term has a fun origin story: In the 1940s, computer pioneer Admiral Grace Hopper was working on an early computer when it stopped working. The problem? A real moth had gotten stuck inside! When they removed it, they said they were “debugging” the system. We still use the term today for fixing code errors.

Part 2: Coding Smarter in App Inventor (Good Habits)

Being patient and following good coding habits can prevent many bugs and make debugging easier when they do occur:

• Patience is Key: Debugging can sometimes feel slow or frustrating. Remember that finding and fixing problems is a normal part of coding. Guma omwoyo! (Be patient/calm!)
• Baby Steps (Code Small, Test Often): This is crucial!
  • Don’t write hundreds of blocks before testing.
  • Do write a small piece of code (e.g., make one button do something).
  • Test it immediately using the AI Companion on a phone/tablet or the Emulator.
  • Does it work? Great! Now add the next small piece.
  • Repeat: Code a little, test a little.
  • Why? If an error occurs, you’ll know it’s likely in the small section you just added!

• Saving Your Sanity (Version Control in App Inventor): Imagine spending hours coding, adding a new feature, and suddenly the whole app breaks, and you don’t know why! Version control saves you from this headache. App Inventor offers two main ways:
  • Projects -> Save project as…: This creates a new copy of your entire project with a different name. Any changes you make from then on are in this new copy. Use this if you want to try a major change without affecting your original.
  • Projects -> Save Checkpoint: This saves a snapshot of your current project’s state with a name you choose (like “v2_LoginWorking”). You continue working in the original project. This is great for marking milestones – if you mess up later, you can easily go back to a working checkpoint via Projects -> Restore Checkpoint. Use checkpoints frequently!
• Clean Workspace (Collapse & Disable Blocks):
  • Collapse Blocks: Right-click on a large block (like an event handler or procedure) and choose “Collapse Block”. It shrinks down, making your workspace less cluttered. Right-click -> “Expand Block” to see it fully again.
  • Disable Blocks: Need to temporarily stop some code from running?
    1. Drag the blocks out of their “parent” block (like an if or when…do). They’ll turn grey and won’t run. Drag them back in to re-enable.
    2. Right-click a block or stack and choose “Disable Block”. They turn grey. Right-click -> “Enable Block” to turn them back on. Useful for testing without deleting code.
• Leave Notes (Comments): Explain your code!
  • Right-click any block and select “Add Comment”. A blue question mark appears; click it to type your note (e.g., “Checks if password is correct”).
  • Why? Helps your teammates, helps the judges, and helps you remember what your code does weeks later!

The “Checkpoint” option will save a copy with whatever name you give it, but you continue working in the original. The idea is to “checkpoint” that version that works and continue your development in the main version of the project.

The “Save project as” option will create a copy of the code you are working on and save it under a new name. Any edits you make will be in the new copy.

COLLAPSE BLOCKS

Collapsing blocks is a way to keep your code organized, as your code workspace starts to get crowded with blocks.

If you right-click on a block, you’ll see an option to collapse it.

To expand your blocks again, right-click on them and select Expand Block.

Collapsed blocks will compress it down to one bar on your screen.

They still work the same as regular blocks, they just take up less space. This can be helpful if you have blocks you no longer need to edit and want to clean up your screen

DISABLE BLOCKS

You can also disable blocks.

They remain on your screen but don’t run in the app.

With disabled blocks, you can test your app without certain code blocks. You can enable them later and they will run.

You can also disable blocks that you have used for testing only, like Notifiers.

There are two ways to disable blocks in App Inventor

Simply dragging blocks out of an event handler block will disable them and prevent them from running. Because they are not part of any event, there is no way they will ever execute. You can always snap them back in to use them.

You can also right-click on a block or group of blocks and choose “Disable Block“. The blocks will appear greyed out to show they will not execute. This way you can disable an entire set of blocks.

To enable your blocks again, simply right-click and choose “Enable Block”.

COMMENTS

Programmers often leave comments in their code to explain what it does. 

Comments can be helpful when other people are looking at your code, such as teammates, mentors, and judges.

Comments can also help if you return to your code later and have forgotten what parts of it do.

To add a comment, right-click on the blocks and select “Add Comment”.

After that, a question mark will appear in the corner of the block and you can add text. You can view the comment by clicking on the question mark.

DEBUGGING TIPS

NOTIFIERS AND LABELS

The Notifier component can help you figure out why your code is broken. 

To put a Notifier in your App Inventor app drag it over from the user interface palette.

The easiest way to use the Notifier is to add ShowAlert blocks with information for you to see that certain blocks have run (or not).

In addition to messages, you can display information like the value of a variable or the position of an ImageSprite.

You can also add Labels to display current information in your app. 

For example, you might want to know the value of a variable as certain events happen while the app is running. 

You can set the Label.Text to whatever it is you want to know and it will display on your app. 

Once you’ve debugged your error, you can either make the Label invisible, or delete it altogether from your app.

DO IT

 The Do it feature is another great tool for debugging.

While you are live testing your app, either with a phone and the AI Companion app, or with the emulator, you have access to a new command, “Do It”.

The command is greyed out until you connect to a phone or the emulator through the Connect menu.

Do it lets you run a block without having to interact with the app itself, so you can see the current value of a variable or element. 

Just drag out a “get global” variable block and right-click. Select “Do It” from the dropdown menu and that block of code will execute.

A yellow Do It box will appear above the box with the result. This can work for any component property too!

You can also use Do It to change something in your app. For example, you might want to change an item in a list. Drag out the block to do that, and select Do It. You won’t see the result, but the list will be updated within your app.

You can also run an existing code block in your app. 

For example, here the ListView elements will be updated using Do It. That will be reflected in the app. The ListView will display the new elements set with the Do It command.

USE TEST DATA

If you have a lot of information to use in your app, it can be helpful to use test data. Test data is a simpler, smaller set of data that you can use to make sure your app is working correctly.

Let’s say you are making an app that displays nearby restaurants. You are using Google Sheets to store the restaurant information.

You can start with just one or two test restaurants and test your app to make sure it works.

Once it’s tested and working, you can add the complete set of restaurant data to your Google sheet.

Part 3: Detective Tools for App Inventor (Debugging Techniques)

When a bug appears, here are some App Inventor tools to help you find it:

• Pop-up Clues (Notifier & Labels): Use these to see what your code is doing while it runs.
  • Notifier: Drag a Notifier component (from the User Interface palette) onto your screen in the Designer (it will appear as a non-visible component). In the Blocks editor, use the Notifier1.ShowAlert block. Set the notice input to display a message (“Got here!”) or, more usefully, the value of a variable (use a get global variable block) or a component property. This helps you trace the code execution and check values at specific points.
  • Labels: Add a temporary Label in the Designer. In the Blocks, use set MyDebugLabel.Text to display variable values, calculation results, sensor readings, etc., directly on the screen during testing.
  • Remember: Delete these Notifiers and temporary Labels (or make the Labels invisible) once the bug is fixed!
• Ask the App Directly (The “Do It” Command): This is a very powerful App Inventor feature for live debugging!
  • How: You MUST be connected via AI Companion or Emulator.
  • In the Blocks editor, right-click on almost any block, especially blocks that get a value (like get global MyVariable or Label1.Text).
  • Select “Do It” from the menu.
  • A yellow comment box will pop up right there in the Blocks editor showing the current value of that variable or property in the running app!
  • You can also use “Do It” on blocks that perform actions (like set global MyVariable to… or call MyProcedure). This executes that block immediately in your connected app. It’s fantastic for testing logic or checking the state of your app in real-time.
• Simplify (Use Test Data): If your app uses lists or external data (like from CloudDB or a Spreadsheet), test your logic with a very small amount of data first. Ensure it works with 2-3 items before trying it with hundreds.
• Instant Feedback (Live Test Property Changes): Just like in Thunkable, if something looks visually wrong during Live Testing (AI Companion/Emulator):
  • Go to the Designer view.
  • Select the component.
  • Change a property (like Width, Height, X, Y, TextColor).
  • Look at your connected device/emulator – the change should happen instantly, helping you fix layout or appearance issues.

Part 4: App Inventor Bug Hunt (Activity 1 – Fix the Timer App – 20 mins)

Time to put your detective skills to work!

Your Mission: Debug the provided App Inventor Timer App.

Steps:

1. Load the App: Download the .aia file from the lesson and import it into App Inventor (Projects -> Import project (.aia) from my computer…).
2. Connect & Test: Connect to the AI Companion or Emulator (Connect menu).
3. Find the Bugs:
   • Press the “Start” button without entering anything in the text box. What happens? (Error/Crash?)
   • Enter 0 or a negative number (like -10) and press “Start”. What happens? (Error/Unexpected behavior?)
4. Fix the Bugs:
   • Go to the Blocks editor for the StartButton.Click event.
   • Use Conditional Blocks (if/else if/else)! Before trying to use the input with the Clock component:
     • Add an if block to check if TextBox1.Text is empty (use a text = “” comparison). If true, use Notifier1.ShowAlert to tell the user to enter a number.
     • Add an else if block to check if the TextBox1.Text (converted to a number) is less than or equal to 0. If true, use Notifier1.ShowAlert to tell the user to enter a positive number.
     • Put the existing code that enables the Clock1.Timer inside the final else section (this code only runs if the input is valid).

Part 5: Document Your Work (Activity 2 – Add a Comment – 10 mins)

Practice good coding hygiene!

Your Mission: Add at least one explanatory comment to an App Inventor project.

Task:

1. Open your main Technovation App Inventor project (or the fixed Timer App).
2. Find a section of blocks that does something important or might be confusing later.
3. Right-click on the main block of that section and select “Add Comment”.
4. Write a brief note explaining the purpose of those blocks.

Part 6: The Reality of Coding (Final Thoughts)

Remember these key things as you code:

• Bugs are normal. Every coder deals with them. Debugging is problem-solving!
• Code in small steps. Test frequently.
• Use version control (Save As, Checkpoint).
• Use comments.
• Use Notifier, Labels, and especially the Do It command to investigate.
• Take breaks! If you hit a wall, step away. A short break often clears your head. Kawumuleko! (Take a break!)
• Celebrate your successes, even small bug fixes!

Part 7: Quick Review (Key Terms)

• Debugging: Finding and fixing code errors.
• Version Control: Saving working copies (Save As, Checkpoint).
• Test data: Using simple data for initial testing.
• Comments: Notes in code for explanation.
• Notifier / Labels: Components for displaying debug info.
• Do It: App Inventor command to inspect/run blocks during live testing.

Part 8: More App Inventor Help

Need more resources? Check out:

• The App Inventor Community forum.
• The Version control video linked in the lesson.
• Other tutorials and tips mentioned (Karen’s tips, Live Development info).

Conclusion

Ogenda bulungi! (Go well!) You’ve now learned crucial techniques for debugging your App Inventor projects. Using these strategies – especially coding in small steps, testing often, and leveraging tools like the Notifier and Do It command – will make the process much smoother and less frustrating. Embrace debugging as part of the creative process! Mweraba! (Goodbye!)